Wen/tU Tang Li
Shelling software can be divided into two types: compression and protection. The purpose of compression is to reduce the program volume, such as ASPack, UPX, and PECompact. Protection is designed to prevent programs from being tracked and debugged, such as ASProtect and phantom. The existence of shell will make us unable to find the real entry point of the program, so that we cannot correctly analyze the disassembly program, and it will play a protective role for the program. Next, let's take a look at the differences between a program with and without shells and some features with UPX shells. At the same time, we can also understand the structure of the PE file. Before starting, we should first prepare the tool, including UPX1.24 (Win32 console version+ollydbg+lordpe, to compile a self-compiled vcpus applet (in this example, the program is named dasmtest.exe, no dll, there is a button, and a "hello" dialog box will be ).
This UPX version is a console program, that is, we need to use it in DOS or command line. If you shell the source program on the command line, you will see a prompt about the compression rate, file format, and successful shelling, as shown in 1. Note that the file name after the UPX command must carry the exe extension, otherwise the error "file not found" will be reported.
Figure 1
For source EXE files without shelling, the size is 20 KB, And the size is 6.5KB after shelling. Use LordPE to view the related content of the two files, as shown in figure 2 and Figure 3. Through the comparison of the two figures, we can see the important changes after shelling: program entry point (EntryPoint) and number of file blocks (NumberOfSections). Of course, file alignment) and the image size (SizeOfImage) will also change.
Figure 2 source EXE
Figure 3. EXE after shelling
The change in the program entry point (EntryPoint) after shelling is the place where this shell is bothering us. Click the LordPE Sections button to view the block information of the two files, as shown in Figure 4 and figure 5. It can be clearly compared that the block names of unshelled source files are all block names of a normal PE file (note, if the debug version is selected when the VC ++ program is released, there will be a reloc Section). After shelling, there are obvious traces of UPX. UPX re-organizes the blocks, and the VSize (Virtual size) and Roffset (relative offset) are also complete.
Figure 4 source EXE
Figure 5. EXE after shelling
Let's take a look at the debugging information with OllyDbg. As shown in 6, the source EXE program is debugged at the normal entry point of 00401700 (the information shown in Figure 2), and the module is in dasmtest (the title bar shows module dasmtest ). The program after shelling is debugged at the 004069B0 entry (the information shown in figure 3), and the module is still displayed in dasmtest (the module dasmtest is displayed in the title bar ), obviously this is not the real entrance of the program, but some confusing information. To find the real entrance in the file after shelling, we have to track the address shown in figure 8. The "JMP dasmtest.00401700" at 00406B08 will jump to the real entrance of the program. After the jump, it will be the same as the source program disassembly code that we did not shelling.
Figure 6 Source EXE
Figure 7. EXE after shelling
Figure 8. EXE after shelling
So far, we can summarize the changes made to the program in the UPX shell: file size, program entry point, program block name, and program debugging information.
In fact, it is very easy to find out the real entry address of the UPX shelling file in OllyDbg. In Figure 7, the first sentence is PUSHAD, which is the shell in the field environment protection, in the OllyDbg, you don't need to trace data. You just need to flip down the screen and see "POPAD, JMP ********", which is the real entry point. In the next sentence of POPAD, we can press F2 to set the breakpoint so that the program runs here at the beginning. Then, we can bypass the interference of all the shells above.