i was using radare for some reverse engineering together with IDA as a place
to compare analysis and have found some issues to fix in the udis disassembler.
i'll send the patchs to the udis86 author, to make the code more readable
avoiding
positive-negative values like ebp+0xffffffbc which is a bit noisy and hurts my
eyes.
But after some hours spend on ida i decided to start using the radare debugger
at the same time saving the project with 'Ps' and feel really comfortable with
it,
reading the code faster than in ida.
Another nice feature I used for the analysis of the binary was the new 'pm'
command,
which allows me to read the function arguments of a call subroutine in this way:
- step before the call
- read how many pushes or ESP/EAX accesses before the call (or just type the
function description yourself)
> pm xxi @ esp
0xbffff350 0x08053068
0xbffff354 0xbffff389
0xbffff358 50
> pD 30 @ eip
0x0804D1E2 eip:
0x0804D1E2 e8adbdffff ^ call 0x8048F94 ; sym_memcpy [1]
0x0804D1E7 c785e8fdffff00. dword [ebp-0x218] = 0x0
.----> 0x0804D1F1 8b85e8fdffff eax = [ebp-0x218]
This is really useful, so i can easily see that this is in reality:
sys_memcpy(0x8053068, 0xbfff389, 50);
At this point come to my mind the idea to dynamically analyze the code inside
code blocks
performing a fork on the child process to avoid process manipulation (or !dump
, !restore).
This way the code analysis will be able to 'precalculate' values before
accessing the code
allowing to analyze each of the values accessed and showing a little
description of what
happened to each one.
I think this is a cool idea because we will be able to add extra metadata to
the graphs
and this way enhace the graphs internals to implement in a near future a
pseudo-decompiler
in realtime over the disassembed code (like a plain disasembly view, but with
some claridifications,
like function call conventions, loops (for, while), conditionals (if) and so. i
dont plan to
make a pure-c decompiler like hex-rays, but a simple one with inline assembly
will be imho
better (for portability, less work and faster analysis), so the code decompiler
will work
for any architecture supported by radare (ppc, arm, x86 and java).
PD: I've been thinking about adding support to other virtual architectures like
Dalvik (Android one)
or Flash (swf). The second one is far more easier and almost done by the flasm
project, but the
Dalvik one needs some reverse engineering work, because there'r no specs. I
have decompiled the
dx.jar where is the 'core' of the sdk. A tool that converts a list of .class
files into a single
.dex file. Some of the classes inside dx.jar perform the conversion between
java and dalvik and
there'r internal strings and arrays containing lists of supported opcodes and
parameters, the file
format has been almost reverse engineered too, so maybe dalvik support can be
added without much
effort, but actually I've no time for doing all these things at the same time
heeh, so feel free
to give me feedback or code/documentation of it.
--pancake
_______________________________________________
radare mailing list
[email protected]
https://lists.nopcode.org/mailman/listinfo/radare
