Another method (much more common for software that asks for two pieces of information, like a name and a key) is to take a memdump of the process at the "your key is invalid" dialog, find the invalid key you just typed, and hope that a valid key is somewhere nearby in memory. Unlike the assembly trick, this requires 0 programming expertise beyond the ability to type `strings` on the command line.
This works because some programs use a hashing algorithm to calculate the key based on the name, do a strcmp, and pop a messagebox if the keys don't match, without zeroizing the valid key buffer first. If the key buffers are on the stack (or if the two mallocs just happen to use the same region in memory), it is often easy to find a valid key if you know where the invalid one is.
I guess software that derives keys this way is far less common than it once was, but I know of somebody who cracked something using this method just a few years ago, so it still pops up from time to time.
When I was a child, in the 90s, I did this all of the time.
Input a unique string I could watch for, fire up SoftICE, watch for the string, and then step through until the == comparison happened, then either grab the calculated key and input it, or patch the comparison from == to != or just return true, depending on the implementation.
SoftICE was such a gift and pain in the ass.
I did a massive crack that involved a program and it’s inf/dll hardware driver package.
Some of the most rewarding work I’ve done and also just so tedious!
Having to stop the OS like that and accidentally getting to the kernel but then not wanting to lose my position so having to hit step over and step out until just the right place… whew.
Yep. I used SoftICE to do a few of these dongle-workarounds. Amazing and terrible software. :D
Haha yeah. It was mostly just fun for me as a nerdy child who spent way too much time on Astalavista forum.
Cracking and RE were just gateways into a career in (defensive) security for me.
I honestly can’t recall how I even found SoftICE, but my uncle gave me a floppy with LJPEGViewer and the license was written on the disk. Eventually I lost the original but I’ll be dammed if I’m going to use Paint. I fired up SoftICE, managed to break before the “invalid key” dialog, and just did a cute little “return true” and that was that
mellanox switches included an executable keygen in their firmware bundle. It could be used to both generate a key (given feature set) combined with a secret, but could also be used to validate what features a given key gave you (using the secret). Hence, the secret was stored in the binary and was easily visible with strings and one could then just use the tool itself to generate keys.
Sort of reminds me of the DEC PAKGEN tool to generate licenses for the VMS license management facility, which DEC distributed so third-party software vendors could issue licenses for their own software.
To prevent vendor A from creating licenses for vendor B's products, each DEC-issued PAKGEN license only authorized license generation for a specific named vendor's products.
As with all other DEC-supplied VMS software, PAKGEN was licensed through the VMS license management facility.
Thus if you could somehow get a PAKGEN license for the vendor name "DEC", you could use it to generate licenses for arbitrary DEC products.
Including PAKGEN itself.
And you could therefore generate licenses authorizing PAKGEN to generate licenses for arbitrary vendors' products.
The proper thing to do is not to zeroize the correct string memory before comparing. The proper thing is to only store the hash in the binary in the first place, not the correct string. (Although having a 2nd layer of hashing before comparing might also be a good idea, and in that case you would want to zeroize the 1st hash before comparing the 2nd hash.)
You can't not store the correct string in this case, as the key is calculated from the user's email address. There is an infinite number of possible keys. THe only way to check if the key is correct is to recalculate it yourself.
These days, I guess you could make the key an ECDSA signature for a public key embedded in the binary if you were willing to accept such long keys.