trailofbits / cb-multios Goto Github PK

Unfortunately, DARPA switched to compiled C programs for their proof of vulnerabilities for the "CFE" (the second year of the competition). All the valid test cases/polls and first year proof of vulnerabilities are in XML.

We need to rectify this difference and I'm not sure the best approach.

Seeing this on many challenges when trying to compile on Arch.

[363/10141] Linking CXX executable challenges/CML/CML_patched
FAILED: challenges/CML/CML_patched 
: && /usr/bin/clang++  -m32 -z execstack -z norelro   -rdynamic challenges/CML/CMakeFiles/CML_patched.dir/lib/calloc.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/ctype.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/cxa.cc.o challenges/CML/CMakeFiles/CML_patched.dir/lib/exit.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/fflush.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/fopen.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/fread.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/free.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/fwrite.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/fxlat.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/malloc.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/malloc_common.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/memchr.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/memcmp.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/memcpy.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/memmove.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/memset.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/printf.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/realloc.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/stdio.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/strcasecmp.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/strcasestr.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/strchr.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/strcmp.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/strcpy.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/strdup.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/strlen.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/strncasecmp.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/strncpy.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/strndup.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/strsep.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/strstr.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/strtol.c.o challenges/CML/CMakeFiles/CML_patched.dir/lib/strtoul.c.o challenges/CML/CMakeFiles/CML_patched.dir/src/attribute.cc.o challenges/CML/CMakeFiles/CML_patched.dir/src/cmlnode.cc.o challenges/CML/CMakeFiles/CML_patched.dir/src/interface.cc.o challenges/CML/CMakeFiles/CML_patched.dir/src/node.cc.o challenges/CML/CMakeFiles/CML_patched.dir/src/parser.cc.o challenges/CML/CMakeFiles/CML_patched.dir/src/query.cc.o challenges/CML/CMakeFiles/CML_patched.dir/src/service.cc.o challenges/CML/CMakeFiles/CML_patched.dir/src/string.cc.o challenges/CML/CMakeFiles/CML_patched.dir/src/stringmanager.cc.o challenges/CML/CMakeFiles/CML_patched.dir/src/textnode.cc.o -o challenges/CML/CML_patched  -Wl,-rpath,/home/rayce/builds/cb-multios/build/include:/home/rayce/builds/cb-multios/build/include/tiny-AES128-C  include/libcgc.so  include/tiny-AES128-C/libtiny-AES128-C.so && :
/usr/bin/ld: challenges/CML/CMakeFiles/CML_patched.dir/lib/free.c.o:/home/rayce/builds/cb-multios/build/../challenges/CML/lib/cgc_malloc_private.h:91: multiple definition of `g_heap'; challenges/CML/CMakeFiles/CML_patched.dir/lib/calloc.c.o:/home/rayce/builds/cb-multios/build/../challenges/CML/lib/cgc_malloc_private.h:91: first defined here
/usr/bin/ld: challenges/CML/CMakeFiles/CML_patched.dir/lib/malloc.c.o:/home/rayce/builds/cb-multios/build/../challenges/CML/lib/cgc_malloc_private.h:91: multiple definition of `g_heap'; challenges/CML/CMakeFiles/CML_patched.dir/lib/calloc.c.o:/home/rayce/builds/cb-multios/build/../challenges/CML/lib/cgc_malloc_private.h:91: first defined here
/usr/bin/ld: challenges/CML/CMakeFiles/CML_patched.dir/lib/malloc_common.c.o:/home/rayce/builds/cb-multios/build/../challenges/CML/lib/cgc_malloc_private.h:91: multiple definition of `g_heap'; challenges/CML/CMakeFiles/CML_patched.dir/lib/calloc.c.o:/home/rayce/builds/cb-multios/build/../challenges/CML/lib/cgc_malloc_private.h:91: first defined here
/usr/bin/ld: challenges/CML/CMakeFiles/CML_patched.dir/lib/realloc.c.o:/home/rayce/builds/cb-multios/build/../challenges/CML/lib/cgc_malloc_private.h:91: multiple definition of `g_heap'; challenges/CML/CMakeFiles/CML_patched.dir/lib/calloc.c.o:/home/rayce/builds/cb-multios/build/../challenges/CML/lib/cgc_malloc_private.h:91: first defined here
clang-11: error: linker command failed with exit code 1 (use -v to see invocation)
[368/10141] Building C object challenges/CGC_Hangman_Game/CMakeFiles/CGC_Hangman_Game_patched.dir/src/words.c.o
ninja: build stopped: subcommand failed.

