Exetools - How to patch .NET DLLs?

Exetools (https://forum.exetools.com/index.php)

- General Discussion (https://forum.exetools.com/forumdisplay.php?f=2)

- - How to patch .NET DLLs? (https://forum.exetools.com/showthread.php?t=7022)

Newbie_Cracker

03-03-2005 23:21

How to patch .NET DLLs?

Hi everybody.
Yesterday I tried to patch a component of ASP .NET. The DLL had a simple check routine. It tested a 30-day license key. If there was no license key, It would show a box in a design page with this message :
To remove this message, please, obtain a 30 day trial key.

I changed some br and brfalse and so on. But at re-compiling time, .NET compiler stoped and said signature not found or something like this.
What's the problem? What's wrong with the patched DLL?
I thought my changes was wrong. So, I changed the place of EXPIRED and NO LICENSE messages in the DLL, but the above failure was occured again.
Is there a signature stored in the DLL and .NET runtime libraries check them? Something like CRC?

One of my friends has seen some crashes in patched DLLs. But patched EXE files work fine. :(

Best regards.

MrAnonymous

03-04-2005 12:16

Closest I can figure is StrongArm which acts as a CRC Check for .net apps, but which is easily broken do a search that might be it.

SystemeD

03-04-2005 18:50

You must understand if the error message is from the app (or some kind of protector) or a standard framework .net error (related to strong name signature).
In the second case you can find useful infos here and in the related links:

hxxp://www.exetools.com/forum/showthread.php?t=6530

Can you post where to find your target?

jjhsd

03-04-2005 21:07

Patch 0x102c, change 80 to 00, then it should work.
I have patched 4 applications. Every time i modify a DLL, I have to patch this offset, otherwise it will give me an exception.

SystemeD

03-05-2005 01:09

In this way you set Stong Name Signature lenght from 80h to 0h and let the framework think that the assembly is not signed.
This way of patching doesn't work for ASP.NET application.

Newbie_Cracker

03-05-2005 01:50

Thanks folks.

Here is the original DLL and one of the modified one.

SystemeD, error message was the standard frameword .net error. Because it occured at compiling time, not at running time.

I'll test the method of jjhsd. But as you said, this method won't work on ASP .NET (The dlls are for ASP .NET, but I'm now sure written by ASP .NET). So what's the solution? :(

I couln't upload the files. Upload manager window hangs :(
So uploaded to GeoCities.

hxxp://www.geocities.com/newbie_cracker_ms/RadTreeView_Original.zip
hxxp://www.geocities.com/newbie_cracker_ms/RadTreeView_message_jump.zip

SystemeD

03-07-2005 21:48

A way to do that is contained here:

hxxp://community.reverse-engineering.net/viewtopic.php?p=24882#24882

However, I've taken the files you uploaded and I will give them a look as soon as I have some time,
Bye

Newbie_Cracker

03-08-2005 06:20

Thanks alot SystemeD.
Complete solution.

These values (public key & hash) are extractable in IDA, at the start of disassembled code. Then could be searched by HIEW.
But, is it possible to fill these values with 00s ?
Could you test it plz? I don't have .NET compiler and know nothing about it.

Regards.

taos	03-08-2005 23:47

In hXXp://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpconmsildisassemblerildasmexe.asp
you can read this:
"The text file produced by Ildasm.exe can be used as input to the MSIL Assembler (Ilasm.exe)."
Then,you must remove .publickey and .hash entries from disassembly and use ILASM.EXE like omega_red says. Don't use IDA or HIEW, use ILASM/ILDASM.

you can donwload .net sdk here:
hxxp://www.microsoft.com/downloads/details.aspx?familyid=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en
or here 2.0 beta:
hxxp://www.microsoft.com/downloads/details.aspx?FamilyID=916ec067-8bdc-4737-9430-6cec9667655c&DisplayLang=en

here you can understand how to use ILDASM with the famous HELLO WORLD example.
hxxp://www.c-sharpcorner.com/vsnet/IldasmTool.asp

Regards

jjhsd

03-09-2005 21:23

what happened if the DLL has been protected by some obfuscator?
I had such experience, if the obfucation replaces the function and variable names with ascii characters (not english character) then we cannot compile it back because of these ascii letters.

zacdac

03-09-2005 21:34

There is no need to decompile to IL and recompile, nor is there any need to remove the public key. You can just patch the assembly directly.

Use ILdasm to determine the hex sequence that is to be patched and use a hex editor to search for the unique occurrences of those bytes and modify the IL op-codes directly. Use one of the many MSIL op-code references for a listing of them.

If the assembly is strong named, then you will need to patch that as well.
Yes for a winforms assembly the patching of the size of the strong name field in the COR header will do the trick, but for an asp.net assembly you will need to also patch the strong named attribute which is stored as meta data before the RAS key.

Also note that if there are other strong name assemblies referenced, they may also be required to be patched because strong named assemblies need to call other strong named assemblies.

Additionally if the assembly does some self checking this may also require patching, however it is very rarely implemented.

ZD

Newbie_Cracker

03-10-2005 06:11

Quote:

Originally Posted by zacdac

For a winforms assembly the patching of the size of the strong name field in the COR header will do the trick, but for an asp.net assembly you will need to also patch the strong named attribute which is stored as meta data before the RAS key.

I didn't understand completely.
Here is the public key of the above mentioned DLL which IDA shows :

Code:

.assembly RadTreeView

{

  .hash algorithm 0x00008004

  .ver 4:0:0:0

  .originator = (

   00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 00

   00 24 00 00 52 53 41 31 00 04 00 00 01 00 01 00

   CD 62 12 05 0E 7C CD 6F 51 AF 2C 41 FD CC 65 44

   AC E3 CF 79 6A 19 49 C5 80 C3 FF 52 7C AC 91 1D

   9B E0 5F AD 28 47 CE F4 E7 E5 EC 87 9F C9 4B E4

   9E 31 C7 97 C2 B8 39 25 C4 ED F6 AA 83 FA 78 A3

   5A 47 C0 F4 7B 44 A8 F9 3F D1 44 A9 B7 96 BF 74

   9E 8D FC B3 99 82 11 52 A9 5C 7A 37 EB A3 82 B6

   9D A5 8B 7A 1C 87 DA 5C ED 0B 7A 72 BA B1 3F 12

   52 C6 2F 50 DD 35 44 06 E6 F3 B0 4B AF F4 19 BD)

}

The bold numbers mean : RSA1

You mean I must patch 80 at 0x102c to 00 and bytes before RSA1? bytes before RSA1 or complete section of public key?
And patch to what? to 00s?

Regards.

SystemeD

03-10-2005 18:04

Quote:

Originally Posted by zacdac

...but for an asp.net assembly you will need to also patch the strong named attribute which is stored as meta data before the RAS key.

Could you be more explicit?
Here is some of the output from ildasm for the target we are talking about, what must be patched for an aspnet assembly?
Thanks

Code:

.custom instance void DotfuscatorAttribute::.ctor(string) = ( 01 00 16 31 34 32 32 31 3A 31 3A 32 2E 30 2E 31   // ...14221:1:2.0.1

                                                                36 39 37 2E 31 38 34 38 35 )                      // 697.18485

  .custom instance void [mscorlib]System.Reflection.AssemblyConfigurationAttribute::.ctor(string) = ( 01 00 00 00 00 ) 

  .publickey = (00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 00   // .$..............

                00 24 00 00 52 53 41 31 00 04 00 00 01 00 01 00   // .$..RSA1........

                CD 62 12 05 0E 7C CD 6F 51 AF 2C 41 FD CC 65 44   // .b...|.oQ.,A..eD

                AC E3 CF 79 6A 19 49 C5 80 C3 FF 52 7C AC 91 1D   // ...yj.I....R|...

                9B E0 5F AD 28 47 CE F4 E7 E5 EC 87 9F C9 4B E4   // .._.(G........K.

                9E 31 C7 97 C2 B8 39 25 C4 ED F6 AA 83 FA 78 A3   // .1....9%......x.

                5A 47 C0 F4 7B 44 A8 F9 3F D1 44 A9 B7 96 BF 74   // ZG..{D..?.D....t

                9E 8D FC B3 99 82 11 52 A9 5C 7A 37 EB A3 82 B6   // .......R.\z7....

                9D A5 8B 7A 1C 87 DA 5C ED 0B 7A 72 BA B1 3F 12   // ...z...\..zr..?.

                52 C6 2F 50 DD 35 44 06 E6 F3 B0 4B AF F4 19 BD ) // R./P.5D....K....

  .hash algorithm 0x00008004

  .ver 4:0:1:0

}

I usually decompile, remove .publickey and .hash lines and then recompile.

Newbie_Cracker

03-11-2005 00:14

As jjhsd said, in case of obfuscated, decompiling and compiling again, may not possible sometimes.

sKip	03-11-2005 00:55

Have you read this?

http://www.codeproject.com/dotnet/#Security

specially:

Building Security Awareness in .NET Assemblies : Part 3 - Learn to break Strong Name .NET Assemblies

-> An example how to break RSA in .NET

It´ll help you to understand how to break[patch] RSA etc. in .Net

SystemeD

03-11-2005 01:25

Quote:

Originally Posted by newbie_cracker

As jjhsd said, in case of obfuscated, decompiling and compiling again, may not possible sometimes.

It's not completely true...
Probably you are saying this because ildasm crashes while dumping, but this only means that obfuscator inserted some invalid metadata. So:
1 - If you find and remove this metadata you are still able to decompile/recompile.
2 - Future version of ILDASM will be able to manage invalid metadata so it would not be a problem anymore.

Quote:

Originally Posted by zacdac

...but for an asp.net assembly you will need to also patch the strong named attribute which is stored as meta data before the RAS key.

It's true, I tried it by myself. I made some experiments and finally I found the way to do that. Well, you have to patch the Strong Name length as for Win apps and than patch this (again 80h to 00h):

Code:

00012140   0E 0E 04 20 01 01 02 03  20 00 01 80 A0 00 24 00   ... .... ..€ .$.

00012150   00 04 80 00 00 94 00 00  00 06 02 00 00 00 24 00   ..€..��........$.

00012160   00 52 53 41 31 00 04 00  00 01 00 01 00 CD 62 12   .RSA1........&#205;b.

00012170   05 0E 7C CD 6F 51 AF 2C  41 FD CC 65 44 AC E3 CF   ..|&#205;oQ&#175;,A&#253;&#204;eD&#172;&#227;&#207;

Recompile the app that use the dll and... enjoy! ;)

Newbie_Cracker

03-13-2005 01:46

SystemeD
I patched byte you've shown and sent patched DLL to my friend to test it.
This time .NET compiler said : "Invalid program" (or something like this).
May its because of joining your method and method of patching 80 at offset 102C.

Tonight, I played with a simple file compiled with and without Strong Name. I noticed after compiling with KEY, 80 A0 and PublicKey are the major differences between two files. So my suggestion is : Patching whole PublicKey and 2 bytes before it to 00.

I must test it again.

And...
Present version of ILDASM (.NET SDK 1.1) crashes at decompiling time and the produced file is uncompilable. Do you decompile and recompile the mentioned dll successfully?

SystemeD

03-14-2005 18:30

Quote:

Originally Posted by newbie_cracker

I patched byte you've shown and sent patched DLL to my friend to test it.
This time .NET compiler said : "Invalid program" (or something like this).
May its because of joining your method and method of patching 80 at offset 102C.

It's exactly what you have to do. I checked it again and it works. Be carefully because the code I posted may be different from yours (you have to look at the position of the bytes), because I downloaded the latest version of the app for testing.

Quote:

Originally Posted by newbie_cracker

Tonight, I played with a simple file compiled with and without Strong Name. I noticed after compiling with KEY, 80 A0 and PublicKey are the major differences between two files. So my suggestion is : Patching whole PublicKey and 2 bytes before it to 00.

Probably it would work too, I didn't try it...

Quote:

Originally Posted by newbie_cracker

Present version of ILDASM (.NET SDK 1.1) crashes at decompiling time and the produced file is uncompilable. Do you decompile and recompile the mentioned dll successfully?

In my previous post I talked about future versions, try ILDASM from SDK 2.0 Beta... ;)

PS: I suggest you to patch only the strong name infos at first. Test if the assembly works and after apply all other cracking patches.

jjhsd

03-16-2005 20:34

what i have encoutered is ildasm does work, but the output file it produces contains a lot of ascii characters(not a-z). then ilasm will have problem to compile it back.

SystemeD

03-16-2005 21:34

Can you point me to your target?

jjhsd

03-17-2005 08:42

RedGate SQL Bundle - "RedGate.Licensing.Client.dll"

i ran ildasm, dumped everything. then couldn't compile it back (without changing any il code)

hxxp://www.red-gate.com/downloads/bundle.exe

TQN	03-17-2005 10:32

Did you try it with Reflector. If in Reflector, you only see garbage function names, member variables, the dll used obfuscation, and ILASM can failed when recompiling.

SystemeD

03-17-2005 17:20

jjhsd:

Funny! I just played with it few months ago but I don't remember what I did exactly...
I think it's time to take a look at the new version... :D

jjhsd

03-17-2005 17:38

SysteMD:

the software's protection can be defeated by other ways, but not using decompiling.

TQN:

yeah, i have tried and can see garbage function names from there.

SystemeD

03-17-2005 19:40

It's not completely true, I tested it and, for example, I succeded to decompile/remove Strong Name Signature/recompile the assembly named "RedGate.Licensing.Client.dll".
The only problem I encountered is that Ildasm produced a resource file with an invalid name ("똁.resource"). So I renamed it in "a.resource" and modified the dump to point to the new resource file. I recopiled the assembly and it worked.
I don't know if it is the problem you had but I would use decom/recomp technic for this target too.

JMI	03-17-2005 23:24

jjhsd and SystemD:

PAY ATTENTION AND STOP USING THE "QUOTE" BUTTON WHEN A "QUOTE" IS NOT NECESSARY.

You just add to the burden of the database and I'm gettig tired of fixing your posts.

Regards,

jjhsd

03-18-2005 08:34

yes, it works. I didn't change resource file name in the dump, that's why it failed.
thank you. : )

Newbie_Cracker

09-26-2005 03:58

StrongName Signature Remover

1 Attachment(s)

Last night I saw a little tool for removing StrongName Signature from .NET applications in Woodman forum.
Little description of this tools is :

SNRemove v1.00
Copyright (c) 2005 Nir Sofer
Web Site: http://www.nirsoft.net

But it didn't fix SN Signature in ASP .NET Applications.
So I created this patcher to solve this for all .NET Applications. It's the result of this topic. :)

Best regards.

Unforgiv3N

09-26-2005 04:52

Nice Job, Thanks!
NeWBiE_Cracker ;)

All times are GMT +8. The time now is 23:18.