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

Codatify doesnt work if .text / .data sections are missing. #5

Closed
fuzzywalls opened this issue Nov 13, 2019 · 4 comments
Closed

Codatify doesnt work if .text / .data sections are missing. #5

fuzzywalls opened this issue Nov 13, 2019 · 4 comments
Assignees
Labels
bug Something isn't working enhancement New feature or request

Comments

@fuzzywalls
Copy link
Collaborator

ARM binaries seem to not create them. Find a different way to discover code vs data.

@fuzzywalls fuzzywalls added bug Something isn't working enhancement New feature or request labels Nov 13, 2019
@fuzzywalls fuzzywalls self-assigned this Nov 13, 2019
@astrelsky
Copy link
Contributor

There are methods to check if a memory block is executable and if a block is read/write/volatile if this helps at all.

@fuzzywalls
Copy link
Collaborator Author

That might be necessary, I'm not sure yet. Currently I'm experimenting with getFirstData, getLastData, getFirstFunction, and getLastFunction to find the necessary blocks and creating address ranges around those. Worked well for fixing up the code, but fixing up the data requires a little more processing.

@fuzzywalls
Copy link
Collaborator Author

@astrelsky The getFirstX route was a dead end because there is no guarantee the functions will be in one contiguous block. I experimented with the permission methods you mentioned in an ARM binary. Single memory blocks contained code and data which means it was marked with execute and read permissions, so not a lot to go on with that. I was able to do something similar by using a memory manager function, getExecuteSet, it returned a range of what it considered code. This still contained some data, which introduces some false positives, but it is at least working. Going to try and lower the false positive rates a little now.

@astrelsky
Copy link
Contributor

@astrelsky The getFirstX route was a dead end because there is no guarantee the functions will be in one contiguous block. I experimented with the permission methods you mentioned in an ARM binary. Single memory blocks contained code and data which means it was marked with execute and read permissions, so not a lot to go on with that. I was able to do something similar by using a memory manager function, getExecuteSet, it returned a range of what it considered code. This still contained some data, which introduces some false positives, but it is at least working. Going to try and lower the false positive rates a little now.

You could probably filter them further by checking if at least one disassembled instruction already exists in the memory block. If the block isn't writeable then it is more likely to only contain instructions. It can still potentially have data though.

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

No branches or pull requests

2 participants