Replacing Methods in Reflector

[Dave Prost]

Hi

I have a couple of methods that I've re-written and want to replace in the original executable but not sure the best way to do it.

One way I could see is to use reflexil and go through each module line by line but that will take ages. Another way I thought of, and this may be completely unrealistic, is to dump the IL and then simply replace the two methods with the new code. Then try to reassemble it. Like I said I don't even know if that's possible I was just 'free thinking'

Any help would be much appreciated.

Thanks

DP

[Kurapica]

this is possible ofc...

you can also add a new section to the exe and save the 2 new methods MSIL code in that new section, then you have to fix the RVA

of the the original methods in the "Methods" table to point to the new section, I think this is more elegant

[Dave Prost]

Thanks for the response Kurapica.

Can you point me to a tutorial that outlines what you're suggesting or give me a few tips please? I'm a relative newbie at this

DP

PS: The two new methods I would be adding already exist with the same names etc. Don't know if that's relevant but just thought I'd mention it.

UPDATE: I've looked in CFF Explorer and found the relveant parts for each module but now I'm stuck. I dont' know how to add a new section to the exe and then how to add the modules to that section. What tools should I be using etc?

Found this and going through it now: http://forum.ragezone.com/f562/adding-section-exe-cff-explorer-602984/

Cant' register to read the rest of the article as their system has me flagged as a 'spammer' for some reason Still stuck.

Edited May 18, 2011 by Dave Prost

[Kurapica]

I think using ildasm is more convenient in your case, just disassemble the 2 files and copy paste

the 2 new methods, playing with metadata tables requires some knowledge.

try and tell

[Dave Prost]

Again I'm not 100% sure what you mean. I've tried disassembling the main exe using ildasm and had to use 1.1 because all others failed. Then to test I tried to reassemble but it wouldn't work. Kept reporting error. I thought the easy solution would be to disassemble will ildasm then replace the two methods with mine. As I say I couldn't assemble it again.

Any clues or ideas much appreciated.

DP

[Kurapica]

Try uploading the 2 files here, otherwise I can't be more helpful

[Dave Prost]

Hi Kurapica - Thanks for the offer but I really want to try and do this myself. I want to learn and just giving the files to you won't help me to learn. I do appreciate your kind offer though.

Is the CFF solution really that hard to grasp? Is their any tutorial available that outlines it? Have you done such a tutorial?

Here's the two files I'm trying to merge. As I say I can't seem to assemble ANY il files for some reason so if you could use the CFF solution that would be great. Thanks for your help Kurapica

http://www.multiupload.com/3C0JK1URM1

Thanks for the help.

DP

Edited May 18, 2011 by Dave Prost

[kao]

Hehe, that particular software keeps appearing in different, shall we say, "help requests"?

You're going the hard and unnecessarily complicated way. Building new #US stream and replacing calls to string decryption routine with "ldstr" instruction is much simpler and more elegant solution. See my answer to previous request for that same product: http://forum.tuts4you.com/index.php?showtopic=25946

Problems that I see with your code:

* Your code has references to System.Threading namespace which is not used by original code. Adding that manually will be real pain-in-the-butt.

* Your code uses string constant (filename), which is not present in original code. You would have to add it to #US stream manually.

* C# generates code which refers to different functions. Function tokens in original code are different, so you'd have to fix them all manually anyway.

Summary - approach that Kurapica suggested works for small functions, but not for that significant changes as you're trying to do. If you insist on going your way, you really should switch to ILDasm/ILAsm.

You have really nice problem to solve.. Have fun!

kao

[Dave Prost]

[RESOLVED - kinda] - Well I finally managed to get ildasm and ilasm to work. Was able to replace the method and recompile. However when I then deobfuscate again the strings are not visible. Not sure where I went wrong but I'll figure it out. Thanks!!

Thanks for the feedback Kao. I'll study the other thread and hopefully arrive at a solution.

Kao can you elaborate on your comment "Building new #US stream and replacing calls to string decryption routine with "ldstr" instruction is much simpler and more elegant solution" please? I think that's kind of what I was trying to do but obviously dont' have quite the required skillset to pull it off I've already written a small app that will parse the IL file and replace the existing calls with there corresponding decrypted strings using ldstr. The problem though is I can't recompile the IL code. In fact I can't recompile ANY IL code from any application. I've used 4-5 versions of ilasm and all give errors about problems in the decompiled code. This is even with 'clean' files from other applications that I haven't even tried to manipulate the code.

Thanks

DP

UPDATE: I'd already done your #3 suggestion but was looking for a way to actually have the strings appear in the deobfuscated code which is why i was looking for a more elegant solution. I suppose I could just use my text file of 2500 strings but that seems a little clumsy.

Read a tutorial about making a reflector plugin and I think that's a little above my knowledge level just at the moment.

I'll keep pressing on with it for now but any other helpful advice or suggestions are always appreciated.

Thanks

Edited May 19, 2011 by Dave Prost

[kao]

Hehe, sorry. I'm always in a rush and tend to forget that not everyone has studied .NET internals back and forth..

Defeating string encryption in .NET assembly has 2 tasks:

1) you need to get all strings decrypted somehow;

2) you need to modify the assembly to use decrypted strings instead of encrypted ones;

From what you've posted, I assume you did #1 already. It's quite easy task, as I mentioned to PutterPlace's topic, it took me around 20 minutes.

Now that you have decrypted strings, there are several ways to fix the executable:

1) use Ildasm to disassemble the executable, modify IL code, use Ilasm to assemble it back. Unfortunately, it's rarely an option these days, there are lots of protection options that defeat or confuse ILDasm. I don't like this method because it can introduce nasty and hard to detect bugs, but it's also one of the easiest, if you can get ILDasm/ILAsm to work.

For disassembling you could try commandline "ildasm /all /utf8 /out:disasm.il yourexe.exe". It will generate huge disassembly file and all the resource files. One file will have unprintable characters in the name. Rename it to something like "encryptedstrings.bin" and fix all references to it in disassembly. Then try to assemble it with ILAsm. If that works, you can start modifying disassembled code.

2) you can try to replace string decryption method with your own method and encrypted strings with decrypted ones. I don't see much point in doing that - even after changes, decompiled code won't show decrypted strings. So why bother?

3) you can build new #US stream and replace all calls to string decryption method with the "ldstr" instruction.

According to ECMA-335 specification, user defined strings are stored in #US stream. I would take the executable, take the existing #US stream and add all decrypted strings to it, it's quite easy (See ECMA spec for #US format). Then I would use Rebel.NET (http://www.ntcore.com/files/rebelnet.htm) to replace existing #US stream with the new one. One last step, I would find all calls to string decryption function and replace them with "ldstr" instruction with correct arguments. It's a simple as search/replace for specific byte sequences. Probably hex-editor won't do the trick but a simple 20-line utility would suffice.

I'm running out of time now (again!), so I cannot make a detailed description on how to do that. But it looks like a good subject for detailed tutorial if and when I have some spare time.

Cheers,

kao.

P.S. Yes, I really like numbered lists. Everything must be in order..

EDIT: I re-read your last post. You want to add your decrypted strings to executable, just to run SAE again, so that it would deobfuscate strings?! Is Rube Goldberg some relative of yours?

Edited May 19, 2011 by kao

[Dave Prost]

Thanks once again for your feedback. A tutorial would be very useful for myself and others.

In the end I ended up replacing all the strings in the decompiled version and using that as a 'dead file' to trace the obfuscated file. It's working ok and I learned a few things along the way.

DP