Results 1 to 10 of 10

Thread: .NET strong name signature.

  1. #1
    Naides is Nobody
    Join Date
    Jan 2002
    Location
    Planet Earth
    Posts
    1,647

    .NET strong name signature.

    I have been dealing with a very big program coded in C#.
    There are some files that mention Aladdin HASP HL, but I am not sure exactly how the protection is all put together.
    Anyway solving this puzzle has been difficult because the files/code that contain the salt of the protection are not present in disk. they seem to be unpacked on the fly, and I have not been able to find where the original code is stored. If I analyze the application using Lutz Reflector, It asks me where module such and such is located and I cannot find it. I can see that the main application invokes classes from this "ghost" modules but the actual code is labeled as unavailable by Reflector.

    I pretty much grepped the whole hard drive with strings (The name of classes and functions) that should be contained in the "ghost" protection modules, which are .NET dlls, and came out empty handed, suggesting that the ghost code is encrypted somewhere.

    Eventually, using DBGClr.exe, I was able to see that the ghost modules were indeed loaded at specific memory addresses.

    Let's call the key protection module "protectfile.dll".
    Process dumpers like PE tools or LordPE do not see those ghost modules, but if I attach OllyDBG to the .NET executable and I look at the address given to me by DBGClr.exe I see the protectfile.dll .NET code right in memory on a nameless location, of type MAP, RW. It has a typical PE header and everything looks Kosher (Who said olly is useless with .NET? you can place breakpoints on regular API messaboxw and the like, to learn about the overall location of the protection)

    Olly saved the contents of the MAP section to a file in disk which is a perfectly functioning .NET dll!!!!

    I disassembled the .dll with IDA, analyzed it with Reflector: When Reflector asks for which file contains this and this code, I point to the dumped file, and now reflector analyzes its code seamlessly. What is better, If I load the original application with the dumped "protectfile.dll" in its working directory, instead of loading the unpacked ghost, the application loads my dumped "protectfile.dll", and works just fine

    I did a small surgery to protectfile.dll so the application will always be licensed, and:

    Fuck: Strong signature exception, .NET refuses to load the modified .dll.

    I tried to remove the strong name form the file using SNremove.exe,
    but now the application refuses to load protectfile.dll without strong name signature.

    I know for a fact that my crack works, because if I modify the bytes in memory, using olly, after the original protectfile.dll is loaded, the main application works as licensed.

    So I can think of a few ways to clear this hurdle:

    Re-signing the modified protectfile.dll. It is my understanding that this is not an easy feat: The strong name signature works by making a hash from the file, and then the hash is encrypted using RSA 2048 bit key, with the vendor's private key. at load time, .NET generates a hash of the file, un-encrypts the hash out of the signature using the public key and if they don't match, blam!

    Some people published a work around taking advantage of a bug in .NET framework 1.1 .
    http://www.grimes.demon.co.uk/workshops/fusionWSCrackOne.htm
    Apparently the bug was fixed in .NET 2.0 which is the framework of these executables, so I do not know how far this would take me.

    Another approach would be to use a loader, that would patch protectfile.dll in memory, after it passed muster for integrity, but a loader for .NET executable has its own wrinkles: I don't know if the typical apis of a loader will clash with the .NET environment.

    Another crazy idea I had was attacking the .NET framework itself, sabotaging the code that does the strong name validation and throws the invalid signature exception to make .NETsmile despite the signature being wrong.
    (Doubt this will work, I think .NET is fraught with checks and self healing mechanisms)

    Before I go on inventing the wheel, anyone here with knowledge in the issues could suggest something?

    Note: I promise I will write a tutorial but I need to defeat this beast first. . .

  2. #2
    Registered User
    Join Date
    Dec 2005
    Posts
    216
    Blog Entries
    5
    That is quite.... strange. On CodeProject I've seen a tutorial on how to remove strong name signatures using ILasm, all he did was just cut out the strong name part of the .net program and reassemble it in ILasm. But from what I understand the application refuses to work without a valid strong name signature for the file? Well, I'm sure you thought of this, but what about patching the application to load irregardless?

    Anyways, there is 2 places it can fuck you over:
    a) the application checks for the strong name signature (solve: patch the app)
    b) the .NET framework is checking for the signature(solve: remove signature via the method outline on the Code Project).

    If you're looking to patch .NET itself so that it always returns good on the strong name... well I think I did that like a year ago. If I remember correctly the API you are interested in is "StrongNameSignatureVerification" in mscoree.dll.

    Hope that helps.

  3. #3
    <script>alert(0)</script> disavowed's Avatar
    Join Date
    Apr 2002
    Posts
    1,281
    Quote Originally Posted by naides View Post
    I don't know if the typical apis of a loader will clash with the .NET environment.
    They shouldn't clash... a loader should work just fine for this situation.

  4. #4
    The easiest way I know is by using sn.exe.
    Code:
    sn -Vr <assembly> [<userlist>] [<infile>]
       Register <assembly> for verification skipping (with an optional, comma
       separated list of usernames for which this will take effect and an
    optional test public key in <infile>).
    A second way that worked for me is to place the original assembly in the GAC (C:\windows\assembly). Drag and drop it there in Explorer. After that the file is located on disk in a directory similar to this:
    C:\WINDOWS\assembly\GAC\<assembly>\<version>__<publickey>\<assemblyname>.dll
    Now write a small program that patches the above file. Because the file is located in the GAC, the CLR skips the strong name verification test. It does this because it already checked the strong name when the assembly was dropped in the GAC.
    Hope it helps

  5. #5
    Naides is Nobody
    Join Date
    Jan 2002
    Location
    Planet Earth
    Posts
    1,647
    As usual, big thanks to all the people that took the time to help me. You are always awesome. . .
    As the lazy bastard I am, I tried first the simplest of the suggestions: the second one that jstorme gave me.

    It worked like charm!!!!

    I moved the original .dll to the GAC, and the app reads it from there as long as I erase the .dll from the working folder.
    I used HIEW to modify the .dll in place and violá!!! Other HexEditors (HexWorkshop, Ultraedit) that use Windows API to browse for files in the GAC get lost and refuse to load GAC files at face value.

    jstorme: I owe you one. Very many thanks

  6. #6
    Registered User
    Join Date
    Dec 2005
    Posts
    216
    Blog Entries
    5
    It also awakened an interesting idea in my head using StrongNameSignatureVerification" in mscoree.dll and mscowrks.dll for anti tampering, since I just found out it is possible to request the strong key of an image. So what you do is load the DLL into memory, and try to verify its strong key with the above listed API ( a variant of it actually). If no strong key is present or strong key is bad, you know that it has been tampered with and GG

  7. #7
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    The following tool also comes to mind, which (depending on their verification method) could be useful here:

    Re-Sign, for automatically removing and reapplying your own signature to .NET assemblies:
    http://www.woodmann.com/forum/showthread.php?t=9926
    "Give a man a quote from the FAQ, and he'll ignore it. Print the FAQ, shove it up his ass, kick him in the balls, DDoS his ass and kick/ban him, and the point usually gets through eventually."

  8. #8
    Naides is Nobody
    Join Date
    Jan 2002
    Location
    Planet Earth
    Posts
    1,647
    Thank you dELTA. I tried the re-signing with the .dll but it failed to work: The application checks some part of the strong signature when it loads .dll modules, so unless I want to make major surgery in the verification part of the code I stayed with the GAC solution. On the other hand, re-signing .exe modules became necessary and worked just fine. Ugghhhhh! This one was like peeling an onion.

    I also tried the sn -Vr <assembly> trick but it failed at some point. I will work it around when I have more time. . .

  9. #9
    [Ntoskrnl]
    Guest
    Load the assembly in the CFF Explorer, click on Rebuilder and check "Remove Strong Name Signature", then click on Rebuild.

    Just like this:

    http://ntoskrnl.pmode.net/remsns.jpg

    To make an app work with a non-signed dll you have to set to 0 the PublicKeyOrToken in the AssemblyRef table.

    Just like this:

    http://ntoskrnl.pmode.net/snsinv.jpg

    I hope this helps.
    Last edited by [Ntoskrnl]; October 12th, 2007 at 06:15.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  10. #10
    Naides is Nobody
    Join Date
    Jan 2002
    Location
    Planet Earth
    Posts
    1,647
    Thank you for the suggestion NT. I'll give it a try . . .

Similar Threads

  1. .net strong name assembly question
    By mr_tex in forum The Newbie Forum
    Replies: 0
    Last Post: November 22nd, 2013, 19:42
  2. issue with .NET strong name remove
    By LaBBa in forum The Newbie Forum
    Replies: 1
    Last Post: March 23rd, 2011, 07:03
  3. SLM7x signature
    By sumon in forum The Newbie Forum
    Replies: 5
    Last Post: March 27th, 2007, 20:52
  4. Tool for removing strong name signatures from .NET assemblies
    By dELTA in forum Tools of Our Trade (TOT) Messageboard
    Replies: 1
    Last Post: October 5th, 2005, 12:20
  5. strong? Possible attacks?
    By Ray in forum RCE Cryptographics
    Replies: 2
    Last Post: July 25th, 2005, 13:48

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •