Duplicate relocations in DLL
Hi everyone, Packaged with a game, I found a peculiar DLL which has duplicate blocks in the relocation table. I mean that the same pages are relocated twice and this of course breaks the DLL. I'm not sure about what could be a right way to support such (broken) DLLs. A possibility would be to keep track of already relocated pages and skip them if needed. Suggestions are welcome. Regards, Alessandro Pignotti
On 15 May 2013, at 16:31, Alessandro Pignotti wrote:
Packaged with a game, I found a peculiar DLL which has duplicate blocks in the relocation table. I mean that the same pages are relocated twice and this of course breaks the DLL. I'm not sure about what could be a right way to support such (broken) DLLs. A possibility would be to keep track of already relocated pages and skip them if needed. Suggestions are welcome.
I've just asked a colleague of mine about this and according to him it's perfectly legal in Windows to have multiple relocation blocks for the same section, in which case Windows will also fixup everything twice. So simply ignoring such relocations is normally wrong. Which dll from which game is this? Jonas
On 16 May 2013, at 16:34, Jonas Maebe wrote:
On 15 May 2013, at 16:31, Alessandro Pignotti wrote:
Packaged with a game, I found a peculiar DLL which has duplicate blocks in the relocation table. I mean that the same pages are relocated twice and this of course breaks the DLL. I'm not sure about what could be a right way to support such (broken) DLLs. A possibility would be to keep track of already relocated pages and skip them if needed. Suggestions are welcome.
I've just asked a colleague of mine about this and according to him it's perfectly legal in Windows to have multiple relocation blocks for the same section, in which case Windows will also fixup everything twice. So simply ignoring such relocations is normally wrong. Which dll from which game is this?
Addendum: he just realised that you may be talking about multiple base relocation arrays for a single page (arrays that contain the offsets of the instructions that need fixing up), which would indeed be strange. Still, it would be interesting to know which dll it is. Thanks, Jonas
I think it's actually the second case you mentioned. I'm pasting an excerpt from 'objdump -x' of the dll. The issue happens with bgm.dll from the game "Hotline Miami". Regards and sorry for the long paste below, Alessandro Pignotti ----------------------------------------------- bgm.dll: formato del file pei-i386 bgm.dll architettura: i386, flag 0x00000103: HAS_RELOC, EXEC_P, D_PAGED indirizzo di partenza 0x6d741000 Characteristics 0x230e executable line numbers stripped symbols stripped 32 bit words debugging information removed DLL PE File Base Relocations (interpreted .reloc section contents) Virtual Address: 00001000 Chunk size 268 (0x10c) Number of fixups 130 ... Virtual Address: 00002000 Chunk size 296 (0x128) Number of fixups 144 ... Virtual Address: 00003000 Chunk size 336 (0x150) Number of fixups 164 ... Virtual Address: 00004000 Chunk size 296 (0x128) Number of fixups 144 ... Virtual Address: 00005000 Chunk size 112 (0x70) Number of fixups 52 ... Virtual Address: 00006000 Chunk size 12 (0xc) Number of fixups 2 ... Virtual Address: 00007000 Chunk size 228 (0xe4) Number of fixups 110 ... Virtual Address: 00008000 Chunk size 356 (0x164) Number of fixups 174 ... Virtual Address: 00001000 Chunk size 268 (0x10c) Number of fixups 130 ... Virtual Address: 00002000 Chunk size 296 (0x128) Number of fixups 144 ... Virtual Address: 00003000 Chunk size 336 (0x150) Number of fixups 164 ... Virtual Address: 00004000 Chunk size 296 (0x128) Number of fixups 144 ... Virtual Address: 00005000 Chunk size 112 (0x70) Number of fixups 52 ... Virtual Address: 00006000 Chunk size 12 (0xc) Number of fixups 2 ... Virtual Address: 00007000 Chunk size 228 (0xe4) Number of fixups 110 ... Virtual Address: 00008000 Chunk size 356 (0x164) Number of fixups 174 ...
On 16 May 2013, at 16:34, Jonas Maebe wrote:
On 15 May 2013, at 16:31, Alessandro Pignotti wrote:
Packaged with a game, I found a peculiar DLL which has duplicate blocks in the relocation table. I mean that the same pages are relocated twice and this of course breaks the DLL. I'm not sure about what could be a right way to support such (broken) DLLs. A possibility would be to keep track of already relocated pages and skip them if needed. Suggestions are welcome.
I've just asked a colleague of mine about this and according to him it's perfectly legal in Windows to have multiple relocation blocks for the same section, in which case Windows will also fixup everything twice. So simply ignoring such relocations is normally wrong. Which dll from which game is this?
Addendum: he just realised that you may be talking about multiple base relocation arrays for a single page (arrays that contain the offsets of the instructions that need fixing up), which would indeed be strange. Still, it would be interesting to know which dll it is.
Thanks,
Jonas
On 16 May 2013, at 19:03, Alessandro Pignotti wrote:
On 16 May 2013, at 16:47, Jonas Maebe wrote:
Addendum: he just realised that you may be talking about multiple base relocation arrays for a single page (arrays that contain the offsets of the instructions that need fixing up), which would indeed be strange. Still, it would be interesting to know which dll it is.
I think it's actually the second case you mentioned. I'm pasting an excerpt from 'objdump -x' of the dll. The issue happens with bgm.dll from the game "Hotline Miami".
I've found a copy of the dll and gave it to my colleague. His analysis is that the preferred load address (0x6D740000) does not overlap with any Windows system dll, and most likely never will because the range it's in is reserved for very small dll's and they have lots of room left before they will reach that address. As a result, this dll never gets relocated under Windows. He constructed a Windows test that forced it to load the dll at a different address anyway, and then it also crashes under Windows. He believes that this was done on purpose to break Wine and other non- Windows environments. It's an interface to BASS/fmod, and these libraries supposedly have very strict licensing requirements that require you to pay per platform you want to support. By constructing the dll this way it will always (with the caveat mentioned above) run on Windows, but not under Wine (unless the preferred load address is available and Wine loads it there, but there are no guarantees for that; I don't even know whether Wine tries to do this). As to the best solution: not sure. Current Wine behaviour matches that of Windows, it's the unavailable preferred load address that triggers the "problem". Jonas
Wine does not seem to even try to load DLLs at their preferred address. Still, I'm not sure this is actually bad and I think Win8 forces randomization of the layout anyway, Alessandro
He believes that this was done on purpose to break Wine and other non- Windows environments. It's an interface to BASS/fmod, and these libraries supposedly have very strict licensing requirements that require you to pay per platform you want to support. By constructing the dll this way it will always (with the caveat mentioned above) run on Windows, but not under Wine (unless the preferred load address is available and Wine loads it there, but there are no guarantees for that; I don't even know whether Wine tries to do this). As to the best solution: not sure. Current Wine behaviour matches that of Windows, it's the unavailable preferred load address that triggers the "problem".
Jonas
Alessandro Pignotti <alexpigna.dev(a)gmail.com> writes:
Wine does not seem to even try to load DLLs at their preferred address. Still, I'm not sure this is actually bad and I think Win8 forces randomization of the layout anyway,
We definitely try, but for high addresses there's a chance that some Linux library was already loaded there. -- Alexandre Julliard julliard(a)winehq.org
On 17 May 2013, at 13:40, Alessandro Pignotti wrote:
Wine does not seem to even try to load DLLs at their preferred address. Still, I'm not sure this is actually bad and I think Win8 forces randomization of the layout anyway,
Afaik an application can tell the OS that it should not apply ASLR to certain DLLs. My colleague also looked further into it and didn't find any trace of a post-processing tool. However, the dll was compiled with one of the first mingw releases (gcc 2.8 or 2.95), and the problem may simply have been caused by a buggy linker. Jonas
participants (3)
-
Alessandro Pignotti -
Alexandre Julliard -
Jonas Maebe