Koyuta, one thing you must understand is that .Net applications are not compiled to native code, they are compiled to Microsoft Intermediate Language (MSIL). As such, the file analyzation tools (disassemblers, PE editors, hex editors, etc) you are used to working with are useless (pe explorer, ultraedit, ida, windasm, etc.). You need to use tools made for MSIL. .Net apps are compiled to native code by a JIT (just-in-time) compiler when you actually run the application. Once a .Net application is running, because it has been compiled to native code at that point, you can attach to it with your debugger of choice. But, this won't do you much good as far as cracking it goes, because you need to patch the MSIL bytes, not the native code it JIT compiles to.

Fortunately, the .Net Framework SDK and Visual Studio .Net come with everything you need. As I mentioned before, ildasm.exe disassembles a .Net app into MSIL code so you can see it on its lowest level. (MSIL looks somewhat like asm, but is much higher level, so it isnt too hard to figure out) Then you can change the MSIL code, and recompile it using ilasm.exe if you dont want to patch the IL bytes directly.

If you have a .Net app compiled in debug mode, you can use DbgCLR.exe and debug the app seeing the MSIL code instead of the native code. Because MSIL is still much higher level than asm, this is much easier.

Anyway, you really need to read up on .Net, CLR, and MSIL. If you don't understand how they work, there will be far too much to explain concerning how to crack a .Net app. Just the same as it is necessary to know asm before cracking a normal app. If you already have a good understanding of .Net, you will see that cracking a .Net app is very easy.

I am moving houses tomorrow, so it may be a while until I have time to do the tutorial. But I will definately do it, eventually, unless someone else does one first.