Comments (5)
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.
Related Issues (20)
- Failed to Compile with "-DTARGET_32BIT=ON" HOT 1
- Wrong handling of i1 in visitCastInst HOT 2
- visitSelectInst does not propagate the symbolic expression HOT 2
- Store i1 into memory HOT 2
- Change the license of the runtime to LGPL HOT 6
- Support for variadic functions HOT 1
- Failed to build the Vagrantfile
- LLVM compatibility policy HOT 6
- Can't create expressions for concrete non-undef structs HOT 2
- _sym_get_input_byte() in simple backend
- sprintf wrapper
- Crash when concrete non-undef structs contain floats
- afl-showmap generating incorrectly sized map HOT 1
- SymCC may crash if test-case handlers are instrumented
- cannot generate new testcase for a simple case
- program links to libstdc++, not instructmented libc++
- Could not compile libcxx: malloc/malloc.h not found HOT 7
- Fail to compile gpac with clang frontend error HOT 1
- Fuzzing with AFL and Symcc does not work HOT 2
- SymCC fails to compile with -DTARGET_32BIT=ON HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from symcc.