Newbie: Problems with JMP

[APM]

Hello,

I am using the following relative jump instruction

E9 0C070000

but my program keeps crashing.

Using W32Dsam, in the decompiled text, I see the instruction:

:00274181 JMP 00274892

which is what I inted to have. But when I try to run the program
in debugging mode, I see that the W32DSam debug window show that this
instruction is

:00274181 jmp F04D4892

which is causing the cause of the crash of my program. Now, my
question is,
what is the cause of this and how can I solve it?

Note that even more amazing to me is the fact that decompiling my
program using
Ollydbg, I read that the memory location I am looking into contains:

00274181 E9 0C0726F0 JMP F04D4892

Why are the last two bytes of my instruction changed depending on who
is reading them?

Thank you,

Arturo.

[Ka-Chi CHEUNG]

> I am using the following relative jump instruction
>
> E9 0C070000
>
> but my program keeps crashing.
>
> Using W32Dsam, in the decompiled text, I see the instruction:
>
>:00274181 JMP 00274892

Hmmm, from what I see, it doesn't look like you are writing your
own code but rather patching some other code.....Doing some cracking huh?
If I am indeed wrong, and you are trying to use E9 0C070000 in your code,
then may I suggest that you use your assembler to figure out the offset
for you.....

>
> which is what I inted to have. But when I try to run the program
> in debugging mode, I see that the W32DSam debug window show that this
> instruction is
>
>:00274181 jmp F04D4892
>
> which is causing the cause of the crash of my program. Now, my
> question is,
> what is the cause of this and how can I solve it?
>

You should really look at the op code. Is it still E9 0C070000? I
really doubt it. I have heard that WDASM is a bit buggy on the debugging
side, but I don't think it will make such a big mistake. It is likely that
your opcode has already changed to E90C0726F0

If the disassembled code differs from the runtime code, it is most
probable that 00274148 has been written over during runtime. Use SoftICE
and bpm on cs:00274181 to see for sure. Another easy way to check this is
to start debugging, ie loading the program to mem, but don't run anything,
and check whether 00274181 is indeed your existing opcode, then break
point on it and run to see if it got changed.

> Note that even more amazing to me is the fact that decompiling my
> program using
> Ollydbg, I read that the memory location I am looking into contains:
>
> 00274181 E9 0C0726F0 JMP F04D4892
>

Same as above
Ka-Chi