Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strip second executable section #16

Open
4l3x777 opened this issue Mar 21, 2024 · 3 comments
Open

Strip second executable section #16

4l3x777 opened this issue Mar 21, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@4l3x777
Copy link

4l3x777 commented Mar 21, 2024

Good job, mate!
Do you have any idea to rebuild executable without adding second executeble section?
I think it have to look like as https://github.com/jnastarot/furikuri project

@4l3x777 4l3x777 changed the title Strip second executeble section Strip second executable section Mar 21, 2024
@es3n1n
Copy link
Owner

es3n1n commented Mar 21, 2024

Hello,
Implementing such a feature requires a little bit more time than I have these days. And while theoretically implementing this is possible and at first glance doesn't require a lot of work, I am not sure if I would get to it anytime soon.
PR welcome though.

@es3n1n es3n1n added the enhancement New feature or request label Mar 21, 2024
@ZehMatt
Copy link

ZehMatt commented Mar 21, 2024

Is there even a reliable way to extend the existing .x section without having to fix RVA's for x64 builds? This will likely shift the address of sections that follow invalidating all RVA's. With relocation items its probably possible but there is still a chance that some code uses imagebase relative addressing.

@es3n1n
Copy link
Owner

es3n1n commented Mar 21, 2024

Is there even a reliable way to extend the existing .x section without having to fix RVA's for x64 builds? This will likely shift the address of sections that follow invalidating all RVA's. With relocation items its probably possible but there is still a chance that some code uses imagebase relative addressing.

Ah yes, I completely forgot about x64 rva addressing, if we want to process those as well, we would need to analyze all of the functions within the binary and recompile every single one of them. This indeed requires a lot of work and at the current state I'm not 100% sure in reliableness of my code analysis thingy 😄, however, I fixed some bugs in the dev branch, but there are still a lot more.

However, there is another (a bit more dirty, but still) approach for this, with the custom SDK we can allocate a bunch of memory in the .text section and overwrite it with our stubs. But yeah, I'm not really a fan of such implementation 🤷‍♂️ .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants