upvote
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.

reply
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.

reply
Yep. I used SoftICE to do a few of these dongle-workarounds. Amazing and terrible software. :D
reply
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.
reply
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.)
reply