Binary hacking an executable part duex

A couple of the tools I use for binary hacking:

One of the problems with binary hacking a .net executable is references. Say you have an executable and a .dll file that is referenced by the executable. If you modify the .dll and resign it with a new public key token, the executable’s reference will be broken.

You are welcome to download the following code and binaries to "crack" along with me.

Crack Me Test files

In the zip file above, I have the following files:

crack01

In the Common Library class library code, is the following:

Code Snippet
  1.     Public Shared Function IsLicensed() As Boolean
  2.         Dim retval As Boolean = False
  3.         retval = False
  4.         Return retval
  5.     End Function

<rant>This is BAD for you to protect your executables this way. There are even professional .NET component designers who use methods like this. All you have to do is change the false to a true and it is cracked. Please, you are selling these components to developers, some who know how to crack, and most know how to use reflector at least. Duh!</rant>

Open up ILDASM by typing ILDASM at the visual studio command prompt. Once you open the CommonLibrary.dll Go to the view menu, and choose “show bytes”. Navigate to the method you wish to crack, in this case the CommonLibrary.LicenseProtector.IsLicensed() function and double-click on it. crack02 This brings up the IL code for it, but more importantly, by turning on the “show bytes” it allows you to find this method in the binary file.

Now go ahead and open the CommonLibrary.dll in UltraEdit or any other binary editor. We are going to change the false to a true.

According to the picture above on the right, we are looking for the following hex code 16 0B 16 0B 07 2A. Your code may vary. Once we find it, and are sure we are in the right place by searching again for it, we can now edit it. Change the 16s to 17s. This makes the false to a true.crack03

This is how it looks after. 17 0B 17 0B 07 2A.

Now that we’ve cracked it, we have to re-sign it with a public key. Run the following, which creates a crack.snk key file.

sn.exe -k crack.snk

Then we can run the SNReplace. The code for that is at the top of the article, create a console app and paste that code there.

snreplace.exe commonlibrary.dll crack.snk

crack04crack05

Now, open the CrackMeTest.exe in reflector and the commonlibrary.dll in reflector. When you click on the CrackMeTest.exe in reflector, you will see the public key token, which is 82db601ed5cd3521 (On my machine). Since you re-signed the commonlibrary.dll you will see a different public key token. If you navigate in Reflector to the method CommonLibrary.LicenseProtector.IsLicensed() you will see it returns true.

crack06

Great, but now we have to fix the reference between the exe and dll. Write down the public key tokens for both. Now we run the resigner on the executable.

snreplace.exe CrackMeTest.exe crack.snk

This will change the public key of the executable to the same as the dll file. Plus it will help us, since we won’t have duplicates for the public key since we re-signed our exe.

Open the exe in UltraEdit. We are looking for the old key, which in this case is 82 DB 60 1E D5 CD 35 21 (May be different on your machine). When we find it, we just swap that out with the new key, and then we re-sign the executable again. Voila, the reference to the .dll has changed to the new key.

kick it on DotNetKicks.com

11. July 2009 22:58 by Rick | Comments (2) | Permalink

Cracking .NETZ executables

.NETZ is a free open source tool that compresses and packs the Microsoft .NET Framework executable (EXE, DLL) files in order to make them smaller. Smaller executables consume less disk space and load faster because of fewer disk accesses.

Today we are going to show you how to extract assemblies from them, so we can crack them!

First, we use reflector to save the resources to a folder. Right-click on the zip.dll and choose Save As… Then do the same for the guid resource.

Saving resource from reflector

Then, in reflector, we find the unzip method. It’s in the namespace netz.NetzStarter.Unzip(data() as byte)

So we copy that code to the clipboard, and fire up Visual Studio and make a new console app.

Paste the unzip code to the module, and add namespaces at the top:

Imports System.IO
Imports ICSharpCode.SharpZipLib.Zip.Compression.Streams

Then we add the following code to the Main() sub.

