Slashdot Mirror

Hello,

Here is a list of data recovery programs I have put together. Some of them may be a little old, for floppies or optical media only, but should still be useful. Unless otherwise noted, they are all for Microsoft Windows.

A-FF Labs - NTFS Undelete and Partition Find and Mount
Access Data - FTK Imager
Acronis - RecoveryExpert
Advanced NTFS Recovery - NTFS Recovery (may handle FAT32 as well)
bitMART - Restorer Ultimate
Brant, Dmitry - DiskDigger
BriggSoft - Directory Snoop
CGSecurity - TeskDisk and PhotoRec
Convar - PC Inspector File Recovery
Digital Assembly - Adroit Photo Recovery (pictures only)
DiskInternals - NTFS Recovery
DIY Data Recovery - iRecover
DTI Data - Recover It All
DataRescue.Com - PhotoRescue (intended for flash RAM cards, which are typically formatted with FAT, may work with other devices as well)
EASEUS - Data Recovery & Security Suite
Fsys Software - DFSee
Gibson Research Corp. - Spinrite
Gillware - GillWare File Viewer
Higher Ground Software - Hard Drive Mechanic Gold
Kato, Brian - Restoration (also here)
LC Technology -
[Continued in next message, as for some reason, Slashdot would not let me post in its entirety (too many URLs?). AG]

Hello,

Here is a list of data recovery programs I have put together. Some of them may be a little old, for floppies or optical media only, but should still be useful. Unless otherwise noted, they are all for Microsoft Windows.

A-FF Labs - NTFS Undelete and Partition Find and Mount
Access Data - FTK Imager
Acronis - RecoveryExpert
Advanced NTFS Recovery - NTFS Recovery (may handle FAT32 as well)
bitMART - Restorer Ultimate
Brant, Dmitry - DiskDigger
BriggSoft - Directory Snoop
CGSecurity - TeskDisk and PhotoRec
Convar - PC Inspector File Recovery
Digital Assembly - Adroit Photo Recovery (pictures only)
DiskInternals - NTFS Recovery
DIY Data Recovery - iRecover
DTI Data - Recover It All
DataRescue.Com - PhotoRescue (intended for flash RAM cards, which are typically formatted with FAT, may work with other devices as well)
EASEUS - Data Recovery & Security Suite
Fsys Software - DFSee
Gibson Research Corp. - Spinrite
Gillware - GillWare File Viewer
Higher Ground Software - Hard Drive Mechanic Gold
Kato, Brian - Restoration (also here)
LC Technology -
[Continued in next message, as for some reason, Slashdot would not let me post in its entirety (too many URLs?). AG]

Really? What do you make it wear?

ant.

Not only that, but discovering how it works is trivial, using a tool like IDA Pro, of which I am a happy costumer. Refusing to give out source for this, citing security reasons, reminds me of certain proprietary software companies running scared.

That's fantastic. =)

Best one I've personally spent any time with is IDA. Check out all the stuff this thing can do. I'm especially fond of those wingraph charts in the large gif they have there.

Source code? Pfft. Who needs it?

Software pirates will just use IDA Pro instead of GCC to get the job done. The part they've always cared about (Don't Steal Mac OS.kext) was never open source anyway.

If Apple says that software pirates are the only reason, don't believe them.

Melissa

Ilfak Guilfanov created IDA Pro http://www.datarescue.com/ the number one Disassembler around.
If there's anyone who doesn't need the source code, it's him.

http://www.datarescue.com/freefiles/funnyad.jpg

I wouldn't call what they are offering as trusted computing. They are not the manufacturers of the OS, so whatever they are offering is NOT trusted computing.

"Trustworthy" was here used only as a saying. As in "Please, trust us". Please read the ISC diary entry.

Since it's a typical binary patch you have to trust them that this patch won't hose your system or make you pwned by these or other folks.

The patch is distributed by Ilfak Guilfanov, who develops the IDA Pro Disassembler and Debugger. The WMF fix installation package includes source code for the DLL it installs.

Look, when I want to upgrade my box, I just do a apt-get update; followed by either apt-get dist-upgrade or use synaptic. I know my sources (I select them myself), I know that the reality checks exist (gpg keys, outside sources verifying the software, etc.). I know I'm not getting hosed when I install software from my usual Debian repositories.

Sure, you use apt-update when your os vendor has relased a fix. But what do you do when no official fix is yet unavailable, as the situation is now for Windows users?

