19 ms·

But what happened with the app your friend was trying to run?? Were you able to patch it and make it work? (and if "yes", how?)

jchw 5y ago
Ahh, sorry I never completed the story. The program was simply fixed. I believe the way they wound up fixing it was simply static linking libpng and zlib. I found another workaround too, which was a very obscure linker flag, but I can’t recall what it was as it has been a few months now. If you run into this problem with a random binary and can’t get it fixed properly, you can use Microsoft’s REBASE.EXE or EDITBIN.EXE to rebase the preferred base address to be within the range of a RIP relative CALL. If you are savvy with PE, writing such a tool by hand is very straightforward; you need to write a PE parser that can map virtual addresses, relocate as if you are a real PE loader, update the preferred base address, and write back to disk. The only case where something like this won’t work is when the executable has some kind of on-disk CRC checking, or something along those lines. (So probably, VMProtect and Themida encumbered binaries can’t be modified this way. But that’s OK, as most tools of this sort only works with Microsoft’s toolchain, which does not have pseudo-relocs.)
- marklar423 5y ago
  Out of curiosity, if the tool was compiled for MinGW doesn't that mean it would run natively on Linux? Why was your friend trying to run the MinGW version?
  - jchw 5y ago
    MinGW does allow you to write Windows-specific code. The code in question could be ported, and in fact I think it might be now, but it still puzzled us why it didn’t work on Wine. I only wanted to help on this particular avenue for the sake of making Wine better. I had figured that it was most likely an issue with Wine that could be rectified. Unfortunately, emulating Windows ASLR behavior in userspace accurately may prove to be fairly difficult, so it’s probably not worth it :) I’m not convinced pseudo relocs actually work reliably on Windows in this way, although I could be wrong.

jchw 5y ago

Ahh, sorry I never completed the story. The program was simply fixed. I believe the way they wound up fixing it was simply static linking libpng and zlib. I found another workaround too, which was a very obscure linker flag, but I can’t recall what it was as it has been a few months now. If you run into this problem with a random binary and can’t get it fixed properly, you can use Microsoft’s REBASE.EXE or EDITBIN.EXE to rebase the preferred base address to be within the range of a RIP relative CALL. If you are savvy with PE, writing such a tool by hand is very straightforward; you need to write a PE parser that can map virtual addresses, relocate as if you are a real PE loader, update the preferred base address, and write back to disk. The only case where something like this won’t work is when the executable has some kind of on-disk CRC checking, or something along those lines. (So probably, VMProtect and Themida encumbered binaries can’t be modified this way. But that’s OK, as most tools of this sort only works with Microsoft’s toolchain, which does not have pseudo-relocs.)

marklar423 5y ago
Out of curiosity, if the tool was compiled for MinGW doesn't that mean it would run natively on Linux? Why was your friend trying to run the MinGW version?
- jchw 5y ago
  MinGW does allow you to write Windows-specific code. The code in question could be ported, and in fact I think it might be now, but it still puzzled us why it didn’t work on Wine. I only wanted to help on this particular avenue for the sake of making Wine better. I had figured that it was most likely an issue with Wine that could be rectified. Unfortunately, emulating Windows ASLR behavior in userspace accurately may prove to be fairly difficult, so it’s probably not worth it :) I’m not convinced pseudo relocs actually work reliably on Windows in this way, although I could be wrong.