Hi, everyone

I'm new at cracking .NET applications.
My first target is easy to decompile with ILDASM and the code is pretty readable even though I'm new to the framework platform. However, I'm missing a decent opcode list and, most of all, a program where I can see the opcodes together with the disassembly so I can study the code and get to know where to patch and which new opcodes to replace the original ones.

Anakrino crashes here and IDA 4.15 doesn't seem to load the target DLL.
I would appreciate any help on .NET "opcode-lists" and tools to see/change bytes in .NET applications. I have already searched both this forum and Google but didn't find any tool which can help me. A tool like the p-code debugger from my old friends from WkT! would be extremely handy for this task.

I'm currently downloading M$ SDK, but would love to use any other tool which doesn't come from them.

Thank you all in advance for your time and your kind help.
Happy cracking!

Mr. BlacK

i think your point is good.. but will be better if your primary purpose will be knowledge instead of cracking ... i'm looking too for any info. on how to reverse bytes , like any other app. VB , delphi .. , with use of ahex editor ... is this possible?? i got Ildasm + a tool made by Yoda to get detailed information of the structure.. but what about adeep analisys like W32dasm gives or IDA gives what exactly can be reversed with this .NET applications?? cuestions is .. is it possible to patch this kind of applications? how? what tools can be used?? ..i saw some comments about patching the Framework libraries used.... is that the only solution ?

Regards

i created this tool last year for .NET lookup tool.
hxxp://biw.rult.at/tools/dexil.zip

have fun.

>is it possible to patch this kind of applications?

Some guys in Biw has crack some .net protections

http://biw.rult.at/tuts/crackmenot_tut.rar

Regards

For the people who have tried both tools, how does IDA compare to ILDASM when disassembling .NET programs? Won't IDA show any opcodes, like with normal programs, if you activate it from the options?

Hi everyone.

I've been playing around and had some success. I used IDA 4.51 + ILDASM + .NET deflector. Each of these programs have something which the others don't have, and combined, they make reversing .NET applications much easier.

I was using a foreign version of ILDASM, which made me unable to see that there was an option to see the bytes corresponding to each instruction. This, combined with the ability if .NET deflector to decompile some classes and the clean and intuitive new interface of IDA, really helped me a lot.

I have just done some basic jump patching to bypass checks in binaries which don't have the "tampering check" enabled (this topic was covered somewhere on this forum), so I guess it's too early to make out any conclussions, but my first impression is quite good, even though I haven't even used the SDK debugger yet, for example.

Let me know if I can be of any help to any of you starting this subject too. My knowledge is very basic, but I am willing to share what I know with whoever is interested on this.

And the last, but not the list, I have to accept that the way I requested for help may lead to some kind of misunderstanding. I associate inside my head cracking with learning and my main interests are learning, having fun, and sharing my conclusions with the rest of you. Please excuse me if my first post didn't show my intentions in the correct way.

BTW, I'm still missing an "opcode" list for the .NET framework.
Were you able to find any?

Thank you all for your replies. I will check those links posted.
Happy cracking!

Mr. BlacK

Well, I tried the links.

Both tutorials at BiW reversing are very interesting and dexil is a great help too, thank you!!!

I have to explain that when I patched the binaries, I did it the old way, that is, I patched one kind of jump to another ( 2B - 2C - 2D are the possible IL opcodes for jumps I have seen so far ). IDA (4.51) will show the opcodes too together with a handy arrow system very useful to track jumps, and .NET Deflector will sometimes dump a very accurate decompilation of the IL code.
When .NET deflector fails to decompile, disassembling is quite ilustrative too.

Take a look at all of these programs and some other posts/tutorials on .NET reversing and you will see it's quite easy. The dead listing approach reminds me a lot to the one related with Visual Basic p-code applications. I guess that with some more knowledge on the .NET framework itself it will be easy to play with .NET binaries.

Another question which arises is if EXE packers will work with .NET binaries or if a new generation of packers must be created, which may make these applications *EVEN* slower. I will try some UPX now to answer to this point.

Please let me know your conclusions too and thanks for your help and time.

Mr. BlacK

Mr. Black i was searching for this tool ".NET deflector" without success .. where can i find it?

He probably means ".NET Reflector":

http://www.aisto.com/Roeder/DotNet

For anyone interested in this "tampering protection" (strong name signatures), here's that old thread discussing it:

http://www.woodmann.net/forum/showthread.php?t=4389

Yes, sorry, I mistyped the name. It's .Net Reflector, as dELTA already pointed out. It seems to be a great tool, but it lacks (or I haven't been able to find it) the ability to show IL opcodes and sometimes the decompiler fails. Anyway, it really surprised me. Give it a try!

