Concretize address in initLeaAst #962
Conversation
|
Can you explain in what scenarios |
|
AST evaluation may be wrong due to undertaint or missing instructions translations. We are getting real life examples for that. Computing memory address from concrete state allows us to avoid such errors. For instance: If ebx contains invalid AST, wrong memory will be dereferenced. While if we concretize ebx from concrete state, we dereference correct memory. |
Using a DBI or in pure emulation with Triton? (In pure emulation, concrete state is updated from AST evaluation).
This is true only if you use a DBI to keep synch between the Triton state and the DBI state right? Do you see any case where your patch must not be used as default behavior? |
| triton::uint64 concreteAddress = baseValue + indexValue * scaleValue + dispValue; | ||
|
|
||
| auto regSize = this->architecture->gprBitSize(); | ||
| if (regSize != 64) { |
There was a problem hiding this comment.
I think you can remove the if and directly perform the &= whatever the regSize is equal to 64 or not.
There was a problem hiding this comment.
This is -Wshift-count-overflow and breaks my tests, because of O3 optimizations.
|
Yeah, we use DBI, and this feature should be default. I updated the pull request. |
SweetVishnya
force-pushed
the
concretize_address
branch
from
8bf7424
to
f1646c2
Compare
|
We solved this issue by synchronization of concrete and symbolic memory states. We compare concrete values received from DBI with Triton ASTs evaluation. If values are different, we concretize the corresponding register or memory. This also helps us to kill some symbolic registers after syscalls. So, now all memory accesses are correctly computed and there are no symbolic branches with wrong taken direction. @JonathanSalwan, you can close this PR and a corresponding issue #956. |
Closes #956