I wouldn't call what they are offering as trusted computing. They are not the manufacturers of the OS, so whatever they are offering is NOT trusted computing.

"Trustworthy" was here used only as a saying. As in "Please, trust us". Please read the ISC diary entry.

Since it's a typical binary patch you have to trust them that this patch won't hose your system or make you pwned by these or other folks.

The patch is distributed by Ilfak Guilfanov, who develops the IDA Pro Disassembler and Debugger. The WMF fix installation package includes source code for the DLL it installs.

Look, when I want to upgrade my box, I just do a apt-get update; followed by either apt-get dist-upgrade or use synaptic. I know my sources (I select them myself), I know that the reality checks exist (gpg keys, outside sources verifying the software, etc.). I know I'm not getting hosed when I install software from my usual Debian repositories.

Sure, you use apt-update when your os vendor has relased a fix. But what do you do when no official fix is yet unavailable, as the situation is now for Windows users?

I'd start buy actually reading the source - building it if you can. Run profilers on it and try to get some kind of visual representation of the underlying code tree. If you have source, try using something like DOXYGEN to autogen some documentation (and structure) out of it. Someone mentioned Rational - you can get a trial license. Try to understand what the code does. For the most part games are straight forward, in that you have objects that have specific behaviours. You can try to establish the object hierarchies and see if you can redefine these to make more sense - or just be different.

For the fragments of source you don't have - try using tools such as truss to track flow of what is going on. GDB is your friend and you probably want to try running it through the debugger - especially if the extracts you were given were compiled without stripping the symbols. nm is also another useful one at trying to get an idea of the symbols in your binary and establishing 'from meaningful names' what on earth goes on inside.

Push your binaries through a disassembler like ldasm or datarescue - win. NASM also has a disassembler. Try and get a feel for what is going on.

Now comes the hardpart - it's not called reverse 'engineering' for nothing. You've done the reverse bit. It's now time to engineer a solution which shows that you've gone through the 'reverse' bit. It can be y our view on how the code should work. Don't be affraid to reuse resource files/bitmaps, etc. That's allowed. It's the code which counts. You'll probably find that the assignment gave you something which was sub-optimal, in either design or processing - or both. It's your turn to write it the way which it should have been written. I'll leave the 'team dynamic' to you. Don't let one person have all the fun. Probably you - it's good to give others a chance. See what people are intersted in and allocate the work load. Just be prepared to fix everyone's bugs the night before submission - it's not so bad - it's 'fun.'

IDA pro, best dissasembler around ;) http://www.datarescue.com/

Yeah, the "most of the source code" part is a bit scary. If they really are talking about reverse engineering from executables they are in for a hell of a time. The state of the art is a project I work on now and then, Boomerang, and it isn't for the faint of heart. I've been hearing for years about people who are working on decompilation tools that are integrated into IDA Pro but I've yet to see it. The time where you can enter a binary, press a button and get back compilable, maintainable source code is still a long long way off. But that's good, friends of mine do commercial decompilation work.

This implies that the debugger can be detected. There are many ways you can implement debugger stealthing at the debugger level, and there's always the option of modifying/removing the debugger detection routines. I've done quite a bit of research in automated removal of debugger detection routines, some of which is available at http://www.datarescue.com/cgi-local/ultimatebb.cgi ?ubb=get_topic;f=4;t=000320;p=0 if you're interested.

Most of what stops normal people won't stop a good reverse engineer with a good debugger and disassembler.

Wait until this EU directive is challenged in court.

First thing I do when I buy an original is copy it to hard disk
and remove the CD protection check.

Same with CD, rip to mp3, copy to IPOD.

Same with Xbox and PS2 games..

I hate removable medias... and I don't like to be forced to use
them because of some stupid protections.

Software protection only protects companies from honest people, pirates don't care about protection as most of them
are so trivial to crack with IDA.

http://www.datarescue.com/IDA + http://www.sabre-security.com/BinDiff (sorry, messed it up on the first attempt)

There are legitimate ways to compare executables (as opposed to the method used by the authors of "Who Wrote SoBig?").

0) All of these ideas involve disassembly. http://www.datarescue.com/idabaseIDA Pro is the best dsassembler on the market; all ideas below are implemented as extensions to it. Nothing even comes close to its sheer strength, except perhaps the underdeveloped, alpha knockoff http://lida.sourceforge.net/Lida.

