Angr can't find path to address unless extra constraints are added to the initial state

When running the following script on the unbreakable challenge from GoogleCTF 2016, no path to the specified address is found, even though one definitely exists. Angr does not say anything about unconstrained paths, so I don’t know any reason why no path would be found.

#!/usr/bin/env python2

from angr import *

input_size = 0x43
flag = claripy.BVS('flag', 8 * input_size)

p = Project('./unbreakable-enterprise-product-activation', load_options={'auto_load_libs': False})
state = p.factory.entry_state(args=[p.filename, flag])
pg = p.factory.path_group(state, veritesting=True)

state.libc.buf_symbolic_bytes = input_size + 1

for a, b in zip('CTF{', flag.chop(8)):
    state.se.add(ord(a) == b)

state.se.simplify()
logging.getLogger('angr.path_group').setLevel(logging.DEBUG)

pg.explore(find=(0x400830,), avoid=(0x400850,))
f = pg.found[0]

print f.state.se.any_str(flag)

If I add in some more constraints on the input buffer, then a path is found to that address:

#!/usr/bin/env python2

from angr import *

input_size = 0x43
flag = claripy.BVS('flag', 8 * input_size)

p = Project('./unbreakable-enterprise-product-activation', load_options={'auto_load_libs': False})
state = p.factory.entry_state(args=[p.filename, flag])
pg = p.factory.path_group(state, veritesting=True)

state.libc.buf_symbolic_bytes = input_size + 1

for a, b in zip('CTF{', flag.chop(8)):
    state.se.add(ord(a) == b)

# This for loop was added
for c in flag.chop(8):
    state.se.add(c > ord(' '))
    state.se.add(c < ord('~'))

state.se.simplify()
logging.getLogger('angr.path_group').setLevel(logging.DEBUG)

pg.explore(find=(0x400830,), avoid=(0x400850,))
f = pg.found[0]

print f.state.se.any_str(flag)

[salls]

It seems to be an issue with our memcpy simprocedure which is used internally by strncpy. When the length is symbolic it will try to take the libc.maximum_buffer_size, if you set that value higher it works. I’m adding a warning and updating the memcpy simprocedure

[salls]

memcpy was easy to add a warning to. For strcpy we’d need to look at strlen. But in strlen it isn’t as easy. I’m not sure what a good condition would be for warning users. We could warn every time strlen is called on symbolic data, but maybe that’s too annoying