Foro de elhacker.net

Buenas,

Llevo unos cuantos días intentando sacar el formato de un fichero de datos binario y después de muchas horas con editores hexadecimales estoy un poco cansado...

La cosa es que tengo varios dumps, de los cuales conozco su estructura de sectores y bloques :silbar:.
Aun así no conozco el formato de los valores almacenados en estos y me estaba planteando hacer un script en python para buscar ints, floats, caracteres, timestamps etc. tanto en big endian como ittle endian, pero estoy segurisimo que ya hay algo hecho.

Como ya os he dicho, tengo varios dumps, los cuales he comparado también con kdiff3 para sacar los datos que se están modificando e ir juntando piezas. La idea es ir haciendo dumps e ir comparando los cambios.

¿En los casos en los que tenéis varios dumps de momentos diferentes, vosotros que camino seguís? Puede que exista alguna herramienta especifica para todo estoy que estoy pidiendo, pero de momento estoy tirando de diff, xxd, bless, 010editor y se me acaban las ideas para automatizar y agilizar un poco el proceso...

Saludos y Gracias.

Cómo generaste los ficheros de datos binarios? Si tienes el programa que los genera en base a una serie de datos o configuraciones, etc. ¿No es mejor apuntar a analizar el binario y ver como genera los archivos?

Si tu máquina A genera muchas salidas: B,C,...,Z tienes tanto la máquina A como sus salidas, por qué revisar las salidas si puedes revisar la composición de la máquina?

Si los archivos tienen igual longitud, puedes probar hacer diff con hex workshop. La comparación binaria se le da bastante bien y detecta "corrimientos" en los datos.

Ahora, sidispones del binario que genera los archivos, lo ideal es analizar el mismo (como dijo .:UND3R:. )

Saludos!

Hola,

Ojala tuviera el binario que genera estos ficheros pero no es así... Me voy a mirar lo de hexworkshop.

La idea del script python era pasarle un valor, tipo y fichero dump y realizar una búsqueda binaria corriendo bit a bit y comparando tanto little endian como big endian.

Lo de comprar dos dumps diferentes los cuales supuestamente conozco cuanto ha cambiado el valor, me sirve más que nada para suponer la longitud en bytes de lo modificado, pero es pura especulación.

Gracias.

¿Qué sistema operativo?
¿Qué tipo de protección tiene los programas que hizo volcado?
¿Para qué son las informaciones? keygen? crack?

Esta información es útil para que podamos apoyarte

Básicamente son dumps de un sistema muy conocido NFC... el cual tiene 16 sectores con 4 bloques por sector y cada bloque tiene 16 bytes ...  :silbar:

Edit: Si quereis paso el diff de 2 dumps que tengo.

Buenas,

Aún no he conseguido nada, subo la comparación de los dumps a ver si se os ocurre algo,
los datos están alineados, son lineas de 16 bytes.

Esto es el antes...

< 0e a6 22 00 00 88 0e ca 36 c9 76 64 54 e2 64 eb  ..".....6.vdT.d.
< 0e a6 22 00 00 88 0e ca 36 c9 76 64 54 e2 64 eb  ..".....6.vdT.d.
                                                         
< 04 40 35 a2 12 07 0a 04 1e 60 b3 64 40 56 1d 3f  .@5......`.d@V.?
< 04 40 35 a2 12 07 0a 04 1e 60 b3 64 40 56 1d 3f  .@5......`.d@V.?
                                                         
< 18 39 80 40 20 80 b2 4d f3 1d 59 50 44 3a 9a 66  .9.@ ..M..YPD:.f
< 19 19 80 40 20 52 b2 4d a7 1d 99 0f 44 3a ce 53  ...@ R.M....D:.S
< 18 39 80 40 20 50 b2 4d a5 1d 19 65 44 fb 40 db  .9.@ P.M...eD.@.
                                                         
< 19 19 80 40 20 82 b2 4d b2 1d d9 0e 44 fb 80 b6  ...@ ..M....D...


Y el después...

> 02 a6 22 00 00 08 0d ca 36 c9 76 64 54 e3 84 f4  ..".....6.vdT...
> 02 a6 22 00 00 08 0d ca 36 c9 76 64 54 e3 84 f4  ..".....6.vdT...
                                                         
> 04 40 35 a2 1a 07 0a 04 1a 60 b3 64 40 56 1d 30  .@5......`.d@V.0
> 04 40 35 a2 1a 07 0a 04 1a 60 b3 64 40 56 1d 30  .@5......`.d@V.0
                                                         
> 18 39 80 40 20 80 b2 4d f3 1d 59 50 54 22 9e 1e  .9.@ ..M..YPT"..
> 19 19 80 40 20 52 b2 4d a7 1d 19 0f 54 22 da 65  ...@ R.M....T".e
> 18 39 80 40 20 50 b2 4d a5 1d d9 d0 54 e3 40 39  .9.@ P.M....T.@9
                                                         
