Hello stryker :)
Win9x supports any base >= 400000h.. so all you've to worry about is not going lower than that, and of course you should avoid also something extreme like ~70000000h.
Win9x supports any base >= 400000h.. so all you've to worry about is not going lower than that, and of course you should avoid also something extreme like ~70000000h.
try to run the same exe (with fixed value: 4000000h, not hinst) two times on win98.
try to run the same exe (with fixed value: 4000000h, not hinst) two times on win98.
400000h not 4000000h :grin:
Both 400000h and 4000000h work fine on 9x.
Tested: ran 2 instances of app with 400 0000h on 98.
without relocation.
Result: OK.
Tested: ran 2 instances of app with 400 0000h on 98.
without relocation.
Result: OK.
As long as we are picking a base address, maybe a more useful number should be used? 0C9C300h? 058C300h? I think I'll use 0C30000h. :grin:
thanks for the tests :) Now, I can put this aside.
I would guess that if you picked a very low base, then you must retain relocation information.
On NT based OS's, down to 10000h ought to work ok.
On Win9x, as I already wrote, it must be >=400000h.
bitRAKE: alignment must be 10000h minimum, so no ????C300h, I'm afraid. ;)
On Win9x, as I already wrote, it must be >=400000h.
bitRAKE: alignment must be 10000h minimum, so no ????C300h, I'm afraid. ;)
bitRAKE: alignment must be 10000h minimum, so no ????C300h, I'm afraid. ;)
To fool disassemblers you should really crypt your code.
Runtime SMC "unfolding" is even better.
Runtime SMC "unfolding" is even better.
The more the marrier - thanks, Maverick. :)
what does relocating mean?
what does relocating mean?
What said that module handle must be an address of EXE in memory? The system should be able to restore this address from the handle, but it's possible, for example - because the addresses are always 4k aligned - to use the lowest 12 bits of module handle value for some additional module flags, etc.
As far as I know, microsoft doesn't guarantee anything about HANDLEs;
they are supposed to be opaque "objects" which shouldn't be used directly
in any way. Depending on your base address to be your HINSTANCE works for
now, and probably will in all windows versions, but there's no guarantee.
Or could you point me to an official article by microsoft that says otherwise?
At last, what is so awful by doing one single call to GetModuleHandle(NULL),
which no user will ever be able to feel? Even hutch seems to agree here :).
It's right what maverick says, 0x400000 should always be free for executable
loading (or else m$ will have serious trouble) - but there's still no guarantee
that your hinstance is your imagebase...
But oh well, if you want to be elitists, so be it.
they are supposed to be opaque "objects" which shouldn't be used directly
in any way. Depending on your base address to be your HINSTANCE works for
now, and probably will in all windows versions, but there's no guarantee.
Or could you point me to an official article by microsoft that says otherwise?
At last, what is so awful by doing one single call to GetModuleHandle(NULL),
which no user will ever be able to feel? Even hutch seems to agree here :).
It's right what maverick says, 0x400000 should always be free for executable
loading (or else m$ will have serious trouble) - but there's still no guarantee
that your hinstance is your imagebase...
But oh well, if you want to be elitists, so be it.
Help! i'm in the dark... what is the significance of ????C300h other than the fact that C3 looks kinda like a guy with a big nose?
assuming hInstance is the address of your base image... can't you use
or something similar?
The call should push the addr of @@ onto the stack, and the pop should put it into eax.
It works on my program
--Chorus
start: call @F
@@: pop eax
and eax,0FFFF0000h
or something similar?
The call should push the addr of @@ onto the stack, and the pop should put it into eax.
It works on my program
--Chorus
Help! i'm in the dark... what is the significance of ????C300h other than the fact that C3 looks kinda like a guy with a big nose?
C3 is the retn instruction.
Couple of more questions re:HINSTANCE.
1) When I load up my program in OllyDebug, the initial state of the registers says EAX = 401000h i.e., the ptr to start. Is the debugger doing this, or is this how windows starts off your program? I tried using eax right off the bat and it didn't work...
2) If in your PE header you "prefer" your image base to be 400000h, don't all your items in .data etc, get hardcoded to this address. For example, if you disassemble or debug your app you see that mov hInstance,eax becomes mov [405580h],eax. Which is an absolute value. So if your program *was* loaded at a non-preferred location, wouldn't the app crash once you tried to move a dword to 405580h? After all, your data wouldn't be mapped to 405000h anymore (or wherever the linker decides it should go)
--Chorus
1) When I load up my program in OllyDebug, the initial state of the registers says EAX = 401000h i.e., the ptr to start. Is the debugger doing this, or is this how windows starts off your program? I tried using eax right off the bat and it didn't work...
2) If in your PE header you "prefer" your image base to be 400000h, don't all your items in .data etc, get hardcoded to this address. For example, if you disassemble or debug your app you see that mov hInstance,eax becomes mov [405580h],eax. Which is an absolute value. So if your program *was* loaded at a non-preferred location, wouldn't the app crash once you tried to move a dword to 405580h? After all, your data wouldn't be mapped to 405000h anymore (or wherever the linker decides it should go)
--Chorus
2) ..not if you provide a valid reloc section.. then all those istances like [405580h] will be known, and will be relocated to the new address.
This is very common for DLL's.
This is very common for DLL's.