Reverse Engineering Team Board

Reverse Engineering Team Board (
-   Reverse Code Engineering (
-   -   Inject .NET information here (

Devine9 02-04-2003 08:56 PM

Inject .NET information here
Anything you guys got on .Net lets talk about it.. Fraviamb had some info on the DSA signature.. I think it is just an identification string rather than a security setting although it also does a bit of that.. as you can set the length to 0 and patch away.. and it thinks it was never set.. How soon crc checking will come into play to make sure the DSA is not tampered with is petty obvious though.. just things to watch out for.. but RET has some things coming out in this area.. so if everyone would kindly pool every link or reference or tid bit of thought onto this here thread we'll be that much better off.. and perhaps we'll have something quite wonderfully magnificent at the end of all of this.

Devine Right [RET]

zacdac 02-09-2003 07:20 PM

Okay, as requested I will try and supply you with some information to get you started.

First, there are two types of .Net managed applications.
1) WinForms application (windows app)
2) ASP.NET application (asp web app)

The distinction is important because the applications are treated differently internally by the .NET framework (the framework can be though of as a runtime engine).

Second, a .NET dll/exe maybe digitally signed or may not be digitally signed. It is up to the author to implement. A digitally signed .NET assembly (in this context assembly means a dll or exe file) is referred to as a "strong named assembly"

You can patch a non "strong named assembly" without any problems, however if the assembly is a strong named assembly, then the .NET framework will raise an exception if the file has been tampered with (that is, raise an exception if the digital signing proves to be invalid).

Note: when patching .NET assemblies, you are patching Microsoft Immediate Language (MSIL) and not assembly language (machine code). The instruction set and the opcodes are very different. For example NOP = 90h in ASM, but in MSIL NOP = 00h.

The zero trick is possible due to what I believe is a bug in the .NET framework. It works because you trick the framework into believing that an assembly is a not digitally signed by setting the size of the digital key to zero.

Note that the next version of the .NET framework is due to be release when the .NET server is released in late April 2003. It is possible that this bug may be rectified in that version.

Note that the zero trick only works on WinForm assemblies. ASP.NET assemblies are not fooled by the trick (the code of the .NET framework engine for ASP.NET is different to the WinForms version).

It is still possible to patch a “strong named” ASP.Net assembly, by reverting the strong named attribute in the file. This will also work with WinForm assemblies. Note, this method is not a trick. The strong named attribute is stored within the assembly(file). Modifying the attribute causes the file to be a NON strong named assembly from the .NET framework view point.

An important consideration however is that within the .NET Framework, a strong and non strong named assembly are linked to other (external) assemblies differently. To explain, when you create a .NET project you make references to external libraries. When this linking occurs, information about the external library (dll) is stored within the project. The strong named attribute of the external library is also stored. Hence, if you modify the strong named attribute of an assembly that is called from another assembly (remember assembly may be a dll or exe) you are invalidating the information stored in the calling assembly and an exception will be raised by the .NET framework.
On the subject of CRC checking, an alternate method that is currently employed is to use the .NET framework itself to test for the strong named attribute (that is you can call a function like IsAssemblyStrongNamed() to see if the attribute has been modified.

On the subject of Obfuscation, the next version of VS.NET will include preEmptive solutions Dotfuscator as part of the package. At this stage I have not found obfuscation to be a problem with patching .NET assemblies because functions/classes are still (and have to be) identified by a unique identifier.


Devine9 02-10-2003 01:44 PM

Okay good thanks a lot :)
Okay this is what i got:
as well as

also a search on msdnmag for .NET pulls up quite a bit.. but a lot of that information is written in sucha way to give a good knowledge but hide a lot of key things obviously.

Devine Right [RET]

littlejohn 02-19-2003 07:26 PM

Some documents about .NET obfuscation
I found some interesting material about .NET obfuscation here:


there are some (stupid) hints on how to fool anakrino.


zacdac 03-04-2003 09:56 PM

Not sure it this project is still going ahead?

Anyway, this is a real world example of a winforms .NET application that uses the pro version of hxxp://


The app is code generator for .NET. It's pretty simple to reverse, (a one byte patch) but it does illustrate some techniques, such as the obfuscators built in string encryption.

The reason for highlighting it was that the anti-ildasm trick has been implemented and this is the first example I have come across.

The theory is that there is a bug in ildasm.exe that is exposed when it tries to disassemble certain (invalid) meta data.
The obfuscator places the invalid metadata in each of the classes in the application. This prevents ildasm from dumping the disassembled IL to file.

If I can obtain the obfuscator, it should be a simple matter of comparing two files (valid and invalid) to find what the invalid metadata is, and then create a invalid metadata cleaner.


Devine9 03-04-2003 11:46 PM

The project is most definitely still going.. thanks for the link. A lot of us have been researching all over and i've been reading non stop about everything i can find on obfuscation types for the MSIL and breaking Anakrino.. this though is the first i've heard of breaking ILDAsm.. although this not really that big of a deal if ILDAsm can render the data to the screen and you can view the code then you can just compare the classes for similar bad code in there.. I've also ordered the book Inside Microsoft .NET IL Assembler, nother couple days till that comes in.. I think first thing we'll focus on is writing up a nice large essay on a great bulk of what we have learned up until the time of writing.. and then begin on the other 2 projects we have planned. If you have any more links let me know by mail or on here.. and we'll keep swaping data here. This is going
quite well ;)

Thanks again,

Devine Right [RET]

zacdac 03-05-2003 12:14 AM

hehe breaking Anakrino. To be honest I gave up on using this app a long time ago. I found that it simply gave incorrect results. It was far easier to just read the IL code directly.

The problem with ILDasm is that there is no search facility. Hence the main reason for dumping it to file.

If ILDasm comes across the invalid metadata while rendering to the screen or file, it will crash.

You can use IDA to display IL code, however IDA struggles to display calls to system libraries. ILDasm resolves these calls correctly.

The second reason for using ILDasm is that you can recompile the IL code with ILasm. Doing this allows you to produce a debug file for the assembly and then allows you to use the IL debugger.

BTW. I have this book in chm format.
What you also may want to seek is the documents from the VS.Net studio beta. There were some technical documents that listed IL instructions references and structures etc.


Devine9 03-27-2003 11:49 AM, benny took a look at the structure, a good explanation of the MANIFEST etc.

Devine9 03-27-2003 11:51 AM

also check out 29a site for benny's dotNET virus i thin its called.. kinda interesting how he did it.. he redirects the pointer to the CLR then eecutes his code and cleans up after himself and resets everythign and the exe executes as normal without the user seeing. Not really a very advanced idea, but its interesting.

Devine Right [RET]

zacdac 04-01-2003 07:07 PM


Found another interesting target the other day

It is the first i have found protected with

The actual application can be patched because the author has left a weak link in the design. He relies on a third party dll to validate the key. Modifying the dll to always return true for the license validation solves this problem.

Patching the application however was not the interest with this one. It was the implementation of remotesoft .net protection.


All times are GMT -4. The time now is 04:56 PM.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.