Index
> Windows > Base address $BFC00000 not working |
| Author |
|
|
AlexP 12 Mar 2008, 23:16
In Windows, any address over 0x8000 0000 is reserved for the 2gb space for windows libraries and other fun stuff.
[edit] this cutoff mark can be changed, I don't remember how. |
|||
12 Mar 2008, 23:16 |
|
|
Controller 13 Mar 2008, 00:15
I'm working on a replacing a system dll which uses this base address. That's why (I guess) I must same address.
|
|||
|
13 Mar 2008, 00:15 |
|
|
AlexP 13 Mar 2008, 01:37
Maybe it uses sysenter? IDK, someone else must be able to help you.
|
|||
|
13 Mar 2008, 01:37 |
|
|
f0dder 13 Mar 2008, 01:43
AlexP wrote: Maybe it uses sysenter? IDK, someone else must be able to help you. Sounds like the problem is FASM has a signed check when dealing with RVAs for 32bit code... _________________  - carpe noctem |
|||
|
13 Mar 2008, 01:43 |
|
|
Controller 13 Mar 2008, 01:51
It endeed uses some strange code due mixed 16/32 code etc (Some instructions I even had to include as binary). But thats not the problem here
 |
|||
|
13 Mar 2008, 01:51 |
|
|
AlexP 13 Mar 2008, 02:28
f0dder wrote:
Just shows how much I know about OS libraries! |
|||
|
13 Mar 2008, 02:28 |
|
|
f0dder 13 Mar 2008, 02:36
AlexP wrote:
Well, I just don't get why you're throwing sysenter into the mix, Controller's post is about a build-time FASM problem, and nowhere in his source snippet is sysenter mentioned. Are you just trying to sound smart because kernel32.dll was mentioned?
I dunno if sysenter is even used directly in the "high-level" win32 subsystem DLLs anyway, or only after going through NTDLL.DLL... also, I can't recall seeing a sysenter being used directly, iirc always done through a "call [fs:0xC0]" or something like that. _________________ - carpe noctem |
|||
|
13 Mar 2008, 02:36 |
|
|
revolution 13 Mar 2008, 02:51
I think the problem is the wapple, it is probably due to the interaction with the cyletruncion. If that doesn't solve your problem then check the hoodickey on the whatsit, that ought to fix it.
Do I sound smart or what!!! |
|||
|
13 Mar 2008, 02:51 |
|
|
revolution 13 Mar 2008, 02:55
But seriously, the minimal code to trigger this error:
Code: format pe gui 4.0 dll at 0xbfc00000 start: dd RVA start ; <---- error: value out of range. Last edited by revolution on 13 Mar 2008, 02:58; edited 1 time in total |
|||
|
13 Mar 2008, 02:55 |
|
|
AlexP 13 Mar 2008, 02:57
lol! I actually was trying to understand that untill about halfway through...
f0dder: No, I just (guessed) that since you cannot access the upper memory normally, you needed to be in some special windows mode (aka sysenter???) IDK, just a gues.. Ohh, and I have seen the sysenter instruction in Olly, just bored so I held down f7 through ExitProcess one time I think. |
|||
|
13 Mar 2008, 02:57 |
|
|
bitRAKE 13 Mar 2008, 03:18
f0dder wrote: Sounds like the problem is FASM has a signed check when dealing with RVAs for 32bit code... org $FFFFFFFFBFC00000 Not that the addresses are generated correctly - he'll have to check that, but they should be relative. Look at file EXPRESSI.INC of the FASM source: Code: rva_ok: mov byte [edi+12],0 mov eax,[code_start] mov eax,[eax+34h] cdq ;* change to mov edx,0 should fix it - maybe break something else? sub [edi],eax sbb [edi+4],edx add edi,14h jmp calculation_loop Edit: any ORG directive is sufficient to bypass the error - error is somewhere else? All the addresses get messed up, so it really doesn't fix anything. org $BFC01000 worked on my test file, but I think it depends on section ordering. _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
|
13 Mar 2008, 03:18 |
|
< Last Thread | Next Thread > |
Forum Rules:
|