A problem seems as if couldn't be rellocated correctly.

NTDEV
1

I write a call in a driver ProbeForRead(0x800000,0x1000,1);
when i view it in IDA like:
push 1
push 1000
push 800000
call ds:ProbeForRead
but when the driver is loaded by the system, it looks like:
push 1
push 1000
push 800000
call [0001322C]

it seems as the call address could not be relocated correctly. Why?
Thanks

2

when the driver had been loaded in the system, the call should be call [BaseAddr+0000322C]. because [BaseAddr+0000322C] stored the import function entry for ProbeForRead.

3

xxxxx@gmail.com wrote:

I write a call in a driver ProbeForRead(0x800000,0x1000,1);
when i view it in IDA like:
push 1
push 1000
push 800000
call ds:ProbeForRead
but when the driver is loaded by the system, it looks like:
push 1
push 1000
push 800000
call [0001322C]

it seems as the call address could not be relocated correctly. Why?

How did you get that listing? If the instruction says, for example:
E8 2C 32 01 00
then everything is perfectly OK. The E8 call instruction is relative.
The operand is added to the EIP register (which contains the address of
the next instruction) to create the destination address.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

4

The original data(in the *.sys file) at the call address is FF 15 2C 32 01 00, when the driver had been loaded by the system, 2C 32 01 00 should be equal to BaseAddr+0000322C.

5

> The original data(in the *.sys file) at the call address is FF 15 2C 32 01 00,

… which means we are speaking about indirect call instruction here - it is 2-byte opcode that starts with 0xFF prefix, so that it tells the CPU to call a function, address of which is stored at 0x0001322C This is how all imported functions are called under PE format. Apparently, linker assumes that your driver will get loaded at the base address 0, so that 0x0001322C is just the offset into PE image - the system loader will write the address of the callee to BaseAddress+0x0001322C . Therefore, I don’t really know what the “problem” is all about here - what you show us is perfectly normal code…

Anton Bassov

6

xxxxx@hotmail.com wrote:

> The original data(in the *.sys file) at the call address is FF 15 2C 32 01 00,
>

… which means we are speaking about indirect call instruction here - it is 2-byte opcode that starts with 0xFF prefix, so that it tells the CPU to call a function, address of which is stored at 0x0001322C This is how all imported functions are called under PE format. Apparently, linker assumes that your driver will get loaded at the base address 0, so that 0x0001322C is just the offset into PE image - the system loader will write the address of the callee to BaseAddress+0x0001322C . Therefore, I don’t really know what the “problem” is all about here - what you show us is perfectly normal code…

I *believe* his claim is that the instruction was unchanged after the
driver had theoretically been loaded and relocated. However, he hasn’t
told us what he was using to view this information, so I am dubious.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

> I *believe* his claim is that the instruction was unchanged after the driver had theoretically

been loaded and relocated. However, he hasn’t told us what he was using to view this
information, so I am dubious.

Well, he said something about IDA. My theory is that, in actuality, he presented a line from disassembled binary, rather than that of a loaded image - it is obvious that the line like “call [0001322C]” is just bound to
bugcheck, so that it just cannot have been taken from a loaded kernel image…

Anton Bassov

8

i meant, in IDA, “FF 15 2C 32 01 00” was interpreted as call ds:ProbeForRead.
when it had been loaded in the system, i view it by SoftICE,or syser, it shows call [0001322C]

9

> when it had been loaded in the system, i view it by SoftICE,or syser, it shows call [0001322C]

Try viewing with the proper tool, i.e. WinDbg.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

10

but, in WinDbg, it shows the same call. its strange that not all "FF 15 2C 32 01 00"s are interpreted as call [0001322C], some are interpreted correctly as call ProbeForRead because the address in the instructions can be relocated correctly.

11

xxxxx@gmail.com wrote:

but, in WinDbg, it shows the same call. its strange that not all "FF 15 2C 32 01 00"s are interpreted as call [0001322C], some are interpreted correctly as call ProbeForRead because the address in the instructions can be relocated correctly.

My guess is that there are other critical pieces of this story that
you’re not telling us. Relocation clearly works – the system would
come crashing down in an instant if it did not.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.