Newer challenges use libpov for testing vulnerabilities, right now only POV xmls are supported

I am trying to generate polls for all the programs but I have encounter OSError for some challenges which prevent generating polls and some other errors. How can I fix these problems to generate polls?
These are some examples of many programs has same errors.

Hey, I don't know what is the best place to ask this so hopefully I can get some feedback here. I wanted to pick out some CGC binaries from your corpus that are ideally plug and play with AFL. By plug and play I mean they should terminate upon processing a input instead of implementing an event loop and take in as argument a single input.

I've gone through some of them but the ones that I have analyzed are either too complex to setup with AFL or require modifications to the source code to break the event loop eg. lazy calc. I know I can do the source code modifications to such to make them AFL-friendly but I was wondering if there were any that can be plugged into AFL without any modifications.

It would be great if you could configure the build to not build everything. For my purposes I don't need the pollers or the POV's and those take a long time to build.

Hi,
I was trying to build the all challenge binaries in Ubuntu-18.04 for and it is not the first time. I made cmake clean to build again every time by typing "cmake --build . --target clean" but with building all programs with code coverage flags as you can see in the attachement "buildco.sh" it works one time building all of the challenge binaries however next building stopped on "target Carbonate_pov_1" the I left it and wait about 12hrs when I came back I found it the same as it stopped at " Carbonate_pov_1" then I stop it by ctrl+C then clean agian and build it with buildco.sh and the errors showed up as same as on the screenshot.

I am trying to test all the challenge binaries and get the code coverage for them. Also, I am continuing to test all the challenges more times for different purposes how can solve the problem if I face it next times or can you fix the problem?

Thank you

buildco.txt

Hi I have this error while trying to rub build.sh on linux. How can fix it?

Creating Makefiles
Creating build directory
CMake Error at cmake/32.cmake:20 (add_compile_definitions):
Unknown CMake command "add_compile_definitions".
Call Stack (most recent call first):
/usr/share/cmake-3.10/Modules/CMakeDetermineSystem.cmake:91 (include)
CMakeLists.txt:4 (project)

CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
-- Configuring incomplete, errors occurred!

In here: https://github.com/trailofbits/cb-multios/tree/master/challenges/String_Storage_and_Retrieval, the folder CROMU_00038 is inside for no apparent reason. I check it out and CROMU_00038 and CROMU_00024 (challenge on the link) and both say "String Storage and Retrieval"

100+ challenge binaries are a lot. We should make a minimized set of challenge binaries that we believe represent good variety.

Not certain how we'd determine this set though...

