|
![]() |
|||
|
home products solutions news downloads order support about us |
|
|||
PE Explorer Feature Tour |
||||
|
|
WINDOWS Win32 DISASSEMBLER Win32 PE Disassembler: Dig into executables The PE Explorer Disassembler is designed to be easy to use compared with other disassemblers. To that end, some of the functionality found in other products has been left out in order to keep the process simple and fast. While as powerful as the more expensive, dedicated disassemblers like IDA Pro, PE Explorer focuses on ease of use, clarity and navigation. We just made a good disassembler at a reasonable price. If your daily work involves reverse engineering of software and exploiting code, source code reviews, testing and evaluation of vulnerabilities, PE Explorer will save you hours of time!
PE Explorer does not decompile code. It disassembles code, which is the task of converting machine code into assembler, but it does not generate C or C++ code from the disassembled output. Which is a task of great difficulty. Besides, in most cases, there is nothing in the executable that indicates what programming language was used to generate the program. The disassembler supports the most common Intel x86 instruction sets and extensions (MMX, 3D Now!, SSE, SSE2 and SSE3). We tried to achieve most of the power of IDA Pro, while requiring less skill or knowledge, by automating more of the disassembly process. The PE Explorer Disassembler assumes that some manual editing of the reproduced code will be needed. To facilitate additional hand coding, however, the disassembler utilizes a qualitative algorithm designed to reconstruct the assembly language source code of target binary win32 PE files (EXE, DLL, OCX) with the highest degree of accuracy possible. The fundamental challenge in disassembling compiled files is to correctly interpret the examined data. Separating code from data can be extremely difficult, especially when the initial code includes countermeasures intended to hinder disassembly. In order to meet this challenge, we developed a customized model, specifically designed to reduce incorrect data type identifications. Although the customized modeling performed by the disassembler does increase processing time, the result is a dramatic reduction of incorrect opcode translations. We think you will agree that that the extra time needed to achieve this high level of accuracy is justly compensated for by the time saved when hand correcting the output. Search for Text Strings within an EXE The disassembler pulls ASCII text out the data portion of the file. Unlike the various strings utilities that search and extract the text strings from a file, PE Explorer is much more accurate and detailed in extracting these strings out from specified memory locations instead of searching. The output of strings found in the binary gives you a good knowledge of what some of the functions and subroutines called by this binary are.
Search for VCL Obiects The Borland VCL object model is designed in such a way that we think it will be possible to reproduce the original assembly language source code perfectly. At Heaventools, improving the disassembler is an ongoing part of our PE Explorer development efforts.
The Disassembly Process The disassembly process begins by identifying the compiler used to build the target file. Forehand knowledge of how a compiler puts files together improves the guesswork involved in determining the data allocation patterns within the target file. Moreover, given this information, identifying most of the objects, procedures, variables, types etc. of the target file can be achieved with a very high degree of accuracy. Only various Borland® compilers are currently identified. The disassembler will decompile files built with other compilers too. At this time, however, it will only display specifically identified internal items for files compiled with Borland® compilers. ![]() After the compiler has been identified, the disassembler searches the target file for a relocation table. If a relocation table is found, the information is used to detect the absolute offsets to the various content items in the file (for example: mov eax, offset L0041F46A, jmp L004A49FE). In turn, this information is used to form the Jumps list and the Rets list. The Jumps list stores the addresses to positively identified instructions and the Rets list stores the addresses to tentatively identified instructions. These addresses are then arranged according to the degree of certainty regarding their identification. As the information from the Jumps list and the Rets list accumulates, the decoding process begins to emulate the execution of the code found within the target file. When the primary branch of the decoding process finishes executing, the remaining information from the Jumps list and the Rets list is processed. Information accumulated in the Jumps list is evaluated first, followed by the information in the Rets list, until both lists are empty. If the repeated scanning option is selected, this step is repeated until the disassembler has resolved any outstanding references. The decoding process concludes by generating labels for any items that remain unidentified and setting the output positions for all of the various items found in the target file. After all processing has been completed, the disassembler displays the resulting source code for the target file. This output can be manually edited or saved to disk for future reference. Disassembler - Options Before the disassembly process the Options window displays the following options: THE GENERAL TAB ![]() Instruction Sets - Enabling these options directs the disassembler to support the most common instruction sets (MMX, 3D Now!, SSE, SSE2 and SSE3). Detect Segment Register Usage - Typical Windows applications do not use the segement registers for direct read/write operations. The exception is with files compiled with Watcom C/C++ 32 which uses the segment registers for data addressing. These insructions also can be found in files compiled with other compilers. As a rule they are system files and utilities. Auto Rescan - Enabling this option directs the disassembler to make additional passes through the image data using hints found during earlier passes to make a refined interpretation. Use Auto Rescan count to set the number of passes. 4-5 is usually adequate. Save Borland VCL Objects after Preload Step - Enabling this option allows you to save all found Borland VCL objects before the disassembly process ends. Number of displayed Opcode bytes - This value specifies the number of OpCode bytes that will be displayed per line of code in the disassembly listing. A value of 0 means that no OpCode bytes will be displayed. This value only affects the number of OpCode bytes displayed in the disassembly and will not impact the actual disassembly itself. If this value is set to something less than the actual length in bytes of a particular line of code, a plus sign will be added to the end of the displayed bytes to signify that additional vaues exist on that line that are not being shown. THE ADVANCED TAB ![]() Verify Offsets - Enabling this option directs the disassembler to double check the validity of an analyzed value to ensure that this value can be an offset. Recommended. Reverse Offset Checking Order - By default, the disassembler interprets not-yet-processed data as code and if that fails then as offsets to data. This option directs the disassembler to interpret not-yet-processed data as data and if that fails then as offsets to code. Find ANSI and Unicode Strings - This option directs the disassembler to automatically detect ANSI and Unicode strings greater than 3 characters in length. Find Alignment - Because accessing aligned data is faster, many compilers align their output by padding it with meaningless commands such as nop and mov eax,eax. Forcible Find Offsets - This option directs the disassembler to automatically detect offsets to data in code that remains unrecognized after the primary pass through the image. Analyze Uprocessed Data - During the disassembly process some unanalyzed blocks of data are found that lack a direct address relative to a known program procedure. Enabling this option directs the disassembler to attempt to detect the contents of these indirectly addressed blocks and to determine whether they contain code or a known type of data. Recommended. Enabling this options improves the quality of the disassembly listing.
|
|||