Closed alexrp closed 1 year ago
Thanks for the report! This is odd indeed, I'll investigate when I have some time 👍
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 😊
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?
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.
Just tried with the dev
branch and ASLR is off as it should be, so closing this.
Executables dumped by Unlicense have ASLR enabled:
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.)