bypass license of very old software, Access violation (C0000005) x32dbg

Question

I'm trying to bypass the license of a very old software that i was using many years ago, now, the company of that software is closed and i can't get a license so, with a little bit of knowledge in assembly i changed

mov byte ptr ds:[ecx+0x72], al

to

mov al,1

then i got

The software compare a hash with the hash of the key code you entered, if it's the same, it will work a random license request code generated everytime you run the .exe

using GenerateRandomNumber and hashed by using HkdfHashAlgorithm here's the .exe

https://www.mediafire.com/file/ujd576jm8eg7oay/SpoolManager.exe/file

I'm not sure if that illigal to post it here, but I have no other solution

Appreciate any help

Answer 1

mov al, 1, the instruction you want to use becomes b0 01 (you can check here), assuming x86-32. That is, 2 Bytes.

The instruction you are patching (mov byte ptr ds:[ecx+0x72], al) is 88 41 72 and so takes up 3 Bytes. See the problem already?

That means you are only patching the first two bytes of the instruction and need to pad it with a single-byte NOP (no operation, i.e. 90) in order for all subsequent instructions to be correct.

Otherwise the processor will start decoding at <patched-instruction>+2 and assume that it is correct. Which it probably isn't.

Not sure what all those screenshots are supposed to be about. They seem to have no relation to the instructions you said you were patching ...

---

Now that you have posted the screenshot of the patch site, we can even potentially tell you what the CPU was trying to execute.

The patch site before your patch was directly at the return from a function:

88 41 72                mov    BYTE PTR [ecx+0x72],al
c2 04 00                ret    0x4
; ------ end of function
90                      nop
90                      nop
90                      nop
90                      nop
90                      nop
90                      nop

After your patch it would have looked like this:

b0 01                   mov    al,0x1
72 c2                   jb     0xffffffc6
04 00                   add    al,0x0
; ------ end of function
90                      nop
90                      nop
90                      nop
90                      nop
90                      nop
90                      nop

Still 12 Bytes overall (6 inside the function you were patching), but a completely different meaning. We can guess that either the jump instruction was taken and led into a location which gave the access violation, or that the condition (of jb) didn't evaluate to true and the CPU executed the add followed by 6x nop and then ended up in a completely different function (at least this looks like a function prologue) but with the stack still in place from the call to the previous function and so on ...