[QUOTE=SergioCalero;4923918]¿Novedades? Veo todo muy atascado. Hay un grupo de franceses dándole caña.

Se filtraron las imágenes .sdx de los firmwares 9.8.4 y 9.7.5, son los últimos más estables.

App que usan los técnicos para flashear panel y elementos:

[url]https://drive.google.com/file/d/1xKWsbG_1xXf5MLK0QQmc1gj6DL1Z3Ue1/view?pli=1[/url][/QUOTE]

Y va a seguir todo atascado, o al menos por un rato...

Te cuento lo que he podido sacar:

Los sdx que vienen dentro de la apk no dan rastro de absolutamente NADA (ni rastro de arquitectura, instrucciones o datos legibles a primera pasada, ni strings, ni fotos, nada...). Por tanto y entiendo hasta donde llega mi conocimiento, que dichos archivos siguen un formato propietario.

En cuanto a la apk poco o nada se puede hacer, puedes pasear por el código pero es bastante engorroso, esta ofuscada. (De igual manera, dudo que sea útil POR AHORA salvo que en ella se guarde como tratar el firmware) reconozco no me he metido a fondo, pero si es verdad que hay métodos de encapsulamiento para la subida del archivo a la consola central, mantengo en que A PRIMERA VISTA no parece algo relevante, simplemente fragmentación del archivo para la subida.

Para seguir...

Se necesita de alguien que tenga cierta experiencia y bastante manejo en ingeniería inversa para volcar esos sdx en un emulador tipo QEMU, partiendo de que sabemos que se trata de un LPC2368FBD100, y que por tanto, estamos en ARM7, pero me repito, primero necesitamos saber como la consola trata el firmware al recibirlo lo que me parece totalmente inviable, por tanto, la opción más corta (y viable) sería tirando del datasheet del procesador y hacer un dump del firmware extraído de la memoria en caliente, pues aquí ya sería casi con total seguridad interpretable.

Lo primero es lo primero, y lo cierto es:

Con InstVerifast, la aplicación que veo usan los franceses en el hilo, se puede desviar las peticiones de la alarma de los servidores de Securitas a unos propios, algo que yo ya he conseguido, llegado aquí: Cuál es mi problema? No se como interpretar los mensajes de la alarma, quiero decir, obviamente puedo relacionarlos según las acciones que yo haga y los mensajes que reciba, a lo burro y simplificado:

Si desconecto la alarma de la corriente y envía a los servidores 3839 cada vez que la desconecto, sé que 3839 significa perdida de conexión eléctrica.

(Resaltar que con casi total seguridad estos códigos no son fijos, es decir, cambian por cada alarma)

Pero lo cierto es que la alarma necesita un "feedback", concretamente un ACK, por parte del servidor el cual NO le puedo dar puesto que desconozco totalmente el protocolo de comunicación entre Alarma-Servidores de Securitas.

Lo interesante sería juntarnos bastantes e indagar, me he leído entero el hilo y ya puedo ver que hace tiempo ya tenían los SMS (que forman parte del protocolo de comunicación) en los que, en este caso, los servidores de Securitas comunicaban a la alarma lo que tenía que hacer o necesitaban, ejem.: Estado de alarma, Arma la alarma, Desarma la alarma, Foto, etc... Aún así, sigue siendo insuficiente puesto que si comparas cada aporte verás que los SMS tenían diferentes comandos (no siguen un patrón en su totalidad).

Por ahora, esto es todo lo que puedo aportar, puedes hacer la alarma funcional? Sí, parcialmente: solo recibir notificaciones del estado sin poder darle una respuesta, nada de fotos, armar o desarmar remotamente, etc. Para continuar, estaría bien ver conversaciones COMPLETAS de alarmas en producción, algo que yo no puedo puesto que no tengo la alarma en alta.

Saludos.