shellphish_afl - difference in afl-fuzz file when compiling manually - Githubissues

angr / wheels

Wheels for speeding up builds and helping people out.

BSD 2-Clause "Simplified" License

7 stars 4 forks source link

shellphish_afl - difference in afl-fuzz file when compiling manually #2

Open lzina opened 5 years ago

lzina commented 5 years ago

Hi,

I installed shellphish_afl-1.2.1-py2.py3-none-manylinux1_x86_64.whl in order to run shellphish/fuzzer and it works as expected.

For optimization issues, I want to edit the afl-fuzz.c file. However, when I download shellphish_afl (i tried both 1.1/1.2.1), run setup.py to compile files, create the same folders architecture, and actually replace afl-fuzz in afl-unix , the shellphish/fuzzer does not work as expected. Below is the error I get:

[0;36mafl-fuzz [1;97m2.52b[0m by <lcamtuf@google.com>
[1;92m[+] [0mLooks like we're not running on a tty, so I'll be a bit less verbose.[0m
[1;92m[+] [0mYou have 3 CPU cores and 4 runnable tasks (utilization: 133%).[0m
[1;94m[*] [0mChecking CPU core loadout...[0m
[1;92m[+] [0mFound a free CPU core, binding to #0.[0m
[1;94m[*] [0mChecking core_pattern...[0m
[1;94m[*] [0mSetting up output directories...[0m
[1;94m[*] [0mScanning '/dev/shm/work/Palindrome/input'...[0m
[1;92m[+] [0mNo auto-generated dictionary tokens to reuse.[0m
[1;94m[*] [0mCreating hard links for all input files...[0m
[1;94m[*] [0mValidating target binary...[0m
[1;94m[*] [0mAttempting dry run with 'id:000000,orig:seed-0'...[0m
[1;94m[*] [0mSpinning up the fork server...[0m

[1;91m[-] [0mHmm, looks like the target binary terminated before we could complete a
    handshake with the injected code. Perhaps there is a horrible bug in the
    fuzzer. Poke <lcamtuf@coredump.cx> for troubleshooting tips.
)B[?25h[0m[1;91m
[-] PROGRAM ABORT : [1;97mFork server handshake failed[1;91m
         Location : [0minit_forkserver(), afl-fuzz.c:2253

Attached both afl-fuzz exec files: afl-fuzz.zip

I read the setup.py, build.sh etc. and didn't see any special command or relevant path that should cause the problem.

Maybe one of you can think about any idea?

Thanks!!

lzina commented 5 years ago

As I see, the issue is remarked as a bug, Will it be fixed soon? and actually, what is the bug?

lzina commented 5 years ago

I found the problem!

If you choose to compile the afl-fuzz.c by yourself, be aware to the fact that you also need to replace the afl-qemu-trace in the relevant ARCHES under afl-unix/tracers .

For example I built the qemu-2.10.0 with build_qemu_support.sh and replaced the afl-qemu-trace file in both ~/venv/bin/afl-unix/tracers/i386 and ~/venv/bin/afl-unix/tracers/x86_64 accordingly.

rhelmot commented 5 years ago

@zardus can you assign this to one of your students?

lzina commented 5 years ago

what do you mean "assign this to one of your students"? assign what?

On Mon, May 20, 2019 at 9:14 PM Audrey Dutcher notifications@github.com wrote:

@zardus https://github.com/zardus can you assign this to one of your students?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/angr/wheels/issues/2?email_source=notifications&email_token=AH5H5EUXEQMR2OBHIMQJCWLPWLS7TA5CNFSM4HN4PTA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVZUU2Y#issuecomment-494094955, or mute the thread https://github.com/notifications/unsubscribe-auth/AH5H5EUQF34P23Y36625LXLPWLS7TANCNFSM4HN4PTAQ .

zardus commented 5 years ago

My interpretation of this issue is that we just need to make sure repackage shellphish-afl whenever we repackage shellphish-qemu. Once people start manually in custom ways, I'd say they're on their own.