1) http://www.datarescue.com/idabase/flirt.htmFLIRT signatures work surprisingly well for the detection of statically-linked libraries (assuming the library itself hasn't been recompiled). It is basically binary-based but there are important measures for dealing with code that can/will change between different binaries.

A plugin called http://www.sport-und-event.de/backtrace.de/plugins /idb_2_pat.zipIDB2PAT for IDA can take an executable and produce FLIRT signatures for all functions in it, which can be applied against any other executable for comparison. I find this very handy for malware versioning analysis.

2) http://www.razorteam.com/publish/papers/comparing- binaries.htmlInstruction Semantic-Based Binary Comparison The paper calls itself "Comparing binaries with graph isomorphisms" but this is a misnomer because there is nothing graph-based about the comparison; only the visualization has any bearing on graph theory. This technique attempts to match the assembly instructions almost exactly (not necessarily a byte-for-byte direct comparison). No public implementation is available for this method.

The problem with the two methods above and the reason that byte-for-byte comparison won't work in general is that compilers regularly re-arrange code or change register allocation, especially in the case an optimization is applied differently between builds. Two successive builds might look completely different on the binary level. Microsoft's internal compilers are especially notorious for this.

Enter 3) http://www.sabre-security.com/products/bindiff.htm lBinDiff by Halvar Flake. BinDiff is the most promising idea of the three (though designed for a different purpose than 1)). By using structural and graph-theoretic properties of executables (e.g. the call-tree) and the functions within them, BinDiff is able to compare executables without looking at the instructions themselves (except for properties that can be deduced in a CPU-independent fashion by IDA). That means that BinDiff can potentially diff binaries for different platforms, meaning the binaries could be using a different executable file format and a different assembly language. Obviously, the two binaries described would be remarkably different.

2) & 3) conception was motivated by the idea of diffing security patches (which they do with various degrees of effeciency). 1) is arguably at the core of IDA's power.

P.S. the "Who Wrote SoBig?" authors are completely full of shit. From the paper:

"AMS [a *completely unrelated* email client] and Sobig contain common high-level functionality, as both programs generate and send email. Although there are many ways to create this functionality in source code, it is extremely unlikely that two people working independently would generate similar opcode sequences for this type of functionality. From the results of our comparisons, the first 1K of memory indicated that they are very similar types of executables."

No shit, that's because the first 1k of the executable is usually the PE header. "Very similar types of executables"? What does that mean, anyway? The whole report is anonymous, unfounded slander.

There are legitimate ways to compare executables (as opposed to the method used by the authors of "Who Wrote SoBig?").

0) All of these ideas involve disassembly. http://www.datarescue.com/idabaseIDA Pro is the best dsassembler on the market; all ideas below are implemented as extensions to it. Nothing even comes close to its sheer strength, except perhaps the underdeveloped, alpha knockoff http://lida.sourceforge.net/Lida.

1) http://www.datarescue.com/idabase/flirt.htmFLIRT signatures work surprisingly well for the detection of statically-linked libraries (assuming the library itself hasn't been recompiled). It is basically binary-based but there are important measures for dealing with code that can/will change between different binaries.

A plugin called http://www.sport-und-event.de/backtrace.de/plugins /idb_2_pat.zipIDB2PAT for IDA can take an executable and produce FLIRT signatures for all functions in it, which can be applied against any other executable for comparison. I find this very handy for malware versioning analysis.

2) http://www.razorteam.com/publish/papers/comparing- binaries.htmlInstruction Semantic-Based Binary Comparison The paper calls itself "Comparing binaries with graph isomorphisms" but this is a misnomer because there is nothing graph-based about the comparison; only the visualization has any bearing on graph theory. This technique attempts to match the assembly instructions almost exactly (not necessarily a byte-for-byte direct comparison). No public implementation is available for this method.

The problem with the two methods above and the reason that byte-for-byte comparison won't work in general is that compilers regularly re-arrange code or change register allocation, especially in the case an optimization is applied differently between builds. Two successive builds might look completely different on the binary level. Microsoft's internal compilers are especially notorious for this.

Enter 3) http://www.sabre-security.com/products/bindiff.htm lBinDiff by Halvar Flake. BinDiff is the most promising idea of the three (though designed for a different purpose than 1)). By using structural and graph-theoretic properties of executables (e.g. the call-tree) and the functions within them, BinDiff is able to compare executables without looking at the instructions themselves (except for properties that can be deduced in a CPU-independent fashion by IDA). That means that BinDiff can potentially diff binaries for different platforms, meaning the binaries could be using a different executable file format and a different assembly language. Obviously, the two binaries described would be remarkably different.

