As I said in my previous mail. Here's the bindiff implementation for radare ;)
This is actually an initial implementation. The current base is:
- An IDA plugin to dump an IDB to RDB (radare database) format
- An API to:
- load/save RDB databases
- find differences between program_t and block_t (full programs and blocks)
The algorithm is really simple at the moment and it does not yet correctly
handles xrefs, and this is so important for getting better results, but it's
just the base. O:)
I plan to extend the RDB api to make't able to automatically generate an RDB
file from a raw binary analyzing code like IDA does providing a nice api easily
interfaceable with Vala to provide an easy-to-use object oriented api for
binary analyzing, so this way we will not depend on IDA ;)
The current engine is far more fast than the sabre one (ok, it doesn't does the
same), but the engine is pure C/Vala instead of Java+IDA. This results on a
<0.1s to load two databases of 400K binaries (tcpis.sys) and diffing them.
If time is a problem in the future the api is quite thread-safe, so throwing
each separate load to a different cpu and syncing them will be easy.
The rdbdiff tool help says:
[EMAIL PROTECTED]/prg/pvcroot/radare/rdbdiff$ ./rdbdiff -h
Usage: rdbdiff [-hV] [-i fmt] [-o fmt] [file_0] [file_1]
-i [format] input format (idb, rdb (default))
-o [format] change output format (gml, html, txt (default))
-h shows this help
-V print version information
environment:
ARCH set architecture (arm, java, x86 (default))
But currently it ignores most of the flags O:) only rdb and txt output formats
are supported.
About the graphing mental jerking stuff I have been working in the VAPI file for
diacanvas (diacanvas.sf.net) library that provides a ValaGtk widget to draw
diagrams.
It's not a graphing library and it's not yet stable, but it gives me a gtk
widget
which I can easily embed on the vala-gradare frontend to draw graphs of data
structures, code blocks and blockdiffs, so the final idea is to have a
click-friendly
frontend for bindiffing binaries with cool graphs.
The diffing algorithm is described in rdbdiff/rdbdiff.c and it is something
like:
- load each rdb in memory
- calculate a checksum for each code block
- ignore blocks with the same checksum
- find blocks with same label and different data
- diff them
- control stackframe size changes
- control byte-level differences
- needs udis() call to generate disassembly
- mark them as processed
- detect new code blocks
When properly handling xrefs we can track code block references until a root
label
to better identify code changes and origins.
I would like to discuss these tips with you to define a better code block
diffing
algorithm. What do you think about these steps? which ones will you add?
A current sample output is:
[EMAIL PROTECTED]/prg/pvcroot/radare/rdbdiff$ time ./rdbdiff tcpip.1.txt
tcpip.2.txt
tcpip.1.txt entrypoint = 0x00096bef
tcpip.2.txt entrypoint = 0x00061416
checksum 00000044
checksum 00000044
ignored by checksum: [EMAIL PROTECTED]
ignored by checksum: [EMAIL PROTECTED]
ignored by checksum: sub_983FA
Ignored blocks by checksum: 3 / (20, 20)
Function '[EMAIL PROTECTED]' differs (address = 0x00062d6a)
stackframe differs: 8 vs 4
n_bytes differs: 64 vs 47
Function '[EMAIL PROTECTED]' differs (address = 0x00062d2b)
7 4c vs 0c 8 22 vs fc 9 06 vs 04 15 50 vs 10 16 b7 vs 8b
17 08 vs 05 22 14 vs 94 23 e2 vs f1 24 05 vs 04 29 70 vs 58
32 4c vs 0c 33 22 vs fc 34 06 vs 04
Function '[EMAIL PROTECTED]' differs (address = 0x00062d59)
stackframe differs: 8 vs 4
n_bytes differs: 56 vs 12
Function '[EMAIL PROTECTED]' differs (address = 0x000622c7)
27 74 vs fc 28 e0 vs ef 29 05 vs 04 33 70 vs f8 ...
Function '[EMAIL PROTECTED]' differs (address = 0x000621bd)
n_bytes differs: 263 vs 261
....
Found 15/(20,20) blocks with same name and different checksum
Missing 2 blocks to analyze
tcpip.1.txt block 0x000982f3 not processed
tcpip.1.txt block 0x000982c5 not processed
tcpip.1.txt block 0x00098022 not processed
tcpip.1.txt block 0x00062c84 not processed
tcpip.1.txt block 0x000627bf not processed
Have fun!
--pancake
_______________________________________________
radare mailing list
[email protected]
https://lists.nopcode.org/mailman/listinfo/radare
