Hola,

Los ejemplos vienen tambien con el proyecto ya echo. No te lo tienes que crear tu...

Luego es llamar al Makesis con el .PKG  y te crea el .SIS....

Saludos,
Sir Graham.

Hola,

Entiendo por "extraccion".... a un Inquiry de Bluetooth. Osea obtener los datos de los terminales con bluetooth cercanos.

La operacion bloqueante es un Inquiry.
Esto no quita que no puedas en un thread estar realizando otras. De echo para poder usar el Inquiry sin bloqueo es necesario o bien usar threads o en el caso de Linux implementarla en comandos simples de HCI.

Ahora bien, un scanner completo de Marketing de proximidad es algo mas que un Inquiry....  vamos bastante mas....
...y hasta aqui puedo leer ... como en el 1,2,3....

Saludos,
Sir Graham.

Hola,

Ya veo cual es el problema.
Para compilar un ejemplo, debes compilar "el proyecto completo", no SOLO uno de los modulos .cpp.

De echo en el proyecto ya estaran definidas las rutas para los includes de ese proyecto (con lo cual no necesitas configurarlo dentro del propio VC++ para todos los proyectos).

Cuando compilas una aplicacion para Symbian, a parte del ejecutable (que puede ser EXE o APP) es necesario una serie de ficheros mas. Para ello se crea un archivo de instalacion .SIS (que engloba todos los ficheros necesarios a parte del ejecutable).

Saludos,
Sir Graham.

Hola,

Una operadora no tiene problemas en ver el trafico ya que por ella, ese trafico pasa descifrado y plano. No necesita nada especial para hacerlo. No conozco
IUSACELL/Mexico y sus posibles practicas... pero lo tienen muy facil. 

A nivel de NO OPERADORA. Que yo sepa se puede:

- Ver y oir las redes analogicas y capturar el numero de telefono y ESN.
- En GSM/GPRS se puede capturar el IMSI (datos del canal de control numeros de telefono y demas) y descifrar el A5 (sin necesitar el KI) solo rompiendo el Kc.
(Que yo sepa no se obtiene el Ki en estos procesos)

Pero no conozco ningun producto (para uso oficial) que lo haga en 3G sin participacion de la operadora esto mismo.

Si alguien lo conoce, seria interesante de verlo. Aunque solo sea por curiosidad...

Saludos,
Sir Graham.

Hola,

El problema es que has cargado el header e32def.h sin la definicion del tipo TInt64. Prueba a cargar antes el header e32std.h.

Respecto a la firma. Es lo que hay. Si quieres seguridad para instalar aplicaciones sin troyanos (que no son virus), tienes ese incordio.
La solucion de Littlehorse es valida. Nosotros no la usamos por que luego queremos cercionarnos que le va ha funcionar al resto de usuarios.

 

Saludos,
Sir Graham.

Hola,

Si tienes razon. No me habia dado cuenta del tema de 3G.

No obstante, si es complicado en 2G, ni te cuento en 3G, primero por que los algorimos de encriptacion y autentificacion no son los mismos (A5 <> KASUMI), aunque algunas operadoras siguen usando la misma SIM no usan USIM.
Eso si puede ser un agujero de seguridad para 3G. 
En el caso de usar USIM, como comentaba, te enfrentas en vez del A5 al famoso KASUMI del que no tengo noticia que se lo hayan saltado.

Por otra parte como COMP128 me refiero al generico: independiente de la version V1, V2 o V3.  A la hora de Sniffar la señal no importa tanto la version del COM128 como a la hora de clonar (la gestion es diferente aunque tenga mucha relacion). En un caso necesitas el Ki completo y en otro solo parte del resultado (Kc).
Ademas (que yo sepa) el V3 no lo han implantado porque como comentaba en mi anterio email siguen faltando los ultimos 10 bits del Kc (clave de encriptacion).
Se supone que esa version era el cambio que tenia la V3. ¿?

Si las SIM son las mismas en todos los casos, (obiamente la seguridad parte de las mismas claves por necesidad).  Quizas este sea un punto interesante para atacar al tema...

Asi todo se necesitan cosas concretas. Un chipset de GSM no se pone en modo "promiscuo" tal cual...

Saludos,
Sir Graham.

Hola,