2) & 3) conception was motivated by the idea of diffing security patches (which they do with various degrees of effeciency). 1) is arguably at the core of IDA's power.

P.S. the "Who Wrote SoBig?" authors are completely full of shit. From the paper:

"AMS [a *completely unrelated* email client] and Sobig contain common high-level functionality, as both programs generate and send email. Although there are many ways to create this functionality in source code, it is extremely unlikely that two people working independently would generate similar opcode sequences for this type of functionality. From the results of our comparisons, the first 1K of memory indicated that they are very similar types of executables."

No shit, that's because the first 1k of the executable is usually the PE header. "Very similar types of executables"? What does that mean, anyway? The whole report is anonymous, unfounded slander.

Not that complicated? -It seems you got the wrong answer, so did google.

Oddly enough, there actually is a working f(x) answer and even google does not know what it is...

http://www.datarescue.com/ubb/ultimatebb.php?ubb=g et_topic;f=4;t=000183

Surely a binary-only codec could be probed with something similar?

Also under windows, SoftICE, is also an excellent debugger which lets you assemble in place and do many other neat things.

Under linux, people have been trying to make SoftICE look-a-like debugger, such as LinICE, etc. and gdb is quite a powerful tool and is scriptable.

I don't know about you, but I'll rather be keeping my win98 systems safely protected behind nat and a strict firewall than trusting some stranger offering me unofficial service packs.

There's no source code of course, but this stuff isn't exactly opaque. Get yourself a copy of IDA Pro or SoftIce and dig in. You might learn a thing or two!

You boot windows or try and run IDA through WINE.

A person with a decent disassembler and knowledge of reverse engineering can get to your secrets even if they are binary only, so that argument is not valid. IIRC, Nvidia stated that their driver include some third party code that they cannot open source.

It's the optimization step that causes issues: one of the main things the computer doesn't need which is stripped out is variable names, comments, etc. without them, there's no context. You can figure out the algorithm from the assembly, but you can't easily figure out what it's operating on. ...

NAND - Flash based media uses a complex low level sector virtualization called "wear leveling algorithm" to distribute the wear evenly across the memory array and maximize the number of write cycles it can sustain.

The actual point is, when carrying stuff around, there's a very high probability that it will experience some sort of impact, and you probably know what happens when you drop your hard drive. OTOH, there's no real replacement yet for HDDs in your vanilla PC or laptop. Continuous writing, i.e. having a swap file on flash memory, would probably really wear it out pretty quickly.

It is just a bunch of simple IDA pro plugins and it will give you a false sense of security.

Halvar has published is own open source version called BugScam on sourceforge

For professionals (read: willing to pay $$$) I recommend the Ida Pro disassembler. The Fast Library Identification & Recognition Technology (FLIRT) combined with Parameter Identification & Tracking (PIT) make it the tool of choice for serious reverse engineering.

For professionals (read: willing to pay $$$) I recommend the Ida Pro disassembler. The Fast Library Identification & Recognition Technology (FLIRT) combined with Parameter Identification & Tracking (PIT) make it the tool of choice for serious reverse engineering.

For professionals (read: willing to pay $$$) I recommend the Ida Pro disassembler. The Fast Library Identification & Recognition Technology (FLIRT) combined with Parameter Identification & Tracking (PIT) make it the tool of choice for serious reverse engineering.

The first five points in that FAQ answer are nonsense, at least for the last ten years. Every good disassembler, such as IDA Pro, already has library identification code with signatures from dozens, if not hundreds, of compilers and libraries. When I disassemble programs, the compiler and libaries are identified instantly, and all of the uses of library routines and named and tagged. A decompiler would do the same thing. The real problem with decompiling C++ code is the trend towards the generic programming idiom, with a heavy reliance on templates and inline functions. All of that information is lost when compiling. The FAQ answer that you quoted is so wildly out of date as to be laughable.

It's a shame that nobody mentioned IDA yet -- an interactive decompiler that does not restore the source code but instead tries to work with the human to figure out what parts of machine code do and mean by splitting data and code and giving readable names to functions and variables to start with.

Sure. All the time.

This post to me is the classic "open-source is better than Windows because <blank>", where half the time, the poster hasn't completely investigated all of the claims he/she makes. I may be called a troll, but I've done development on both Linux and Windows (predominantly Windows), but I'd like to clear up some of the "comparisons" made by the poster.

