Hello, I have been looking for a way to get the concrete stack addresses of values. I have tried many methods and I could not find one that would consistently give a stack address which corresponds to the concrete stack address of the same buffer on the stack... Part of the problem seems to be with the large stack size that is normally allocated by tritonDSE which is far larger than what the concrete stack size of the same program would be, even setting the start and end addresses of the stack does not seem to correctly fix this issue as can be seen by uncommenting the start and end stack values in the attached example. Is there a good fix for this? Does triton not track an accurate representation of the stack or is there some technique that could be leveraged in triton/tritonDSE to get an accurate stack representation?
tritondse_concrete_stackaddr_problem.py
test.c
The compiled test executable was compiled for i386 with no protections and ASLR is disabled on the system used for testing. When running the executable we always take care of stripping the environment variables with "env -i"
Hello, I have been looking for a way to get the concrete stack addresses of values. I have tried many methods and I could not find one that would consistently give a stack address which corresponds to the concrete stack address of the same buffer on the stack... Part of the problem seems to be with the large stack size that is normally allocated by tritonDSE which is far larger than what the concrete stack size of the same program would be, even setting the start and end addresses of the stack does not seem to correctly fix this issue as can be seen by uncommenting the start and end stack values in the attached example. Is there a good fix for this? Does triton not track an accurate representation of the stack or is there some technique that could be leveraged in triton/tritonDSE to get an accurate stack representation?
tritondse_concrete_stackaddr_problem.py
test.c
The compiled test executable was compiled for i386 with no protections and ASLR is disabled on the system used for testing. When running the executable we always take care of stripping the environment variables with "env -i"