I also recommend reading some previous topics on .NET, particularly the ones about strong signatures (http://www.woodmann.net/forum/showthread.php?t=4389) and .NET debugging (http://www.woodmann.net/forum/showthread.php?t=4459), the two BiW tutorials about dotNET reversing at http://biw.rult.at, and the article about IL itself already mentioned in some other post, located at http://www.macadamian.com/column/assemblies.html

Enjoy yourselves

@Delta

There are two basic types of MSIL (miscrosoft intermediate language) disassemblers.

ILDASM, Reflector and the like use the Reflection api to disassemble a dot net assembly.

IDA does not use the reflection api, instead it examines the bytes of the dot net assembly to disassemble.

The distinction between the two methods above is useful because many of the current crop of dot net protectors have the ability to stop disassembly via the reflection api. This is achieved by placing invalid meta data in the CLR (common language runtime) header of the file. This meta data is ignored during the execution of the program so it runs fine.

@Mr_Black

For a listing of MSIL opcodes, there were documents that shipped with the initial beta release of Visual Studio .Net. These contained the info you wanted. The document name escapes me atm, but i will try to remember to look it up for you. There is also a MSIL chm book around as well.

ZD

i see these kind of applications are getting in used almost frecuently from some author to avoid reversing.. what else could be?? i don't see nothing special by coding using this Net framework crap .. applications just runs slowly + needs 23 MB of framework crap libraries to run out.. give me abreak

but imagine all program will be coded using this... the situation could be dangerous for us (reversers) so i'll hope more tools up+ todate will arrive for this.. more tuts + knowledge to kick once again Microsoft monopoly and his .net frame stuff

we'll see more program using this... author are thinking this can't be cracked ... bullshit . we're getting use to it...let's hope the really good programs we had bought or we use freely won't use this for our speedy needs... imagine an application coded with this and Using Xtreme Protector...

LOLLL

Hi. First to thank master zacdac for his explanations, which clarify why my target "couldn't be decompiled" with Reflector. I'll search info on those obfuscators, because it would be nice to code some anti-invalid data tool to play with

I also have to say that I totally agree with cRk. My test target is an internal beta build of a quite famous iRC client recoded in .NET. Even though it's a beta, which will be optimized, the code takes too long to load and sucks a lot. The organization of the DLLs reminds me a lot of the Java classes. It seems like we will have to start thinking of the future as a Virtual-Machine powered one: damn slow, but multi-platform. At least, once we get to know how to reverse these programs, I guess we will be able to play with different Operating Systems, which is always fun. Maybe it will be a good way to attrack crackers to the magical world of *N?X cracking

While so, it's time to study and learn.
zacdac, I will search too, but please let me knoe if you put your hands on some of those books/docs you just wrote about

Thanks for the answers.
It's nice to see people sharing the same (cool ) interests.
Happy reversing!

To find the opcodes, this kind of site :
http://dotnet.di.unipi.it/EcmaSpec/PartitionIII/

is very useful

Have a nice day !

Wow, thanx SynApse.
That's a very good resource!

The offline version is available at http://dotnet.di.unipi.it/ecmaspec/ecmaspecs.zip

Thanks again!

I would appreciate any help on .NET "opcode-lists" and tools to see/change bytes in .NET applications

.NET is related to OS
"opcodes" is related to processor. Big difference

yeah, i agree with The-Svin.
i would not call the opcodes of msil an real opcode.
the .NET is just a stupid VM.. another java steal off.
and i too wonder why we need VM on our real machine and runnning 20k app which takes 10sec to run while we can code 2k app in asm and run in 1ms
something went wrong in the mind of m$ programmers.
ah well.
they do shape the world as they see, sad but true.

Well, what would you call them then? In Java, they are called "bytecodes" anyway.

I have it on good authority that dELTA knows his "Beans" and we're not talking coffee here.

Regards,

bytecodes sounds better. not confusing

Here's something that shouldn't be missing from your .NET cracking toolbox: Mono. ( hxxp://www.go-mono.com ). Freely available implementation of a .NET runtime including source.

I'm afraid that this will be unstopable.. as some of the newer API's of Longhorn & Avalon will only be accessible from the .NET runtime. So people will be forced to make .NET programs.

As for the speed issue.. in .NET you can use Ahead Of Time compilation, meaning you have native x86 code that you run, just like a normal .exe program.

finally this just comercial business between microsoft monopoly and the hardware manufacturers .. each time a new OS comes they all need more RAM & more faster computer .. and then people have to BUY .. i'm not saying this won't be future way the software will be.. but in my case i will look for something different than Billy crap and will stay using old Way ..making and application in this way wouldn't be better .. and i'm sure many people don't like .NET stuff .. i have used someof them as soon as i see how slow they works i end up uninstalling right away..

WinXP . Win2003 ..... new oneswill come ... but noone of Them will Survive Reversing and neither BUGS ..... Longhorn ??

i WOnder how many service packs and security patches will be done for that one

this is all Business my friend

Regards