After some days the hackaton work comes functional and these are the results:
brainstorm provide few patches for fixing the build and install of the ruby bindings adding a test suite for the API. This seems to be a long process, so dont expect to have this done for 1.1. My main additions was for the virtual machine and the variable support. Now are both basically implemented and semi documented :D I have ported radare to the ch3s NAS arm5, and this will be the main development platform for ARM for further releases instead of my n810. SO i have now a full linux with gcc on arm 500mhz. To fix the virtual address vs physical address problem I have added two new variables (io.vaddr and io.paddr) that are used to define these values manually and fix the disassembly output and the seeking access. This makes the engine a bit more complex and I will refactor a bit libr_io to support it too for 1.2. But now the support for PE on ARM is one of the next targets :) (thanks esteve!) Now it is possible to define new opcodes to the virtual machine, these ones are used to act as a wrapper layer for the architecture dependent features. For example, in intel: a call is defined with this command: "avo call = esp=esp-4,[esp]=eip+$$$,eip=$1 For ARM will be: "avo call = lr=pc,pc=$1 As before the registers can be defined and dependencies between them can be also defined as register aliases that wrap the 'get' and 'set' actions over them: "avra al al=eax&0xff al=al&0xff,eax=eax>16,eax=eax<16,eax=eax|al The access to memory from the virtual machine can be cached to avoid real memory writes that will corrupt the memory and probably make the underlaying application crash. Expect some better code analysisi facilities for 1.2 using this virtual machine engine. Actually it works, but needs some more testing and needs to be moved into libr. To execute real code in the virtual machine (emulate real code) can be done with the 'avx' command that emulates N opcodes (avx 10) and each opcode can be of different types: [0x4A13B8C0]> avrt .bit .int64 .int32 .int16 .int8 .float32 .float64 ---- The other really nice feature is the variable support which is now complete :) but needs more work on the architecture-dependent layer.. now automatically is only supported x86. The variable support gives the possibility to register variables, and variable accesses per function. This step can be automatically done with the '.af*' command (or recursively with '.aF'. We can define variable types (like in C with typedef) with the Cv command: [0x4A13B8C0]> Cv? Usage: Cv [name] [size] [pm-format-string] Cv int 4 d ; define 'int' type Cv- int ; remove 'int' var type Cv float 4 f [0x4A13B8C0]> Cv float 4 f dword 4 x int32 4 d int 4 d byte 1 b char 1 b These are the default ones. On top of this you can assign a stackframe offset for a function located at a certain point and then a get/set list of offsets. Arrays are supported and also structures and all the basic types supported by the 'pm' command (print memory format) This give us the nice feature to automatically identify local variables in a function and show the values while debugging :) This is done with the CFV command. To manually define variable accesses you can use the CFa, CFA and CFv commands that stands for CodeFunctionArgument, FastArgument(register) and Variable (local in function stackframe). [0x4A13B8C0]> CFv? Try CF[aAv][gs] [delta] CFag 0 = arg0 get CFvs 12 = var12 set a = arg, A = fastarg, v = var --- Nibble has been working on radiff, adding an advanced bindiff method that shows disassemblies instead of hexdumps while disassembling a program. This is done in perl and using rabin with radare. The multi-arch support is seamless. Thanks for reading :) --pancake _______________________________________________ radare mailing list [email protected] http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
