symbolic execution seems to go off track
See original GitHub issueI have been working with rex and discovered a binary that rex doesn’t successfully recognize the rip overwrite of a classic stack overflow. However, it also appears that angr doesn’t successfully symbolically execute this binary, so that’s probably the bigger problem and could be the reason why rex isn’t working. Here’s the code:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
char buf[64];
void blerg() {
char buf[8];
read(0,buf,12);
}
int main() {
char buf2[8];
gets(buf2);
}
The make line is: gcc -z execstack -fno-stack-protector -Wall -o stack_overflow stack_overflow.c
The compiled binary I’m working with can be found here: http://pastebin.com/raw/HEysndYm
I’m following basic symbolic execution steps (import -> create state -> create path group -> explore) and it seems to go off track. Here’s an example of the output trace:
In [7]: pg
Out[7]: <PathGroup with 7 active>
In [8]: pg.active[5]
Out[8]: <Path with 433 runs (at 0x106d1a3)>
In [9]: list(pg.active[5].trace)
Out[9]:
['<SimIRSB 0x400470>',
'<SimIRSB 0x400440>',
'<SimProcedure __libc_start_main>',
'<SimIRSB 0x4005b0>',
'<SimIRSB 0x400400>',
'<SimIRSB 0x400415>',
'<SimIRSB 0x4005e1>',
'<SimIRSB 0x4005e6>',
'<SimIRSB 0x400540>',
'<SimIRSB 0x40054b>',
'<SimIRSB 0x4004e0>',
'<SimIRSB 0x400518>',
'<SimIRSB 0x4005fd>',
'<SimIRSB 0x400606>',
'<SimProcedure __libc_start_main>',
'<SimIRSB 0x400587>',
'<SimIRSB 0x400450>',
'<SimIRSB 0x106ecc0>',
'<SimIRSB 0x106ecda>',
'<SimIRSB 0x106ecf4>',
'<SimIRSB 0x106ed0a>',
'<SimIRSB 0x106ed25>',
'<SimIRSB 0x106ee20>',
'<SimIRSB 0x107b2d0>',
'<SimIRSB 0x107b2db>',
'<SimIRSB 0x107b2ef>',
'<SimIRSB 0x107b2fc>',
'<SimIRSB 0x107b301>',
'<SimIRSB 0x107b3e0>',
'<SimIRSB 0x107b318>',
'<SimIRSB 0x107b530>',
'<SimIRSB 0x107a3d0>',
'<SimIRSB 0x107a3da>',
'<SimIRSB 0x107a3e8>',
'<SimIRSB 0x107a5b0>',
'<SimIRSB 0x107a5c4>',
'<SimIRSB 0x107b490>',
'<SimIRSB 0x107b4a0>',
'<SimIRSB 0x107b4b7>',
'<SimIRSB 0x106d130>',
'<SimIRSB 0x106d145>',
....
It continues on like that. It appears to have jumped to a non-function part of the binary and is basically treating it as code, thus causing it to never finish and do strange things.
Issue Analytics
- State:
- Created 7 years ago
- Comments:13 (11 by maintainers)
Top GitHub Comments
Does it cause your testcase from the first post to terminate? You should also turn off LAZY_SOLVES for this
Ok, then this is technically a bug in rex, which should initialize its path group with
pg = proj.factory.path_group(proj.factory.full_init_state(...))
. This never really mattered for CGC since the full init state is the same as the entry state!