In this section, you will understand the techniques to identify the OEP in the packed binary. In the following screenshot, examining the packed binary in pestudio (https://www.winitor.com/) shows many indicators that suggest the file is packed. The packed binary contains three sections, UPX0, UPX1, and .rsrc. From the screenshot, you can see that the entry point of the packed binary is in the UPX1 section, so the execution begins here, and this section contains the decompression stub that will unpack the original executable at runtime. Another indicator is that the raw-size of the UPX0 section is 0, but the virtual-size is 0x1f000; this suggests that the UPX0 section does not occupy any space on the disk, but it occupies space in memory; to be specific, it occupies a size of 0x1f000 bytes (this is because the malware decompresses the executable in memory and stores it in the UPX0 section during runtime). Also, the UPX0 section has a read, write, execute permission, most likely because after decompressing the original binary, the malicious code will start executing in UPX0:
Another indicator is that the packed binary contains obfuscated strings, and when you load the binary in IDA, IDA recognizes that the import address table (IAT) is in a nonstandard location and displays the following warning; this is due to UPX packing all the sections and IAT:
The binary consists of only one built-in function and only 5 imported functions; all these indicators suggest that the binary is packed:
To find the OEP, you will need to locate the instruction in the packed program that transfers control to the OEP. Depending on the packer, this can be simple or challenging; you will normally focus on those instructions that transfer control to an unclear destination. Examining the flowchart of the function in the packed binary shows a jump to a location, which is highlighted in red by IDA:
The red color is IDA's way of saying it cannot analyze because the jump destination is unclear. The following screenshot shows the jump instruction:
Double-clicking on the jump destination (byte_40259B) shows that the jump will be taken to UPX0 (from UPX1). In other words, upon execution, the malware executes decompression stub in UPX1, which unpacks the original binary, copies unpacked code in UPX0, and the jump instruction will most likely transfer the control to the unpacked code in UPX0 (from UPX1).
At this point, we have located the instruction that we believe will jump to the OEP. The next step is to load the binary in a debugger and set a breakpoint at the instruction performing the jump and execute until it reaches that instruction. To do that, the binary was loaded into x64dbg (you can also use the IDA debugger and follow the same steps) and a breakpoint was set and executed until the jump instruction. As shown in the following screenshot, the execution is paused at that jump instruction.
You can now assume that the malware has finished unpacking; now, you can press F7 once (step into), which takes you to the original entry point at address 0x0040259B. At this point, we are at the malware's first instruction (after unpacking):
