[time-nuts] FE-5680A firmware dump

[Poul-Henning Kamp]

--------
In message <509C3858.6050306 at verizon.net>, Peter Gottlieb writes:

>The reason is that code frequently combines tables and instructions [...]

What I do in PyRevEng is try to automate this and many other steps.

The disassembler gets pointed at an address were we know there is an
instruction, starting for instance at the RESET vector.

The disassembler returns a disassembly of the instruction and two
optional parts:  A flow description and a pseudo-instruction.

The flow description will tell where this instruction can go next,
for instance, calls, jumps, returns and so on.  This "discovered"
addresses are added to the list of places to disassemble.  If there
is no flow description, the next instruction after this one is
disassembled.

But the way this is used is that it's driven by a python script,
so that you can steer this process, for instance if you discover
a table:

        for a in range(0xfff3, 0xfff9, 3):
                cpu.disass(a)

There's a lot of other stuff you can do too, annotate stuff,
define labels etc. etc. and the pseudo-instruction stuff is
an experiment to allow data/constraint-driven disassembly as well.

I have an older prototype of this which will spot C-function
arguments, and propagate their types throug calls/local/global
variables also.

Once you've done all you can at this point, an analysis pass happens,
which tries to make sense of the instruction flow by finding
functions, code modules etc.

Finally the output is generated, see two examples here:

Listing:
	http://phk.freebsd.dk/misc/_.hp5370b.txt

Flowgraph:
	http://phk.freebsd.dk/misc/_.hp5370b.pdf


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.