Hola,

Que yo sepa, Blackberry no tiene codigo nativo. Solo Java. Ademas es un Java J2ME con extensiones especiales (por ejemplo para bluetooth).

El problema de Java no solo es la velocidad (que para diccionario puede ser suficiente). El mayor problema es el acceso a hardware que puede tener. Todo esta abstraido de la maquina virtual y en general suele ser limitado.

Si eso le unes el tema de que el movil por compatibilidad suele restringir el acceso al layer de HAL... pues "complicao" lo veo...

Yo la ventaja que le veo a Android es que si logras eliminar la parte del codigo de Bionik de su libreria estatica, podriamos "portar" el codigo de Aircrak sin muchos problemas. En definitiva no deja de ser un Debian con "algunos retoques"...

Saludos,
Sir Graham.

Hola,

No me parece algo descabellado. La verdad es que nosotros estuvimos pensando algo parecido.

El problema es empezar con alguna plataforma.

Por supuesto por velocidad y accesibilidad se descartan las que no puedan realizarse en codigo nativo. Desde Java (J2ME) no es factible realizar una operativa de este tipo. Asi que todos los telefonos con sistemas operativos propietarios (que solo admiten aplicaciones java se descartan).

Symbian se descarta desde el primer momento. Aunque programes en lenguaje nativo (C++) no es factible acceder al WiFi a un nivel bajo. Ya empezando por eso olvidamos el tema de poner el chiset en modo promiscuo.

De igual forma lo descartamos con Windows Mobile. De Windows solo tiene el nombre. La mayoria de las funciones son totalmente particulares e independientes de plataforma. Veo dificil realizar una gestion de este tipo.

El iphone no lo conocemos bien. No se que tanto se puede llegar hacer con el effective C (el lenguaje nativo para el System X). Lo dejo como duda.

La unica plataforma en que yo veo posibilidades reales de hacerlo es Android. A priori solo ejecuta aplicaciones de Java, pero existen dos caminos para poder programar en C/C++. Uno el NDK, y otro usar el compilador cruzado incluido en el ToolChain. Ambos caminos los hemos probado con exito. Las aplicaciones funcionan a maxima potencia (unas 100 veces mas rapido que en Java) y tienes acceso a toda la funcionalidad de "pseudo-Debian" del cual partieron para hacer Android. Hay que por supuesto, obtener el nivel de Root, cosa que bien saben los usuarios de Android (no es muy dificil). Los android llevan un micro de 500Mhz a 1Ghz, lo cual ya no es tan despreciable para hacer cosas...
Queda por probar si el chipset de Wifi admite el modo promiscuo...

Saludos,
Sir Graham.

Hola,

Intento contestar a tu pregunta, sin que ello me lleve a revelar informacion confidencial.  (Si ves carencias en la contestacion, es por que no puedo dar mas detalles)

Hay dos partes en la base datos:

* Una la base datos en si, que es una lista de telefonos moviles disponibles en el mercado (con todas las caracteristicas que has podido ver en este screeshot):

http://www.xblue.es/screenshots/XBlue_IDDB.jpg
(esta es una aplicacion de uso interno)

* Y otra parte es la asociacion de uno o varios identificadores a cada modelo de terminal para que el motor heuristico de reconocimiento los detecte.
(Parte que tambien se gestiona desde la aplicacion interna, pero por motivos obvios no se muestra en ese pantallazo).

Ambas deben estar permanentemente actualizadas. Eso lo hacemos de forma automatica Y GRATUITA para TODOS los usuarios del sistema XBlue (en cualquiera de sus modalidades: Lite, Basic o Pro).

¿Como se hace la actualizacion?
Para la primera parte tenemos acuerdos con gente que esta constantemente actualiza diferentes bases de datos de moviles. Son varios proveedores para evitar carencias por "localizacion" del proveedor o por simplemente por errores en sus bases de datos (Nosotros aunamos todos los resultamos y podemos asi detectar y correguir errores de caracteristicas, nombres, etc...)



