Ilasm.exe (MSIL assembler) and ildasm.exe (MSIL disassembler) that come with the MS.Net Framework SDK are all you need. For debugging, use DbgCLR.exe that comes with Visual Studio.Net.I have cracked/keygenned quite a few.Net apps now, but it has become somewhat boring because it is so easy. There is not much of a challenge in that area. Unpacking is definately much more fun!What.Net program is it that you are trying to crack? If it is one that I have already done, I may write a tutorial on it if I have the time. 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. Quote:Added 14May2003.NET programs are designed to operate together easily, and use a standard interpreted language. Because of this, they are even more difficult to protect than non.NET ('unmanaged') programs.
Farpoint Spread 8 Serial Number
We have an idea how it could be done, but we'll need to some time to experiment with it and see how useful it might be - we don't know when we might get the time necessary to do this. Armadillo cannot protect such programs at present.If you understand that limitation, but still want to use Armadillo for licensing purposes, it can be done. You'll need to make an 'unmanaged' DLL (i.e. A non.NET DLL), which you can protect with Armadillo, and somehow make your.NET program dependent on that DLL, so that it cannot run without it. Then just use the licensing portion of Armadillo normally, for that DLL.This means, you must include unmanaged portion into your.NET app and Arma just protect it and can do nothing to.NET assembly. Koyuta (and any others who are interested in.NET reversing),In preparation for writing a tutorial on.NET reversing, I went ahead and wrote a keygen for FarPoint Spread for Windows Forms v1.0.2.0. In the spirit of things, I wrote the keygen itself in.NET (C#).
Farpoint Spread 8 Keygen
Basically, the tutorial I will write will describe step-by-step from the beginning how I reversed the algo, wrote the keygen, and what was involved in doing so.A few notes:First, I reversed the serial check in the installer, not the serial check in the application itself. The dll containing the serial check for the installer is written in.NET (Managed C), so I figured this could also act as a tutorial for reversing installer serial checks (which Koyuta seemed to be interested in). Obviously, the installer and application use the same validation algo, just in different files and different environments (and also different languages in this case; the installer is written in Managed C, the app itself appears to be C#). So, the keygen itself is no different for having done this, but just a heads up that the tutorial will involve reversing the installer (which is still.NET), not the app itself.Second, I have included the source code for the keygen in my release, which may be of some interest to those who are planning to read the tutorial, or those who are interested in just seeing some interesting C# code.Third, in addition to generating valid Product Key/Serial Number combinations, the keygen also includes the ability to validate/verify any PK/SN you type in.
The purpose of this is to save you some trouble when following along in the tutorial, so that as you write your own keygen (which you should do, else what is the purpose of the tutorial!), you can see if its output is valid quickly without testing over and over in the installer (which is very very slow to validate the PK/SN for some reason). Or, if you don't want to use my keygen to do the validation, you can just take the included source and implement the validation in your own keygen/app.I have uploaded the keygen, keygen source, and install files to the exetools FTP (/incoming/FarPoint Spread for Windows Forms v1.0.2.0 with Keygen). I only uploaded the install files to ensure that the version I wrote the keygen for and will write the tutorial for (1.0.2.0) will be immediately available to everyone, even if a newer version is out (thus making 1.0.2.0 hard to find).Koyuta, please send me a PM or something to let me know if you are still interested in having this tutorial.
If you're not interested, I'm not sure if I will still make the tutorial (you're the only one who really seems interested in.NET), because it will be an extremely time-consuming process.