SOLVED: Asm question - Call instruction - Signed #

Okay, I am quite new to assembly, and this is just a small question that I have been trying to figure out for the past 2 hours. At this point I figured I would get the advice of someone with more experience.
Basically I am trying to find the connection between the address where the call instruction is at, to the address of the function being called.

Here is what IDA shows: (I only changed the name of the function)
BF912B25    E8 B8 B3 F8 FF         call XYZ(x,x)
Although IDA reports the address of XYZ being BF89DEDD




It seems like B8 B3 F8 FF would == FFF8B3B8 because of DWORDs being in little endian format, but adding or subtracting that value to the call instruction's address(BF912B25) is not getting me anywhere near the function's(XYZ) address(BF89DEDD)

Usually it seems that all you need to do is add the bytes(in DWORD format) to the address where the call instruction is located.
But what is going on here instead is: a subtraction is taking place because the call's address BF912B25 is > than the fn's address BF89DEDD
Maybe because of this subtraction the byes B8 B3 F8 FF are translated differently?
Perhaps FF might have something to do with a subtraction taking place, instead of an sum?



So overall my question is:

Given call's address of BF912B25, how exactly are these bytes B8 B3 F8 FF manipulated so that the final address is the address of XYZ: BF89DEDD ?
I have done so many different mathematical operations, and haven't even gotten close to BF89DEDD

I also tried to find some way for those bytes(B8 B3 F8 FF) to be manipulated so that I got an answer close to 74C48 because that is the difference between calls address(BF912B25) and XYZ's address(BF89DEDD), but I cannot seem to find any pattern or translation/mathematical operation to get that value(74C48)






Thank you very much for your help.
-Matt

PS - If you are as baffled as I am, and need to know exactly what I am debugging and/or need screenshots from IDA for more information, then let me know
(I just didn't post them because I am trying to figure it out on my own... but obviously this is quite a set back for me not being able to translate those byte codes into the final address of the function XYZ)


Edited by Matts_User_Name - 17 July 2009 at 5:40pm

Wow!
I cant believe I didn't see that.
 
You would have thought I would have just tried subtracting 8B3B8 to call's address by killing the Fs.
That does indeed make sense because that translates to an offset for subtraction.

I guess while doing so many tests, that one threw me off because calc.exe reported it as positive number, but now doing a test of entering -1, it gives 0xFFFF,FFFF,FFFF,FFFF and when going back to dec it then reports it as 18,446,744,073,709,551,615 instead!
I guess it doesn't do too well with signed numbers from Hex or Bin --> Dec

Man I spent 3+ hours working on this... and I had a feeling it was something to do with the Fs.
I shall make a note to watch for trailing Fs(in byte display) and recognize it will be a subtraction offset, where I need to kill the Fs

Hopefully this helps someone else out there that became tripped up by this.



Thank you very much!

Lookup two's complement on Wikipedia :).

Well, that's just how the call/jmp instructions are coded. If you want to do an absolute jump, you can do this:

mov eax, 0x12345678
jmp eax

See http://www.geocities.com/thestarman3/asm/2bytejumps.htm

Originally posted by BanMe Indirect calling can go here to ;)   ive modified it since then but hey I just use push instead of pop and I user the Context Registers to pass stuff..newer sources are included in my server.. if you can find it and understand it props to you :D   http://www.woodmann.com/forum/showthread.php?t=12854

What does this have to do with the topic? Matts_User_Name was asking about call instructions, not CSR replacements...