|
From: Stephen T. <st...@to...> - 2006-11-17 18:31:34
|
On Fri, 2006-11-17 at 18:00 +0000, Tom Hughes wrote: > I think you need to explain a lot more about what you're trying to > do before I can answer that... I am working on a reverse engineering shared library which can be called from a variety of programs. The present problem I am trying to solve is how to detect a binary program is compressed or not. That is a packer/compression tool is used on the original binary and produces a smaller executable. This compressed program is not the real program but its hard to determine from the binary if this is true or not. I am supposing that if I mark the memory of the code one color (e.g. Orange) and the data another (e.g. Green) that I can at least detect if the suspect binary is a self-modifying program or not. A compressed binary is one class of self-modifying code. So just merely running the code and determining if it attempts to execute any part of its data section is not specific enough. So the Unpacker component in this framework takes in input from other components in order to do its job. It needs to know the architecture for the given binary along with starting code address, code size, starting data address, data size and a memory map of the suspect binary. A memory map is a data structure I created for managing the binary images. It provides me the ability to jump to various points in the image and write or read from it. The Unpacker use the type of architecture to create a specific Simulator (e.g. x86). A simulator is a class that uses the VEX library to translate the binary image to simulate execution. That was the suggestion that Julian gave me since the framework is only going to handle user space applications. So I need to give the simulator a starting address into the memory map where the first instruction is and the memory map in order to start it working. So for now I desire to load the suspect binary into its desire location (e.g. 0x4000000 for win32 programs). If I can I would like to recover the unpacking code from the suspect binary to analyze it to hopefully discover unique properties to unpacking programs. I would be able to use this information to create a better compressed binary detector. Also I would like to recover the original program instructions. So I would have two memory maps as output, unpacker code and original code. I know I need to create a PE file loader like valgrind has done for ELF programs. Right now the fundamental issue is how to locate the program and called DLLs at their desired location in memory if possible. I am sorry for being vague. Its sincere hope that what I have provided will help you understand the nature of the problems I am trying to solve. Stephen |