HaYDeN wrote:
If you use a register or other mechanism that can reference or represent a true 64bit value then you can jmp across the entire address space, the problem with this is one is trying not to dirty any registers.
Not sure if you saw this, as I edited it in around the time you were probably writing your response:
Aiken Drum wrote:
... I think you can just do this in place of the plain jmp:
Code:
jmp [rip+0]
dq %returnaddress%
But I'm out of my element with x64, so I'm not sure.
Edit 2: That change in the lua compiles for me, but hacktool is injecting the plain jmp, which doesn't, and I don't know how to change that, so that's as far as I got.
If you can afford the extra bytes at the source location, you should be able to do full 64-bit jumps in all cases. I don't know how much code you're replacing in each case, though. If something is just diverting a single source jmp, then obviously that's not feasible.
But back to your post:
HaYDeN wrote:
Interesting anyway, it could be because of large amounts of ram but that shouldn't matter, I only have 12GB - I have not seen this problem arise - by design it should try to allocate the memory as close as possible to origin process, only thing I can think of is that your memory is _horribly_ fragmented due to long uptime and/or thrashing micro allocations.
Nope. Even off a fresh boot, I get the same results.
Quote:
Code:
if (HackTool->GetArchitecture() == 64) {
size_t TempNearTo = HackTool->GetBaseAddress() + HackTool->GetBaseSize();
if ((NearTo == 0) && (TempNearTo > 0)) {
NearTo = TempNearTo;
}
}
I don't know what compiler you're using, but size_t is unreliable as a type to hold pointers as integers, which is what you appear to be doing here. Not so much size-wise, unless you're compiling in some kind of 32-bit compatibility mode for source tha was written for x86, but more because it's not guaranteed signed or unsigned. You should really be using intptr_t or uintptr_t, if your STL/compiler supports a recent enough C++ standard to have them.
My concern is that you might have an overflow or underflow or wrap in your ints-as-pointers math. Not here, since this code looks innocuous, but maybe somewhere else. Or maybe one or both values are getting truncated to 32 bits somewhere, in which case 0x1c7000000 -> 0x0C7000000 could appear to be within 2GB of 0x140000000.
Dunno, just throwing out ideas. Can you seed/hardcode a dummy run with the addresses from my quoted debug spew and see if you spot it going awry at some point?
Login
FAQ
Search
Members
- Indeed correct - in theory with a typical fixed jmp you would be restricted to that of an 32bit (hah!) integer (i.e. + or - 2GiB / 0x80000000h) from the jmp position.