Para la segunda parte, el sistema tiene una gestion de aprendizaje en a datos obtenidos en los scanners de bluetooth y reglas adquiridas "a parte" (no puedo comentar mas). Simplemente decir que esta logrado el tema dado que por lo que hemos podido comprobar la curva de aprendizaje de esta gestion es logaritmica. Los fallos van reduciendose escalonadamente hasta eliminarlos.
De echo es una de la partes en la que nos sentimos mas orgullosos. Hemos hecho pruebas comparativas con otras herramientas y estamos a bastante distancia en cuanto a resultados.

Procuramos que eso no pase teniendo muy actualizada nuestra base de datos    pero obviamente puede ocurrir...
No obstante, al ser un proceso heuristico, es muy dificil que obtengamos una solucion completamente "nula" a la identificacion: el peor de los casos sera parcial o aproximada. Ademas para esos casos tenemos "grados" de fiabilidad en la deteccion, pudiendo actuar en consecuencia. Esto es: A parte de darnos la informacion de la marca y modelo, internamente, tenemos una informacion en grados sobre la fiabilidad de esta deteccion.

Como veras... no es una cosa de hacerla en un par de dias, o meses. Es un proceso que lo venimos elaborando desde hace "años"...

Saludos,
Sir Graham.

Hola,

En el FTP de endorasoft: endorasoft.es en la carpeta \Bluetooth\Bluetooth Java Hack Apps tienes una recopilacion de estas aplicaciones.

 

La mayoria son Java, por lo que el riesgo potencial para el terminal donde se instale es minimo: desde java no puedes realizar practicamente ninguna accion fuera de los limites establecidos por la java machine: para bien para mal.

 

Saludos,
Sir Graham.

Hola,

En nuestro caso, es mas elaborado que eso. Date cuenta que muchos modelos cuenta con los mismos perfiles de bluetooth "exactamente". Con lo cual, ni con tecnicas de MAC, ni los perfiles de SDP son suficientes para esa gestion.

A parte la deteccion se realiza de forma automatica sin alterar la seguridad de bluetooth en ningun momento. No se pide PIN, ni confirmacion para la deteccion.
(No se accede a perfiles de modem ni cosas parecidas para mandar comandos).

¿Como se hace?

Con mucho "cuidadin"   y unos algoritmos heuristicos que nos han llevado mucho tiempo elaborarlos.

No puedo comentar mucho mas aqui, dado que esa es una pieza competitiva muy importante dentro del XBlue. Por supuesto al ser un metodo heuristico tiene un indice de fallo, pero lo hemos conseguido reducir a un 5%-6% con lo cual es a nivel practico mas que suficiente.

El saber marca y modelo del telefono remoto nos permite realizar multiples operaciones con los contenidos antes de ser enviados, permitiendo opciones mucho mas amplias para nuestro herramienta de marketing de proximidad. De echo, Lo consideramos una de las claves para diferenciarnos del resto. Por eso hemos invertido tanto tiempo y lo hemos "afinado tan bien".

Antes ya nos han preguntado por esta cuestion aqui y en nuestro foro de Endora:

http://foro.elhacker.net/hacking_mobile/marca_y_modelo_de_los_telefonos_celulares_por_medio_de_la_mac_del_dispositivo-t286536.0.html;msg1417458


Proximamente vamos a sacar una version para Symbian del XBlue Point Mobile (de forma gratuita), que cuenta con esa caracteristica y la nueva base de datos de Identificacion. Solo con eso, ya resulta muy interesante enceder tu movil y saber que tipos de moviles hay a tu alrededor...

http://www.xblue.es/xblue_point_mobile.html


Saludos,
Sir Graham.

Hola,

No estoy totalmente puesto de como hacen "exactamente" esas aplicaciones las operaciones. Pero si te puedo marcar unas pautas.


El programa se llama ObexFTP pero tengo entendido que tiene los dos protocolos (Obex FTP y Obex Push) que son diferentes. No solo tienes que saber el canal del perfil mediante el SDP, tambien tienes que usar el protocolo correcto. Salvando las diferencias, entiende al canal como si fuera un "puerto de TCP/IP" y el procotolo como si fuera "ftp", "http", "pop3", etc...