DARPA renamed all the CBs based on their creator names and an index. The creators originally named them with more descriptive names (e.g. https://github.com/trailofbits/cb-multios/blob/master/original-challenges/KPRCA_00033/README.md is "Loud Square Instant Messaging Protocol (LSIMP)" and https://github.com/trailofbits/cb-multios/blob/master/original-challenges/CROMU_00012/README.md is "TIACA")

The DARPA names provide little value outside of the competition and are a bit of a barrier to adoption.

DARPA made up a lot of terms that are a barrier to adoption for the wider community. We need to strip this.

Hi all. I am new to learn CGC programs and I hope this is the right place to ask a question. Please forgive me if the question is not suitable enough to ask.

Normally, we can use tester.py or cb-test.py with a binary of POV to validate the vulnerabilities inside the CGC program. My question is that is it possible to trigger the vulnerabilities using a single input? Like, for example

$./Palindrome "some string input"
// crash

$./Palindrome_patched "some string input"
// not crash

Can I do the above thing correctly? Or are there any solutions to implement this?

Thanks for your help and any suggestions are welcome!

Hello.

In the WhackJack challenge, in the service.c file we can see it is declared a
playerInfoType players[MAX_PLAYERS] but this vector (and consequently the player_name attribute of each player) is not initialized.

The cgc_show_players function in player.c assumes it is. When a user inputs 4 in the main menu to ask for the statistics, some of the players may be printed because the first byte of their player_name string is not '\0'. This behavior is not predicted by the POLL state machine.

This leads to a POL failure in my system. The fix is easy:
playerInfoType players[MAX_PLAYERS] = {0}; and I think it won't affect the intended vulnerabilities.

I didn't make a pull request because I don't know if assuming that the memory is always initialized to zero is an assumption here and maybe I'll have this same problem in other challenges too... Please let me know if that's the case.

Hi,

I just find these great work and it is very helpful. I have built these CGC binaries based on your approach. When I start to test these binaries, I found there were no poller. So I wonder how do you guys generate the pollers. I know there is generate-poller script in your repository. I can also use the script to generate poller for each binary. But I want to keep the same poller with your testing poller. Since I want to compare my testing results with your published results. Thanks.

Hi All, When we test PoV for each CGC binary, should it pass or fail? Based on your result, PoV will pass for each CGC binary. What is the PoV testing? Thanks.

Right now the CI only performs the default build, which is dynamically linked. We should add a LINK=STATIC setting to the matrix to test static builds as well.

I have tried to add -fno-stack-protector to /cb-multios/CMakeLists.txt: +56

In addition, I also checked /cb-multios/build/challenges/Accel/CMakeFiles/Accel.dir/flags.make,
Ｃ_FLAGS = -fno-builtin -w -g -m32 -fno-stack-protector -O0 -std=gnu99

But stack canary is still not closed

Some switch-case instructions in DARPA challenges are compiled into efficient jump tables. That has an unfortunate downside of complicating symbolic execution since jump tables are basically indirect jumps on symbolic variables (and it's hard to know all possible jumps).

Building CFG's with tools like BAP when that kind of primitives are in the binary also fails sometimes.
Consider maybe adding the flag -fno-jump-tables to GCC which disables jump tables on switches.

While using the challenges as part of NIST's SATE 6 tool evaluation, Frama-C identified some issues in a few challenges, mostly related to undefined behaviors (e.g. shift of negative values, read of uninitialized variables), but also a few typos, which do not correspond to the intended bugs in the challenges, indicating they seem to be accidental.

I compiled a partial report of the issues and reported them to NIST, which suggested to report them upstream.

Would you be interested in patches for them? If there is interest, I can submit pull requests to each item separately, so you can decide whether to take it into consideration. For instance, some programmers don't care about signed overflows, so you may decide not to merge those.

For reasons we can't understand, PyYAML fails to install properly on Travis-CI Linux builds. It works on Ubuntu installs locally. But if you're trying to install PyYAML with pip on Travis-CI, python can't find the import and the build fails.

We tried a few different strategies: setting virtualenv to look for system packages and installing them with apt, pip with and without sudo, using env python -m pip. Nothing works as far as we can tell. OS X builds fine with a simple sudo pip install pyyaml so we're not sure what the problem is.

Starting program: /home/fhr/CLionProjects/cb-multios/build64-gcc/challenges/Azurad/Azurad 

Program received signal SIGSEGV, Segmentation fault.
small_alloc_run (heap=<optimized out>) at /home/fhr/CLionProjects/cb-multios/challenges/Azurad/lib/malloc_common.c:224
224         hdr->hdr.prev_size = 0;

Hi,
In 64bit-mode, a lot of programs will crash with the segment fault at the start of the running. It's nearly all about cgc_memory function.
How to solve this problem?
My env:
OS: Ubuntu 20.04LTS
compiler : clang-7/ clang-10 / gcc-7 / gcc-9

[100%] Built target Casino_Games_pov_3
clang: error: unable to execute command: Killed
clang: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
Target: i386-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg:

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/pov-f62828.c
clang: note: diagnostic msg: /tmp/pov-f62828.sh
clang: note: diagnostic msg:

challenges/Carbonate/CMakeFiles/Carbonate_pov_1.dir/build.make:62: recipe for target 'challenges/Carbonate/CMakeFiles/Carbonate_pov_1.dir/pov_1/pov.c.o' failed
make[2]: *** [challenges/Carbonate/CMakeFiles/Carbonate_pov_1.dir/pov_1/pov.c.o] Error 254
CMakeFiles/Makefile2:516: recipe for target 'challenges/Carbonate/CMakeFiles/Carbonate_pov_1.dir/all' failed

First-timer here. Ubuntu 16.04. Installing just clang-3.8 doesn't set up a symlink for clang, which build.sh expects.

There appear to be two canonical ways to solve this: using update-alternatives and installing the clang package.

I first solved my problem in two ways: by adding

set(CMAKE_C_COMPILER "/usr/bin/clang-3.8")
set(CMAKE_CXX_COMPILER "/usr/bin/clang-3.8")
set(CMAKE_ASM_COMPILER "/usr/bin/clang-3.8")

to the top of CMakeLists.txt (doesn't seem very portable since it's a specific clang version) and by symlinking /usr/bin/clang-3.8 to /usr/bin/clang (plus same for clang++).

Submitting a PR now to add clang to the dependency list in the README.

Here's the error message when running ./build.sh:

root@667b3968f7af:/cb-multios# ./build.sh
Creating build directory
Creating Makefiles
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:4 (project):
  The CMAKE_C_COMPILER:

    clang

  is not a full path and was not found in the PATH.

  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
  the compiler, or to the compiler name if it is in the PATH.


CMake Error at CMakeLists.txt:4 (project):
  The CMAKE_CXX_COMPILER:

    clang++

  is not a full path and was not found in the PATH.

  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.


-- Configuring incomplete, errors occurred!
See also "/cb-multios/build/CMakeFiles/CMakeOutput.log".
See also "/cb-multios/build/CMakeFiles/CMakeError.log".
root@667b3968f7af:/cb-multios#

Port everything to Windows

• Create a Windows shim layer between the DECREE API and Win32
• Port service-launcher to Windows
• Port cb-test and cb-replay to Windows and verify all the polls pass
• Add Windows/Visual Studio support to the CMake Build system

I enjoy this awesome project. But I found two errors when I run ./genpools.sh to generate polls.

The first is 'No module named support' in 'machine.py'.

I found some 'machine.py' import 'support' via

sys.path.append(join(dirname(dirname(dirname(abspath(__file__)))), "support"))
import support as sp

However, the dictionary is deleted.

The second is "'module' object has no attribute 'cgc_sin'".

The 'machine.py' uses math.cgc_sin but there is no 'cgc_sin' in 'math'. I check the original cgc repository. The code was math.sin. Then I made a diff of these two files.

28,29c28,29
<         print args, math.cgc_sqrt(variance)
<     return math.cgc_sqrt(variance)
---
>         print args, math.sqrt(variance)
>     return math.sqrt(variance)
137,139c137,139
<         Op('COS', 1, f=lambda args: math.cgc_cos(args[0])),
<         Op('LN', 1, f=lambda args: math.cgc_log(args[0])),
<         Op('LOG10', 1, f=lambda args: math.cgc_log10(args[0])),
---
>         Op('COS', 1, f=lambda args: math.cos(args[0])),
>         Op('LN', 1, f=lambda args: math.log(args[0])),
>         Op('LOG10', 1, f=lambda args: math.log10(args[0])),
143,144c143,144
<         Op('SIN', 1, f=lambda args: math.cgc_sin(args[0])),
<         Op('SQRT', 1, f=lambda args: math.cgc_sqrt(args[0])),
---
>         Op('SIN', 1, f=lambda args: math.sin(args[0])),
>         Op('SQRT', 1, f=lambda args: math.sqrt(args[0])),

Is there a mistake introduced by global replacing?

Error Traceback:

A_Game_of_Chance
Traceback (most recent call last):
  File "/root/cb-multios/tools/generate-polls/generate-polls", line 267, in <module>
    main()
  File "/root/cb-multios/tools/generate-polls/generate-polls", line 165, in main
    machine = get_state_machine(args.machine)
  File "/root/cb-multios/tools/generate-polls/generate-polls", line 117, in get_state_machine
    module = imp.load_source('state_machine', filename)
  File "poller/for-release//machine.py", line 30, in <module>
    import support as sp
ImportError: No module named support
Accel
Traceback (most recent call last):
  File "/root/cb-multios/tools/generate-polls/generate-polls", line 267, in <module>
    main()
  File "/root/cb-multios/tools/generate-polls/generate-polls", line 226, in main
    graph.walk(current_id, total)
  File "/root/cb-multios/tools/generate-polls/generator/graph.py", line 231, in walk
    response = node()
  File "poller/for-release//machine.py", line 261, in quit
    self._show(k)
  File "poller/for-release//machine.py", line 189, in _show
    value = value.evaluate()
  File "poller/for-release//machine.py", line 104, in evaluate
    result = round(self.op.evaluate(map(lambda x: x.evaluate(), self.args)), 3)
  File "poller/for-release//machine.py", line 104, in <lambda>
    result = round(self.op.evaluate(map(lambda x: x.evaluate(), self.args)), 3)
  File "poller/for-release//machine.py", line 104, in evaluate
    result = round(self.op.evaluate(map(lambda x: x.evaluate(), self.args)), 3)
  File "poller/for-release//machine.py", line 104, in <lambda>
    result = round(self.op.evaluate(map(lambda x: x.evaluate(), self.args)), 3)
  File "poller/for-release//machine.py", line 104, in evaluate
    result = round(self.op.evaluate(map(lambda x: x.evaluate(), self.args)), 3)
  File "poller/for-release//machine.py", line 127, in evaluate
    return self.f(args)
  File "poller/for-release//machine.py", line 143, in <lambda>
    Op('SIN', 1, f=lambda args: math.cgc_sin(args[0])),
AttributeError: 'module' object has no attribute 'cgc_sin'

We should remove DARPA's build system. It's confusing having two.

Unfortunately, the challenge creators used a lot of symbols that conflict with libc symbols (function, type, and structure names). Additionally, the type signatures were not kept consistent. This confuses static analysis tools that have encoded ISO standard C functions into their model, requiring a lot of gymnastics to get the tools working properly.

Prefixing all symbols with cgc_ will also allow us to remove -nostdinc and make porting to Windows much more straight-forward.

We are currently using both Github Actions and AppVeyor for CI.

We should remove AppVeyor and use Github Actions for all supported OS builds in CI.

Write a readme that includes:

• Introduction to the challenge set
  • Why they're cool
  • What you can do with them
  • Some example uses (e.g. linter shootout, static-analysis tool comparison, fuzzer comparison, translation tool testing, etc)
• Build Instructions
  • For all the binaries and individual binaries
  • Explanation of patched and non-patched binaries
• Test Instructions
  • How to generate polls
  • How to run polls
  • How to test the pov (vs both patched and vulnerable versions)
• Why we made some decisions when porting
  • cmake
  • dynamic linking vs system libc
  • nostdinc
• State of each binary on each platform

This way we can see that they at least work

Hi, I met some problems with generating polls. I successfully built the challenges with ./build.sh, and then I tried to generate the poll with ./genpolls.sh, however, I got many error messages in this process, and also when I ran ./tester.py -a -o out.xlsx it stuck(overnight) with following challenges:

Testing A_Game_of_Chance...
POV:
        Running 2 test(s) => Passed 2/2
POLL:
        for-release:    Running 200 test(s)

Attached is the log file with the command ./genpolls.sh &> genpolls.log. It looks like I didn't generate the polls correctly, but I have no idea how to fix this problem. Please give me some comments about this issue, thank you.

genpolls.log

Hi,

I found some new vulnerabilities which are different with the current POVs.
For example, in the PKK_Steganography, I attached two test cases in new_pov.tar.gz, which includes:

test_float: floating point exception
test_seg: Segmentation fault

The two bugs cannot be solved in the patched version.

So I want to ask whether the bugs exist in the original cgc codes or caused by your modification.

Thanks.
new_pov.tar.gz

That's not an issue per se, but I was wondering if there was a list with all faulty lines.

I'm aware of PATCHED macros, but those don't necessarily tell the line where the program actually breaks.

The reason behind it is to make it a test suite easier to be analyzed by researchers of source code analysis tools, like this one: https://samate.nist.gov/SARD/view.php?tsID=104

Thanks in advance!

Using socat doesn't work for these challenges. The way IPC is used in these challenges is described here.

Real software doesn't have a page of random bytes mapped into every process for its entropy. We need to rewrite the challenges that use the "random page" to use a more standard mechanism for randomness.

https://github.com/CyberGrandChallenge/cgc-release-documentation/blob/master/walk-throughs/submitting-a-cb.md#flag-page

The global CXXFLAGS and those that are set in the build_directives.txt files are ignored by the build system and the CFLAGS are used instead. This seems to be fine for most of the challenges, but results in exception handling being compiled into the challenges. This might have unexpected effects on analysis tools, if they don't support dealing with that.

Currently the challenge binaries do not work on WSL. WSL does not support 32bit executables.

This is really a duplicate of #14.

Many of these were written with poor 32bit assumptions like sizeof(int) == sizeof(void *).

Why is 32bit even a thing anymore?

Hi,
first of all thanks for this great project. I'm trying to compile the challenges using ./build.sh but I encountered the following error:

/home/frapik/Desktop/cb-multios/processed-challenges/Pac_for_Edges/lib/malloc_common.c: At top level:
cc1: warning: unrecognized command line option ‘-Wno-writable-strings’
/home/frapik/Desktop/cb-multios/processed-challenges/Pac_for_Edges/src/service.c: At top level:
cc1: warning: unrecognized command line option ‘-Wno-writable-strings’
[  2%] Linking C executable Pac_for_Edges
/home/frapik/Desktop/cb-multios/processed-challenges/Pac_for_Edges/src/service.c: At top level:
cc1: warning: unrecognized command line option ‘-Wno-writable-strings’
[  2%] Linking C executable Pac_for_Edges_patched
[  2%] Built target Pac_for_Edges
[  2%] Built target Pac_for_Edges_patched
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

Can anyone help me to fix it please?

Thanks

Hello, I am a newbie to cgc, and would like to ask me how to use AFL to test CGC. I need to use AFL's llvm mode to compile the CGC source code and test it. I have not found a tutorial on related operations at present, and I hope to get your support. Looking forward to your reply

The current status google doc link in the README is broken.

Hi,
When I test DARPA Challenge Binaries on Linux, in the directory ‘cb-multios/build/challenges’, I can find each challenge has the binary and pov.pov.
I run an example in the directory ‘cb-multios/build/challenges/Hug_Game’, when I run ‘../../../tools/tester.py -c Hug_Game --povs’ as github, it shows:

### 
\Running tests against 1 challenge(s)

Testing Hug_Game...
POV:
	Running 2 test(s) => Passed 1/2
Done testing Hug_Game => Passed 1/2 tests

I don’t understand if the challenge has been triggered successfully, and what the meaning of the passed 1/2?

And I want to debug the binary using gdb, but I don’t know the true option, I run 'gdb Hug_Game', and next ‘r < pov.pov’, but it looks like doesn’t work.
So can you tell me how to debug it by using gdb?

Thanks

Shouldn't void cgc__terminate(unsigned int status)
in libcgc actually receive a normal int?

Some of the challenges return a negative status.

When following the READ.me to build, I encountered the following error:
"cb-multios/challenges/SPIFFS/lib/stdlib.c:102: undefined reference to `fabs'"

libc6-dev is good, but I did not find any place to add "LD_FLAGS".

KLEE can't cope with main functions that have fewer than 2 arguments.

I believe the current CBs don't use argc and argv at all. Some are passed the flag page as an argument to main(), but these can pretty easily be converted to use a local variable instead (I think).

Here's what my CMakeLists.txt file looks like:
~/cb-multios/CMakeLists.txt
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -z execstack -z norelro -static-libgcc -static-libstdc++")
set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} -s")
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -s")

but it doesn't work

I get the following errors after build.sh:

-- Build files have been written to: /Users/artem/git/cb-multios/build
[465/11140] Linking C shared library include/tiny-AES128-C/libtiny-AES128-C.dylib
FAILED: include/tiny-AES128-C/libtiny-AES128-C.dylib
: && /usr/bin/clang  -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -dynamiclib -Wl,-headerpad_max_install_names -m32 -o include/tiny-AES128-C/libtiny-AES128-C.dylib -install_name @rpath/libtiny-AES128-C.dylib include/tiny-AES128-C/CMakeFiles/tiny-AES128-C.dir/aes.c.o   && :
ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS)
ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd, missing required architecture i386 in file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd
Undefined symbols for architecture i386:
  "___memset_chk", referenced from:
      _AES128_CBC_encrypt_buffer in aes.c.o
      _AES128_CBC_decrypt_buffer in aes.c.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[474/11140] Building C object challenges/HeartThrob/CMakeFiles/HeartThrob_patched.dir/src/check.c.o
ninja: build stopped: subcommand failed.

#64 makes macOS use ninja; Windows should do the same on AppVeyor.