make chains with retn 0x10 portable #108
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bug: chains including x86_64
retn 0x10
instructions not terminated in a recoverable position.We used this python script against the
angrop_retn_test
binary:This is the resulting chain1:
Note how the value immediately following the syscall is still
p64(0x0)
.It looks like the
next_pc
is not populated until concretized and until another gadget is appended to the end of the chain.It was our understanding that chains should always end in a state where the next value on the stack should be PC. This was throwing off some of our calculations, so we made this branch.
Since you already wrote some impressive logic to overwrite a
next_pc
value when chains are added together, we thought we would take advantage of this. We decided to add a simple rop.shift(arch.bytes) chain (which should be as simple as a singleret
gadget) to the chain currently trying to be concretized, and then concretize the conglomerate chain instead.This is chain1 after our modifications: