Polymorphic engines, in managed languages?

Question

Hey, I have developed my programming skills to a point where i can do most everyday stuff quite well and easily, and I thought one day, that making a polymorphic engine would really test my skills, and I was wondering if anybody had any pointers on making a polymorphic engine for a program, where to start, maybe some code examples? really anything would be helpful at this point :)

here are some of my resorces:

• http://en.wikipedia.org/wiki/Polymorphic_code <- this is the one im particularly interested in..
• http://en.wikipedia.org/wiki/Polymorphic_engine

Answer 1

Well, as far as I know a polymorphic engine is just the code you want run encrypted, then pair that with a decryption module. So all you need to do is encrypt your code into a string. Then you write a decypter. I would use a basic symmetric encryption class like hxxp://www.obviex.com/samples/Code.aspx?Source=EncryptionCS&Title=Symmetric%20Key%20Encryption&Lang=C%23 After that, run the code in memory, something like hxxp://support.microsoft.com/kb/304655

EDIT: If you wanted to get more indepth, you could always write your own encryption/decryption, make it something like base_64 (no key), instead of AES (with a key)

Hope that helps, Max

Answer 2

Polymorphic code is not possible in C# or managed languages. It requires you to produce assembly code for a specific platform (.NET is not platform-specific) into a buffer or data area, then jump into that buffer or data area. There are many layers of software and hardware in place to stop that happening - see the NX bit on Wikipedia for example.

You can't do it in managed code. You'd have to write it in unmanaged code and call into that.

Hope that helps.

---

Please see the helpful comment on this answer, as you can dynamically create managed code from managed code; I was considering unmanaged code, as is used on the whole.

Answer 3

As I mention in a comment, this is possible in .NET using the magical System.Reflection.Emit namespace. You just create a new DynamicMethod and emit any [valid] opcodes into it, and then call Invoke.

I've spent the last few hours trying to build a simple showcase for a "clean" program that would create new copies of itself with encrypted il code. The approach I went for was having an Exec method, grab the il-bytes (using MethodBase.GetMethodBody), encrypt them and emit a new assembly having the iv+key and the encrypted bytes. The main method would then decrypt, create a new DynamicMethod, call DynamicILInfo.SetCode and hopefully work. It didnt.

The encryption/decryption thingie worked, and my emitted code was correct. However, it seems that you can not take the raw bytes from one assembly and just execute them in another.

Data (from BitConverter.ToString) from run A and run B.
A: 28-01-00-00-0A...
B: 28-11-00-00-0A...

Unless you know the byte values for every opcode, open ILDAsm, choose View > Show bytes. There's also a View > Show token values which also helps debugging. Press ctrl-m for View > MetaData > Show! to resolve tokens and other magical creatures.

"28 01 00 00 0A" -> CALL 0A000001 -> [According to ctrl-m] MethodBase.GetCurrentMethod

These different token values are generated sequentially by the compiler. This means that it's impossible to guarantee that everything will work using raw bytes. Just think of the common case where the compiler only created tokens for every method call require to decrypt your byte array, and you call Console.WriteLine in your encrypted code. No such token is written, and you'll end up with a "BadImageFormatException: Bad binary signature" when invoking your dynamic method.

I leave it as a task for the read (or until I'm bored again) to transform the byte array, during the emitting process, to a format which the decryptor can read and emit to real il bytes. The emitting process will create all necessary tokens, so it should work.

If you want to chicken out from all the awesomeness of emitting opcodes, do some dynamic compilation from code stored as strings (which can of course be encrypted). This, however, lose in both cleverness, coolness and everything else that can be used to measure the pure awesomeness of the developer (YOU!). Check out this tutorial for a quick display of dynamic compilation and execution of C# within strings.