In this topic, I want to talk about Anti-unpacking techniques.
As we know, one of the famous anti-reverse-engineering techniques is packing malwares. It helps the malware become undetectable by the AVs and complicated. The other advantage of packing malwares is that it reduces the final size of the binary. Most packers are easy to use and are freely available.
Nonpacked binaries are loaded completely by the OS; But in packed programs, the stub loader is loaded by the OS. Stub loaders, load the packed program in their memory space, unpack them and then the original program appears. After this operation, the original program which is loaded by the stub loader assumes the execution.
One of the most famous packers is UPX. It's open-source so that everyone can see how it packs and unpacks, how it is possible to prevent Unpacking procedure, what its stub headers are, etc.
You can pack your binary with UPX and then unpack it again using -D switch. But the malware should not become simply unpacked, right? How we can prevent the malware from being unpacked in the standard way using the UPX unpacker? One way is to overwrite the stub headers (l_info and p_info). Lets check out these header structures defined at address /src/stub/src/include/linux.h in the UPX source:
Look at the image and see if you can find the magic...
Yes. UPX! is the magic in the stub-loader and is considered by the UPX unpacker. So if we overwrite the magic, the headers gets corrupted and its not possible to unpack the program using the unpacker. Consider the changes made and the result of the upx unpacker:
As you see, we have corrupted the headers and the unpacker results an error. Well, a person that has enough knowledge of the stub, can easily fix the stub and change the bytes to the original ones. You have other choices too! Overwriting p_filesize and p_blocksize fields causes upx to crash. however, by reading the UPX source code, you can figure out how to use the size generated by the UPX unpacker that is compared with the mentioned fields in the binary. I've edited the corresponding part of the UPX source code at address /src/p_lx_elf.cpp on line 4995:
Now lets overwrite p_filesize and p_blocksize and use our new UPX unpacker:
Lets see whats the result of our own UPX unpacker:
Happy Hacking!
As we know, one of the famous anti-reverse-engineering techniques is packing malwares. It helps the malware become undetectable by the AVs and complicated. The other advantage of packing malwares is that it reduces the final size of the binary. Most packers are easy to use and are freely available.
Nonpacked binaries are loaded completely by the OS; But in packed programs, the stub loader is loaded by the OS. Stub loaders, load the packed program in their memory space, unpack them and then the original program appears. After this operation, the original program which is loaded by the stub loader assumes the execution.
One of the most famous packers is UPX. It's open-source so that everyone can see how it packs and unpacks, how it is possible to prevent Unpacking procedure, what its stub headers are, etc.
You can pack your binary with UPX and then unpack it again using -D switch. But the malware should not become simply unpacked, right? How we can prevent the malware from being unpacked in the standard way using the UPX unpacker? One way is to overwrite the stub headers (l_info and p_info). Lets check out these header structures defined at address /src/stub/src/include/linux.h in the UPX source:
Look at the image and see if you can find the magic...
Yes. UPX! is the magic in the stub-loader and is considered by the UPX unpacker. So if we overwrite the magic, the headers gets corrupted and its not possible to unpack the program using the unpacker. Consider the changes made and the result of the upx unpacker:
As you see, we have corrupted the headers and the unpacker results an error. Well, a person that has enough knowledge of the stub, can easily fix the stub and change the bytes to the original ones. You have other choices too! Overwriting p_filesize and p_blocksize fields causes upx to crash. however, by reading the UPX source code, you can figure out how to use the size generated by the UPX unpacker that is compared with the mentioned fields in the binary. I've edited the corresponding part of the UPX source code at address /src/p_lx_elf.cpp on line 4995:
Now lets overwrite p_filesize and p_blocksize and use our new UPX unpacker:
Lets see whats the result of our own UPX unpacker:
Happy Hacking!
