Additional Questions (sorry, don't know where to put them) about symcc HOT 5 CLOSED

I rebuilt docker and I can compile sample.cpp fine again.

from symcc.

I think it's perfectly fine to create issues for these questions so that others can find the answers as well :)

(1) I first played with the sample.cpp that came with the docker file. I noticed the solution is only discovered if i provided an input with a string length equal to the value that is being compared (root). If i tried anything else such as echo 'a' or echo 'aaaaa' and pass it to the sample binary. the generated solution under /tmp/output does not contain 'root'. Is this the correct behaviour?

Yes, and I should document it better: SymCC never changes the length of the input (which is the same behavior as, for example, QSYM or S2E). We rely on the fuzzer to vary the input length. If you want to run only concolic execution, you can pick an input that is known to be long enough - in the case of the example program, SymCC will insert null characters in various positions and eventually produce a string of length 4 that leads to the interesting code path (see the helper script to automate the process of repeatedly running SymCC on a target, and #14 for some drawbacks of this approach).

(2) The second thing I tried is to compile the sample.cpp through sym++. I understand the libc++ stuff have to also be instrumented, and that the docker container have already setup and environment variable SYMCC_LIBCXX_PATH which points to "/libcxx_symcc_install". However, when i compiled the sample.cpp, i get the following error:

ubuntu@symcc:~$ sym++ -o sample sample.cpp
In file included from sample.cpp:1:
In file included from /libcxx_symcc_install/include/c++/v1/iostream:37:
In file included from /libcxx_symcc_install/include/c++/v1/ios:214:
/libcxx_symcc_install/include/c++/v1/iosfwd:189:14: error: use of undeclared identifier 'mbstate_t'
typedef fpos<mbstate_t> streampos;
^
[...]
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.

So this is outside the Docker container? Could you show me the SymCC-related output of env in that shell? The errors look as if you don't have an instrumented libc++, or maybe the path isn't correct. If you want to use the system's regular libc++ instead, you can export SYMCC_REGULAR_LIBCXX=1.

(3) Lastly, I tried to build a 'sample' under C with the following code:

#include <stdio.h>

int main(int argc, char *argv[]) {
//char *name = argv[1];
char name[100];
printf("What is your name?\n");
gets(name);
if (strcmp(name, "root") == 0)
printf("What is your command?\n");
else
printf("Hello %s\n", name);

return 0;
}

[...]

Any suggestion as to why this is not working?

This is because we currently don't have wrappers for the string-related functions in libc; see #23. My comment on the issue mentions three possible solutions; I agree that the first should be implemented at least for the most common functions (which should be really easy), but I haven't had the time yet. (Note that the C++ equivalent will work because the instrumented libc++ enables SymCC to see the internals of the string comparison; it is, unfortunately, much harder to get users to work with an instrumented libc...)

from symcc.

Below is the content for 'env'. This is within the docker container created from the Dockerfile

ubuntu@symcc:~$ env
AFL_CXX=clang++-10
HOSTNAME=symcc
AFL_CC=clang-10
AFL_SKIP_CPUFREQ=1
PWD=/home/ubuntu
LLVM_CONFIG=llvm-config-10
CXX=g++-10
HOME=/home/ubuntu
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:.tar=01;31:.tgz=01;31:.arc=01;31:.arj=01;31:.taz=01;31:.lha=01;31:.lz4=01;31:.lzh=01;31:.lzma=01;31:.tlz=01;31:.txz=01;31:.tzo=01;31:.t7z=01;31:.zip=01;31:.z=01;31:.dz=01;31:.gz=01;31:.lrz=01;31:.lz=01;31:.lzo=01;31:.xz=01;31:.zst=01;31:.tzst=01;31:.bz2=01;31:.bz=01;31:.tbz=01;31:.tbz2=01;31:.tz=01;31:.deb=01;31:.rpm=01;31:.jar=01;31:.war=01;31:.ear=01;31:.sar=01;31:.rar=01;31:.alz=01;31:.ace=01;31:.zoo=01;31:.cpio=01;31:.7z=01;31:.rz=01;31:.cab=01;31:.wim=01;31:.swm=01;31:.dwm=01;31:.esd=01;31:.jpg=01;35:.jpeg=01;35:.mjpg=01;35:.mjpeg=01;35:.gif=01;35:.bmp=01;35:.pbm=01;35:.pgm=01;35:.ppm=01;35:.tga=01;35:.xbm=01;35:.xpm=01;35:.tif=01;35:.tiff=01;35:.png=01;35:.svg=01;35:.svgz=01;35:.mng=01;35:.pcx=01;35:.mov=01;35:.mpg=01;35:.mpeg=01;35:.m2v=01;35:.mkv=01;35:.webm=01;35:.ogm=01;35:.mp4=01;35:.m4v=01;35:.mp4v=01;35:.vob=01;35:.qt=01;35:.nuv=01;35:.wmv=01;35:.asf=01;35:.rm=01;35:.rmvb=01;35:.flc=01;35:.avi=01;35:.fli=01;35:.flv=01;35:.gl=01;35:.dl=01;35:.xcf=01;35:.xwd=01;35:.yuv=01;35:.cgm=01;35:.emf=01;35:.ogv=01;35:.ogx=01;35:.aac=00;36:.au=00;36:.flac=00;36:.m4a=00;36:.mid=00;36:.midi=00;36:.mka=00;36:.mp3=00;36:.mpc=00;36:.ogg=00;36:.ra=00;36:.wav=00;36:.oga=00;36:.opus=00;36:.spx=00;36:*.xspf=00;36:
REAL_CXX=g++-10
SYMCC_LIBCXX_PATH=/libcxx_symcc_install
TERM=xterm
SHLVL=1
AFL_PATH=/afl
PATH=/symcc_build:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
CC=gcc-10
OLDPWD=/tmp
_=/usr/bin/env

from symcc.

So the build issues that you asked about in (2) are inside the Docker container? That's curious - I double-checked the Docker image after reading your message, and it worked fine for me. Maybe some changes in the base image that affect SymCC? 🤔 But if building inside the container doesn't work for you, does that mean you did the experiments that you mentioned in (1) outside the container? Sorry for the confusion, I think I'm missing something...

from symcc.

The first experiment was performed within docker as well. After the container was successfully built, i see a built copy of the file. I will redo the entire container later today to see I am seeing the same behaviour.

from symcc.