Mensajes

Hola hola

Estoy programando en ASM y me he encontrado con un pequeño problema que no he sabido como arreglar.
Supongamos que declaro un buffer:

Código (asm) [Seleccionar] Expandir

Nombre rb 100
y al usar una API, ese buffer se llena pero no del todo. ¿Hay algún modo de "pasar" esa parte llenada a una variable directamente?

[eax]

AND Destino, Dato

Imaginemos que tenemos guardado en eax el valor 101011 y en ebx el valor 011101. Tras hacer "and eax, ebx" nos quedaría guardado en eax el valor  001001.

Sacado del Tutorial de ASM de E0N
Es decir que "and eax, 1" aplica el operador AND a eax y 1 y guarda el resultado en eax.

El problema está en que mi USB no es reconocido por el Stack de Windows, he tenido que instalar BlueSoleil
Informaré sobre mis avanzes si tengo éxito

[hcidump]

En Windows y mas con un Stack "que no es de Microsoft" (el Bluesoleil) ahora mismo no se decirte si tienes Hooks. Yo en principio lo dudo, a no ser que esten al nivel de WinSock.

No me refiero a hooks propios del Stack sino hacer un hook a parte, como hookear cualquier API del S.O.

En Linux tienes un dumpeador de las operaciones que hace el BlueZ. Quizas es mejor que te pases a ese S.O. para este menester.

Si te refieres al hcidump, mi intención es llegar a niveles mas bajos de dumping

La idea es instalar la Pila Bluetooth de "BlueSoleil" (en Windows) y conectar el ordenador al móvil. Por otra parte, hookear las APIs necesarias para la conexión... así veriamos todo el tráfico que sale y/o entra del/al ordenador (incluido los valores necesarios para la creación de la K_ab )

¿Es posible hacer esto? Quiero que alguien comente algo antes de probarlo

Tienes razón, me confundí al leer tu post
He pensado en una variante del ataque que comentaste de la suplantación de la BD_ADDR y del Car Whisperer. Cuando tenga tiempo te la comento

Asi que el incremento exponencial del tiempo entre un intento y otro no existe.

el dominio de combinaciones de la clave es altisimo

¿A que clave te refieres? ¿Al PIN para conectarse a un dispositivo?
Si es así, un simple PIN de 4 digitos es facilmente crackeable en cuestión de segundos (10.000 combinaciones posibles).

Podria analizar los diferentes resultados aunque necestaria muchos datos, mucho esfuerzo y algo de suerte. Por ahora me quedo en la teoría de las ideas que me vienen a la mente y ya las implantaré
Sólo una cosa: entre un intento de autenticación y otro, el tiempo de espera aumenta exponenecialmente para evitar ataques replay (espero que me entiendas ). ¿El tiempo de espera es para todos los dispositivos? Es decir, el M1 intenta conectarse al M2, y fallan... bien, pues M1 tiene que esperar cierto tiempo para intentar conectarse otra vez con M2. ¿Pero si al fallar el M1 intento un M3 conectarse al M2, tambien debe esperar cierto tiempo (a causa del fallo del M1)?

Espero que no haberte mareado mucho

Asi que habria que desamblar, mmm...
Se me ocurren otras formas de conocer cómo se genera el IN_RAND...
No se a que te refieres con lo del RISK, explicate

Hola SirGraham. Como siempre tan explicativo

Como bien dices, la IN_RAND se basa en el clock-offset del dispositivo... así que depende del timestamp.
Lo que me interesa por ahora es conocer cómo los módulos bluetooth generan el IN_RAND. ¿Hay alguna forma de llegar a esa información?

Saludos maestro