COMPILERS:

MS:
Killed most compilers for their platform (except the oddball ones) by squashing them with their own. Visual C++ generates pretty tight code, but you're just screwed if you run into a bug with it. Oh, and it costs lots of money. Most compilers commercial. Mingw/cygwin exists but not supported well (MSDN support bitterly hates both).

True, Microsoft has pretty much killed the competition, although your claim that it "costs a lot of money" is a little off centre. You can download the .NET Framework, which includes everything you need to build Win32 applications (everything but the IDE) for free off of MSDN. If you decide to splurge, you can buy Visual C++ Standard for the massive sum of $89.99.

DEBUGGERS/DIAGNOSTICS:

MS:
Um...ntinternals put out regmon and filemon. Apparently MS puts out WinDBG for free, though I haven't used it and apparently it isn't too popular. No free high level debuggers. Few diagnostic programs for already compiled code.

Again, spoken like someone who barely has any actual experience in the realm. WinDBG is an extremely powerful kernel/user mode debugger, and in my experience works just as well as anything else on the Win32 platform for debugging user mode code. The Visual Studio integrated debugger is also great. As far as diagnostic programs, there are quite a few, such as NuMega DevPartner Studio, or Rational's DevelopmentStudio. Windows NT-based operating systems also ship with Performance Monitor which is an often unused tool which allows you to monitor many application specific diagnostics. For disassembly, there's IDA, which is without a doubt the ultimate disassembler for Windows.

DEVELOPER SUPPORT:

MS:
Guess at what's going on underneath the covers, most of the time. No source to look at. Some newsgroups, mostly for higher level problems. Can purchase extremely expensive (though usually effective) MSDN incidents.

There are many Windows developer sites, namely sites like CodeProject, CodeGuru, and let's not forget: MSDN. MSDN has thousands of articles, and full API documentation. You can also read back-issues of MSDN Magazine. Provided you can't find your answers on the aforementioned sites, there's always Google Groups ... which in the past has had the answer to nearly every Win32-related question I've ever had. So you can see that saying developer support for Microsoft platforms is weak is quite an understatement.

SAMPLE CODE:

Many many source examples listed on the sites above ...

APIS:

Windows:
The most godawful APIs in the world. Win32 is so full of cruft, poor conventions, inconsistent conventions, and unnecessarily complicated *crap* that it's amazing. Most advanced MFC programmers end up having to interact with Win32 as well to do certain things that MFC can't do. Has some great snippits on MSDN, along the lines of "Do not use this argument, as it represents a security risk and has been obsoleted. Some developers may wish to use this argument for backwards compatibility with Microsoft CSPs."

By the tone of this paragraph, I take it that the main area of exposure the developer has had to Microsoft APIs is with the CryptoAPI, which IMO is one of the worst APIs Microsoft has ever released. One of the advantages of having a sole API provider is that there is a uniformity across all areas of the system, so that if I need to figure out how to use a new API set, it always looks familiar.

MFC programmers need to interact with the API at some point. If you think that MFC will protect you from the API, then you are sorely mistaken. Many Windows programmers jump into development by learning MFC, without learning how API works underneath, and subsequently end up writing shit applications. I personally would not touch MFC with a 10-foot pole (try WTL instead).

Ultimately, I prefer development for the Windows platform, but only because it was what I was trained on. I do realize that Linux has excellent development tools. What I hate to see is Linux zealots bashing Microsoft without actually knowing anything or having a lot of experience with the Microsoft Platform.

Trillian is not open sores software, and will never be. If you care to see if it has spyware, I recommend the best disassembler available for any platform, IDA Pro.

GAIM has a lot further to go before it reaches trillian's capabilities, especially with what windows users want (like good skinning).

IDA Pro Disassembler

It's not quite a debugger I suppose

Multiple Processor : same interface and features for dozens of processors
Fully Interactive : you work with the disassembler and forget about tedious multiple passes.
High Level Constructs, such as unions, structures, variable size structures and enumerated types.
Stack Variables keep track of your local variables, Local Variables.
Program Navigator Toolbar
Fully dynamic Global and Local Labels.
Low Level Constructs such as bitfields
Interactive Register Renaming makes RISC processors easy.
Auto-commenting : you can even define and use your own comments base.
Versatility : loads and disassemble virtually any file. Visit our gallery for a small subset.
Graphing : through a VCG Port. Graphing as it stands in version 4.21

