Index
> Windows > Partial relocations |
| Author |
|
|
revolution 17 Jun 2015, 23:47
"jmp address" doesn't generate any relocation because "jmp near" is relative.
"jmp [address]" will need a relocation. To answer your question, it is easy to prevent all relocations by not including and relocation information in the exe. |
|||
17 Jun 2015, 23:47 |
|
|
alexfru 18 Jun 2015, 06:18
revolution wrote: "jmp address" doesn't generate any relocation because "jmp near" is relative. If "address" happens to be a numeric constant and not a code label, there needs to be relocation when assembling into an object file. I just had to include support for such relocations in my linker. The relocation isn't needed, of course, when assembling into an executable that will be loaded at a known fixed location. |
|||
|
18 Jun 2015, 06:18 |
|
|
revolution 18 Jun 2015, 06:40
alexfru wrote: If "address" happens to be a numeric constant and not a code label, there needs to be relocation when assembling into an object file. So anyway, if you need that then an alternative could be: Code: mov eax,0x12345678 jmp eax |
|||
|
18 Jun 2015, 06:40 |
|
|
alexfru 18 Jun 2015, 06:52
Doesn't have to be Windows. In my case someone was trying to create C-callable wrappers for MikeOS APIs and my C compiler, Smaller C, and calls to those are like "call 3". Everything was fine until they tried to link object files containing those "call 3's" with my linker. It was definitely not an expected scenario for me when I was writing my linker.
 |
