Cheat Engine

[predprey]

I understand that most x64 executables compiled for Windows uses MS's x64 calling convention. So far, that has yielded no problems and I interpret the arguments passed into a function as rcx,rdx,r8,r9 etc. However, while reversing the file structure for Zone of Enders, I encountered this behaviour for Window's SetFilePointerEx function which goes against the argument passing rule of the above convention. As shown in the screenshot below, the offset to move the file pointer to seems to be stored in RDI instead of RDX. The syntax for SetFilePointerEx is

[Dark Byte]

This is just a way to get the current filepointer location

It moves the current filepointer by 0 and stores that in the address pointed at by r8 (local var in this case)

There is likely another setfileposition call somewhere else that sets it, or it's done by closing and reading useless data to get back

[predprey]

Thanks, I had doubts on whether it was really just getting the current file pointer even though the ASM code and calling convention rules says it is. The file pointer most likely got updated before this routine got executed because double checking with the file itself, RDI is always the position to be read in next. Now I'm just puzzled how the game is moving its pointer.

Backtracing from a breakpoint within the kernel function itself only gave me this location that calls SetFilePointerEx for this exact file handle though. All other calls for SetFilePointerEx handles other files. Game doesn't break on SetFilePointer either.

Will closing an existing file handle and opening another for the same file return the same file handle value? The file handle for the same file remains the same for the same session though it may change between different runs.

[Dark Byte]

It's impossible to predict if the filehandle value will be different when it gets closed and reopened. Best assume different

Perhaps instead of normal read and writes it uses filemapping

[predprey]