cracking .Net Program

Hello,

I have a .Net application written in C#.

It's very similar to most of the shareware that use "Enter name/key" mechanism to register.

What tools can be used to analyze .Net program?

Any softice breakpoints / tools can be used?

I guess ppl will use obfuscator to mess up the .net assembly first.
Decompiling a .net assembly seems no big use for that.

Any opinions?

Thanks in advance.

I am just a beginner :-)

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.

Hello,

You are the one who replied me before, thanks :-)

I spent some of my spare time learning to crack and programme coz so interesting


I continue to try every means to crack the
farpoint Spread .Net for Windows form, first from installer(dll) ,
then from the registration screen but it's in .Net, I'm searching for information on how to analyse it.

Because I'm a beginner,seems this component is quite difficult for me to crack or I'm too stupid :-0

Anyway if you are interested in it and don't mind writing a tutorial
, your effort is highly appreciated.


Koyuta

Tools I am learning and using :
PE Explorer V1.93 from wxw.heaventools.com
Numega SoftICE Driver Suite/softice 2.6
(I have 2.6, 2.7 and 3.0(beta) )
Ultraedit as Hex editor
Visual studio .Net Enterprise

[JMI]

Koyuta:

You need to stop posting clickable links on this Forum. Always turn off the "Automatically parse URLs" button in the "Options" section and always use "hxxp"; "h**p"; and/or "wxw" or "xxx" for "www."

Regards.

Heh... I've good news for you, girls(?) and guys: NET applications structure is a bit different. So what? So they will remain OPEN DOORS for You for a long time..... I'm still learning them while parallel programming... I'll try to inform You about future discoveries (not earlier than winter ). If someone has NET exe protected with any protector PLEASE SEND IT TO ME. I'd like to know the way it goes....

Regards.

[Squidge]

Well,

Armadillo Standard will protect .net loaders (not user code).
Armadillo Professional can protect .NET exe's fully (including user code).

So, download Arma if you don't already have it, reg it with Pro code, and protect a .net exe.

I can provide a .net C# exe if you require one (It'll have to be compiled example code from Microsoft however, as I've no idea of how c# works)

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.

Originally posted by Squidge
Armadillo Standard will protect .net loaders (not user code).
Armadillo Professional can protect .NET exe's fully (including user code).

Code-Lock claims to protect .Net applications, too, though I haven't tested it. From their website:

"Code-Lock is an advance secure software protection system that will protect your Visual Basic and .NET applications by stopping crackers in their tracks."

Satyric0n,

Thanks for your reply.

I am trying to understand those tools , the intermediate language and the framework.

In my opinion, both .Net C# or VB.Net are much more easy to learn and program than traditional languages.

What do you think?

Originally posted by Squidge
Armadillo Standard will protect .net loaders (not user code).
Armadillo Professional can protect .NET exe's fully (including user code).

Apparently Arma can't protect .NET programs. From its help:

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. 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.

[Squidge]

Yes, your right. I got it confused with other types of programs which are "interpreted", such as Foxpro.

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#). 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.

Anyone have a clue or ideas for reversing/cracking other micro$oft's interpreted language??
I have a problem cracking the Dexterity application with used in
MS Business Solutions (e.g. SBM & Great Plains) ...

Any help would be very appreciated.

regards,
Excelman

[JMI]

ExcelMan:

Your post is a blatant REQUEST which is both off the topic of this thread and doesn't belong in the General Discussion Forum. If you want help with "other micro$oft's interpreted languages" post your request in the Request Forum where it belongs. You add nothing to the discussion here with your Request.

Please pay attention to the rules.

Regards.