|||
|
18 Jun 2015, 06:52 |
|
|
revolution 18 Jun 2015, 07:05
alexfru wrote: Doesn't have to be Windows. |
|||
|
18 Jun 2015, 07:05 |
|
|
alexfru 18 Jun 2015, 07:32
Sure, move, unless your question was intended for the OP.
|
|||
|
18 Jun 2015, 07:32 |
|
|
revolution 18 Jun 2015, 08:39
I got confused there. But anyhow, if the OP doesn't mean Windows specifically then the question still stands. Otherwise it might be useful for another topic to discuss non-Windows (and perhaps any non-mainstream-OS) style relocations.
|
|||
|
18 Jun 2015, 08:39 |
|
|
randomdude 18 Jun 2015, 14:01
i have a dll that creates a codecave into the main exe. lets say i want to create it at exe address 0x00401000 by placing a jmp there and then jmp back to 0x00401005
Quote: mycodecave: this wont work, it will jmp to base of dll code +5 isntead of at exe address 0x00401005 |
|||
|
18 Jun 2015, 14:01 |
|
|
revolution 18 Jun 2015, 14:38
So the exe has no relocations? But the DLL does?
Does using a register work for you? Code: mov eax,0x00401005 jmp eax |
|||
|
18 Jun 2015, 14:38 |
|
|
randomdude 18 Jun 2015, 15:29
sure i can use that, but it would be much better if i could jmp directly like when a dll has no relocations
|
|||||||||||
|
18 Jun 2015, 15:29 |
|
|
revolution 18 Jun 2015, 15:43
If you make it a macro then it will feel just like a normal instruction:
Code: macro goto dest { push dest ret } |
|||
|
18 Jun 2015, 15:43 |
|
|
randomdude 18 Jun 2015, 15:51
LOL man
i dont care how it looks in my code, i just want to be able to use jmp <address> in a realocated dll wtihout using any dirty trick |
|||
|
18 Jun 2015, 15:51 |
|
|
randomdude 18 Jun 2015, 16:22
made this dll in c
it probably has relocation table, yet the jmp is not relocated push ebp mov ebp, esp jmp near ptr 401000h cant fasm do the same?
|
|||||||||||
|
18 Jun 2015, 16:22 |
|
|
typedef 19 Jun 2015, 13:47
randomdude wrote: sure i can use that, but it would be much better if i could jmp directly like when a dll has no relocations Just parse the PE headers man. Also look into ASLR. |
|||
|
19 Jun 2015, 13:47 |
|
|
Tomasz Grysztar 19 Jun 2015, 15:25
randomdude wrote: made this dll in c The problem here is that the x86 near jump instruction is encoded with a relative offset and not the absolute address. So when "jmp 401000h" has to be created, the encoder needs to know where this instruction is going to reside in memory in order to calculate this offset correctly. The sample DLL you provided contains this instruction encoded with the assumption that this DLL is loaded at its default image address (6FA00000h). Therefore it is not going to work correctly when it is loaded at a different address. You can verify it by first loading some other DLL at 6FA00000h address, thus forcing the hello2.dll to be loaded elsewhere - note that then the jump instruction no longer jumps to 401000h: Code: ; foo.asm format PE GUI 4.0 DLL at 6FA00000h ; hijack the base address entry DllEntryPoint include 'win32a.inc' section '.text' code readable executable proc DllEntryPoint hinstDLL,fdwReason,lpvReserved mov eax,TRUE ret endp proc foo mov eax,$ ret endp section '.edata' export data readable export 'foo.dll',\ foo,'foo' section '.reloc' fixups data readable discardable ; hello1.asm format PE GUI 4.0 at 0x00400000 as 'exe' entry start ;================================================== ; Includes ;================================================== include 'win32a.inc' ;================================================== section '.text' code readable executable ;================================================== ;0x00401000 invoke MessageBox,0,testmsg,0,MB_OK invoke ExitProcess,0 dllname db 'hello2.dll',0 proc start invoke foo ; make sure that foo.dll is loaded invoke LoadLibrary,dllname ; the jump to 401000h is not going to happen this time endp ;================================================== section '.idata' import data readable ;================================================== library advapi32,'ADVAPI32.DLL',\ comctl32,'COMCTL32.DLL',\ comdlg32,'COMDLG32.DLL',\ gdi32,'GDI32.DLL',\ kernel32,'KERNEL32.DLL',\ shell32,'SHELL32.DLL',\ user32,'USER32.DLL',\ wsock32,'WSOCK32.DLL',\ foo_dll,'FOO.DLL' include 'api\advapi32.inc' include 'api\comctl32.inc' include 'api\comdlg32.inc' include 'api\gdi32.inc' include 'api\kernel32.inc' include 'api\shell32.inc' include 'api\user32.inc' include 'api\wsock32.inc' import foo_dll,\ foo,'foo' ;================================================== section '.data' data readable writeable ;================================================== testmsg db 'test',0 ;================================================== ;section '.reloc' fixups data readable discardable ;================================================== ;if ~ $-$$ ; dd 0,8 ;end if That being said, you can easily obtain the same effect in fasm, the ORG directive is there to tell the assembler that you want to assume that your assembled code is going to be loaded at specified address. But to make sure that this is a valid assumption is then up to you: Code: org BASE + RVA $ jmp 401000h |
|||
|
19 Jun 2015, 15:25 |
|
|
revolution 20 Jun 2015, 04:12
randomdude: There is no way to do what you want with current x86 encoding and Windows DLL requirements. You will have to use at least one "dirty trick".
In another thread you appear to be focussed upon making it "fast". But I seriously doubt that this is actually a problem for you. So I would suggest just start with something simple like the goto macro above. Then if the performance is really shown to be an issue move on to something more advanced and awkward to code. |
|||
|
20 Jun 2015, 04:12 |
|
|
randomdude 20 Jun 2015, 09:49
ok guys, thanks for clearing it up
il use the auto patching my own dll jmp's like i posted in the other thread |
|||
|
20 Jun 2015, 09:49 |
|
|
l_inc 20 Jun 2015, 20:32
randomdude
Your original question is quite confusing, cause what you actually need is not to prevent, but to generate a relocation. The relocation should be of a type that does not add, but rather subtracts the base offset. The problem is that this type of relocations is not supported by PEs. In fact you could use a far jump to jump to an absolute address: Code: jmp $23:$00401005 But you should avoid it in terms of performance, cause that might be much slower, and does not provide any size advantage versa revolution's suggestion anyway. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
20 Jun 2015, 20:32 |
|
< Last Thread | Next Thread > |
Forum Rules:
|