Flag: Tornado!
Hurricane!
|
|
Topic created on: December 22, 2006 16:23 CST by phossal  .
[Edited]
Here's a little tutorial on how to recognize some of the common compression algorithms:
http://sekai.insani.org/archives/24
You can also: a) upload a sample somewhere for us to have a look or b) disassemble the application and try to reverse the algorithm
|
Great link Igor.
It would be nice to add compression-detection to Ilfak's encryption-detection IDA plugin, FindCrypt. There's also an OllyDbg port of FindCrypt. Looking at the list, FindCrypt already detects zlib. Adding in the other compression routines form Igor's link probably wouldn't be too difficult.
|
Welcome to "File Format Reverse Engineering", a subset of the larger RE field. While it is often possible to learn a great deal about a file's format in a hex editor, when compression and/or encryption are involved, it is generally easier (for an experienced reverse engineer) to determine the algorithms by looking at the code (generally only available in assembly via a disassembler such as IDA Pro).
You need to open the application that created your file into IDA Pro, not the file itself. The file is unlikely to contain any code, as you have already found. You also need:
* A solid understanding of low-level machine architecture. It doesn't matter how many HLLs you know (though that often helps) if you don't know that 1 + 1 is sometimes 10. I have seen many good C++ / Java programmers fail to grasp RCE during an in-depth two week course.
* A good understanding of assembly language (in general, although specific knowledge of assembly for the processor the application runs on is a big "leg up").
* A disassembler and/or a debugger. If you're talking a host-based application (e.g., Windows or Unix program), you're way ahead of the game in that you can use a debugger.
* Good troubleshooting and problem-solving skills.
* Time. The problem you speak of sounds fairly trivial for an experienced reverse engineer (e.g., a few days to two weeks); however, many of us have built careers on learning and enhancing our RE knowledge. RCE projects can take anywhere from 15 minutes (e.g., quick triage of a new virus or worm) to multiple years, depending on the difficulty, goals, ...
Have fun!
PS - The application that creates the file would be more useful to someone like me than the file itself. It can take man years to reverse engineer the file format using only the file, and perhaps an hour or two to find and analyze the compression routine(s) by looking at the application.
PPS - I'm not volunteering to do the job -- I don't get paid for that, and prefer to spend my free time in other ways... :) Just trying to give some guidance.
|
I havent reversed any static file format yet
but like psujobu says above the most easy way out is to find the app that either created it or that uses it catch it when it is either writing it or reading it and then poke around those functions
some where there has to be a CreateFile, WriteFile ,_lopen ,_lread , fread ,fwrite , NtCreateFile, NtWriteFile, int 0x80 , whatever it takes
and once you get hold of it you can make better sense
instead of feeling around in dark with some unknown file
|
Note: Registration is required to post to the forums.
|
|
|
|
There are 31,328 total registered users.
|
|
![[+] expand](/imagery/files/soysauce_blueprint.gif){kind=link}