2

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

enter image description here then i got

enter image description here

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

using GenerateRandomNumber enter image description here and hashed by using HkdfHashAlgorithm enter image description here 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

Improve this question
2
  • Can you show code where did you change assembly? And assembly that you changed has very different meaning than original.
    – Rok Tavčar
    Dec 19, 2019 at 8:34
  • @RokTavčar please check updated post
    – JDEV
    Dec 19, 2019 at 14:14

1 Answer 1

Reset to default
4

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

Improve this answer
2
  • I don't have enough knowledge in assembly to understand your answer, i'm sure it's correct and i really appreciate it i goes more deeper and i found the line where it compare the request code with the code i entered, if it's equal it jump, je so i changed it to jne and the .exe stopped working please check my new question to understand more reverseengineering.stackexchange.com/questions/22784/…
    – JDEV
    Dec 19, 2019 at 17:14
  • 1
    The point is that on CISC instructions have different lengths. And if you want to patch something you must make sure that your patch doesn't cause subsequent instructions to become invalid. This could also happen if your patched instruction is longer than the original one at the patch site.
    – 0xC0000022L ♦
    Dec 20, 2019 at 9:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.