I put sign.exe thru IDA and identified the checksum algorithm. I found out that the only thing that goes thru the checksum is 35 35 00 then 0E DA is skipped and then the rest is put thru. The algorithm is a simple crc alike algo that adds the chars xors with the length and rotates some bits. You can find a perl program i wrote to calculate the checksum for a given range at: this location.

Good luck with your project,
Gijs

This really is fascinating stuff. Note that most of the entrants used the disassembler known as IDA, available here. There was also much discussion of this contest recently on various security-related mailing lists.

Hopefully they will be doing a similar contest again next year. In the meantime, I guess we'll just have the Scan of the Month to analyse.

IDA would no doubt be an incredibly helpful tool. It's also cheaper than Photoshop, which I imagine would not be very useful at all...

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.

If Microsoft introduces stupid protection scheme they will be reverse engineered and cracked.

Btw take a look at a cute and now obsolete gdb batch crack I wrote a while back when there was no linux binaries available to play the retail version of quake3 but a protected demo.

But on *nix (BSD, Linux, etc) AMD works great and will probably beat the hell out of intel, and remember the Internet server arena is not yet sominated like desktop and internal servers.

Maybe the guys who got M$ sourcecode should give it to AMD to let them optimize as Intel does ;) Well there is always IDA!

> How DO you reverse engineer software?

Using disassembly/decompilation, debugging and/or probing (as in "black-box"). Have a look at this essay I've written. It's about my analysis of the program "Net Nanny", but the techniques used are fairly typical.

>Anyway, am I in over my head even contemplating it?

No. But it depends on why you want to do it. This is not a good way to pick up on new graphics algorithms, unless there is something very specific that you are after. However, you should give it a try if you think you might enjoy this kind of low-level puzzle (for me, it's a puzzle).

> I have a feeling that by the time [...]

Possibly, but I really think you would have the sense to give up before spending that much time :-)

I might aswell tell you what tools I use:

The most powerful tool is NuMegas SoftIce. It's a systemlevel debugger for the Win32 platform (would love a linux version).

After SoftIce comes IDA. IDA is a very competent disassembler. It runs under Win32, but it supports many different processors and file-formats (MZ/NE/PE/ELF/DLL/etc).

Of course, you also need a good hex-editor. I use HIEW.

I primarily use reverse-engineering techniques to discover backdoors and extract encryption algorithms in commercial software (Me and a friend reversed the censorware CyberSitter earlier, which lead to the downfall of the Scientologists "ScienoSitter").

I also use the techniques to explore unknown file formats, see for example the project to reverse the fileformat used in the game Baldur's Gate. When doing this it is much less "debugging/disassembling" then it is hanging around the hexeditor.

If you want to learn, check Fravia's Pages of Reverse Engineering. While there's lot's of crap there, there's also some nuggets of good information. You can also use his messageboard to interact with competent reversers, but beware, you will have to show that you are working on your side too. Don't ask for ready solutions.

Hope this was of help, be in touch if you have any questions.

Some of the best Reverse Engineering Tools

IDA Pro From Data Rescue


www.datarescue.com

Soft-Ice From Numega


www.numega.com

Even without using something like this, disassembly of programs cannot be 100% correct. There is a lot of information needed to reconstruct a program that is thrown away by the compiler. For example you can't determine where a jump table (switch statement) or function pointer (virtual function) will lead to without actually executing the program and then it's not possible to cover all of the cases that could occur. IDA does a pretty good job of guessing though. Also IDA has hacks if it is looking at C code like looking for procedure frame headers (push ebp; mov ebp, esp) and termination code (pop ebp; ret). My solution to correct disassembly is to use emulation. This insures you never have an incorrect interpretation, but you will miss code that is never executed, and this can be important for understanding how errors and exceptions are handled.

Just because you can dissemble something doesn't mean you can understand it. It requires a huge amount of time to try to comprehend uses for unnamed memory locations and layout of data structures. In the case of a driver this is frustrated by the fact you are dealing with a lot of hidden code and data (the logic on the hardware). Not all drivers are "small pieces of code." Having looked at several vendor's Direct3d driver source code I can tell you each was extremely large and complex. Writing the driver with full knowledge of everything is hard enough, but disassembling one and understanding it would require super human willpower. There are all sort of commands that will do different things depending on that state of the card, so you have to understand what previously executed code was important to getting the card into that state.