Sub Main()
    Dim folder As String = "C:\Cracked\Files"
    ' This is the name of the resource we took from
    ' reflector.
    Dim bFile As String = _
    	System.IO.Path.Combine(folder, "A6C24BF5-3690-4982-887E-11E1B159B249")
    Dim b() As Byte = My.Computer.FileSystem.ReadAllBytes(bFile)

    ' Attach a .exe to the end of the string
    bFile += ".exe"
    ' write the bytes to the file.
    Using ms As MemoryStream = UnZip(b)
        Dim outBytes() As Byte = ms.GetBuffer
        My.Computer.FileSystem.WriteAllBytes(bFile, outBytes, False)
    End Using
End Sub

And run it. It should make an executable file in the same folder… Happy cracking!



kick it on DotNetKicks.com
6. March 2009 11:11 by Rick | Comments (2) | Permalink

Refactoring someone else’s code

I needed some code to do a function for my work. I found a .NET dll that costs $49 dollars. Well, after looking at it in reflector (which I always do to get a better idea of the architecture), I decided to refactor it.

I could have just used it.

I could have just made it work and had my boss purchase it.

I had already started on something similar when I decided to search the net for code already made, after all, why rewrite the wheel.

Well, the code was OK. You know when you look at someone’s code and you can always tell how much programming a person knows.

This person/people were only beginner/mid level programmers, and they were selling code with no visible programming patterns, had spelling mistakes, many duplications and more. So I used reflector to extract the source code.

Mostly what the code did, was a bunch of classes with properties, and two class that would concatenate the properties to a string, do a http post, and retrieve/parse the xml result to another class named Result.

Fine. So I refactored it, spending 4 hours or so on it. I added a factory pattern to distinguish between the two “gateway” objects that had almost the same code. I added an interface for the gateway. I added a base class for most of the generic properties for the classes, and left only the ones that were different from the base class.

At the end of the day, I got let go from work due to the economy, so did about 1/3 of the company, so I never got to implement this code in a project.

At this point, I would say 70-80% of the code I re-wrote. So the question remains, do I now own the code? or do they still retain rights to it?

At this point, it really only saved me a couple hours of typing in property declarations. What do you think?



kick it on DotNetKicks.com
14. January 2009 19:07 by Rick | Comments (3) | Permalink

Binary hack a .NET executable

I would first like to preface this article in saying: If you’re .net library is being protected by a single boolean function, you deserve to be hacked… :)

It’s actually not that hard to binary hack an assembly. I first learned it by reading these blog entries: Part 1 Part 2

When you change an .net executable by re-signing it after hacking, you have a small problem. Any dlls or executables referencing this executable will break because the public key has changed.

You can fix this by round-tripping to IL code and back.

ildasm.exe File.exe /text /out=File.il

Then edit the public key in the .IL file(s), and run this:

ilasm.exe File.il /exe /output=OutExe /key=PubKey.snk

Voila! All references replaced.

Hacking

To hack a binary, you need a good hex editor. I use UltraEdit. Here’s the code for a IsLicensed() method.

Public Function IsLicensed() As Boolean     Try         Me.License = _          LicenseManager.Validate(MyBase.GetType, Me)         Return True     Catch ex As Exception         Return False     End Try End Function

All you would have to do is change the Return False to Return True. Not a good way to protect your code. In binary, 16 is false, and 17 is true. so editing one byte changing from 16 to 17 and then re-signing makes a control be fully licensed. The license check will always fail, but by returning true, it’s licensed (as far as it knows). Remember to remove the old one from the GAC, and to update all references.



kick it on DotNetKicks.com
5. January 2009 20:07 by Rick | Comments (0) | Permalink

About Rick

Rick lives in North Las Vegas. He loves his wife, kids, dog, motorcycle, music and programming. There ain't nothing else. Oh yeah, mountain dew!



Programming interests are geared towards multimedia. Platforms are asp.net, windows forms, and WPF.

Calendar

<<  July 2010  >>
MoTuWeThFrSaSu
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678

View posts in large calendar

RecentComments

Comment RSS