├── .gitignore ├── LICENCE ├── NEWS ├── README.md ├── README.orig.md ├── doc └── radamsa.1 ├── jni ├── Android.mk ├── Application.mk └── radamsa.c └── tests ├── ab.sh ├── bd.sh ├── benchmark ├── blank.sh_ ├── fail.sh ├── ft.sh ├── ld.sh ├── li.sh ├── lr2.sh ├── ls.sh ├── meta.sh ├── nop.sh ├── num.sh ├── run ├── seek.sh ├── sr.sh ├── tcp-client.sh_ ├── tcp-serve.sh_ ├── tr.sh ├── tr2.sh ├── ts1.sh ├── ts2.sh ├── uniq.sh ├── xpd.sh ├── xpi.sh ├── xpn.sh ├── xpp.sh └── xps.sh /.gitignore: -------------------------------------------------------------------------------- 1 | libs/ 2 | obj/ 3 | -------------------------------------------------------------------------------- /LICENCE: -------------------------------------------------------------------------------- 1 | Copyright (c) 2013 Aki Helin 2 | 3 | Permission is hereby granted, free of charge, to any person obtaining a copy 4 | of this software and associated documentation files (the "Software"), to deal 5 | in the Software without restriction, including without limitation the rights 6 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 7 | copies of the Software, and to permit persons to whom the Software is 8 | furnished to do so, subject to the following conditions: 9 | 10 | The above copyright notice and this permission notice shall be included in 11 | all copies or substantial portions of the Software. 12 | 13 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 14 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 15 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 16 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 17 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 18 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 19 | THE SOFTWARE. 20 | -------------------------------------------------------------------------------- /NEWS: -------------------------------------------------------------------------------- 1 | Changes in 0.6 2 | - added pcapng awareness (thanks to Alberto Zaccagni and Guglielmo Fachini of Nozomi Networks) 3 | - automatic uniqueness filter catches most duplicates (-C flag) 4 | - added UDP output 5 | Changes in 0.5 6 | - %s in output path is the suffix of the main sample file used, if applicable, based on commit by Ditmar Wendt 7 | - added --seek to seek a specific testcase 8 | - added more unicode mutations by Chris Weber 9 | - added optional delay between outputs 10 | - started a NEWS log 11 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Android port of [Radamsa](https://gitlab.com/akihe/radamsa) 2 | 3 | Just a generated code export with minor Android NDK tweaking to compile and support Android ABIs. 4 | Run `ndk-build` from root directory to compile 5 | -------------------------------------------------------------------------------- /README.orig.md: -------------------------------------------------------------------------------- 1 | # A Crash Course to Radamsa 2 | 3 | Radamsa is a test case generator for robustness testing, a.k.a. a fuzzer. It is typically used to test how well a program can withstand malformed and potentially malicious inputs. It works by reading sample files of valid data and generating interestringly different outputs from them. The main selling points of radamsa are that it has already found a slew of bugs in programs that actually matter, it is easily scriptable and, easy to get up and running. 4 | 5 | ## Nutshell: 6 | 7 | ``` 8 | $ # please please please fuzz your programs. here is one way to get data for it: 9 | $ sudo apt-get install gcc make git wget 10 | $ git clone https://gitlab.com/akihe/radamsa.git && cd radamsa && make && sudo make install 11 | $ echo "HAL 9000" | radamsa 12 | ``` 13 | 14 | ## What the Fuzz 15 | 16 | Programming is hard. All nontrivial programs have bugs in them. What's more, even the simplest typical mistakes are in some of the most widely used programming languages usually enough for attackers to gain undesired powers. 17 | 18 | Fuzzing is one of the techniques to find such unexpected behavior from programs. The idea is simply to subject the program to various kinds of inputs and see what happens. There are two parts in this process: getting the various kinds of inputs and how to see what happens. Radamsa is a solution to the first part, and the second part is typically a short shell script. Testers usually have a more or less vague idea what should *not* happen, and they try to find out if this is so. This kind of testing is often referred to as negative testing, being the opposite of positive unit- or integration testing. Developers know a service should not crash, should not consume exponential amounts of memory, should not get stuck in an infinite loop, etc. Attackers know that they can probably turn certain kinds of memory safety bugs into exploits, so they fuzz typically instrumented versions of the target programs and wait for such errors to be found. In theory, the idea is to counterprove by finding a counterexample a theorem about the program stating that for all inputs something doesn't happen. 19 | 20 | There are many kinds of fuzzers and ways to apply them. Some trace the target program and generate test cases based on the behavior. Some need to know the format of the data and generate test cases based on that information. Radamsa is an extremely "black-box" fuzzer, because it needs no information about the program nor the format of the data. One can pair it with coverage analysis during testing to likely improve the quality of the sample set during a continuous test run, but this is not mandatory. The main goal is to first get tests running easily, and then refine the technique applied if necessary. 21 | 22 | Radamsa is intended to be a good general purpose fuzzer for all kinds of data. The goal is to be able to find issues no matter what kind of data the program processes, whether it's xml or mp3, and conversely that not finding bugs implies that other similar tools likely won't find them either. This is accomplished by having various kinds of heuristics and change patterns, which are varied during the tests. Sometimes there is just one change, sometimes there a slew of them, sometimes there are bit flips, sometimes something more advanced and novel. 23 | 24 | Radamsa is a side-product of OUSPG's Protos Genome Project, in which some techniques to automatically analyze and examine the structure of communication protocols were explored. A subset of one of the tools turned out to be a surprisingly effective file fuzzer. The first prototype black-box fuzzer tools mainly used regular and context-free formal languages to represent the inferred model of the data. 25 | 26 | ## Requirements 27 | 28 | Supported operating systems: 29 | * GNU/Linux 30 | * OpenBSD 31 | * FreeBSD 32 | * Mac OS X 33 | * Windows (using Cygwin) 34 | 35 | Software requirements for building from sources: 36 | * gcc / clang 37 | * make 38 | * git 39 | * wget 40 | 41 | ## Building Radamsa 42 | ``` 43 | $ git clone https://gitlab.com/akihe/radamsa.git 44 | $ cd radamsa 45 | $ make 46 | $ sudo make install # optional, you can also just grab bin/radamsa 47 | $ radamsa --help 48 | ``` 49 | 50 | Radamsa itself is just a single binary file which has no external dependencies. You can move it where you please and remove the rest. 51 | 52 | 53 | ## Fuzzing with Radamsa 54 | 55 | This section assumes some familiarity with UNIX scripting. 56 | 57 | Radamsa can be thought as the cat UNIX tool, which manages to break the data in often interesting ways as it flows through. It has also support for generating more than one output at a time and acting as a TCP server or client, in case such things are needed. 58 | 59 | Use of radamsa will be demonstrated by means of small examples. We will use the bc arbitrary precision calculator as an example target program. 60 | 61 | In the simplest case, from scripting point of view, radamsa can be used to fuzz data going through a pipe. 62 | 63 | ``` 64 | $ echo "aaa" | radamsa 65 | aaaa 66 | ``` 67 | Here radamsa decided to add one 'a' to the input. Let's try that again. 68 | 69 | ``` 70 | $ echo "aaa" | radamsa 71 | ːaaa 72 | ``` 73 | 74 | Now we got another result. By default radamsa will grab a random seed from /dev/urandom if it is not given a specific random state to start from, and you will generally see a different result every time it is started, though for small inputs you might see the same or the original fairly often. The random state to use can be given with the -s parameter, which is followed by a number. Using the same random state will result in the same data being generated. 75 | 76 | ``` 77 | $ echo "Fuzztron 2000" | radamsa --seed 4 78 | Fuzztron 4294967296 79 | ``` 80 | 81 | This particular example was chosen because radamsa happens to choose to use a number mutator, which replaces textual numbers with something else. Programmers might recognize why for example this particular number might be an interesting one to test for. 82 | 83 | You can generate more than one output by using the -n parameter as follows: 84 | 85 | ``` 86 | $ echo "1 + (2 + (3 + 4))" | radamsa --seed 12 -n 4 87 | 1 + (2 + (2 + (3 + 4?) 88 | 1 + (2 + (3 +?4)) 89 | 18446744073709551615 + 4))) 90 | 1 + (2 + (3 + 170141183460469231731687303715884105727)) 91 | ``` 92 | 93 | There is no guarantee that all of the outputs will be unique. However, when using nontrivial samples, equal outputs tend to be extremely rare. 94 | 95 | What we have so far can be used to for example test programs that read input from standard input, as in 96 | 97 | ``` 98 | $ echo "100 * (1 + (2 / 3))" | radamsa -n 10000 | bc 99 | [...] 100 | (standard_in) 1418: illegal character: ^_ 101 | (standard_in) 1422: syntax error 102 | (standard_in) 1424: syntax error 103 | (standard_in) 1424: memory exhausted 104 | [hang] 105 | ``` 106 | 107 | Or the compiler used to compile Radamsa: 108 | 109 | ``` 110 | $ echo '((lambda (x) (+ x 1)) #x124214214)' | radamsa -n 10000 | ol 111 | [...] 112 | > What is 'ó µ'? 113 | 4901126677 114 | > $ 115 | ``` 116 | 117 | Or to test decompression: 118 | 119 | ``` 120 | $ gzip -c /bin/bash | radamsa -n 1000 | gzip -d > /dev/null 121 | ``` 122 | 123 | Typically however one might want separate runs for the program for each output. Basic shell scripting makes this easy. Usually we want a test script to run continuously, so we'll use an infinite loop here: 124 | 125 | ``` 126 | $ gzip -c /bin/bash > sample.gz 127 | $ while true; do radamsa sample.gz | gzip -d > /dev/null; done 128 | ``` 129 | 130 | Notice that we are here giving the sample as a file instead of running Radamsa in a pipe. Like cat Radamsa will by default write the output to stdout, but unlike cat when given more than one file it will usually use only one or a few of them to create one output. This test will go about throwing fuzzed data against gzip, but doesn't care what happens then. One simple way to find out if something bad happened to a (simple single-threaded) program is to check whether the exit value is greater than 127, which would indicate a fatal program termination. This can be done for example as follows: 131 | 132 | ``` 133 | $ gzip -c /bin/bash > sample.gz 134 | $ while true 135 | do 136 | radamsa sample.gz > fuzzed.gz 137 | gzip -dc fuzzed.gz > /dev/null 138 | test $? -gt 127 && break 139 | done 140 | ``` 141 | 142 | This will run for as long as it takes to crash gzip, which hopefully is no longer even possible, and the fuzzed.gz can be used to check the issue if the script has stopped. We have found a few such cases, the last one of which took about 3 months to find, but all of them have as usual been filed as bugs and have been promptly fixed by the upstream. 143 | 144 | One thing to note is that since most of the outputs are based on data in the given samples (standard input or files given at command line) it is usually a good idea to try to find good samples, and preferably more than one of them. In a more real-world test script radamsa will usually be used to generate more than one output at a time based on tens or thousands of samples, and the consequences of the outputs are tested mostly in parallel, often by giving each of the output on command line to the target program. We'll make a simple such script for bc, which accepts files from command line. The -o flag can be used to give a file name to which radamsa should write the output instead of standard output. If more than one output is generated, the path should have a %n in it, which will be expanded to the number of the output. 145 | 146 | ``` 147 | $ echo "1 + 2" > sample-1 148 | $ echo "(124 % 7) ^ 1*2" > sample-2 149 | $ echo "sqrt((1 + length(10^4)) * 5)" > sample-3 150 | $ bc sample-* < /dev/null 151 | 3 152 | 10 153 | 5 154 | $ while true 155 | do 156 | radamsa -o fuzz-%n -n 100 sample-* 157 | bc fuzz-* < /dev/null 158 | test $? -gt 127 && break 159 | done 160 | ``` 161 | 162 | This will again run up to obviously interesting times indicated by the large exit value, or up to the target program getting stuck. 163 | 164 | In practice many programs fail in unique ways. Some common ways to catch obvious errors are to check the exit value, enable fatal signal printing in kernel and checking if something new turns up in dmesg, run a program under strace, gdb or valgrind and see if something interesting is caught, check if an error reporter process has been started after starting the program, etc. 165 | 166 | ## Output Options 167 | 168 | The examples above all either wrote to standard output or files. One can also ask radamsa to be a TCP client or server by using a special parameter to -o. The output patterns are: 169 | 170 | |-o argument | meaning | example | 171 | |------------|---------|---------| 172 | | :port | act as a TCP server in given port | # radamsa -o :80 -n inf samples/*.http-resp | 173 | |ip:port | connect as TCP client to port of ip | $ radamsa -o 127.0.0.1:80 -n inf samples/*.http-req | 174 | | - | write to stdout | $ radamsa -o - samples/*.vt100 | 175 | | path | write to files, %n is testcase # and %s the first suffix | $ radamsa -o test-%n.%s -n 100 samples/*.foo | 176 | 177 | Remember that you can use e.g. tcpflow to record TCP traffic to files, which can then be used as samples for radamsa. 178 | 179 | ## Related Tools 180 | 181 | A non-exhaustive list of free complementary tools: 182 | 183 | * GDB (http://www.gnu.org/software/gdb/) 184 | * Valgrind (http://valgrind.org/) 185 | * AddressSanitizer (http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer) 186 | * strace (http://sourceforge.net/projects/strace/) 187 | * tcpflow (http://www.circlemud.org/~jelson/software/tcpflow/) 188 | 189 | A non-exhaustive list of related free tools: 190 | * American fuzzy lop (http://lcamtuf.coredump.cx/afl/) 191 | * Zzuf (http://caca.zoy.org/wiki/zzuf) 192 | * Bunny the Fuzzer (http://code.google.com/p/bunny-the-fuzzer/) 193 | * Peach (http://peachfuzzer.com/) 194 | * Sulley (http://code.google.com/p/sulley/) 195 | * Munity (https://github.com/Cisco-Talos/mutiny-fuzzer) 196 | 197 | Tools which are intended to improve security are usually complementary and should be used in parallel to improve the results. Radamsa aims to be an easy-to-set-up general purpose shotgun test to expose the easiest (and often severe due to being reachable from via input streams) cracks which might be exploitable by getting the program to process malicious data. It has also turned out to be useful for catching regressions when combined with continuous automatic testing. 198 | 199 | ## Some Known Results 200 | 201 | A robustness testing tool is obviously only good only if it really can find non-trivial issues in real-world programs. Being a University-based group, we have tried to formulate some more scientific approaches to define what a 'good fuzzer' is, but real users are more likely to be interested in whether a tool has found something useful. We do not have anyone at OUSPG running tests or even developing Radamsa full-time, but we obviously do make occasional test-runs, both to assess the usefulness of the tool, and to help improve robustness of the target programs. For the test-runs we try to select programs that are mature, useful to us, widely used, and, preferably, open source and/or tend to process data from outside sources. 202 | 203 | The list below has some CVEs we know of that have been found by using Radamsa. Some of the results are from our own test runs, and some have been kindly provided by CERT-FI from their tests and other users. As usual, please note that CVE:s should be read as 'product X is now more robust (against Y)'. 204 | 205 | CVE | program | credit 206 | --------------|------------|----------- 207 | CVE-2007-3641 | libarchive | OUSPG 208 | CVE-2007-3644 | libarchive | OUSPG 209 | CVE-2007-3645 | libarchive | OUSPG 210 | CVE-2008-1372 | bzip2 | OUSPG 211 | CVE-2008-1387 | ClamAV | OUSPG 212 | CVE-2008-1412 | F-Secure | OUSPG 213 | CVE-2008-1837 | ClamAV | OUSPG 214 | CVE-2008-6536 | 7-zip | OUSPG 215 | CVE-2008-6903 | Sophos Anti-Virus | OUSPG 216 | CVE-2010-0001 | Gzip | integer underflow in unlzw | OUSPG 217 | CVE-2010-0192 | Acroread | OUSPG 218 | CVE-2010-1205 | libpng | OUSPG 219 | CVE-2010-1410 | Webkit | OUSPG 220 | CVE-2010-1415 | Webkit | OUSPG 221 | CVE-2010-1793 | Webkit | OUSPG 222 | CVE-2010-2065 | libtiff | found by CERT-FI 223 | CVE-2010-2443 | libtiff | found by CERT-FI 224 | CVE-2010-2597 | libtiff | found by CERT-FI 225 | CVE-2010-2482 | libtiff | found by CERT-FI 226 | CVE-2011-0522 | VLC | found by Harry Sintonen 227 | CVE-2011-0181 | Apple ImageIO | found by Harry Sintonen 228 | CVE-2011-0198 | Apple Type Services | found by Harry Sintonen 229 | CVE-2011-0205 | Apple ImageIO | found by Harry Sintonen 230 | CVE-2011-0201 | Apple CoreFoundation | found by Harry Sintonen 231 | CVE-2011-1276 | Excel | found by Nicolas Grégoire of Agarri 232 | CVE-2011-1186 | Chrome | OUSPG 233 | CVE-2011-1434 | Chrome | OUSPG 234 | CVE-2011-2348 | Chrome | OUSPG 235 | CVE-2011-2804 | Chrome/pdf | OUSPG 236 | CVE-2011-2830 | Chrome/pdf | OUSPG 237 | CVE-2011-2839 | Chrome/pdf | OUSPG 238 | CVE-2011-2861 | Chrome/pdf | OUSPG 239 | CVE-2011-3146 | librsvg | found by Sauli Pahlman 240 | CVE-2011-3654 | Mozilla Firefox | OUSPG 241 | CVE-2011-3892 | Theora | OUSPG 242 | CVE-2011-3893 | Chrome | OUSPG 243 | CVE-2011-3895 | FFmpeg | OUSPG 244 | CVE-2011-3957 | Chrome | OUSPG 245 | CVE-2011-3959 | Chrome | OUSPG 246 | CVE-2011-3960 | Chrome | OUSPG 247 | CVE-2011-3962 | Chrome | OUSPG 248 | CVE-2011-3966 | Chrome | OUSPG 249 | CVE-2011-3970 | libxslt | OUSPG 250 | CVE-2012-0449 | Firefox | found by Nicolas Grégoire of Agarri 251 | CVE-2012-0469 | Mozilla Firefox | OUSPG 252 | CVE-2012-0470 | Mozilla Firefox | OUSPG 253 | CVE-2012-0457 | Mozilla Firefox | OUSPG 254 | CVE-2012-2825 | libxslt | found by Nicolas Grégoire of Agarri 255 | CVE-2012-2849 | Chrome/GIF | OUSPG 256 | CVE-2012-3972 | Mozilla Firefox | found by Nicolas Grégoire of Agarri 257 | CVE-2012-1525 | Acrobat Reader | found by Nicolas Grégoire of Agarri 258 | CVE-2012-2871 | libxslt | found by Nicolas Grégoire of Agarri 259 | CVE-2012-2870 | libxslt | found by Nicolas Grégoire of Agarri 260 | CVE-2012-2870 | libxslt | found by Nicolas Grégoire of Agarri 261 | CVE-2012-4922 | tor | found by the Tor project 262 | CVE-2012-5108 | Chrome | OUSPG via NodeFuzz 263 | CVE-2012-2887 | Chrome | OUSPG via NodeFuzz 264 | CVE-2012-5120 | Chrome | OUSPG via NodeFuzz 265 | CVE-2012-5121 | Chrome | OUSPG via NodeFuzz 266 | CVE-2012-5145 | Chrome | OUSPG via NodeFuzz 267 | CVE-2012-4186 | Mozilla Firefox | OUSPG via NodeFuzz 268 | CVE-2012-4187 | Mozilla Firefox | OUSPG via NodeFuzz 269 | CVE-2012-4188 | Mozilla Firefox | OUSPG via NodeFuzz 270 | CVE-2012-4202 | Mozilla Firefox | OUSPG via NodeFuzz 271 | CVE-2013-0744 | Mozilla Firefox | OUSPG via NodeFuzz 272 | CVE-2013-1691 | Mozilla Firefox | OUSPG 273 | CVE-2013-1708 | Mozilla Firefox | OUSPG 274 | CVE-2013-4082 | Wireshark | found by cons0ul 275 | CVE-2013-1732 | Mozilla Firefox | OUSPG 276 | CVE-2014-0526 | Adobe Reader X/XI | Pedro Ribeiro (pedrib@gmail.com) 277 | CVE-2014-3669 | PHP 278 | CVE-2014-3668 | PHP 279 | CVE-2014-8449 | Adobe Reader X/XI | Pedro Ribeiro (pedrib@gmail.com) 280 | CVE-2014-3707 | cURL | Symeon Paraschoudis 281 | CVE-2014-7933 | Chrome | OUSPG 282 | CVE-2015-0797 | Mozilla Firefox | OUSPG 283 | CVE-2015-0813 | Mozilla Firefox | OUSPG 284 | CVE-2015-1220 | Chrome | OUSPG 285 | CVE-2015-1224 | Chrome | OUSPG 286 | CVE-2015-2819 | Sybase SQL | vah_13 (ERPScan) 287 | CVE-2015-2820 | SAP Afaria | vah_13 (ERPScan) 288 | CVE-2015-7091 | Apple QuickTime | Pedro Ribeiro (pedrib@gmail.com) 289 | CVE-2015-8330 | SAP PCo agent | Mathieu GELI (ERPScan) 290 | CVE-2016-1928 | SAP HANA hdbxsengine |Mathieu Geli (ERPScan) 291 | CVE-2016-3979 | SAP NetWeaver | @ret5et (ERPScan) 292 | CVE-2016-3980 | SAP NetWeaver | @ret5et (ERPScan) 293 | CVE-2016-4015 | SAP NetWeaver | @vah_13 (ERPScan) 294 | CVE-2016-4015 | SAP NetWeaver | @vah_13 (ERPScan) 295 | CVE-2016-9562 | SAP NetWeaver | @vah_13 (ERPScan) 296 | CVE-2017-5371 | SAP ASE OData | @vah_13 (ERPScan) 297 | CVE-2017-9843 | SAP NETWEAVER | @vah_13 (ERPScan) 298 | CVE-2017-9845 | SAP NETWEAVER | @vah_13 (ERPScan) 299 | [CVE-2018-0101](https://www.nccgroup.trust/globalassets/newsroom/uk/events/offensivecon2018-the-return-of-robin-hood-vs-cisco-asa.pdf) | Cisco ASA WebVPN/AnyConnect | @saidelike (NCC Group) 300 | 301 | We would like to thank the Chromium project and Mozilla for analyzing, fixing and reporting further many of the above mentioned issues, CERT-FI for feedback and disclosure handling, and other users, projects and vendors who have responsibly taken care of uncovered bugs. 302 | 303 | ## Thanks 304 | 305 | The following people have contributed to the development of radamsa in code, ideas, issues or otherwise. 306 | 307 | * Darkkey 308 | * Branden Archer 309 | 310 | 311 | ## Troubleshooting 312 | 313 | Issues in Radamsa can be reported to the issue tracker. The tool is under development, but we are glad to get error reports even for known issues to make sure they are not forgotten. 314 | 315 | You can also drop by at #radamsa on Freenode if you have questions or feedback. 316 | 317 | Issues your programs should be fixed. If Radamsa finds them quickly (say, in an hour or a day) chances are that others will too. 318 | 319 | Issues in other programs written by others should be dealt with responsibly. Even fairly simple errors can turn out to be exploitable, especially in programs written in low-level languages. In case you find something potentially severe, like an easily reproducible crash, and are unsure what to do with it, ask the vendor or project members, or your local CERT. 320 | 321 | # FAQ 322 | 323 | Q: If I find a bug with radamsa, do I have to mention the tool? 324 | A: No. 325 | 326 | Q: Will you make a graphical version of radamsa? 327 | A: No. The intention is to keep it simple and scriptable for use in automated regression tests and continuous testing. 328 | 329 | Q: I can't install! I don't have root access on the machine! 330 | A: You can omit the $ make install part and just run radamsa from bin/radamsa in the build directory, or copy it somewhere else and use from there. 331 | 332 | Q: Radamsa takes several GB of memory to compile!1 333 | A: This is most likely due to an issue with your C compiler. Use prebuilt images or try the quick build instructions in this page. 334 | 335 | Q: Radamsa does not compile using the instructions in this page! 336 | A: Please file an issue at https://gitlab.com/akihe/radamsa/issues/new if you don't see a similar one already filed, send email (aohelin@gmail.com) or IRC (#radamsa on freenode). 337 | 338 | Q: I used fuzzer X and found much more bugs from program Y than Radamsa did. 339 | A: Cool. Let me know about it (aohelin@gmail.com) and I'll try to hack something X-ish to radamsa if it's general purpose enough. It'd also be useful to get some samples which you used to check how well radamsa does, because it might be overfitting some heuristic. 340 | 341 | Q: Can I get support for using radamsa? 342 | A: You can send email to aohelin@gmail.com or check if some of us happen to be hanging around at #radamsa on freenode. 343 | 344 | Q: Can I use radamsa on Windows? 345 | A: An experimental Windows executable is now in Downloads, but we have usually not tested it properly since we rarely use Windows internally. Feel free to file an issue if something is broken. 346 | 347 | Q: How can I install radamsa? 348 | A: Grab a binary from downloads and run it, or $ make && sudo make install. 349 | 350 | Q: How can I uninstall radamsa? 351 | A: Remove the binary you grabbed from downloads, or $ sudo make uninstall. 352 | 353 | Q: Why are many outputs generated by Radamsa equal? 354 | A: Radamsa doesn't keep track which outputs it has already generated, but instead relies on varying mutations to keep the output varying enough. Outputs can often be the same if you give a few small samples and generate lots of outputs from them. If you do spot a case where lots of equal outputs are generated, we'd be interested in hearing about it. 355 | 356 | Q: There are lots of command line options. Which should I use for best results? 357 | A: The recommended use is $ radamsa -o output-%n.foo -n 100 samples/*.foo, which is also what is used internally at OUSPG. It's usually best and most future proof to let radamsa decide the details. 358 | 359 | Q: How can I make radamsa faster? 360 | A: Radamsa typically writes a few megabytes of output per second. If you enable only simple mutations, e.g. -m bf,bd,bi,br,bp,bei,bed,ber,sr,sd, you will get about 10x faster output. 361 | 362 | Q: What's with the funny name? 363 | A: It's from a scene in a Finnish children's story. You've probably never heard about it. 364 | 365 | Q: Is this the last question? 366 | A: Yes. 367 | 368 | ## Warnings 369 | 370 | Use of data generated by radamsa, especially when targeting buggy programs running with high privileges, can result in arbitrarily bad things to happen. A typical unexpected issue is caused by a file manager, automatic indexer or antivirus scanner trying to do something to fuzzed data before they are being tested intentionally. We have seen spontaneous reboots, system hangs, file system corruption, loss of data, and other nastiness. When in doubt, use a disposable system, throwaway profile, chroot jail, sandbox, separate user account, or an emulator. 371 | 372 | Not safe when used as prescribed. 373 | 374 | This product may contain faint traces of parenthesis. 375 | -------------------------------------------------------------------------------- /doc/radamsa.1: -------------------------------------------------------------------------------- 1 | .TH radamsa 1 "March 28, 2012" 2 | .SH NAME 3 | radamsa \- a general purpose fuzzer 4 | .SH SYNOPSIS 5 | .B radamsa 6 | .RI [ options ] " " [ sample-path ] " ..." 7 | .SH DESCRIPTION 8 | Radamsa is a general purpose data fuzzer. It reads data from given sample files, 9 | or standard input if none are given, and outputs modified data. It is usually 10 | used to generate malformed data for testing programs. 11 | .SH OPTIONS 12 | This program follows the usual GNU command line syntax, with long 13 | options starting with two dashes (`-'). 14 | A summary of options is included below. 15 | .TP 16 | .BR \-h ", " \-\-help 17 | Show a shorter summary of options. 18 | .TP 19 | .BR \-V ", " \-\-version 20 | Show program version. 21 | .TP 22 | .BR \-o ", " \-\-output " \fIpattern" 23 | Specify where to write the modified data. By default the data is written to standard output. The pattern can be a path, in which %n is filled to be the test case number if present, :n to have the data sent to TCP clients connecting to local port n, or a.b.c.d:n to have radamsa connect to port n of IPv4 address a.b.c.d to send each output. 24 | .TP 25 | .BR \-n ", " \-\-count " \fIn" 26 | How many outputs to generate based on the sample(s). Giving -1 or inf causes data to be generated forever. The default is 1. 27 | .TP 28 | .BR \-s ", " \-\-seed " \fIn" 29 | Start from random state n, which is a decimal number. Starting from the same random state with the same command line arguments and samples causes the same outputs to be generated. If no seed is given explicitly radamsa reads a random one from /dev/urandom or takes the current time in milliseconds. 30 | .TP 31 | .BR \-M ", " \-\-meta " \fIpath" 32 | Write metadata about generated data to given path. - can be used to have the metadata written to standard output. The metadata contains the seed followed by one line per testcase. 33 | .TP 34 | .BR \-l ", " \-\-list 35 | Show all available mutations, patterns and generators along with their descriptions. 36 | .TP 37 | .BR \-r ", " \-\-recursive 38 | Include samples from directories recursively. 39 | .TP 40 | .BR \-v ", " \-\-verbose 41 | Print what is being done. 42 | .TP 43 | .BR \-m ", " \-\-mutations " \fIstring" 44 | Request the initial mutation probabilities manually. This is generally not recommended and the options will change in the future versions. 45 | .TP 46 | .BR \-p ", " \-\-patterns " \fIstring" 47 | Request the mutation patterns manually. This is generally not recommended and the options will change in the future versions. 48 | .TP 49 | .BR \-g ", " \-\-generators " \fIstring" 50 | Request the data stream generator probabilities manually. This is generally not recommended and the options will change in the future versions. 51 | .SH EXAMPLES 52 | $ cat file | radamsa | program - 53 | $ radamsa samples/*.foo | program - 54 | $ radamsa -o test-%n.foo -n 100 samples/*.foo 55 | $ radamsa -o :80 -n inf samples/*.resp 56 | $ radamsa -o 127.0.0.1:80 -n inf samples/*.req 57 | .SH SEE ALSO 58 | .BR zzuf (1) 59 | .SH BUGS 60 | Bugs in radamsa can be filed to https://github.com/aoh/radamsa/issues or sent to ouspg@ee.oulu.fi. Bugs outside of radamsa should be filed to their respective bug trackers. 61 | .SH AUTHOR 62 | Radamsa and this manual page were written by Aki Helin at OUSPG. 63 | -------------------------------------------------------------------------------- /jni/Android.mk: -------------------------------------------------------------------------------- 1 | # radamsa Android 2 | # ----------------------------------------- 3 | # 4 | # Anestis Bechtsoudis 5 | # 6 | # Copyright 2014 - 2019 by Census SA. All Rights Reserved. 7 | # 8 | # Licensed under the Apache License, Version 2.0 (the "License"); 9 | # you may not use this file except in compliance with the License. 10 | # You may obtain a copy of the License at 11 | # 12 | # http://www.apache.org/licenses/LICENSE-2.0 13 | # 14 | # Unless required by applicable law or agreed to in writing, software 15 | # distributed under the License is distributed on an "AS IS" BASIS, 16 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 17 | # See the License for the specific language governing permissions and 18 | # limitations under the License. 19 | 20 | LOCAL_PATH := $(call my-dir) 21 | include $(CLEAR_VARS) 22 | 23 | LOCAL_MODULE := radamsa 24 | LOCAL_SRC_FILES := radamsa.c 25 | LOCAL_CFLAGS := -Wall -Werror -O3 -std=c99 -D_GNU_SOURCE -DANDROID 26 | 27 | include $(BUILD_EXECUTABLE) 28 | -------------------------------------------------------------------------------- /jni/Application.mk: -------------------------------------------------------------------------------- 1 | APP_PLATFORM := android-28 2 | APP_ABI := armeabi-v7a arm64-v8a x86 x86_64 3 | -------------------------------------------------------------------------------- /tests/ab.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | # check bad string insertion happens as intended (more likely within quoted area) 4 | 5 | echo '-----------------------------------------------------------------""---------------------------------------------------------------------------' \ 6 | | $@ -m ab -p od -n 20 | grep -q '^-*\".*%.*\"-*$' || exit 1 7 | 8 | -------------------------------------------------------------------------------- /tests/bd.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | /bin/echo -n ab | $@ -p od -m bd | grep -q "^[ab]$" 4 | 5 | -------------------------------------------------------------------------------- /tests/benchmark: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | SAMPLE=rad/main.scm 4 | TIMES=100 5 | #SEED=`date '+%s'` 6 | SEED=313333333337 7 | 8 | echo "Single mutation timings: mutate $SAMPLE $TIMES times, one mutation each" 9 | echo "Radamsa: $@" 10 | 11 | for mutation in $($@ --list | grep "^ " | sed 's/ *\([^:]*\):.*/\1/') 12 | do 13 | echo $mutation | grep -q "^od$" && break 14 | ELAPSED=`time -f "%Us" $@ -s $SEED -p od -m $mutation -o tmp/out-%n -n $TIMES $SAMPLE 2>&1` 15 | echo " $ELAPSED $mutation" 16 | done | sort -n 17 | 18 | -------------------------------------------------------------------------------- /tests/blank.sh_: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | # blank sample files should (with very high probability) trigger random data to be generated 4 | touch tmp/blank 5 | $@ < tmp/blank > tmp/nonblank 6 | cmp -s tmp/blank tmp/nonblank && exit 1 7 | rm tmp/blank tmp/nonblank 8 | 9 | -------------------------------------------------------------------------------- /tests/fail.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | # test that we fail right 4 | 5 | $@ -o non/existent/directory/output Makefile 2>/dev/null 6 | test $? -eq 1 || { echo bad first failure; exit 1; } 7 | 8 | ## output doesn't yet know whether it goes to files, and failure must be tolerated with TCP 9 | #$@ -o /dev/full readme.txt 2>/dev/null 10 | #test $? -eq 1 || { echo bad second failure; exit 1; } 11 | 12 | $@ -o ok nonreadablesam.ple 2>/dev/null 13 | test $? -eq 2 || { echo bad third failure; exit 1; } 14 | 15 | -------------------------------------------------------------------------------- /tests/ft.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | echo zombieslartibartfasterthaneelslartibartfastenyourseatbelts | $@ -m ft -p od -n 60 | grep -q zombieslartibartfastenyourseatbelts || exit 1 4 | 5 | -------------------------------------------------------------------------------- /tests/ld.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | echo -e "foo\nbar\nbaz" | $@ -p od -m ld | wc -l | grep -q 2 || exit 1 4 | 5 | -------------------------------------------------------------------------------- /tests/li.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | echo -e "a\n a\n a\n a\n a" | $@ -p od -m li | wc -l | grep -q 6 || exit 1 4 | 5 | -------------------------------------------------------------------------------- /tests/lr2.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | echo -e "foo\nbar\nbaz" | $@ -p od -m lr2 | wc -l | grep -q 4 || exit 1 4 | 5 | -------------------------------------------------------------------------------- /tests/ls.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | echo -e "foo\nbar" | $@ -m ls -p od | head -n 1 | grep -q bar || exit 1 4 | 5 | -------------------------------------------------------------------------------- /tests/meta.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | echo foo | $@ -M - -o /dev/null -p od -m bi 2>&1 | grep -q 'byte-insert: 1' 4 | 5 | -------------------------------------------------------------------------------- /tests/nop.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | echo "foo" | $@ -m nop -p od | grep -q "^foo$" || exit 1 4 | -------------------------------------------------------------------------------- /tests/num.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | echo " 100 + 100 + 100 " | $@ -m num -n 1500 -p od | grep -q " 101 " || exit 1 4 | 5 | -------------------------------------------------------------------------------- /tests/run: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | echo "Testing $@:" 4 | 5 | rm tmp/* > /dev/null 2>&1 6 | 7 | fail() { 8 | echo "ERROR - " $@ 9 | exit 1 10 | } 11 | 12 | for file in tests/*.sh 13 | do 14 | echo -n " o $file: " 15 | EXIT=0 16 | for try in $(seq 40); 17 | do 18 | $file $@ 19 | EXIT=$? 20 | test $EXIT -eq 0 && break; 21 | done 22 | test $EXIT -eq 0 || { echo "ERROR"; fail "test $file fails"; } 23 | echo "ok" 24 | done 25 | 26 | -------------------------------------------------------------------------------- /tests/seek.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | set -e 4 | 5 | SEED=$RANDOM 6 | 7 | echo "HAL 9000" | $@ --seed $SEED -o tmp/seek-1-%n -n 20 8 | echo "HAL 9000" | $@ --seed $SEED -o tmp/seek-2-%n --seek 19 -n 2 9 | 10 | echo "HAL 9000" | $@ --seed $SEED -o tmp/seek-2-%n --seek 10 11 | 12 | cmp tmp/seek-1-10 tmp/seek-2-10 || exit 1 13 | cmp tmp/seek-1-19 tmp/seek-2-19 || exit 1 14 | cmp tmp/seek-1-20 tmp/seek-2-20 || exit 1 15 | 16 | test -f tmp/seek-2-18 && exit 2 17 | test -f tmp/seek-2-21 && exit 2 18 | 19 | rm tmp/seek-* 20 | -------------------------------------------------------------------------------- /tests/sr.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | echo aa | $@ -p od -m sr | grep -q aaa || exit 1 4 | 5 | -------------------------------------------------------------------------------- /tests/tcp-client.sh_: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | $@ -o 127.0.0.1:31337 -n 10 --seed 42 tests/* & 4 | 5 | PID=$! 6 | 7 | sleep 0.3 8 | 9 | kill -0 $PID || exit 1 10 | 11 | for foo in $(seq 10) 12 | do 13 | nc -l -p 31337 || break 14 | done | md5sum > tmp/tcp-a 15 | 16 | $@ -o - -n 10 --seed 42 tests/* | md5sum > tmp/tcp-b 17 | 18 | kill -0 $PID 2>/dev/null && { kill -9 $PID; exit 1; } 19 | 20 | cmp tmp/tcp-a tmp/tcp-b || exit 1 21 | -------------------------------------------------------------------------------- /tests/tcp-serve.sh_: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | $@ -o :31337 -n 10 --seed 42 tests/* & 4 | sleep 0.3 5 | 6 | while true 7 | do 8 | nc localhost 31337 < /dev/null || break 9 | done | md5sum > tmp/tcp-a 10 | $@ -o - -n 10 --seed 42 tests/* | md5sum > tmp/tcp-b 11 | 12 | cmp tmp/tcp-a tmp/tcp-b || exit 1 13 | -------------------------------------------------------------------------------- /tests/tr.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | echo "(x (Y x))" | $@ -p od -m tr -n 50 | grep -q "(x (x (x (x (Y x)))))" || exit 1 4 | 5 | -------------------------------------------------------------------------------- /tests/tr2.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | echo '(a) (b)' | $@ -m tr2 -p od -n 30 | sort 2>/dev/null | uniq | wc -l | grep -q 2 || exit 1 4 | 5 | -------------------------------------------------------------------------------- /tests/ts1.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | echo 'A (a) (b) (c) B' | $@ -m ts1 -p od -n 400 | sort 2>/dev/null | uniq | wc -l | grep -q 6 || exit 1 4 | 5 | -------------------------------------------------------------------------------- /tests/ts2.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | echo '(a) (b (c))' | $@ -m ts2 -p od -n 30 | sort 2>/dev/null | uniq | wc -l | grep -q 3 || exit 1 4 | 5 | -------------------------------------------------------------------------------- /tests/uniq.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | set -e 4 | echo "HAL 9000" | $@ -o tmp/uniq-%n -n 100 -p od -m num -u 5 | test 0 = $(md5sum tmp/uniq-* | sed -e 's/ .*//' | sort | uniq -c | grep -v " 1 " | wc -l) 6 | rm tmp/uniq-* 7 | -------------------------------------------------------------------------------- /tests/xpd.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | # check that xml node duplication (or repetition) works 4 | 5 | echo 'x bar y' | $@ -m xp -p od -n 100 | grep -q 'x barbar y' || exit 1 6 | -------------------------------------------------------------------------------- /tests/xpi.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | # check that xml node insertion learns attributes 4 | 5 | echo ' hai' > tmp/xpi-$$-1 6 | echo ' hoi' > tmp/xpi-$$-2 7 | 8 | $@ -n 100 -m xp -p od tmp/xpi-$$-* | grep -q '' || exit 1 9 | 10 | rm tmp/xpi-$$-* 11 | -------------------------------------------------------------------------------- /tests/xpn.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | # check that xml attributes get likely desired number values occasionally 4 | 5 | echo '' | $@ -m xp -p od -n 2000 | grep -q 6553 || exit 1 6 | 7 | -------------------------------------------------------------------------------- /tests/xpp.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | # check that xml node path copying happens 4 | 5 | echo 'bar' | $@ -m xp -p od -n 100 | grep -q '.*bar.*<\/foo><\/foo><\/foo>' || exit 1 6 | -------------------------------------------------------------------------------- /tests/xps.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | # check that xml node swapping works 4 | 5 | echo 'X A Y B Z' | $@ -m xp -n 100 | grep -q 'X B<\/bar> Y A<\/foo> Z' || exit 1 6 | 7 | --------------------------------------------------------------------------------