Encrypting Programs - How does that work?

[Tsar]

Anyone know how encrypting programs work? What I am talking about is making a program "FUD" from AVs for example.

How does an AV detect if a program is malicious? and how does encrypting it make it undetectable?
Does encrypting an exe have any other use other than hiding stuff from AVs? Does it help protect from people's programs from being reverse engineered?

Interested in how this works. I think it would be pretty cool if EZ made our own crypter, I'm a pretty good programmer, but I have no clue how crypters work and how they work with regards to the AV.

If you can add some insight thanks!

[ca0s]

I am going to explain the few I know about this topic.

There are variuos types of program encryptions.
First, the basic and old xor'ing method, which xors all the bytes of the executable and puts them after a "stub" which xors them again, so the original code is got, and then executes it (http://evilzone.org/c-c/%28c%29-simple-crypter-stub/).

This method is easily detected, so xor'ing was replaced by more complex encryption algorythms.

Decrypting the executable, writing it to the hard disc, and then execute it makes it easier to detect by AVs, so the next step was executing it directly from memory. This requires a good knoweldge of the executable file structure (PE/ELF). You have to virtually build all the file headers, and then launch the in-memory decrypted executable code.

After this, there are other methods, like obfuscating the code. This is done by adding garbage wich confuses AVs (and people who might try to debug it. This answer to one of your questions: executable files encryption makes things a lot harder for reverse engineers, if done properly.

To detect malware, AVs have two methods: static analysis and runtime analysis (heuristics). The first one simply checks for pre defined data chunks in the file (called signs) and if found, it says malware found. The second one is more complex, and it is based on a control of what the program is doing. If it detects that a program tries to open another process memory and touch its memory in the winapi zone (give a look to this: http://evilzone.org/hacking-and-security/injecting-code-in-another-process/msg936/#msg936), it will say that it is malware.

About an EZ crypter, it will be great. But I think we will had to learn a lot before making something decent.

I had some tutorials and info sheets about this topic, now I don't have access to them, but if I find them I will upload.

I think that is all

[Tsar]

I am going to explain the few I know about this topic.

There are variuos types of program encryptions.
First, the basic and old xor'ing method, which xors all the bytes of the executable and puts them after a "stub" which xors them again, so the original code is got, and then executes it (http://evilzone.org/c-c/%28c%29-simple-crypter-stub/).

This method is easily detected, so xor'ing was replaced by more complex encryption algorythms.

Decrypting the executable, writing it to the hard disc, and then execute it makes it easier to detect by AVs, so the next step was executing it directly from memory. This requires a good knoweldge of the executable file structure (PE/ELF). You have to virtually build all the file headers, and then launch the in-memory decrypted executable code.

After this, there are other methods, like obfuscating the code. This is done by adding garbage wich confuses AVs (and people who might try to debug it. This answer to one of your questions: executable files encryption makes things a lot harder for reverse engineers, if done properly.

To detect malware, AVs have two methods: static analysis and runtime analysis (heuristics). The first one simply checks for pre defined data chunks in the file (called signs) and if found, it says malware found. The second one is more complex, and it is based on a control of what the program is doing. If it detects that a program tries to open another process memory and touch its memory in the winapi zone (give a look to this: http://evilzone.org/hacking-and-security/injecting-code-in-another-process/msg936/#msg936), it will say that it is malware.

About an EZ crypter, it will be great. But I think we will had to learn a lot before making something decent.

I had some tutorials and info sheets about this topic, now I don't have access to them, but if I find them I will upload.

I think that is all

So essentially you are encrypting your program, then binding it to a stub, which will then, upon executing, decrypt your executable and run it?

[ca0s]

Yes, in the first case and in the example crypter I gave to you. But nowadays there are more complex crypters which don't use stub, they put their decryption routines and code obfuscation in a in-memory mapped file. There are really crazy coders

[ande]

Don't forget it is possible to modify existing executables, by modifying the machine code or assembly code if you will(as there is a one to one translation between asm and machine code). However, this is a hell of a lot more work

[Tsar]

I guess this is hard to look at without given an example of what would be encrypted.
For example, most malware just uses whatever it is binded to as a a vessel, then extracts itself and moves somewhere else, setting itself to be running all times in the background.

This is tricky, because we may be able to encrypt it to protect it from first time scans, but if we encrypt it and launch a new process that is decrypted it will most likely get caught.

The only good method I can think of would involve it overwriting itself, can an exe even overwrite itself while it is running? And even if it could it would need to re-encrypt itself before closing.

Ugh!

Anyways I think we could defiantly make a good encrypter that protects from static analysis at least.

[iMorg]

If the permissions of the process are set right than you can have the exe work on itself. The best way to keep it undetected upon decryption is using a polymorphic engine to switch around and change the actual code.
 

[Huntondoom]

using a polymorphic engine to switch around and change the actual code.
 

can you explain how such a thing works?

[Tsar]

If the permissions of the process are set right than you can have the exe work on itself.

That's what I figured, but I think it would be safe to assume the exe wouldn't have permission in most cases

The best way to keep it undetected upon decryption is using a polymorphic engine to switch around and change the actual code.

Good idea, another interesting way would be to have the decrypter act as a sort of interpreter.

Although I don't know if this exists or is even possible but if there was a way to tell your program to take a binary string and execute it (especially multiple ones at once/in a row without switching back so you won't have to deal with your registers getting messed up) it could be pretty easy. I know you can embed ASM into code, but what about straight up binary?

can you explain how such a thing works?

http://en.wikipedia.org/wiki/Polymorphic_code

Essentially mutates itself, upon researching it I also found a cool website with a ton of papers and stuff explaining various topics like this and also a bunch of libraries for using polymorphic code and more;
http://vx.netlux.org/

on polymorphic code:
http://vx.netlux.org/lib/apb01.html

Libraries: (although its probably safe to assume AVs detect them)
http://vx.netlux.org/vx.php?id=eidx

[ca0s]

Although I don't know if this exists or is even possible but if there was a way to tell your program to take a binary string and execute it (especially multiple ones at once/in a row without switching back so you won't have to deal with your registers getting messed up) it could be pretty easy. I know you can embed ASM into code, but what about straight up binary?

This would be like:
- Have some crypted binary code somewhere in memory.
- Open, read, decrypt.
- Assign execution permissions (if you are working in your own process you usually have this rights, this is only problematic if you are trying to inject your code in another process) with VirtualProtect (http://msdn.microsoft.com/en-us/library/aa366898%28v=vs.85%29.aspx).
- Create a function pointer and point it to decrypted code in memory.
- Launch that function.

It is not hard to make, but you have to be careful with the stack and registers. To work safely with registers you have the ASM instructions PUSHAD/POPAD, which save/restore them. About stack, you have to be very careful to execute more than 1 code row and don't make the process crash. It is a butthurt when a ret is executed and it pops a wrong address.

This is turning into a nice investigation/development thread, I like it

[Tsar]

This would be like:
- Have some crypted binary code somewhere in memory.
- Open, read, decrypt.
- Assign execution permissions (if you are working in your own process you usually have this rights, this is only problematic if you are trying to inject your code in another process) with VirtualProtect (http://msdn.microsoft.com/en-us/library/aa366898%28v=vs.85%29.aspx).
- Create a function pointer and point it to decrypted code in memory.
- Launch that function.

Nice the only problem I can see with that is then would be that it would have to encrypt itself upon exiting otherwise next time it was started it would be unencrypted and possibly detected by the AV.

This is turning into a nice investigation/development thread, I like it

I agree, these are the type of threads I like to see on EZ, discussions on interesting stuff, problem solving where everyone gives input, etc

[ca0s]

Nice the only problem I can see with that is then would be that it would have to encrypt itself upon exiting otherwise next time it was started it would be unencrypted and possibly detected by the AV.

No! Decryption process would be done in memory! It has not to crypt itself again, as the binary would stay always crypted.
Also, a good Idea would be to change the crypt key in each crypted block of code, getting the next key from the previous decrypted block. Well, this is a good point to start coding, isn't it?

[Tsar]

No! Decryption process would be done in memory! It has not to crypt itself again, as the binary would stay always crypted.
Also, a good Idea would be to change the crypt key in each crypted block of code, getting the next key from the previous decrypted block. Well, this is a good point to start coding, isn't it?

Is it possible to create a function in memory? I'm unsure how it would work. Lets say we read the encrypted bytes of the exe in, and store them in chars, decrypt them and have the binary instructions all decoded, how would you then go about executing the instructions in memory?

[ca0s]

Is it possible to create a function in memory? I'm unsure how it would work. Lets say we read the encrypted bytes of the exe in, and store them in chars, decrypt them and have the binary instructions all decoded, how would you then go about executing the instructions in memory?

Take a look at the post I put (inyecting code in another process). It is something like that. In C pseudocode would be:

void *code=malloc(sizeOfCode);
decryptCode(code, cryptedCode); // Decrypts crypted code in cryptedCode in code
DWORD prot; // This is needed for the next function
VirtualProtect(code, sizeOfCode, PAGE_EXECUTE_READWRITE, &prot); // Execution privileges
void (*pFun)(void);
pFun=code; // We assign the pFun function pointer to our in memory decrypted code
pFun(); // And then call it!

This code might have errors, but I am too sleepy to care about it now. But that's it.

[Tsar]

Take a look at the post I put (inyecting code in another process). It is something like that. In C pseudocode would be:

void *code=malloc(sizeOfCode);
decryptCode(code, cryptedCode); // Decrypts crypted code in cryptedCode in code
DWORD prot; // This is needed for the next function
VirtualProtect(code, sizeOfCode, PAGE_EXECUTE_READWRITE, &prot); // Execution privileges
void (*pFun)(void);
pFun=code; // We assign the pFun function pointer to our in memory decrypted code
pFun(); // And then call it!

This code might have errors, but I am too sleepy to care about it now. But that's it.

I guess what I'm not quite understanding is when it is decrypted how is it storing the binary for calling?

I'm assuming to decrypt it you will
1. need to read it in somewhere
2. need to store that somewhere in a special way before calling it so it knows it is a function/exe/whatever.

Part I am confused about:
Decrypt()
-read in code, store in byte/char array (byte by byte)
-Decrypt the array
-??? Do we have to write the code somewhere, perhaps to memory, but how will it know it is code to execute and not say a char array or something?