Tu puedes usar cualquier protocolo de estos en cualquier puerto, siempre y cuando el receptor y el emisor esten "de acuerdo". Para ello existe el SDP que permite saber como esta para un receptor todos los perfiles con su informacion.

En Bluetooth puedes saber ademas del canal, el tipo de servicio (el tipo de protocolo a usar) para un perfil concreto.

¿Con  esto que quiero decir? que no envies usando el protocolo Obex FTP sobre un perfil de bluetooth que sea Obex Push y viceversa.


Es cierto que tienes la posibilidad de abrir varios perfiles de bluetooth desde un origen a distintos dispositivos remotos. Pero esto depende tambien del ancho de banda. No es infinito y normalmente con una gestion  de Obex Push no llegas a poder abrir mas de 4 o 5 (a poco que envies algo de informacion).

Para ello tendrias (no se si puedes) volver a abrir la aplicacion para otro dispositivo bluetooth y con su canal de el perfil obex push.

Nosotros no hacemos esa operacion con una aplicacion externa. Hemos implementado varios protocolos (entre ellos el obex push) y se lanza un thread (aproximadamente) por cada conexion que se quiere abrir desde el emisor....

Saludos,
Sir Graham.

Hola,

Todo lo contrario. Es muy util para el operador que el numero de telefono solo este en el HLR (su base de datos). El numero esta asociado a una SIM (de la que se conoce el ICCID, IMSI y ki... aparte de los PINS y PUKS).

Date cuenta que por perdida o robo, es facil sustituir la SIM.

Simplemente cojes una nueva (con su propio  ICCID, IMSI y ki) llamas al operador (un distribuidor de una tienda en este caso) y le das el ICCID de la SIM (el numero que tiene detras) para un numero de telefono de un abonado concreto. El va y sustituye el IMSI y Ki de esa SIM (a traves del ICCID) para ese numero en su base de datos (HLR).

Con una sola operacion te ha activado la nueva tarjeta con ese numero y ha desactivado  la SIM anterior que deja de estar operativa...

Eso es lo que los distribuidores malamente llaman "duplicacion". Que es mas bien "sustitucion"....

Hola,

Nosotros tenemos tambien esos mismos estados, pero los llamamos de otra forma:

Envios
No confirmados
Fuera de tiempo
Fuera de cobertura

Como veras nosotros NO HEMOS QUITADO ese ultimo dato.
Lo que hacemos es tratar de evitar que esa situacion se de lo mas posible.

Saludos,
Sir Graham.

Hola,

Pedazo mensaje.

Te lo resumo brevemente mi respuesta.

Hay dos niveles basicos de proteccion en Bluetooth. Con confirmacion (solo pregunta) y con peticion de pin (autentificacion) + Confirmacion.

Dependiendo de como se creen los perfiles, se les puede adjudicar un nivel u otro.

"Tradicionalmente" y "en la mayoria de los terminales telefonicos" el perfil OBEX PUSH solo tiene nivel de confirmacion y el OBEX FTP lo tiene de autentificacion.
Por lo que eso te cuadrara con las pruebas que has echo.

Ahora bien... en tu caso es mas sencillo el tema. Siempre son los mismos moviles a los que envias el mensaje. Pueden autentificarse la primera vez (esa validacion queda en el telefono) y ya no habria problema para realizar todo tipo de operaciones con el terminal desde bluetooth.
 

Saludos,
Sir Graham.

Hola,

Entiendo que esas referencias que mencionas las habeis definido vosotros, para que pueda contestarte, puedes definir esos estados "con mas detalle".

¿Que quieres decir con ...

un envió (es mas obvio)
el recibido (¿Que diferencia hay con el envio?)
el rechazado (entendemos que no ha cumplido la confirmacion de Obex)
el omitido (¿?)
el no alcanzado (¿?).

... es por concretar mas el tema...

Saludos,
Sir Graham.