metalnem / sharpfuzz Goto Github PK
View Code? Open in Web Editor NEWAFL-based fuzz testing for .NET
License: MIT License
AFL-based fuzz testing for .NET
License: MIT License
Hello! I am trying to run Jil example, but it fails with message:
$ afl-fuzz -i corpus -o findings -t 5000 -m 10000 dotnet bin/Debug/net6.0/fuzzer.dll
afl-fuzz 2.52b by <[email protected]>
[+] You have 12 CPU cores and 2 runnable tasks (utilization: 17%).
[+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt.
[*] Checking CPU core loadout...
[+] Found a free CPU core, binding to #0.
[*] Checking core_pattern...
[*] Checking CPU scaling governor...
[*] Setting up output directories...
[*] Scanning 'corpus'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...
[*] Validating target binary...
[*] Attempting dry run with 'id:000000,orig:1.json'...
[*] Spinning up the fork server...
[+] All right - fork server is up.
[-] PROGRAM ABORT : No instrumentation detected
Location : perform_dry_run(), afl-fuzz.c:2860
My environment - fresh ubuntu 22.04 container with patched AFL 2.52b and dotnet:
$ dotnet --info
.NET SDK (reflecting any global.json):
Version: 6.0.113
Commit: 4a23b50f97
Runtime Environment:
OS Name: ubuntu
OS Version: 22.04
OS Platform: Linux
RID: ubuntu.22.04-x64
Base Path: /usr/lib/dotnet/sdk/6.0.113/
global.json file:
Not found
Host:
Version: 6.0.13
Architecture: x64
Commit: 1af80ba017
.NET SDKs installed:
6.0.113 [/usr/lib/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.13 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.13 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]
My csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<Reference Include="Jil">
<HintPath>Jil.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
<PackageReference Include="SharpFuzz" Version="2.0.1" />
<PackageReference Include="Sigil" Version="4.7.0" />
</ItemGroup>
</Project>
Jil.dll
are instrumented through sharpfuzz jil.2.16.0/lib/netstandard2.0/Jil.dll
and are copied to the root of the project.
Program.cs
is the same as in the example.
What have I missed? Thank you!
Trying to use this on a html to pdf library (https://www.nuget.org/packages/IronPdf/) and got this error:
uname -a :
Linux 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
dotnet version : 8.0.100
sharpfuzz version:
Package Id Version Commands
-------------------------------------------------
sharpfuzz.commandline 2.1.1 sharpfuzz
dnlib.DotNet.Writer.ModuleWriterException: Error calculating max stack value. If the method's obfuscated, set CilBody.KeepOldMaxStack or MetadataOptions.Flags (KeepOldMaxStack, global option) to ignore this error. Otherwise fix your generated CIL code so it conforms to the ECMA standard. Error occurred after metadata event BeginWriteMethodBodies during writing method 'System.Uri IronPdf.Engines.ErrorChecking::CheckBaseUri(System.Uri)' (0x0600050B).
at dnlib.DotNet.DummyLogger.Log(Object sender, LoggerEvent loggerEvent, String format, Object[] args)
at dnlib.DotNet.Writer.ModuleWriterBase.dnlib.DotNet.ILogger.Log(Object sender, LoggerEvent loggerEvent, String format, Object[] args)
at dnlib.DotNet.Writer.Metadata.Error(String message, Object[] args)
at dnlib.DotNet.Writer.Metadata.dnlib.DotNet.Writer.IWriterError.Error(String message)
at dnlib.DotNet.Writer.MethodBodyWriter.ErrorImpl(String message)
at dnlib.DotNet.Writer.MethodBodyWriterBase.Error(String message)
at dnlib.DotNet.Writer.MethodBodyWriterBase.GetMaxStack()
at dnlib.DotNet.Writer.MethodBodyWriter.Write()
at dnlib.DotNet.Writer.Metadata.WriteMethodBodies()
at dnlib.DotNet.Writer.Metadata.Create()
at dnlib.DotNet.Writer.Metadata.CreateTables()
at dnlib.DotNet.Writer.ModuleWriter.WriteImpl()
at dnlib.DotNet.Writer.ModuleWriterBase.Write(Stream dest)
at dnlib.DotNet.ModuleDef.Write(Stream dest, ModuleWriterOptions options)
at SharpFuzz.Fuzzer.Instrument(ModuleDefMD src, Stream dst, Func`2 matcher, Boolean enableOnBranchCallback, TypeDef traceType) in /root/KashX/tools/fuzzing/sharpfuzz/src/SharpFuzz/Fuzzer.cs:line 144
at SharpFuzz.Fuzzer.Instrument(String source, Func`2 matcher, Options options) in /root/KashX/tools/fuzzing/sharpfuzz/src/SharpFuzz/Fuzzer.cs:line 89
at SharpFuzz.CommandLine.Program.Main(String[] args) in /root/KashX/tools/fuzzing/sharpfuzz/src/SharpFuzz.CommandLine/Program.cs:line 69
Failed to instrument the specified file, most likely because it's not a valid .NET assembly.
Any ideas? Looks like others have ran into this during decompilation and found solutions: https://stackoverflow.com/questions/58926381/setting-cilbody-keepoldmaxstack-or-metadataoptions-flags
Hi! I have a question about these lines:
What is data here? And why don't you work with stream like this:And second question: I can not find place (in sharpfuzz for windows) where you fill bitmap with run information. Can you show me it?
Thank you for replies!
Hello,
As stated in https://github.com/Metalnem/sharpfuzz/blob/master/docs/libFuzzer.md support for mac and windows is coming soon. What is the status of this? What is needed to do this, any way one could help?
Hi,
Saw the note on the front page about trophies, so in case you're interested:
I tried running OpenMcdf through SharpFuzz, and it generated a few files that caused ArgumentOutOfRangeException and 2 that caused OutOfMemoryException:
ironfede/openmcdf#40
ironfede/openmcdf#39
ironfede/openmcdf#38
ironfede/openmcdf#30 (generated a file that repros a known issue that had no test case attached).
Thanks for the nice tool :-)
https://github.com/sebastienros/fluid
I should probably make a PR. Or start fixing the issues you have already opened on my other projects ;) (thanks by the way)
Hi! Im trying to write a simple fuzz target and then to compile it using mcs
(or csc
) to mono .exe, but i don't know how to link Sharpfuzz library. It writes:
Program.cs(17,7): error CS0246: The type or namespace name `SharpFuzz' could not be found. Are you missing an assembly reference?
How to link Sharpfuzz properly to my fuzz traget?
On MacOS trying to run instrumented assembly causes it to crash with SIGABRT.
mkdir repro; cd repro; dotnet new console
Program.cs
):using System;
using SharpFuzz;
namespace repro
{
class Program
{
static void Main(string[] args)
{
Fuzzer.Run((stream) => {
Repro((byte)stream.ReadByte());
});
}
static void Repro(byte x) {
if (x == 97) {
throw new Exception(":(");
} else {
Console.WriteLine("Woozy!");
}
}
}
}
dotnet add package SharpFuzz
dotnet build
sharpfuzz ./bin/Debug/netcoreapp2.2/repro.dll
afl-fuzz
or just running the instrumented program with dotnet
then results in a SIGABRT crash. lldb dump:(lldb) target create "dotnet"
Current executable set to 'dotnet' (x86_64).
(lldb) settings set -- target.run-args "./bin/Debug/netcoreapp2.2/repro.dll"
(lldb) run
Process 33285 launched: '/usr/local/bin/dotnet' (x86_64)
Process 33285 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x00007fff6b9022c6 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
-> 0x7fff6b9022c6 <+10>: jae 0x7fff6b9022d0 ; <+20>
0x7fff6b9022c8 <+12>: movq %rax, %rdi
0x7fff6b9022cb <+15>: jmp 0x7fff6b8fc457 ; cerror_nocancel
0x7fff6b9022d0 <+20>: retq
Target 0: (dotnet) stopped.
(lldb) bt all
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
* frame #0: 0x00007fff6b9022c6 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007fff6b9bdbf1 libsystem_pthread.dylib`pthread_kill + 284
frame #2: 0x00007fff6b86c6a6 libsystem_c.dylib`abort + 127
frame #3: 0x000000010205684e libcoreclr.dylib`PROCAbort + 14
frame #4: 0x0000000102054cf2 libcoreclr.dylib`PROCEndProcess(void*, unsigned int, int) + 226
frame #5: 0x000000010224a5e9 libcoreclr.dylib`SafeExitProcess(unsigned int, int, ShutdownCompleteAction) + 489
frame #6: 0x000000010224bea7 libcoreclr.dylib`EEPolicy::HandleFatalError(unsigned int, unsigned long, char16_t const*, _EXCEPTION_POINTERS*, char16_t const*, char16_t const*) + 663
frame #7: 0x0000000102328aaf libcoreclr.dylib`ProcessCLRException + 1535
frame #8: 0x000000010232d146 libcoreclr.dylib`UnwindManagedExceptionPass1(PAL_SEHException&, _CONTEXT*) + 358
frame #9: 0x000000010232d460 libcoreclr.dylib`DispatchManagedException(PAL_SEHException&, bool) + 304
frame #10: 0x00000001023276dd libcoreclr.dylib`HandleHardwareException(PAL_SEHException*) + 669
frame #11: 0x000000010201d7f1 libcoreclr.dylib`SEHProcessException(PAL_SEHException*) + 353
frame #12: 0x000000010205a6a5 libcoreclr.dylib`PAL_DispatchException + 181
frame #13: 0x000000010205a247 libcoreclr.dylib`PAL_DispatchExceptionWrapper + 10
frame #14: 0x00000001090c1b91
frame #15: 0x00000001023b4397 libcoreclr.dylib`CallDescrWorkerInternal + 124
frame #16: 0x000000010221a561 libcoreclr.dylib`MethodDescCallSite::CallTargetWorker(unsigned long const*, unsigned long*, int) + 945
frame #17: 0x00000001020ed106 libcoreclr.dylib`RunMain(MethodDesc*, short, int*, PtrArray**) + 694
frame #18: 0x00000001020ed472 libcoreclr.dylib`Assembly::ExecuteMainMethod(PtrArray**, int) + 402
frame #19: 0x000000010212dea4 libcoreclr.dylib`CorHost2::ExecuteAssembly(unsigned int, char16_t const*, int, char16_t const**, unsigned int*) + 436
frame #20: 0x000000010205f046 libcoreclr.dylib`coreclr_execute_assembly + 230
frame #21: 0x0000000100689388 libhostpolicy.dylib`___lldb_unnamed_symbol948$$libhostpolicy.dylib + 152
frame #22: 0x00000001006727df libhostpolicy.dylib`___lldb_unnamed_symbol752$$libhostpolicy.dylib + 37471
frame #23: 0x0000000100679089 libhostpolicy.dylib`___lldb_unnamed_symbol774$$libhostpolicy.dylib + 297
frame #24: 0x00000001001928a3 libhostfxr.dylib`___lldb_unnamed_symbol928$$libhostfxr.dylib + 451
frame #25: 0x00000001001b25ee libhostfxr.dylib`___lldb_unnamed_symbol1018$$libhostfxr.dylib + 18606
frame #26: 0x00000001001b51c2 libhostfxr.dylib`___lldb_unnamed_symbol1027$$libhostfxr.dylib + 1602
frame #27: 0x00000001001b3678 libhostfxr.dylib`___lldb_unnamed_symbol1025$$libhostfxr.dylib + 1976
frame #28: 0x0000000100193919 libhostfxr.dylib`___lldb_unnamed_symbol931$$libhostfxr.dylib + 297
frame #29: 0x000000010000d052 dotnet`___lldb_unnamed_symbol58$$dotnet + 7842
frame #30: 0x000000010000d645 dotnet`___lldb_unnamed_symbol60$$dotnet + 165
frame #31: 0x00007fff6b7c73d5 libdyld.dylib`start + 1
frame #32: 0x00007fff6b7c73d5 libdyld.dylib`start + 1
thread #2
frame #0: 0x00007fff6b8fc22a libsystem_kernel.dylib`mach_msg_trap + 10
frame #1: 0x00007fff6b8fc76c libsystem_kernel.dylib`mach_msg + 60
frame #2: 0x000000010205b8c8 libcoreclr.dylib`MachMessage::Receive(unsigned int) + 72
frame #3: 0x000000010205a81e libcoreclr.dylib`SEHExceptionThread(void*) + 94
frame #4: 0x00007fff6b9bb2eb libsystem_pthread.dylib`_pthread_body + 126
frame #5: 0x00007fff6b9be249 libsystem_pthread.dylib`_pthread_start + 66
frame #6: 0x00007fff6b9ba40d libsystem_pthread.dylib`thread_start + 13
thread #3
frame #0: 0x00007fff6b90436e libsystem_kernel.dylib`poll + 10
frame #1: 0x000000010204da1e libcoreclr.dylib`CorUnix::CPalSynchronizationManager::ThreadPrepareForShutdown() + 30
frame #2: 0x000000010204f550 libcoreclr.dylib`CorUnix::CPalSynchronizationManager::WorkerThread(void*) + 944
frame #3: 0x0000000102058218 libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 328
frame #4: 0x00007fff6b9bb2eb libsystem_pthread.dylib`_pthread_body + 126
frame #5: 0x00007fff6b9be249 libsystem_pthread.dylib`_pthread_start + 66
frame #6: 0x00007fff6b9ba40d libsystem_pthread.dylib`thread_start + 13
thread #4
frame #0: 0x00007fff6b8fd1ee libsystem_kernel.dylib`__open + 10
frame #1: 0x00000001020cb3ff libcoreclr.dylib`TwoWayPipe::WaitForConnection() + 31
frame #2: 0x00000001020c2e11 libcoreclr.dylib`DbgTransportSession::TransportWorker() + 177
frame #3: 0x00000001020c1759 libcoreclr.dylib`DbgTransportSession::TransportWorkerStatic(void*) + 9
frame #4: 0x0000000102058218 libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 328
frame #5: 0x00007fff6b9bb2eb libsystem_pthread.dylib`_pthread_body + 126
frame #6: 0x00007fff6b9be249 libsystem_pthread.dylib`_pthread_start + 66
frame #7: 0x00007fff6b9ba40d libsystem_pthread.dylib`thread_start + 13
thread #5
frame #0: 0x00007fff6b8ff86a libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff6b9be56e libsystem_pthread.dylib`_pthread_cond_wait + 722
frame #2: 0x000000010204d712 libcoreclr.dylib`CorUnix::CPalSynchronizationManager::ThreadNativeWait(CorUnix::_ThreadNativeWaitData*, unsigned int, CorUnix::ThreadWakeupReason*, unsigned int*) + 338
frame #3: 0x000000010204d327 libcoreclr.dylib`CorUnix::CPalSynchronizationManager::BlockThread(CorUnix::CPalThread*, unsigned int, bool, bool, CorUnix::ThreadWakeupReason*, unsigned int*) + 375
frame #4: 0x0000000102051ca3 libcoreclr.dylib`CorUnix::InternalWaitForMultipleObjectsEx(CorUnix::CPalThread*, unsigned int, void* const*, int, unsigned int, int, int) + 1891
frame #5: 0x0000000102051f32 libcoreclr.dylib`WaitForMultipleObjectsEx + 82
frame #6: 0x00000001020bfb98 libcoreclr.dylib`DebuggerRCThread::MainLoop() + 264
frame #7: 0x00000001020bfa2b libcoreclr.dylib`DebuggerRCThread::ThreadProc() + 251
frame #8: 0x00000001020bf734 libcoreclr.dylib`DebuggerRCThread::ThreadProcStatic(void*) + 132
frame #9: 0x0000000102058218 libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 328
frame #10: 0x00007fff6b9bb2eb libsystem_pthread.dylib`_pthread_body + 126
frame #11: 0x00007fff6b9be249 libsystem_pthread.dylib`_pthread_start + 66
frame #12: 0x00007fff6b9ba40d libsystem_pthread.dylib`thread_start + 13
thread #6
frame #0: 0x00007fff6b8ff86a libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff6b9be56e libsystem_pthread.dylib`_pthread_cond_wait + 722
frame #2: 0x000000010204d6d5 libcoreclr.dylib`CorUnix::CPalSynchronizationManager::ThreadNativeWait(CorUnix::_ThreadNativeWaitData*, unsigned int, CorUnix::ThreadWakeupReason*, unsigned int*) + 277
frame #3: 0x000000010204d327 libcoreclr.dylib`CorUnix::CPalSynchronizationManager::BlockThread(CorUnix::CPalThread*, unsigned int, bool, bool, CorUnix::ThreadWakeupReason*, unsigned int*) + 375
frame #4: 0x0000000102051ca3 libcoreclr.dylib`CorUnix::InternalWaitForMultipleObjectsEx(CorUnix::CPalThread*, unsigned int, void* const*, int, unsigned int, int, int) + 1891
frame #5: 0x0000000102051e6d libcoreclr.dylib`WaitForSingleObjectEx + 77
frame #6: 0x00000001022fb6ee libcoreclr.dylib`CLREventBase::WaitEx(unsigned int, WaitMode, PendingSync*) + 206
frame #7: 0x00000001022647df libcoreclr.dylib`FinalizerThread::WaitForFinalizerEvent(CLREvent*) + 31
frame #8: 0x0000000102264953 libcoreclr.dylib`FinalizerThread::FinalizerThreadWorker(void*) + 115
frame #9: 0x00000001021ddf23 libcoreclr.dylib`ManagedThreadBase_DispatchOuter(ManagedThreadCallState*) + 419
frame #10: 0x00000001021de5c9 libcoreclr.dylib`ManagedThreadBase::FinalizerBase(void (*)(void*)) + 73
frame #11: 0x0000000102264c6c libcoreclr.dylib`FinalizerThread::FinalizerThreadStart(void*) + 204
frame #12: 0x0000000102058218 libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 328
frame #13: 0x00007fff6b9bb2eb libsystem_pthread.dylib`_pthread_body + 126
frame #14: 0x00007fff6b9be249 libsystem_pthread.dylib`_pthread_start + 66
frame #15: 0x00007fff6b9ba40d libsystem_pthread.dylib`thread_start + 13
thread #7
frame #0: 0x00007fff6b8fc22a libsystem_kernel.dylib`mach_msg_trap + 10
frame #1: 0x00007fff6b8fc76c libsystem_kernel.dylib`mach_msg + 60
frame #2: 0x0000000103642e68 libclrjit.dylib`MachMessage::Receive(unsigned int) + 72
frame #3: 0x0000000103641dbe libclrjit.dylib`SEHExceptionThread(void*) + 94
frame #4: 0x00007fff6b9bb2eb libsystem_pthread.dylib`_pthread_body + 126
frame #5: 0x00007fff6b9be249 libsystem_pthread.dylib`_pthread_start + 66
frame #6: 0x00007fff6b9ba40d libsystem_pthread.dylib`thread_start + 13
thread #8
frame #0: 0x00007fff6b8ff86a libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff6b9be56e libsystem_pthread.dylib`_pthread_cond_wait + 722
frame #2: 0x000000010204d6d5 libcoreclr.dylib`CorUnix::CPalSynchronizationManager::ThreadNativeWait(CorUnix::_ThreadNativeWaitData*, unsigned int, CorUnix::ThreadWakeupReason*, unsigned int*) + 277
frame #3: 0x000000010204d327 libcoreclr.dylib`CorUnix::CPalSynchronizationManager::BlockThread(CorUnix::CPalThread*, unsigned int, bool, bool, CorUnix::ThreadWakeupReason*, unsigned int*) + 375
frame #4: 0x000000010205232d libcoreclr.dylib`SleepEx + 141
frame #5: 0x0000000102200d16 libcoreclr.dylib`ThreadpoolMgr::TimerThreadFire() + 150
frame #6: 0x0000000102200be5 libcoreclr.dylib`ThreadpoolMgr::TimerThreadStart(void*) + 181
frame #7: 0x0000000102058218 libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 328
frame #8: 0x00007fff6b9bb2eb libsystem_pthread.dylib`_pthread_body + 126
frame #9: 0x00007fff6b9be249 libsystem_pthread.dylib`_pthread_start + 66
frame #10: 0x00007fff6b9ba40d libsystem_pthread.dylib`thread_start + 13
SharpFuzz library version: 1.6.1
sharpfuzz tool version: 1.6.2
dotnet version: 2.2.401
Hi everybody,
I'm pretty new to the world of fuzzing and was trying to test my program with afl.
I've already done tests and trials with afl, especially in Blackbox mode with qemu because my program runs on .NET.
Seeing this repo I wanted to try to use Sharpfuzz with my program, however after several unsuccessful attempts I decided to try to ask you.
First of all my doubt is if Sharpfuzz can be used to test complex programs (in my case it is an Application console program, which runs on .NET Core) because in the examples that I found in this repo, there are only .NET library tests.
In my attempts with Sharpfuzz I still tried to include a main with the Fuzzer.run function which is required, however I keep getting runtime problems, from the method that calls the stream to read what is passed in input.
I'm referring to the function on line 234 of the src/SharpFuzz/Fuzzer.cs :
file using (var stream = new UnclosableStreamWrapper(stdin)).
Since my program reads from files etc I tried different ways to make it work, either by passing the path, or by modifying the code and passing the content directly to stream, however the function fails every time at that particular point.
Finally, the last doubt concerns the instrumentation part of the .dll: in the examples the .dll libraries are obviously instrumented because we want to test them, however in a more complex program, how can I do to instrument those parts of code that I would like to test, if are the various binary .dlls created at compile time?
For this reason I have the doubt that Sharpfuzz is currently only useful for testing .NET libraries.
thanks in advance to whoever will answer me
Hi! Could yo help me and say where timeout does process in your code? I found only crashes processing. Thank you!
Hi,
I have been having the same problems as this closed issue: #16
I've been trying to run the following example from ReadMe I get the following error:
jack@DESKTOP-HPQQTM1:~/test$ afl-fuzz -i testcases -o Findings3 -m none -t 5000 dotnet bin/Debug/netcoreapp2.1/SharpFuzz.dll
afl-fuzz 2.52b by <[email protected]>
[+] You have 16 CPU cores and 1 runnable tasks (utilization: 6%).
[+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt.
[*] Checking CPU core loadout...
[+] Found a free CPU core, binding to #0.
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning 'testcases'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...
[*] Validating target binary...
[*] Attempting dry run with 'id:000000,orig:Test.json'...
[*] Spinning up the fork server...
[-] Hmm, 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 <[email protected]> for troubleshooting tips.
�
[-] PROGRAM ABORT : Fork server handshake failed
Location : init_forkserver(), afl-fuzz.c:2253
From reading the documentation I also tried running afl-fuzzer with the following parameter -Q. Doing it this way does not trow a fork server handshake error but just hangs with Fork Server is Running:
afl-fuzz -i testcases -o Findings3 -m none -t 5000 -Q dotnet bin/Debug/netcoreapp2.1/SharpFuzz.dll
afl-fuzz 2.52b by <[email protected]>
[+] You have 16 CPU cores and 1 runnable tasks (utilization: 6%).
[+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt.
[*] Checking CPU core loadout...
[+] Found a free CPU core, binding to #0.
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning 'testcases'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...
[*] Validating target binary...
[*] Attempting dry run with 'id:000000,orig:Test.json'...
[*] Spinning up the fork server...
[+] All right - fork server is up.
Running this on WSL ubuntu, Any help resolving this problem would be great.
When I run the script:
pwsh ../scripts/fuzz.ps1 myconsole.csproj -i TestCases -x /usr/local/share/afl/dictionaries/json.dict
The AFL aborted:
afl-fuzz 2.52b by <[email protected]>
[+] You have 40 CPU cores and 1 runnable tasks (utilization: 2%).
[+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt.
[*] Checking CPU core loadout...
[+] Found a free CPU core, binding to #0.
[*] Checking core_pattern...
[-] Hmm, your system is configured to send core dump notifications to an
external utility. This will cause issues: there will be an extended delay
between stumbling upon a crash and having this information relayed to the
fuzzer via the standard waitpid() API.
To avoid having crashes misinterpreted as timeouts, please log in as root
and temporarily modify /proc/sys/kernel/core_pattern, like so:
echo core >/proc/sys/kernel/core_pattern
[-] PROGRAM ABORT : Pipe at the beginning of 'core_pattern'
Location : check_crash_handling(), afl-fuzz.c:7275
To fix that I run:
echo core >/proc/sys/kernel/core_pattern
But now I get different error:
afl-fuzz 2.52b by <[email protected]>
[+] You have 40 CPU cores and 1 runnable tasks (utilization: 2%).
[+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt.
[*] Checking CPU core loadout...
[+] Found a free CPU core, binding to #0.
[*] Checking core_pattern...
[*] Setting up output directories...
[*] Scanning 'TestCases'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...
[*] Loading extra dictionary from '/usr/local/share/afl/dictionaries/json.dict' (level 0)...
[+] Loaded 37 extra tokens, size range 1 B to 12 B.
[*] Validating target binary...
[*] Attempting dry run with 'id:000000,orig:Test.txt'...
[*] Spinning up the fork server...
[+] All right - fork server is up.
[-] PROGRAM ABORT : No instrumentation detected
Location : perform_dry_run(), afl-fuzz.c:2860
I am still searching for a fix but maybe you will have one.
myconsole.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net7.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="SharpFuzz" Version="2.1.1" />
</ItemGroup>
</Project>
DotNet info
# dotnet --info
.NET SDK:
Version: 7.0.110
Commit: ba920f88ac
Runtime Environment:
OS Name: ubuntu
OS Version: 22.04
OS Platform: Linux
RID: ubuntu.22.04-x64
Base Path: /usr/lib/dotnet/sdk/7.0.110/
Host:
Version: 7.0.10
Architecture: x64
Commit: a6dbb800a4
.NET SDKs installed:
7.0.110 [/usr/lib/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 7.0.10 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 7.0.10 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]
Other architectures found:
None
Environment variables:
Not set
global.json file:
Not found
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download
When trying to install on Ubuntu 16.04 LTS with dotnet version 2.1.200:
sudo dotnet tool install --global SharpFuzz.CommandLine --version 1.6.2
I get the following error:
The settings file in the tool's NuGet package is invalid: Settings file 'DotnetToolSettings.xml' was not found in the package.
Tool 'sharpfuzz.commandline' failed to install. Please contact the tool author for assistance.
I'm seeing this error quite often with the Jil example:
[-] PROGRAM ABORT : Unable to communicate with fork server (OOM?)
Location : run_target(), afl-fuzz.c:2417
I'm using AFL 2.56b, With dotnet 3.0. My csproj-file contains this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Reference Include="Jil">
<HintPath>Jil.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
<PackageReference Include="SharpFuzz" Version="1.6.1" />
<PackageReference Include="Sigil" Version="5.0.0" />
</ItemGroup>
</Project>
I've checked the .cur_input
file, but when I add it to the testcases for the next run, it does not lead to a crash, so I'm guessing there is an other issue. In addition, when monitoring the memory usage there does not seem to be happening out of the ordinary: the process simply dies (disappears from top
)
Can you help me investigate?
Hi.
I tried to build AFL from the instruction from readme, but it's failed. I'm on MacOS.
Build logs:
➜ afl-2.52b patch < RemoveInstrumentationCheck.diff
patching file afl-fuzz.c
➜ afl-2.52b make
[*] Checking for the ability to compile x86 code...
[+] Everything seems to be working, ready to compile.
cc -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DDOC_PATH=\"/usr/local/share/doc/afl\" -DBIN_PATH=\"/usr/local/bin\" afl-gcc.c -o afl-gcc
set -e; for i in afl-g++ afl-clang afl-clang++; do ln -sf afl-gcc $i; done
cc -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DDOC_PATH=\"/usr/local/share/doc/afl\" -DBIN_PATH=\"/usr/local/bin\" afl-fuzz.c -o afl-fuzz
cc -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DDOC_PATH=\"/usr/local/share/doc/afl\" -DBIN_PATH=\"/usr/local/bin\" afl-showmap.c -o afl-showmap
cc -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DDOC_PATH=\"/usr/local/share/doc/afl\" -DBIN_PATH=\"/usr/local/bin\" afl-tmin.c -o afl-tmin
cc -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DDOC_PATH=\"/usr/local/share/doc/afl\" -DBIN_PATH=\"/usr/local/bin\" afl-gotcpu.c -o afl-gotcpu
cc -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DDOC_PATH=\"/usr/local/share/doc/afl\" -DBIN_PATH=\"/usr/local/bin\" afl-analyze.c -o afl-analyze
cc -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DDOC_PATH=\"/usr/local/share/doc/afl\" -DBIN_PATH=\"/usr/local/bin\" afl-as.c -o afl-as
ln -sf afl-as as
[*] Testing the CC wrapper and instrumentation output...
unset AFL_USE_ASAN AFL_USE_MSAN; AFL_QUIET=1 AFL_INST_RATIO=100 AFL_PATH=. ./afl-clang -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DDOC_PATH=\"/usr/local/share/doc/afl\" -DBIN_PATH=\"/usr/local/bin\" test-instr.c -o test-instr
echo 0 | ./afl-showmap -m none -q -o .test-instr0 ./test-instr
echo 1 | ./afl-showmap -m none -q -o .test-instr1 ./test-instr
Oops, the instrumentation does not seem to be behaving correctly!
Please ping <[email protected]> to troubleshoot the issue.
make: *** [test_build] Error 1
➜ afl-2.52b export AFL_SKIP_BIN_CHECK=1
➜ afl-2.52b make
[*] Checking for the ability to compile x86 code...
[+] Everything seems to be working, ready to compile.
[*] Testing the CC wrapper and instrumentation output...
unset AFL_USE_ASAN AFL_USE_MSAN; AFL_QUIET=1 AFL_INST_RATIO=100 AFL_PATH=. ./afl-clang -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DDOC_PATH=\"/usr/local/share/doc/afl\" -DBIN_PATH=\"/usr/local/bin\" test-instr.c -o test-instr
echo 0 | ./afl-showmap -m none -q -o .test-instr0 ./test-instr
echo 1 | ./afl-showmap -m none -q -o .test-instr1 ./test-instr
Oops, the instrumentation does not seem to be behaving correctly!
Please ping <[email protected]> to troubleshoot the issue.
make: *** [test_build] Error 1
Hello,
great project!
I was trying your example and I it did not work. I have noticed the code reading environmental variable __AFL_SHM_ID
value to decide whether to run with/without AFL.
Can you tell me what should be the variable of __AFL_SHM_ID
be?
Thanks.
Karel
I am getting stuck on the following issue:
_[-] PROGRAM ABORT : Fork server handshake failed
Location : init_forkserver(), afl-fuzz.c:2253_
I'm using AFL 2.56b, With dotnet 3.1.202 in parrot OS 4.7. My csproj-file contains this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Reference Include="Jil">
<HintPath>Jil.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
<PackageReference Include="SharpFuzz" Version="1.6.2" />
<PackageReference Include="Sigil" Version="4.7.0" />
</ItemGroup>
</Project>
Command I used : [_afl-fuzz -i testcases_dir -o findings_dir -t 5000 -m 10000 dotnet path_to_assembly_](url)
Following is result after the command
[+] You have 4 CPU cores and 3 runnable tasks (utilization: 75%).
[+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt.
[*] Checking CPU core loadout...
[+] Found a free CPU core, binding to #0.
[*] Checking core_pattern...
[*] Checking CPU scaling governor...
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning 'Testcases'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...
[*] Validating target binary...
[*] Attempting dry run with 'id:000000,orig:test.json'...
[*] Spinning up the fork server...
[-] Hmm, looks like the target binary terminated before we could complete a
handshake with the injected code. There are two probable explanations:
Can you help me to investigate.
AFL++ is much improved version of AFL so it's better to replace AFL with AFL++
Is there currently a way to use afl-showmap on an instrumented .NET DLL? I get "No instrumentation detected" when trying afl-showmap, I also tried running it with AFL_SKIP_BIN_CHECK=1.
If not, are there any potential workarounds to verify edge IDs?
Hello, I see you block them. Is this perhaps due to a hard limitation in Cecil?
I would like to instrument System.Private.Corelib. Is there any workaround you know of?
I've been using your SharpFuzz and finding it quite useful. However, I have a question. It seems like SharpFuzz takes input generated by afl and reports that input if an exception occurs. I'm curious about how afl measures coverage for that input. It seems like afl and SharpFuzz operate as separate processes. If I've misunderstood something, please point it out, and I would appreciate it if you could explain the coverage measurement method used by SharpFuzz.
Thank you.
I've passed all steps up until the instrumentation of lib/netstandard2.0/Jil.dll with fails with this error message:
Failed to instrument the specified file, most likely because it's not a valid .NET assembly.
This is WSL Ubuntu 18.04 LTS using .NET Core 2.2.204
Hi,
I am currently working with sharpFuzz.
I am trying to automate the fuzzing of .net dlls on windows and I noticed a strange behavior of libfuzzer-dotnet-windows.
To test my harness generation I wrote a dll that contains different methods which are recognized as targets. The methods bodies are empty and when I fuzz them I only get pulse as output from libfuzzer as expected.
I then started two instances of libfuzzer, one for Jil (deserializeDynamic) and one for an empty method of my test dll. The libfuzzer that fuzzes the empty method of my test dll then constantly detected new coverage and generated inputs were stored in the corpus. This only happens when running one or more instances of libfuzzer that actually find new coverage.
It looks like the coverage feedback is communicated to all running libfuzzer instances.
When libfuzzer is run in forkmode, it starts several libfuzzer instances which are run in the background, is there the same problem?
My current solution to the problem is to fuzz in containers.
Is this behavior expected?
I am using libfuzzer-dotnet
with sharpfuzz (1.6.1) and the latest version of the command line tool to test some dotnet core code.
Slow units are getting outputted, but no exceptions/crashes are.
I have even modified the system under test to throw an exception, and this is not been caught by the fuzzer?
Hi! I'm encountered a problem with fuzzing C# code that runs native C++ code. I compile my C++ code to .so
file like afl-clang++ native.cpp -fPIC -shared -o native.so
and import it to C# with [DllImport("native.so")]
. After instumenting my assemblies with Sharpfuzz I launch AFL++ and it doesn't fuzz my native code.
Is there any way to fuzz native code that is run from C# code?
I'm trying to run Sharpfuzz on .net framework assemblies, but so far without any luck.
The Usage section on the front page says it should be doable for net45 (As far as I read it).
When compiling my net47 project using mono and running
afl-fuzz -i testcases/ -o output/ ConsoleAppMono/bin/x64/Debug/ConsoleAppMono.exe
I get the following error
[-] PROGRAM ABORT : Program 'ConsoleAppMono/bin/x64/Debug/ConsoleAppMono.exe' is not an ELF binary
Location : check_binary(), src/afl-fuzz-init.c:1891
Do you have any pointers on how to do this, or have I misunderstood it being possible for .net framework assemblies?
Please document hidden features of SharpFuzz.
SHARPFUZZ_PRINT_INSTRUMENTED_TYPES
- self-explanatory, but still undocumented. Displays types and methods instrumented.
SHARPFUZZ_ENABLE_ON_BRANCH_CALLBACK
- seems to just crash the target right away with null pointer exception. Does sharpfuzz NOT instrument branches by default?
Exclude classes you don't want to instrument:
sharpfuzz path/to/some_assembly.dll IncludeFilter -ExcludeFilter
Can filter out multiple matches:
sharpfuzz path/to/some_assembly.dll IncludeFilter -ExcludeFilter,Exclude2,Exclude3
I might have missed something.
It would be great to have a new release published to NuGet, so SharpFuzz could be easily consumed as a package.
Due to the recent breaking changes to the LibFuzzer runner, this should probably be a 2.0 release.
public static string ToString<T>(this IEnumerable<T> source, char separator)
{
return ToString(source, separator.ToString());
}
Our csproj file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Reference Include="Core">
<HintPath>Core.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
<PackageReference Include="SharpFuzz" Version="1.6.2"/>
</ItemGroup>
</Project>
Our Program.cs:
using System;
using System.IO;
using SharpFuzz;
using System.Collections.Generic;
using Core.Utils;
namespace Utils.Fuzz
{
class Program
{
static void Main (string[] args)
{
Fuzzer.Run (stream =>
{
using (var test = new StreamReader(stream))
{
List<string> mas = new List<string> {test.ReadLine(), test.ReadLine()};
StringHelper.ToString<string>( mas, test.ReadLine()[0] );
}
});
}
}
}
Is Sharpfuzz available on windows?
Target:
/root/afl-2.52b/afl-fuzz -i Testcases/ -o Findings/ -t 10000 -m 20480 dotnet bin/target.fuzz.dll
AFL:
[-] Hmm, looks like the target binary terminated before we could complete a
handshake with the injected code. There are two probable explanations:
- The current memory limit (20.0 GB) is too restrictive, causing an OOM
fault in the dynamic linker. This can be fixed with the -m option. A
simple way to confirm the diagnosis may be:
( ulimit -Sv $[20479 << 10]; /path/to/fuzzed_app )
Tip: you can use http://jwilk.net/software/recidivm to quickly
estimate the required amount of virtual memory for the binary.
- Less likely, there is a horrible bug in the fuzzer. If other options
fail, poke <[email protected]> for troubleshooting tips.
[-] PROGRAM ABORT : Fork server handshake failed
Location : init_forkserver(), afl-fuzz.c:2253
Target can only be compiled with dotnet-sdk-7.0
.
AFL++:
[-] Hmm, looks like the target binary terminated before we could complete a
handshake with the injected code. You can try the following:
- The target binary crashes because necessary runtime conditions it needs
are not met. Try to:
1. Run again with AFL_DEBUG=1 set and check the output of the target
binary for clues.
2. Run again with AFL_DEBUG=1 and 'ulimit -c unlimited' and analyze the
generated core dump.
- Possibly the target requires a huge coverage map and has CTORS.
Retry with setting AFL_MAP_SIZE=10000000.
- The current memory limit (21.5G) is too restrictive, causing an OOM
fault in the dynamic linker. This can be fixed with the -m option. A
simple way to confirm the diagnosis may be:
( ulimit -Sd $[20479 << 10]; /path/to/fuzzed_app )
Tip: you can use https://jwilk.net/software/recidivm to
estimate the required amount of virtual memory for the binary.
- The target was compiled with afl-clang-lto and a constructor was
instrumented, recompiling without AFL_LLVM_MAP_ADDR might solve your
problem
- Less likely, there is a horrible bug in the fuzzer. If other options
fail, poke <[email protected]> for troubleshooting tips.
[-] PROGRAM ABORT : Fork server handshake failed
Location : afl_fsrv_start(), src/afl-forkserver.c:1175
I don't think so the patch is still working.
I followed the instructions:
# Install SharpFuzz.CommandLine global .NET tool
dotnet tool install --global SharpFuzz.CommandLine
But when after running the PowerShell script I noticed it doesn't find the command sharpfuzz
.
I checked and it is installed:
root@ubuntu:/sharpfuzz# dotnet tool list -g
Package Id Version Commands
-------------------------------------------------
sharpfuzz.commandline 2.1.1 sharpfuzz
root@ubuntu:/sharpfuzz# ls ~/.dotnet/tools
sharpfuzz
Solution
In my case the dotnet is not in the $PATH
so I just needed to add it:
export PATH="$PATH:$HOME/.dotnet/tools"
source ~/.bashrc
Hi! I am using Casr to analyze program crashes found with Sharpfuzz. But the problem is that Casr analyzes stacktraces reproduced by crashes, but the debug-info in target binary disappears after Sharpfuzz instrumentation. For example:
Stacktrace without Sharpfuzz intrumentation:
Unhandled exception. System.ArgumentException: Global tags must be valid URIs. (Parameter 'value')
at YamlDotNet.Core.TagName..ctor(String value) in /YamlDotNet/YamlDotNet/Core/TagName.cs:line 51
at YamlDotNet.Core.Parser.ParseNode(Boolean isBlock, Boolean isIndentlessSequence) in /YamlDotNet/YamlDotNet/Core/Parser.cs:line 496
at YamlDotNet.Core.Parser.StateMachine() in /YamlDotNet/YamlDotNet/Core/Parser.cs:line 134
at YamlDotNet.Core.Parser.MoveNext() in /YamlDotNet/YamlDotNet/Core/Parser.cs:line 107
at YamlDotNet.Core.ParserExtensions.TryConsume[T](IParser parser, T& event) in /YamlDotNet/YamlDotNet/Core/ParserExtensions.cs:line 58
at YamlDotNet.Serialization.Deserializer.Deserialize(IParser parser, Type type) in /YamlDotNet/YamlDotNet/Serialization/Deserializer.cs:line 131
at YamlDotNet.Serialization.Deserializer.Deserialize(TextReader input, Type type) in /YamlDotNet/YamlDotNet/Serialization/Deserializer.cs:line 108
at YamlDotNet.Serialization.Deserializer.Deserialize(TextReader input) in /YamlDotNet/YamlDotNet/Serialization/Deserializer.cs:line 92
at Program.<>c__DisplayClass0_0.<Main>b__0(Stream stream) in /afl_build_fuzz/ProgramAFL.cs:line 40
at SharpFuzz.Fuzzer.RunWithoutAflFuzz(Action`1 action, Stream stream)
at SharpFuzz.Fuzzer.OutOfProcess.Run(Action`1 action)
at Program.Main(String[] args) in /afl_build_fuzz/ProgramAFL.cs:line 30
Stacktrace after Sharpfuzz intrumentation:
Unhandled exception. System.ArgumentException: Global tags must be valid URIs. (Parameter 'value')
at YamlDotNet.Core.TagName..ctor(String value)
at YamlDotNet.Core.Parser.ParseNode(Boolean isBlock, Boolean isIndentlessSequence)
at YamlDotNet.Core.Parser.StateMachine()
at YamlDotNet.Core.Parser.MoveNext()
at YamlDotNet.Core.ParserExtensions.TryConsume[T](IParser parser, T& event)
at YamlDotNet.Serialization.Deserializer.Deserialize(IParser parser, Type type)
at YamlDotNet.Serialization.Deserializer.Deserialize(TextReader input, Type type)
at YamlDotNet.Serialization.Deserializer.Deserialize(TextReader input)
at Program.<>c__DisplayClass0_0.<Main>b__0(Stream stream) in /afl_build_fuzz/ProgramAFL.cs:line 40
at SharpFuzz.Fuzzer.RunWithoutAflFuzz(Action`1 action, Stream stream)
at SharpFuzz.Fuzzer.OutOfProcess.Run(Action`1 action)
at Program.Main(String[] args) in /afl_build_fuzz/ProgramAFL.cs:line 30
Why is it so? And is it possible for Sharpfuzz not to remove this debug-info? It would be really nice, because it makes crash triage pipeline much easier)
After instrumenting my code with SharpFuzz I get constant System.AccessViolationException
s even without fuzzing.
I don't know what exactly causes it, but it seems to always happen in constructors.
I have prepared a tiny reproducer app.
Reproduce:
FuzzMe
is an application under test and the FuzzMe.Fuzz
is the fuzzing harness.tar zxvf reproduce.tar.gz
FuzzMe.Fuzz
app. No errors should pop up:cd reproduce/tests/FuzzMe.Fuzz
dotnet publish -c Release --self-contained -r linux-x64
FuzzMe.Fuzz
app raises no exceptions:echo test | ./bin/Release/net6.0/linux-x64/FuzzMe.Fuzz
FuzzMe*
classes within the FuzzMe.dll
with SharpFuzz:export SHARPFUZZ_PRINT_INSTRUMENTED_TYPES=1
sharpfuzz ./bin/Release/net6.0/linux-x64/FuzzMe.dll FuzzMe
It should print:
FuzzMe.Parser
FuzzMe.Point
FuzzMe.Program
echo test | ./bin/Release/net6.0/linux-x64/FuzzMe.Fuzz
The output looks like this:
Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at FuzzMe.Point..ctor(Int32, Int32)
at FuzzMe.Fuzz.Program.Main(System.String[])
Aborted (core dumped)
The exit code is 134.
The SharpFuzz dependency is 2.0.1 and the SharpFuzz.CommandLine tool is also 2.0.1.
There are private
/protected
readonly
fields in the constructors of Point and Parser classes, but changing them to public
(and without readonly
) changes nothing.
Is there some limitation in SharpFuzz regarding constructors? The real code I wish to test has lots of them.
I tried one example but nothing happened it just hangs, hard to understand if it's doing something or not, there are no logs that say success or else to indicate that it's doing something and what is the progress.
scripts/fuzz-libfuzzer.ps1 `
>> -libFuzzer ".\libfuzzer-dotnet-windows.exe" `
>> -project Newtonsoft.Json.Fuzz.csproj `
>> -corpus Testcases
MSBuild version 17.6.3+07e294721 for .NET
Determining projects to restore...
All projects are up-to-date for restore.
Newtonsoft.Json.Fuzz -> sharpfuzz-samples\src\Newtonsoft.Json\bin\release\net7.0\Newtonsoft.Json.Fuzz.dll
Newtonsoft.Json.Fuzz -> sharpfuzz-samples\src\Newtonsoft.Json\bin\
Instrumenting Newtonsoft.Json.dll
WARNING: Failed to find function "__sanitizer_acquire_crash_state".
WARNING: Failed to find function "__sanitizer_print_stack_trace".
WARNING: Failed to find function "__sanitizer_set_death_callback".
Hi,
In case you're interested:
I tried running PDF Clown through sharpfuzz a while ago and it generated a .pdf file that causes a StackOverflowException on open, but as that library is unsupported I didn't do anything with it.
However, I more recently tried opening that same file in PdfPig and found it also causes a StackOverflowException there - UglyToad/PdfPig#33 - so a pair of bugs with one file.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.