On Fri, Sep 3, 2021 at 11:08 PM duilio foschi via lazarus < lazarus@lists.lazarus-ide.org> wrote:
> I thought it would be easy to use an hex editor like PSPad hex, find the > number > 2005 as 07D5 then fix it (maybe after the right guess in case of multiple > hits). > As a test I compiled a simple example on x86_64 with integers for the year, month and day, placed a break point on the encodedate call and inspected the assembler: /home/christo/tmp/project1.lpr:14 date := EncodeDate(y+$1a2b3c4d, m, d); OpCode Assembler 8B05CEF70700 mov eax,[rip+$0007F7CE] 678DB84D3C2B1A lea edi,[eax+$1A2B3C4D] 81E7FFFF0000 and edi,$0000FFFF In this case the constant $1a2b3c4d is added to the content of register eax, encoded in the lea instruction. The constant is recognizable as a little endian byte sequence 4D 3C 2B 1A following the lea instruction bytes 67 8D B8. Since your setup is probably different, your code may be compiled into slightly different instruction sequences so you have to inspect the generated instruction sequence, as mentioned by Bart. Also note that testing with a string value will likely yield completely different results, since a string literal will in most cases be stored separately as mentioned by Sven. This is in contrast to your original question of modifying an integerconstant which can easily be encoded as part of an instruction. To my surprise, I could not find the word 07D5. As I vaguely remember the > big endian/little endian question, I tried to look for D507: no hit. > This is somewhat surprising since my simple example shows the little endian encoded constant as part of the instruction bytes. However, you have to look at the specific instructions generated in your program. I assume this is for remote patching of a large executable, else it would be simpler to just distribute the recompiled version?
-- _______________________________________________ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
