Shulou(Shulou.com)06/02 Report--

How to use examples to explore the idea of the strong name of .NET, I believe that many inexperienced people do not know what to do about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

There is an industry software on hand, which needs to be plugged in a dongle to work properly, developed in the C # / .net Framework 1.1 environment. This is the genuine software purchased by our company, so it can be used normally, but because of the large number of computers, encryption dogs inevitably have to be unplugged. If you have nothing to do, just study it and learn a lot about debugging.

PEiD can "identify" that the software is Microsoft Visual C # / Basic .NET, and novices should not think that PEiD is used only after shelling.

Then use Reflector analysis, notice that the unplugged encryption dog will pop up a dialog box with the words "* unregistered *", some of the functions are limited. Press F3 to display the search window, enter "unregistered", and click the "String Seach" icon on the right to search for a string. Find one, is a module that the program starts, double-click to go to the left tree list, and then double-click to open the code, I chose the C# format. Generally speaking, I use IL and C # as a control. For a number of reasons, the code has been streamlined and modified. Same as below.

GlobalVariant.zhuce = Check.Textxyz; if (! GlobalVariant.zhuce) {MessageBox.Show (this, "* not registered *");}

At first glance, there is not a single Chinese character in it. There are many strings such as "\ u7237\ u7016". This is the Unicode of Chinese characters. Copy the module code and find a Unicode conversion tool to turn it around. Now you can find the condition judgment that pops up "* unregistered *" directly. This judgment calls a procedure Check.Textxyz in some.dll. Click on the process name to track it, and click on it as follows:

Public static bool Textxyz {get {return ((Check ()! = 0)? 1: 0);}}

Then click on the trace Check () function, which has nothing but definition, and is already the legendary Native Code (native code). It was only later discovered by decompilation.

[PreserveSig, MethodImpl (MethodImplOptions.Unmanaged, MethodCodeType=MethodCodeType.Native), SuppressUnmanagedCodeSecurity] public static int modopt (CallConvCdecl) Check ()

But it doesn't matter. To analyze it, just modify the return ((Check ()! = 0)? 1: 0) in the Textxyz above; return 1 (true) or 0 (false) according to the judgment, and the Native Code for detecting the software dog should be: return ((Check ()! = 0)? 1: 1); return 1 (true) anyway

Well, the plan is confirmed, so let's do it.

The program has 5 DLL and 2 .exe, one of which is not a C # .net program (Assembly). You only need to solve these 5 DLL and 1 EXE. simple!

All the ildasm comes out, and the some.il code is modified according to the above modification. It is very simple, that is, change the ldc.i4.0 in that paragraph to ldc.i4.1.

Ldc.i4.1 0009: ldc.i4.0 / change this to ldc.i4.1

L_000a: br.s L_000d

L_000c: ldc.i4.1

L_000d: ret

Remove all strong names and compile them back with ilasm.

Some. Il got stuck. I was depressed. I thought victory was in sight. Only then did you notice that some.dll uses native code (Native Code). There are also many software features of .NET code in some.dll. It is agreed that Assembly mixed with native code cannot be recompiled because it cannot be decompiled (try it)

Alas, how to do, check the information, the eyes are dizzy, the result is still NO WAY. PS seems to be a strong way to protect .net Assembly programs by mixing .net with native code.

Only hexadecimal editing, get a some.dll, compared with some.il to find the feature string, search in the editor after 16 (false) changed to 17 (true). Here some.il must tick those boxes when exporting (that is, dumping) with ildasm, so that the decompiled code has the hexadecimal code in the some.dll corresponding to the IL instruction. It is convenient to search for location in the editor.

After saving, open the software to see if it can be run-pop up the common language runtime error message! Run DbgCLR of. Net Framework SDK 1.1 to debug and find that there is a problem with strong name authentication! For an Assembly.Net program with a strong name, any byte modified with a hexadecimal editor will cause the strong name verification to fail and make the program unable to run. (I don't know if it will be the same with changing header. I didn't try)

The conventional way to solve the problem of strong name authentication is to recompile the program, but I just tried it, no!

Reverse compile Assembly with native code? After searching and studying for a long time, I couldn't find a solution. So, can all DLL/EXE be forcibly removed from the strong name, try not to run, and it is impossible to load into the GAC to run. So, according to the algorithm, how to "update" some.dll to the correct strong name after modification? There is no answer. I am very interested in this, and I will pay attention to it in the future.

There's nothing you can do about it: how to trick Microsoft.Net into not checking strong names, or how to make it look right? I found a way to write the registry on the Internet, but I tried it several times and wondered if I needed to restart my computer. I didn't try again. Let's just crack the strong name mechanism of .net Framework 1.1. I don't see what use it is.

Crack the strong name verification mechanism of the system:

Combined with the information found on the Internet, the operations related to StrongName strong names are found in the file mscorsn.dll of the .net Framework runtime. The specific location is generally found in the system directory C:\ WINDOWS\ Microsoft.NET\ Framework\ v1.1.4322. The functions involved are StrongNameSignatureVerification and StrongNameSignatureVerificationFromImage.

So copy a mscorsn.dll, open it with OD, click run and let it run again (whether it runs or not), then click debug-> call DLL output from the menu, find the relevant function and refer to the function entry point, and modify them to return a True directly. Modify and save, overwrite the original file of the system, and make a backup first in case the modification fails or the system is restored afterwards. When overwriting, first overwrite the one under the Windows/System32/dllcache/ directory, and then overwrite the one under the Windows/Microsoft.NET/ directory. Now click on the modified program to see how it is.

Run successfully! No abnormality.

My colleague said that I gave this software to Crack together with .net. It is a pity that the system file mscorsn.dll of .net Framework has to be replaced, and it is not known whether the security has declined. The replacement of this system file should also be able to deal with strong names in .net Framework 2.0.

Summary: (very important)

1. If you all see here, it proves that you are patient and modest, please don't be sarcastic: -), please give me a lot of advice.

2. The difficulty of reverse research of net program (Assembly) lies in the mixed compilation of Native Code, which should be the research direction.

3. Whether the strong name verification of the irreversible strong name program can solve the problem from the front whether the strong name can be "updated" is an impossible task?

4. This is important: this article proposes a Crack idea of strong name verification + compiling native code protectors. As long as you find the key points that need to be modified, and as long as you can use a hexadecimal editor to break through the limits, then the program can be used as usual. It's just another name-free verification patch for the system. Although there are gains and losses, on the other hand, when you think about the "strong demand" for software to the point of Crack, will you care about patching the system that is not very annoying? How about this patch, we still need a large-scale experiment, practice to get the real knowledge.

Some people may say, what you think is naive, what if the core function and verification of the software are NativeCode? In fact, don't worry, because the program you are talking about is no longer a .net program. Just put on the cloak of .net to deceive the user. Why use .net to develop programs? There are many answers, such as fast development, powerful and easy to use (all for developers), and so on. If you develop with .net, be sure that the core function of the software is realized by .net NonNative Code. As for the core function of verifying illegal users, write it in Native Code and mix it up. Then, such a program should still be easy to Crack. Without strong name validation, Native Code is of limited use.

After reading the above, have you mastered the method of how to use examples to explore the ideas of the strong name of .NET? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.