Help cracking an obfuscated .NET application pweathe :D

[jacktheripper51]

Hey folks!
I have this obfuscated .NET application here that only runs on a specific PC. I've already done a ton of research on how it's protected.
I'm a novice cracker myself and thought pro-REers could help me through this
(Apologize for a lengthy post)

Whole story:

It's a database application. It works with MSSQL and tried to login with sa with a password stored in the application itself.
It failed to login because the password wasn't set for sa in my instance. So I restricted MSSQL to use TCP/IP and could see
the SSL packets with wireshark, but couldn't decrypt them until I found out MSSQL2000 didn't have any SSL support so
I could then decrypt the password easily. But this isn't the problem. Even after this, the application terminates
right when opened because it's still restricted to the same system.

I fired up rohitab's API Monitor and it actually monitored mscorwks.dll's calls to winapi.
I found out that it unBase64s three keys in the registry and RSA-decrypts them (found it out by hooking CryptDecrypt and CryptEncrypt).
I got the keys and I can decrypt them in my own app (and even encrypt, tested this with the actual application).

But not everything is obvious through API Monitor:
1) It decrypts the three keys into one that's used for a custom title and two integers strings that look like UUIDs. (7120-6377-1045-3112787678 and 3489-1229-8789-0761147476).
2) The application retreives through WMI Win32_Processor.Processorid (which is a hex string) and the network card's name and mac.
3) It then fails.

My guesses:
The two integer strings were generated on the previous system somehow using the info from (2) and stored using the maker's keygen.
It generates two other strings from the info retreived on the current system, compares and fails.

What I tried:
I encrypted 7120-6377-1045-3112787678 without the last digit '8' and stored it in the registry. Fired up the app along with App Monitor.
It could successfully decrypt the string I encrypted (I once again hooked CryptDecrypt) but failed later on with a .Net Exception saying the encrypted string
isn't the right length (WHAT !? DECIMAL ENCRYPTION ?). The Exception does not have any associated CryptDecrypt/CryptEncrypt calls.

The Exception had a call stack (with garbage function names due to obfuscation). I tried every decompiler/disassembler out there only to find most functions consisting of this:
.maxstack 8
IL_0000: nop
IL_0001: nop
IL_0002: ldnull
IL_0003: ret
I want to know how the integer strings could be generated, I don't have the 'decrypted' form yet (i.e. original system name + MAC). I'll get them soon.
Let me know if I need to upload the assembly (note that it works with a ton of other assemblies + a DB you need to import into MSSQL totalling about 20-30MB) I doubt anyone has MSSQL installed anyway

Apologize for my simple English. I hope I have explained well.
Thanks.

[kao]

Originally Posted by jacktheripper51

I tried every decompiler/disassembler out there only to find most functions consisting of this:
.maxstack 8
IL_0000: nop
IL_0001: nop
IL_0002: ldnull
IL_0003: ret

Looks like Necrobits feature from .NET Reactor. MaxToCode and few other protections do similar tricks. Please try using DNID (http://board.b-at-s.info/index.php?showtopic=7910) , ProtectionID (http://pid.gamecopyworld.com/) and similar tools to find out which .NET protector was used there, then search for specific tools to unpack it.

When you get unpacked assembly, your work will become much much easier.