On Wed, 2004-08-25 at 01:59 -0400, Andrew Miklas wrote:
> I've been working with a few people to reverse engineer the drivers included 
> with the WAP54G 1.08.  We're about 50% done translating them back into C.  
> Once we're done, we plan to study the driver in order to write our own from 
> scratch, or ask someone else to cleanroom it.
> 
> However, it's likely that by the time we're done (if ever), the hardware will 
> be supplanted by something else.  We've learnt the hard way that reverse 
> engineering a 420K binary, and completing in a reasonable time isn't as easy 
> as it sounds.  :)  This is especially true when you can't simply make 
> everything public (out of copyright concerns) and do the project in a real 
> open source way.  

I agreee, reverse engineering machine code is not trivial, especially
with the tools currently available. However I don't think that the
difficulty is intrinsic. It is possible (though obviously not simple) to
wite software that is able to infer a great deal from machine code
automatically and produce pretty good decompilations.

Also I think that the pciproxy[0] technique currently offers a simpler
solution. Analyzing the data produced is more akin to reverse
engineering a network protocol than machine code. Reverse engineering
protocols is much less 'copyright sensitive' than decompiling machine
code and, I think, more easily shared.

Anyway, perhaps once I've had some time to make a little more progress
we would be able to compare some notes?

[0]. I should probably explain the technique. It basically involves
running supported operating systems under a PC emulator, and trapping
and logging i/o on the PCI bus.

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D