Hello.

I wanted to have a small discussion on different viewpoints in breaking .NET apps. Considering that I am still in 'spelunking' mode with .NET apps, kindly excuse my naivete, that may, occasionally, rear it's head.

PINPOINTING:
==========
Currently, I am using the classic (and quite personally fulfilling) way of opening up the same in IDA, but NOT as .NET code, but with PE.LDW. This invariably results in absolutely NO disassembly in IDA, but that's OK. I then RUN the app under the default IDA Debugger, breakpoint or pause at interesting areas, and take memory snapshots, including the debug sections. Then, the code location and understanding begins. Most encrypted .NET apps are not a problem when run this way. If it's too bothersome, I simply run the app, then attach the debugger later on. Bottom line, I get the results that I want.

PATCHING:
========
Patching is a bit trickier. I patch it normally, as with any hex editor, going and modifying the app DLLS, as well as the .NET framework DLLS (depending on the versions of .NET - though anything above 1.5 version needs the modifications now needs .NET system DLLs modification) and am *generally* running about merrily. I FIRST try to patch the system DLLs via a loader patch (in-memory patch, if you will) and if that does not work out, I do it physically to the .NET DLLs. All this is done in a VM using VMWARE so that I don't worry about messing up my system (though I wouldn't be surprised if one day MS decide to integrate .NET into the boot loader, causing boot errors if the .NET system is modified - but I digress). At other times, I admit I feel lazy and will do a modification while running IDA PRO from within the IDA debug window itself and modify things there - though with *considerably* less success than the previous methods. Of course, I don't use Olly myself (not a patch on its capabilities - just a matter of choice, I assure you). And if push comes to shove, I bring out Windbg.

While my methods are effective, I feel quite "unshaven" when using them. Somehow, I cannot help but think that I am compromising something, somewhere, missing a more efficient and better method of breaking AND patching a .NET app. Or think that what I am doing (or the tool I am using - IDA and a hex editor) are not quite the BEST of ways.

I am not *THAT* interested in decompiling .NET binaries because of associated problems of refactoring or decompilation prevention code (and the fact that most .NET decompilers are not around for as long as a disassembler like IDA). I am, rather, interested in understanding how *YOU* crack .NET binaries (locating the offending code AND patching. Both!). However, if you've got an interesting .NET decompiling trick, by all means share it.

I feel, somehow, that there is an infinitely better way, someone out here knows, that is so much better than my crude and primitive method of hunting and patching. I'm using club and spears, wearing animal skin around my waist and drawing illegible etchings on cave walls. What I want to know if anyone here has any hunting rifles with scope and massive bullet coverage distances that can hunt animals more efficiently. Comprende?

Thanks for listening.

Have Phun

Wait, why are you patching .NET system libraries? 0o

For decompiling/patching use Reflector or ILSpy. Locate the code you want to change in the decompiled C#, then switch to IL. Then decompile the .NET file with ILDasm, locate the IL you want to patch, patch it, then use ILAsm to reassemble it. Then you're done.

If the app is obfuscated use de4dot to remove the obfuscation. If the app is encrypted use netunpack (http://www.ntcore.com/netunpack.php) to dump it from memory. If its encryption is clever and hooks the JIT to decrypt (http://www.ntcore.com/files/netint_injection.htm) consider using Rebel.net to dump it (http://ntcore.com/rebelnet.php), or write an Ollyscript/plugin/your own hook to do it. If the app is compiled to native code with Salamander Protector, look for leftover IL code using my trick here: (http://www.woodmann.com/forum/entry.php?68-Rebuilding-native-NET-exes-into-managed-NET-exes-by-Exploiting-lefotver-IL)

If you need to debug the IL/native code of a .NET application, there is nothing better than Windbg and Sosex. Here are some tutorials for that:
http://naveensrinivasan.com/2010/04/21/exploring-sosex-to-debug-net-4-0/
http://www.jayway.com/2011/04/26/getting-started-with-managed-dump-files-using-windbg/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+jayway%2Fposts+%28Jayway+Team+Blog+-+Posts%29

^All of that should be enough to deal with 99% of .NET applications.

Cheers,

-rendari

To overcome strong name protections.

Obviously, I can replace the public key with my own (which works - sometimes), but that's too much of detailed work for me, and I am not a encryption specialist. Thence, to my simple mind, this is the only other way. Messy, maybe. Effective, mostly.

It would be smashing if you could provide other ways (hitherto not depending on a version vulnerability) to bypass strong names, though I understand 3.5 and above you can just simply bypass strong names by creating a .exe.config file having the following code, though I've not verified it personally:



Have Phun

http://www.woodmann.com/collaborative/tools/Category:.NET_Signature_Removers