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