3

I am working on PE segment encryption(in C++). I completed the PE32 .text segment encryption. I added stub segment to the PE that will decrypt .text segment at runtime. Used inline assembly in the stub function. But I can't implement the same method in PE32+ executable(64bit exe) as it won't support inline assembly. I am able to add the stub and encrypt the text segment.

Issue is with the decryption logic in the stub.

I tried adding separate .asm files but failed as I am new to assembly language. Is it possible to do without assembly language? Please help me with any good documentation or samples on PE32+ segment encryption.

Improve this question
1
  • You give very little information about how your encryption scheme currently works. As an example, it is customary in some runtime packers/obfuscators to offload stuff like allocating sufficient memory to the PE loader. This can be done by adding sections which have no file content, but have a size (and appropriate protection flags) in memory. To determine the base address oftentimes in runtime packers/obfuscators one would count down at the WORD boundary, looking for MZ ... then trying to take it from there, carefully parsing the PE (aware that the MZ may be a false match).
    – 0xC0000022L ♦
    Commented Jan 3, 2022 at 15:37

2 Answers 2

Reset to default
1

You don't need the assembly language to add a decoder stub for the .text section. You can just write the code in C/C++ compile it as a Position independent executable & extract the ONLY .text section it'll have. After that you can just use a normal PE editor (CFF explorer is pretty robust) to manually add the .stub section and paste the content of the .text section extracted from your position independent compiled code. If you don't wanna go into trouble of creating Position independent code you can just use Position Independent Shellcode available on github.

Improve this answer
-1

If you're going to use assembly stubs, you can just patch it directly to the binary. You don't really need to use c++ to do that for you.
To do that for both 32 and 64 bit, you can use CreateFile, CreateFileMapping, and MapViewOfFile. This will allow you to dump the .text section, basically all sections, of the PE and you can do whatever you want to it. Then you can add a function to decrypt it or whatever and/or write a stub to do the decrypting portion of it in a space big enough to fit that stub or just add another section to the PE

Improve this answer
5
  • Thank you. I am not trying the assembly code now. Is it possible to get some sample code/documentation links for 64bit encryption? Because all the docs I found is for 32 bit. When I tried to apply the same in 64bit, it is not working as expected.
    – AcCoder
    Commented Nov 11, 2019 at 4:14
  • Oh boy, there's a LOT of sources out there for encryption. For you, I would recommend something as simple as a XOR encryption. Once you map out the binary, you can iterate through each section, usually the .text section, and then for each byte in that section, you can XOR it with whatever key. Once you have that, save the new XOR'ed bytes into the binary that way your stub will be able to decrypt it with the same key you used to encrypt it. This is more than enough information to get you going.
    – Jon
    Commented Nov 11, 2019 at 6:38
  • Thank you very much for the reply. But my issue is not with the encryption or decryption. I am able to encrypt the .text segment and added the stub as entry point. I am trying to load the PE sections into memory, decrypt the .text segment there and execute it from memory. It is not happening. I am trying to get a proper way to load, decrypt and run 'PE64' from memory using .stub segment as PE entry point.
    – AcCoder
    Commented Nov 11, 2019 at 9:46
  • I will try the CreateFile,CreateFileMapping and MapViewOfFile as you suggested.
    – AcCoder
    Commented Nov 11, 2019 at 9:53
  • How exactly will CreateFileMapping and MapViewOfFile help at all for this purpose? Remember the inquirer is asking about decrypting something on-the-fly (first thing at runtime). At that point the PE loader in ntdll.dll has already done exactly what you're suggesting in your answer. Given that the encryption evidently requires some post-processing of the pristine "source" (PE) file, it would be easy to store offsets between the stub code and the base address during "encryption". Another common method is to search the MZ of the IMAGE_DOS_HEADER then use that.
    – 0xC0000022L ♦
    Commented Jan 3, 2022 at 15:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.