> 19 19 80 40 20 82 b2 4d b2 1d 99 0e 54 e3 84 2d  ...@ ..M....T..-



Saludos

hacking de telefonos y temas de comparar valores, siempre son de pagos para las compañias que las hacen, no creo que esté asociada a la ingenieria inversa, sino mas bien usar herramientas específicas para cada teléfono en sí...

por otro lado hagamos algo similar para entender

digamos que tienes 2 archivos iguales, idénticos, pero que tienen diferente fecha, confirmaras en un exe/otros  que la diferencia son algunos punteros, hasta ahi no hay drama puede que sea 1 cambio o 10,

digamos que tienes 2 archivos iguales en 2 sistemas operativos iguales y has compreso todo en una raw,  3 millones de  cambios

digamos que tienes 2 archivos iguales compresos con 2 algoritmos distintos (.zip .rar) y estos compresos en 7z y eso quieres comparar (los archivos 7z)
de seguro estarás intentando comparar porque el archivo es el mismo... pero en su interior contienen diferente informacion y compresion, de seguro los punteros a direcciones son diferentes,datos información  ... de seguro seria dieferente si usas un visor de 7zip

 
pregunta, si es el mismo archivo, como diferenciarás esas diferencias de los bloques? entendiendo el compresor no creo, comprendiendo el algoritmo tampoco,deberás comprender el hardware que en teoria refieres NFC que es para crear compatibilidad en dispositivos, osea nanotecnología,  es el resultado de como funciona con esos cambios:.. osea deberias tener un visor específico para ello y no un simple editor hexadecimal

para tu caso puntual, el visor de raw  sobre un dato hexadecimal, debería estar documentado cuando  está estudiado, en los exes, hay cabezeras PE/MZ  

cuando se quiere analizar un sistema operativo se suele utilizar técnicas de forense, y puedes usar volatily entre otros, pero se conoce el sistema que usas (fat/ntfs etc)

Para mi los cambios pueden ser diferentes punteros o direcciones a diferentes informaciones en tu programa

para otros esos cambios pueden ser cambios de fecha o inclusive cambio en alguna firma/clave pgp etc

las posibilidades son infinitas, no creo que analizando dumps alineados logres algo si no trabajas en el mismo idioma que tenga el formato de tu telefono,de seguro trabajan con lenguaje arm  o pics o quien sabe


Saludos Apuromafo

pd: yo creo que no llegaras muy lejos analizando 2 hexadecimales sin saber como funcionan de por si.


imaginate el caso que como buen usuario tengo el codigo de fuente de un programa, compilo el mismo programa pero distinta imagen, tendré punteros distintos, version distinta, pero funcionalidad es la misma, osea insisto, en temas hexadecimales habrán muchisimos cambios que si no se estudia los recursos de la misma, no veré nunca mas que cientos o miles de datos cambiados..

El tema es que los datos guardados en mis dumps son puramente información, de hecho el dump completo ocupa 1024 bytes, esos bytes se dividen en 16 sectores y cada sector se compone de de 4 bloques quedando 16 bytes por bloque teniendo en cuanta que el ultimo bloque de cada sector esta ocupado por metadatos. De hecho quitando los sectores de metadatos y el bloque 0 que contiene el ID nos queda tal que así [ 3*(1024/4)-16 ] por lo tanto tampoco son muchos bytes de los que disponemos quedando los dumps muy pequeños.

Con esta información reducimos mucho la información que se puede guardar en el dump y realmente en el dump completo hay muchos bloques vacíos, por lo tanto no creo que les haga falta comprimir la información que insertan en ellos.

De todos estos bytes, al comparar diferentes dumps, los bytes que cambian son relativamente pocos, por lo que creo que la información guardada esta en raw y no existe compresión.

También hay bloques como podéis ver que la información esta repetida 2 veces exactamente igual, y otros bloques los cuales los primeros bytes son idénticos o siguen patrones posiblemente sean IDs y lo que varia timestamps.

Básicamente lo que creo es que cada linea de 16 bytes pertenece a una "struct" que la serializan y la copian directamente.

La clave aquí, es ir byte a byte e ir descifrando para formar algo con sentido, pero yo no tengo el ojo puesto mucho en estos temas y donde alomejor una persona ve un timestamp en hexadecimal yo veo 3 valores random que no sé si son enteros, de coma flotante o vete a saber... y por eso creo que la clave esta en ir comparando los cambios que se realizan byte a byte y ver si suben, si bajan, si cambian totalmente, cuantos adyacentes se modifican, si se modifican siempre...


Saludos.

Buenas de momento ya he localizado un timestamp el cual esta 3 años desplazado.
Aún así, la diferencia de dias entre varios dumps me coincide, los bytes que lo representan son los últimos 4 de la primera linea: 54 e2 64 eb


Saludos.