Slashdot Mirror

Eg Ndisasm

There are also a few tools that try to convert to high level languages:

Snowman
REC Decompiler

I guess you could reverse-engineer it.

• Original Module
• "Decompiled" Output (run through REC)

The source code to "wl.o" is NOT part of the GPLed code at Linksys's GPL page.

If anyone actually got it to work, rest assured someone would feel threatened and DMCA it off the face of the Internet.

However, there are FAR worse ways to disrupt communications than by tweaking a few lines of code in a driver.

Just to prove it exists:

Reverse Engineering Compiler

With regards the original article - well, that was a bunch of obvious guff really; what you'd expect from high-school geeks of the type I was, some number of years ago. Of note, is that it claimed to decompile C++, when actually it talked only of rather trivial C constructs, something that is a well understood practice already.

Some relatively recent classic decompilation work was done by Cristina Cifuentes who put together a C decompiler that worked to a significant degree for common DOS-based compilers of the time. Effectively the job of "decompilation" can be thought of as "compilation" - instead of compiling C into ASM, you think of compiling ASM into C. Not as daft as it sounds, honest. You can download "dcc" from the above site to investigate further.

Boomerang is a sourceforge project attempting to create a decompiler. Worth a look, as well.

It's worth noting, that there are a number of ways to "cheat". For example, it's often trivial to discover what compiler was used to generate a given object code, and there are usually masses of common library-type code that gives you a leg up. Add to that, the fact that a piece of code was generated by a compiler, and the problem of discovering what a given piece of object code does is drastically simplified - compilers add huge amounts of structure and predictability to the generated object code that can be absent in free-form handwritten assembler (and few people do that anymore!), and much can be made of this.

On the code/data issue mentioned by others in this thread - although separating code/data in general from mixed binaries can be considered hard, in reality it's often quite feasible and even simple. After all, the CPU manages to work it out. Again, the fact that there are so many short-cuts you can take really helps.

Of course, a quick cruise around the cracking community will turn up all sorts of ways and means to shortcut this sort of problem...

Here are the results of a quick googling:

• Univac 494 to 1100 Series Decompiler
• REC Decompiler
• DisC - Decompiler for TurboC

C decompilers exist; here's one. There are others. Most aren't very good. It's a hard problem.

Without debugging information, decompilation tends to result in code with arbitrary variable and function names, of course. But you get names when a DLL or .so is entered, so at least you get the program's major interfaces. Minimal C++ decompilation could be done by adding vtable recognition to a C decompiler.

A more difficult problem is recognition of idioms. Things like "for" statements tend to decompile as lower level constructs. That's OK as a first step. You need some internal representation Initial decompilation might represent all transfers of control with "goto"; higher level recognition then deals with that.

The key to doing a good job is "optimization", finding more concise source code that will generate the object code. The key to this problem is defining an internal representation that can represent any valid machine-language program, and which can be modified as higher level information about the program is discovered. The first step is usually to start at the starting address and build a code tree by following calls, like a good debugger does. Then you start to improve on the code tree, doing things like this:

• Recognition of function calls. Each function call should be decompiled, and all calls to the same function checked to insure they have the same calling sequence. Then a prototype can be generated and placed in a header file.
• Recognition of fixed-format structures. Figuring out how big a structure is can be tough, but at least fixed-format ones should be fully recognized. All references to the structure should be checked for type consistency, and a structure definition generated.
• Recognition of "for", "while", and "switch".
• Once constructors and destructors have been found, the structure of derived objects can be figured out. Now class definitions can be generated.
• Once class member functions have been identified, the most restrictive protection ("private", "public", "protected") that will work should be attached. Similarly, "const" can be inserted for all arguments not seen to be modified.

Decompilation won't always succeed. But you should find all the places where the code is doing something the compiler doesn't understand, and get code back for everything else.

It's a big job, and somebody ought to do it. Among other things, it would be a valuable tool for finding compiler bugs.

Here's an interesting link. Not necessarily a guide though.

dcc isn't practical though, unless you've got a heavily modified version. The offical version is hardwired to only support very small programs, and fixing that would require extensive rewriting of its internal structures.

Not saying that it isn't interesting, only that today, no one (I'll wager) is using dcc for practical reverse-engineering.

There's also rec (reverse-engineering compiler), but it's sort of limited in the kind of input it allows.

IDA on the other hand is the tool of choice for the kind of reverse-engineering you're thinking of. If there were to be a source-generating backend on that one, you'd see a lot of worried faces, I assure you.