ergrelet / unlicense

Dynamic unpacker and import fixer for Themida/WinLicense 2.x and 3.x.
GNU General Public License v3.0
1.06k stars 191 forks source link

Dumped PEs have ASLR enabled #87

Closed alexrp closed 1 year ago

alexrp commented 1 year ago

Executables dumped by Unlicense have ASLR enabled:

$ unlicense TERA.exe
INFO - Detected packer version: 3.x
frida-agent: Setting up OEP tracing for "TERA.exe"
frida-agent: Exception handler registered
frida-agent: TLS callback #0 detected (at 0x7ff76c695090), skipping ...
frida-agent: TLS callback #1 detected (at 0x7ff76c695490), skipping ...
frida-agent: OEP found (thread #32608): 0x7ff76c69587c
INFO - OEP reached: OEP=0x7ff76c69587c BASE=0x7ff76a7b0000 DOTNET=False
INFO - IAT found: 0x7ff76c7b9000
INFO - Resolving imports ...
INFO - Imports resolved: 768
INFO - Fixed IAT at 0x7ff76c7b9000, size=0x1980
INFO - Dumping PE with OEP=0x7ff76c69587c ...
INFO - Fixing dump ...
$ dumpbin /headers unpacked_TERA.exe
... snip ...
            8160 DLL characteristics
                   High Entropy Virtual Addresses
                   Dynamic base <---
                   NX compatible
                   Terminal Server Aware
... snip ...

This is odd, considering Unlicense does try to disable ASLR here:

https://github.com/ergrelet/unlicense/blob/217d0d66c57b5deae45f8abd05c851a0bb3b0e6e/unlicense/dump_utils.py#L106-L107

Fixing this is important for #29. If the binary has any virtualized code areas, it cannot be made runnable without either a) dealing with those the hard way, or b) disabling ASLR. (For context: A crash will usually happen when virtualized code tries to return to normal code, because the calculation of the return address is off.)

(For anyone following along at home, as a workaround, editbin /dynamicbase:no unpacked.exe will fix this.)

ergrelet commented 1 year ago

Thanks for the report! This is odd indeed, I'll investigate when I have some time 👍

ergrelet commented 1 year ago

Turns out section renaming was silently crashing the process (seems like a bug in LIEF) and PE rebuilding wasn't performed.

If you could try with the latest commit from dev and see if it behaves properly now, that'd be perfect 😊

alexrp commented 1 year ago

I'll give it another try ASAP.

Turns out section renaming was silently crashing the process (seems like a bug in LIEF) and PE rebuilding wasn't performed.

This is interesting, I hadn't noticed that. 🤔 As I mentioned in #29, I did manage to make the resulting executable runnable regardless, though with quite a bit of manual PE surgery. So just out of curiosity, what specifically is the PE rebuilding supposed to achieve here?

ergrelet commented 1 year ago

Alright 👍 Yes I just read your write-ups, thanks for that! As for the current "rebuilding" process, it doesn't do much right now, just some superficial fix-ups. But the idea was to improve this rebuilding in the future to deal with #29 for more and more executables.

alexrp commented 1 year ago

Just tried with the dev branch and ASLR is off as it should be, so closing this.