Jump to content
Tuts 4 You

Verify Your Key

Go to solution Solved by Washi,

Recommended Posts


Language :  VB.NET
Platform :  Windows x86 / x64
OS Version :  All
Packer / Protector :  ConfuserEx Modded

Description :

Get the key and verify.

Screenshot :



Link to comment
Share on other sites

  • 1 month later...
  • Solution

Key: 7c6483ddcd99eb112c060ecbe0543e86

Not really a KeygenMe, but oh well..



Only dnSpy was necessary. No deobfuscation needed.

  1. Open app in dnSpy, notice that virtually all method bodies are unreadable.
  2. Set breakpoint on <Module>::.cctor and step once over the first method. Reopen the module from memory and observe that all methods are fully visible now (albeit still obfuscated). Therefore, the method just executed must be the decryption routine.
  3. Dump the module from memory to the disk, remove the original call to this decryption routine, and save module again.
  4. Start new module, notice that it opened a separate cmd window stating that it had detected it is running in a virtual machine, and terminates the current process (why would anyone put this in a keygenme?).
  5. Set breakpoint on Process::Start in System.dll and restart to observe where the call came from in the call stack:
    Crack-me-dumped.exe!<Module>.SearchForVirtualItemEventArgs(string A_0) (IL≈0x004F, Native=0x05352548+0xC4)
    Crack-me-dumped.exe!<Module>.EXPRCONCAT() (IL=0x0091, Native=0x053C5400+0xDC)
    Crack-me-dumped.exe!<Module>.<Module>() (IL=0x005D, Native=0x0122C250+0x7D)

    Remove the call to EXPRCONCAT, save module, restart.

  6. Notice it opened another cmd window, this time stating it had detected emulation (even though I did not do any emulation?). Same process applies here, set breakpoint on Process.Start, inspect call stack,remove call from <Module>::.ctor, save and restart.

  7. Now notice a MessageBox being shown that dnSpy was detected on disk (pretty silly feature, given the fact that it can be very legitimate to have dnSpy on a disk). Pause execution, inspect call stack again, yada yada yada...

  8. Finally, the app opens normally. Enter random key and observe the MessageBox, pause execution, inspect call stack, notice that the method calling the messagebox also has a call to Operators.CompareString, with the textbox's text set as one of the arguments.

  9. Set breakpoint on this call and retry. Step into the Operators.CompareString method to reveal the key in the second argument.


  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...