Para poder esniffar paquetes de GSM o es su defecto de GPRS (mas canales a la vez) el chipset de ese modem tendria que poder ponerse en modo monitor (algo parecido al modo promiscuo de las tarjetas Wi-fi).

Yo no conozco ningun chipset de GSM/GPRS que lo haga.

Por otra parte la resolucion de la clave pasa por el protocolo A3A8 (implementado en la SIM) Este genera la clave de encriptacion y autentificacion (contra el BTS) que luego es cifrada por el A5. Mirando esa autentificacion que se realiza con una funcion HASH llamada COMP128 ves una cosa curiosa.... y es que la clave de encriptacion solo tiene 54 bits. Deberia tener 64, pero los ultimos 10 bits SIEMPRE estan a 0. Nosotros pensamos que esto lo hacen para que organismos oficiales puedan realizar escuchas.

Lo unico que hemos visto que puede ser realmente eficaz, es usar un scanner con DSP que sea capaz de seguir el FH (frecuency Hopping de GSM) y pueda ademas realizar las operaciones mencionadas.

En este hilo de nuestro foro se comenta un poco mas ese tema:

http://www.endorasoft.es/foro/viewtopic.php?f=1&t=15

Espero que te sirva para ir acercandote mas al tema...

Saludos,
Sir Graham.

Hola,

Trato yo de contestar a tus dudas... ya que creo algo de experiencia tengo en el tema...
 


No. no hacen falta dos, pero con uno estas bastante mas limitado.



Nosotros empleamos threads multiples para el proceso general de envio y para cada envio en si. En el de busqueda tambien se emplean theads (en las distintas fases de busqueda) mas que nada para evitar ciertos procesos que son bloqueantes. Aunque esto depende mucho del stack de bluetooth y del SO que estes usando (nosotros lo tenemos para varias plataformas: Windows, Linux, Symbian, nuestra plataforma propia, etc...). Por ejemplo en el caso concreto de linux, lo tenemos tambien hecho en noblocking, con lo cual podriamos prescindir del ciertos threads.

No obstante, como diria Yoda: Los threads poderosos son, pero con ellos tener cuidado debes... mi padawan...

Manejar threads implica un control de datos exaustivo en cada momento, en este caso complica mucho el tema si no se hace "escrupulosamente" bien.



Por supuesto tienes que realizar una conexion, a cada terminal por su canal correspondiente (en este caso del del Obex Push) y enviar la informacion segun el protocolo de Obex.  Lo de los canales se "sobreentiende" por que si no no tendria ningun sentido usar el SDP en la busqueda. Con un simple inquiry tendriamos suficiente.

No obstante, (por si se te ha pasado por la cabeza) el uso de aplicaciones externas para el envio (como es el caso del BluezSpammer) es incompatible con el uso de threads en concurrencia (si ya de por si es complicado usar threads sin mas, usando con una ejecucion externa de una aplicacion puede pasar cualquier cosa). Asi que lo mas prudente es implementarse el protocolo OBEX y realizar la conexion directamente...

Por otra parte no esperes ("ni de coña") poder llegar a las 7 conexiones simultaneas. En un envio de ficheros el ancho de banda disponible del bluetooth no te da aunque sea Bluetooth 2.0.  Todos los que en Marketing de proximidad calculan las conexiones concurrentes segun la formula:

El numero de modulos bluetooth disponibles x 7 = numero conexiones concurrentes que pueden hacer.

 ... te mienten DESCARADAMENTE!!!!. 



Como comentario final: una herramienta de estas (marketing de proximidad) parece sencilla al principio...
...pero segun vas mentiendote en el tema ... se torna MUUUCCHOOO mas complicada de lo que parecia.

 

Saludos,
Sir Graham.

Hola Gospel,

Andas por esas tierras de Dios... o has vuelto a casa por navidad (como el turron)?

Ya me contaras que tal te va....

Saludos,
Sir Graham.

Hola,

Eso ha sido los chicos de Chaos quien lo ha publicado.

No obstante, independientemente de eso, Symbian tiene muchos fallos y errores. Nosotros hemos detectado varios en el stack de Bluetooth, y la contestacion por parte de esta gente es si... ya los conocemos.... pero vamos hacer lo mismo que si no los conocieramos....

De echo muchos de ellos una vez enviados a Symbian en sucesivas versiones no se han corregido....

En fin... Es lo que hay...

Saludos,
Sir Graham.