{"id":288,"date":"2025-12-22T14:28:33","date_gmt":"2025-12-22T14:28:33","guid":{"rendered":"https:\/\/haco.club\/?p=288"},"modified":"2025-12-22T14:31:16","modified_gmt":"2025-12-22T14:31:16","slug":"afl-coverage-instrumentation-callback","status":"publish","type":"post","link":"https:\/\/haco.club\/?p=288","title":{"rendered":"AFL Coverage Instrumentation Callback"},"content":{"rendered":"\n
0000000000000bc0 <bbCallback>:\nbc0:\t90000102 \tadrp\tx2, 20000 <_exit@GLIBC_2.17>\nbc4:\tf9404c43 \tldr\tx3, [x2, #152]\nbc8:\tb4000263 \tcbz\tx3, c14 <bbCallback+0x54>\nbcc:\td53bd042 \tmrs\tx2, tpidr_el0\nbd0:\ta9bf7bfd \tstp\tx29, x30, [sp, #-16]!\nbd4:\t12003c01 \tand\tw1, w0, #0xffff\nbd8:\t910003fd \tmov\tx29, sp\nbdc:\t90000100 \tadrp\tx0, 20000 <_exit@GLIBC_2.17>\nbe0:\tf9403404 \tldr\tx4, [x0, #104]\nbe4:\t9101a000 \tadd\tx0, x0, #0x68\nbe8:\td63f0080 \tblr\tx4\nbec:\t78606844 \tldrh\tw4, [x2, x0]\nbf0:\t53017c25 \tlsr\tw5, w1, #1\nbf4:\t78206845 \tstrh\tw5, [x2, x0]\nbf8:\t4a040021 \teor\tw1, w1, w4\nbfc:\t92403c21 \tand\tx1, x1, #0xffff\nc00:\t38616860 \tldrb\tw0, [x3, x1]\nc04:\t11000400 \tadd\tw0, w0, #0x1\nc08:\t38216860 \tstrb\tw0, [x3, x1]\nc0c:\ta8c17bfd \tldp\tx29, x30, [sp], #16\nc10:\td65f03c0 \tret\nc14:\td65f03c0 \tret\nc18:\td503201f \tnop\nc1c:\td503201f \tnop<\/code><\/pre>\n\n\n\n
This code snippet is an implementation of the AFL (American Fuzzy Lop) coverage instrumentation callback<\/strong> for the AArch64 (ARM64)<\/strong> architecture.<\/p>\n\n\n\n
Specifically, it appears to be the function often named __afl_maybe_log<\/code> or bbCallback<\/code> inserted by the compiler (like afl-gcc<\/code> or afl-clang-fast<\/code>) at the start of basic blocks to track code coverage during fuzzing.<\/p>\n\n\n\n
High-Level Logic<\/h3>\n\n\n\n
The function performs the following standard AFL logic:<\/p>\n\n\n\n
    \n
  1. Check Initialization:<\/strong> Checks if the shared memory bitmap (the “Map”) is initialized.<\/li>\n\n\n\n
  2. Thread Local Storage (TLS):<\/strong> Retrieves a thread-local variable that stores the previous_location<\/code> (ID of the last block visited).<\/li>\n\n\n\n
  3. Edge Calculation:<\/strong> Computes a unique hash for the transition (edge) between the previous block and the current block using: index = current_location ^ previous_location<\/code>.<\/li>\n\n\n\n
  4. Coverage Recording:<\/strong> Increments the counter in the Map at that index<\/code>.<\/li>\n\n\n\n
  5. Update State:<\/strong> Updates previous_location<\/code> to current_location >> 1<\/code> for the next block.<\/li>\n<\/ol>\n\n\n\n
    \n\n\n\n
    Step-by-Step Instruction Breakdown<\/h3>\n\n\n\n
    1. Check if the Map exists<\/h4>\n\n\n\n
    bc0: 90000102   adrp x2, 20000        ; Load page address of global variables\nbc4: f9404c43   ldr  x3, [x2, #152]   ; Load the global pointer `__afl_area_ptr` (the Map) into x3\nbc8: b4000263   cbz  x3, c14          ; If x3 is NULL (0), jump to c14 (return immediately)<\/code><\/pre>\n\n\n\n
      \n
    • The code loads the pointer to the shared memory coverage map. If the fuzzer hasn’t initialized this yet, it simply returns to avoid a crash.<\/li>\n<\/ul>\n\n\n\n
      2. TLS Setup & Context Saving<\/h4>\n\n\n\n
      bcc: d53bd042   mrs  x2, tpidr_el0    ; Move Thread Pointer ID Register (TLS base) into x2\nbd0: a9bf7bfd   stp  x29, x30, [sp, #-16]! ; Push Frame Pointer (FP) and Link Register (LR) to stack\nbd4: 12003c01   and  w1, w0, #0xffff  ; Mask the input (Current Block ID) to 16 bits. Keep in w1.\nbd8: 910003fd   mov  x29, sp          ; Set up the frame pointer<\/code><\/pre>\n\n\n\n
        \n
      • w0<\/code> contains the Current Block ID<\/strong> (passed by the caller).<\/li>\n\n\n\n
      • tpidr_el0<\/code> is used to access thread-local variables. This is crucial for multi-threaded fuzzing to ensure the previous_location<\/code> variable is unique per thread.<\/li>\n<\/ul>\n\n\n\n
        3. Resolve TLS Offset for __afl_prev_loc<\/code><\/h4>\n\n\n\n
        bdc: 90000100   adrp x0, 20000        ; Load address for GOT\/Global area\nbe0: f9403404   ldr  x4, [x0, #104]   ; Load a function pointer (likely a TLS descriptor helper)\nbe4: 9101a000   add  x0, x0, #0x68    ; Prepare argument for the helper\nbe8: d63f0080   blr  x4               ; Call helper function<\/code><\/pre>\n\n\n\n
          \n
        • This block calls a helper function to determine the offset of the thread-local variable __afl_prev_loc<\/code>.<\/li>\n\n\n\n
        • After blr<\/code>, x0<\/code> contains the offset<\/strong> of __afl_prev_loc<\/code> relative to the thread pointer (x2<\/code>).<\/li>\n<\/ul>\n\n\n\n
          4. Load Previous Location & Calculate Edge<\/h4>\n\n\n\n
          bec: 78606844   ldrh w4, [x2, x0]     ; Load `prev_loc` (16-bit) from [TLS_Base + Offset]\nbf0: 53017c25   lsr  w5, w1, #1       ; Calculate `next_prev_loc` = (Current_ID >> 1)\nbf4: 78206845   strh w5, [x2, x0]     ; Store `next_prev_loc` back to TLS for the next time\nbf8: 4a040021   eor  w1, w1, w4       ; Calculate Edge Index: (Current_ID ^ prev_loc)\nbfc: 92403c21   and  x1, x1, #0xffff  ; Ensure Index fits in 64KB (16 bits)<\/code><\/pre>\n\n\n\n
            \n
          • AFL Algorithm Core:<\/strong>\n
              \n
            • Current Edge = Current_ID ^ Prev_ID<\/code>.<\/li>\n\n\n\n
            • Future Prev_ID = Current_ID >> 1<\/code>.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
            • The shift (lsr<\/code>) distinguishes the direction of the edge (i.e., A -> B creates a different hash than B -> A).<\/li>\n<\/ul>\n\n\n\n
              5. Update Coverage Map<\/h4>\n\n\n\n
              c00: 38616860   ldrb w0, [x3, x1]     ; Load byte from Map[Index]\nc04: 11000400   add  w0, w0, #0x1     ; Increment counter\nc08: 38216860   strb w0, [x3, x1]     ; Store byte back to Map[Index]<\/code><\/pre>\n\n\n\n
                \n
              • This increments the “hit count” for this specific code path transition.<\/li>\n<\/ul>\n\n\n\n
                6. Return<\/h4>\n\n\n\n
                c0c: a8c17bfd   ldp  x29, x30, [sp], #16 ; Pop FP and LR\nc10: d65f03c0   ret                   ; Return to the instrumented function\nc14: d65f03c0   ret                   ; Early return path (if Map was NULL)<\/code><\/pre>\n\n\n\n
                Summary<\/h3>\n\n\n\n
                This is the assembly equivalent of the following C logic used in fuzzing:<\/p>\n\n\n\n
                \/\/ w0 is the compile-time random ID for the current block\nvoid bbCallback(unsigned int cur_loc) {\n  unsigned char *map = __afl_area_ptr;\n  if (!map) return;\n\n  \/\/ Access thread-local storage for previous location\n  unsigned int prev_loc = __afl_prev_loc;\n\n  \/\/ Calculate edge index\n  unsigned int index = (cur_loc ^ prev_loc) & 0xFFFF;\n\n  \/\/ Update map\n  map[index]++;\n\n  \/\/ Update previous location for the next callback\n  __afl_prev_loc = cur_loc >> 1;\n}<\/code><\/pre>\n\n\n\n
                \n\n\n\n
                Here is an explanation of these three concepts(Thread Local Storage, thread-local variable and tpidr_el0), moving from the high-level software concept down to the specific hardware implementation in ARM64.<\/p>\n\n\n\n
                1. Thread Local Storage (TLS) \u2014 The System<\/h3>\n\n\n\n
                Thread Local Storage<\/strong> is a computer programming method that uses static or global memory local to a thread.<\/p>\n\n\n\n
                  \n
                • The Problem:<\/strong> Normally, global variables are shared by all<\/strong> threads in a program. If Thread A changes a global variable, Thread B sees the change. This creates race conditions and requires locking (mutexes), which is slow.<\/li>\n\n\n\n
                • The Solution (TLS):<\/strong> TLS allows you to define a “global” variable where each thread gets its own unique copy<\/strong>.<\/li>\n\n\n\n
                • Analogy:<\/strong>\n
                    \n
                  • Global Memory:<\/strong> A whiteboard in the middle of an office. Everyone shares it. If you write on it, I see it.<\/li>\n\n\n\n
                  • TLS:<\/strong> A notebook given to every employee. Everyone has a notebook called “Notes,” but what I write in mine is completely private from what you write in yours.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
                    2. Thread-Local Variable \u2014 The Programming Object<\/h3>\n\n\n\n
                    A thread-local variable<\/strong> is the specific variable that lives inside the TLS.<\/p>\n\n\n\n
                    In C or C++, you declare them using keywords like __thread<\/code>, _Thread_local<\/code>, or thread_local<\/code>.<\/p>\n\n\n\n
                    Classic Example: errno<\/code><\/strong>
                    In standard C programming, errno<\/code> contains the error code of the last failed system call.<\/p>\n\n\n\n
                      \n
                    • If Thread A<\/strong> tries to open a missing file, errno<\/code> becomes 2 (ENOENT<\/code>).<\/li>\n\n\n\n
                    • If Thread B<\/strong> is running successfully at the same time, its errno<\/code> should remain 0.<\/li>\n\n\n\n
                    • Therefore, errno<\/code> is a thread-local variable<\/strong>. If it were a standard global variable, Thread B might incorrectly think it encountered an error because Thread A failed.<\/li>\n<\/ul>\n\n\n\n
                      In the context of your previous AFL code snippet, the variable __afl_prev_loc<\/code> is a thread-local variable. This ensures that if you are fuzzing with multiple threads, Thread A’s execution history doesn’t mix with Thread B’s history.<\/p>\n\n\n\n
                      3. tpidr_el0<\/code> \u2014 The Hardware Register<\/h3>\n\n\n\n
                      This is the specific ARM64 (AArch64)<\/strong> CPU register used to implement TLS efficiently.<\/p>\n\n\n\n
                        \n
                      • Name Breakdown:<\/strong>\n
                          \n
                        • TP:<\/strong> Thread Pointer<\/li>\n\n\n\n
                        • ID:<\/strong> ID<\/li>\n\n\n\n
                        • R:<\/strong> Register<\/li>\n\n\n\n
                        • EL0:<\/strong> Exception Level 0 (User Mode)<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                        • Purpose:<\/strong> It holds the base address<\/strong> of the memory region allocated for the currently running thread<\/em>.<\/li>\n<\/ul>\n\n\n\n
                          When the Operating System switches threads (context switch), it updates tpidr_el0<\/code> to point to the new thread’s private data area.<\/p>\n\n\n\n
                          How they work together (The Flow)<\/h3>\n\n\n\n
                          When your code wants to access a thread-local variable, the CPU performs the following steps (simplified):<\/p>\n\n\n\n
                            \n
                          1. Get the Base:<\/strong> The CPU reads tpidr_el0<\/code> to find out “Where does the current thread’s private memory start?”<\/li>\n\n\n\n
                          2. Get the Offset:<\/strong> The compiler knows that Variable X is located, say, 16 bytes from the start of that memory block.<\/li>\n\n\n\n
                          3. Calculate Address:<\/strong> Target Address = tpidr_el0<\/code> + 16.<\/li>\n\n\n\n
                          4. Access:<\/strong> Read\/Write to that address.<\/li>\n<\/ol>\n\n\n\n
                            Applying it to your code snippet<\/h3>\n\n\n\n
                            Let’s look at lines bcc<\/code> to bec<\/code> from your snippet again:<\/p>\n\n\n\n
                            bcc: d53bd042   mrs  x2, tpidr_el0    ; 1. READ the Thread Pointer base address into x2\n...\nbe8: d63f0080   blr  x4               ; 2. CALL a helper to get the variable's OFFSET (puts it in x0)\nbec: 78606844   ldrh w4, [x2, x0]     ; 3. ACCESS memory at [Base (x2) + Offset (x0)]<\/code><\/pre>\n\n\n\n
                            Why was this necessary in the code?<\/strong>
                            AFL updates prev_loc<\/code> (previous location) to track coverage. If the fuzzer is multi-threaded, two threads running the same function simultaneously would corrupt each other’s coverage map if prev_loc<\/code> were a standard global variable. By using tpidr_el0<\/code> to access a thread-local copy, each thread tracks its own path independently.<\/p>\n\n\n\n
                            \n\n\n\n
                            “CALL a helper to get the variable’s OFFSET”<\/p>\n\n\n\n
                            The helper function is necessary because of Dynamic Linking<\/strong>.<\/p>\n\n\n\n
                            When you compile this code (likely as a shared library or a Position Independent Executable), the compiler does not know<\/strong> where the variable __afl_prev_loc<\/code> will be located in memory relative to the thread pointer.<\/p>\n\n\n\n
                            Here is the breakdown of why the helper is needed and what it does.<\/p>\n\n\n\n
                            1. The Core Problem: “I don’t know where I am yet”<\/h3>\n\n\n\n
                            If you are writing a standard executable (like main.exe<\/code>), the compiler can calculate exactly where every variable is. It can say “Variable X is at offset 16.”<\/p>\n\n\n\n
                            However, this code is likely compiled as Position Independent Code (PIC)<\/strong>. This means:<\/p>\n\n\n\n
                              \n
                            • This code might be inside a shared library (libafl.so<\/code>).<\/li>\n\n\n\n
                            • That library could be loaded into memory at any<\/em> address.<\/li>\n\n\n\n
                            • The library might be loaded after<\/em> the program starts (using dlopen<\/code>).<\/li>\n<\/ul>\n\n\n\n
                              Because of this, the offset of __afl_prev_loc<\/code> is unknown at compile time<\/strong>. The compiler cannot simply write add x0, x2, #16<\/code>. It needs to ask the “runtime linker” where the variable ended up.<\/p>\n\n\n\n
                              2. The Solution: TLS Descriptors (TLSDESC)<\/h3>\n\n\n\n
                              The specific instruction sequence you see (adrp<\/code>, ldr<\/code>, add<\/code>, blr<\/code>) is the signature of the TLSDESC (TLS Descriptors)<\/strong> model, which is the default for AArch64\/ARM64.<\/p>\n\n\n\n
                              It works like a “lazy question”:<\/p>\n\n\n\n
                                \n
                              1. Preparation:<\/strong> adrp<\/code> and add<\/code> prepare the arguments. They point to a “descriptor” in the Global Offset Table (GOT).<\/li>\n\n\n\n
                              2. The Call (blr<\/code>):<\/strong> You call the helper function stored in that descriptor.<\/li>\n\n\n\n
                              3. The Answer:<\/strong> The helper calculates just the offset<\/strong> for you and returns it in x0<\/code>.<\/li>\n\n\n\n
                              4. The Access:<\/strong> You add that offset to your Thread Pointer (tpidr_el0<\/code>) to find the variable.<\/li>\n<\/ol>\n\n\n\n
                                3. Why is it a “Helper” and not just a standard function?<\/h3>\n\n\n\n
                                It is a special, highly optimized function provided by the dynamic linker (like ld-linux.so<\/code>).<\/p>\n\n\n\n
                                  \n
                                • It preserves registers:<\/strong> Notice that the code didn’t save x1<\/code> or x2<\/code> before calling blr x4<\/code>. A standard function call would require saving these. The TLS helper guarantees it won’t mess up your temporary registers (except x0<\/code>), making it very fast.<\/li>\n\n\n\n
                                • It can change:<\/strong> When the program first starts, the helper might point to a “slow path” that calculates the offset and caches it. The next time you call it, it might point to a “fast path” that just returns the now-known constant.<\/li>\n<\/ul>\n\n\n\n
                                  Summary<\/h3>\n\n\n\n
                                  You need the helper because the variable’s location is dynamic<\/strong>.<\/p>\n\n\n\n
                                    \n
                                  • Static Build:<\/strong> “Go to offset 16.” (Fast, no helper needed)<\/li>\n\n\n\n
                                  • Dynamic Build (Your Code):<\/strong> “Call this helper; it will figure out where the variable lives right now, then tell me the offset.”<\/li>\n<\/ul>\n\n\n\n
                                    \n\n\n\n
                                    If this code were part of the main executable (e.g., the .exe<\/code> file), you would be absolutely correct: the offset would be static\/constant. This is called the Local Executable (LE)<\/strong> model.<\/p>\n\n\n\n
                                    However, the assembly you provided is using the General Dynamic (GD)<\/strong> or TLSDESC<\/strong> model. This happens because the compiler is being conservative. It assumes this code might end up in a Shared Library (.so<\/code>)<\/strong>.<\/p>\n\n\n\n
                                    Here is why the offset cannot<\/strong> be static in a Shared Library.<\/p>\n\n\n\n
                                    1. The “Train” Analogy<\/h3>\n\n\n\n
                                    Imagine the Thread Local Storage (TLS) memory area as a long train attached to the Thread Pointer (TP).<\/p>\n\n\n\n
                                      \n
                                    • The Engine:<\/strong> The Thread Pointer (tpidr_el0<\/code>).<\/li>\n\n\n\n
                                    • Car 1:<\/strong> The variables for the Main Executable<\/strong>.<\/li>\n\n\n\n
                                    • Car 2:<\/strong> The variables for Library A<\/strong>.<\/li>\n\n\n\n
                                    • Car 3:<\/strong> The variables for Library B<\/strong>.<\/li>\n<\/ul>\n\n\n\n
                                      The Problem for the Compiler<\/h4>\n\n\n\n
                                      When you are compiling Library B<\/strong>, the compiler has no idea:<\/p>\n\n\n\n
                                        \n
                                      1. How big Car 1<\/strong> (the main app) will be.<\/li>\n\n\n\n
                                      2. If Library A<\/strong> will be loaded before or after Library B.<\/li>\n\n\n\n
                                      3. If Library B will be loaded at startup or loaded later (via dlopen<\/code>).<\/li>\n<\/ol>\n\n\n\n
                                        Because the compiler doesn’t know “how many cars are in front of it,” it cannot hardcode the distance (offset) from the Engine (TP) to its own variables.<\/p>\n\n\n\n
                                        2. The Dynamic Thread Vector (DTV)<\/h3>\n\n\n\n
                                        In complex scenarios (like dlopen<\/code> on Linux), the memory layout isn’t even a contiguous block (a single train). It looks more like this:<\/p>\n\n\n\n
                                          \n
                                        1. tpidr_el0<\/code> points to a Thread Control Block<\/strong>.<\/li>\n\n\n\n
                                        2. Inside that block, there is a pointer to an array called the DTV (Dynamic Thread Vector)<\/strong>.<\/li>\n\n\n\n
                                        3. The DTV is a list of pointers:\n
                                            \n
                                          • Slot 0 -> points to Main App TLS data<\/li>\n\n\n\n
                                          • Slot 1 -> points to Lib A TLS data<\/li>\n\n\n\n
                                          • Slot 2 -> points to Lib B TLS data<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n
                                            To find a variable in Library B, the code has to:<\/p>\n\n\n\n
                                              \n
                                            1. Read tpidr_el0<\/code>.<\/li>\n\n\n\n
                                            2. Find the DTV.<\/li>\n\n\n\n
                                            3. Read the pointer at Slot 2.<\/li>\n\n\n\n
                                            4. Add the offset inside that specific block.<\/li>\n<\/ol>\n\n\n\n
                                              Since the OS assigns “Slot 2” at runtime, the compiler cannot<\/strong> know the final offset relative to tpidr_el0<\/code> at compile time. It requires the helper function to look up the DTV and calculate the current address.<\/p>\n\n\n\n
                                              3. “Linker Relaxation” (Why you might see static offsets anyway)<\/h3>\n\n\n\n
                                              You mentioned that in your opinion it should<\/em> be static. You are right in the sense that performance-wise, we want it to be static.<\/strong><\/p>\n\n\n\n
                                              If you compile this code as a shared object (.so<\/code>), the compiler generates the slow blr<\/code> helper code (General Dynamic) because it has to be safe.<\/p>\n\n\n\n
                                              However<\/strong>, if you verify that this object file ends up in the main executable<\/strong> during the linking phase, the Linker is smart enough to rewrite the code! This is called Linker Relaxation<\/strong>.<\/p>\n\n\n\n
                                              The Linker sees:<\/p>\n\n\n\n
                                                \n
                                              • “Hey, this code asked for a dynamic offset lookup\u2026”<\/li>\n\n\n\n
                                              • “\u2026but I know this is the main executable.”<\/li>\n\n\n\n
                                              • “\u2026so I know the offset is definitely 16.”<\/li>\n<\/ul>\n\n\n\n
                                                It will physically overwrite<\/strong> the assembly instructions:<\/p>\n\n\n\n
                                                  \n
                                                • It replaces the blr<\/code> (call) with nop<\/code> (do nothing).<\/li>\n\n\n\n
                                                • It replaces the complex setup with a simple mov<\/code> or add<\/code>.<\/li>\n<\/ul>\n\n\n\n
                                                  Summary<\/h3>\n\n\n\n
                                                    \n
                                                  • Compiler’s View:<\/strong> “I don’t know where this code will live (Exe vs Lib), so I will generate the Helper Function<\/strong> code just to be safe.”<\/li>\n\n\n\n
                                                  • Linker’s View:<\/strong> “I am building the final binary now. If I can prove the offset is static, I will optimize the assembly to remove the helper.”<\/li>\n<\/ul>\n\n\n\n
                                                    The snippet you pasted contains the un-optimized, “safe” version (TLSDESC), implying it was compiled with -fPIC<\/code> and the linker didn’t (or couldn’t) relax it to the Local Executable model.<\/p>\n\n\n\n
                                                    \n\n\n\n
                                                    AFL++ is not multi-threaded by default.<\/strong><\/p>\n\n\n\n
                                                    By design, a single instance of afl-fuzz<\/code> is a single-threaded process<\/strong> that occupies exactly one CPU core<\/strong>.<\/p>\n\n\n\n
                                                    If you run afl-fuzz<\/code> once on a 64-core machine, it will use 1 core and leave the other 63 idle. To utilize your full hardware, you must manually launch multiple separate instances of the fuzzer (processes), not threads.<\/p>\n\n\n\n
                                                    1. Why isn’t it multi-threaded?<\/h3>\n\n\n\n
                                                    AFL++ (and the original AFL) relies on determinism<\/strong> and global state.<\/p>\n\n\n\n
                                                      \n
                                                    • It uses a “Forkserver” mechanism where the fuzzer pauses the target at main()<\/code>, then fork()<\/code>s a new child process for every single input attempt.<\/li>\n\n\n\n
                                                    • Managing this via threads would be incredibly complex because the “target” (the program you are fuzzing) might crash, hang, or corrupt memory. If the fuzzer were just a thread in the same process, a crash in the target would crash the fuzzer too.<\/li>\n\n\n\n
                                                    • Process isolation ensures that when the target crashes (which is the goal!), the fuzzer survives to record the crash.<\/li>\n<\/ul>\n\n\n\n
                                                      2. How to run it in “Parallel Mode”<\/h3>\n\n\n\n
                                                      Since it doesn’t spawn threads automatically, you use Distributed\/Parallel Fuzzing<\/strong> by running multiple processes that share a folder to sync their findings.<\/p>\n\n\n\n
                                                      You typically run one “Main” instance (deterministic) and many “Secondary” instances (randomized).<\/p>\n\n\n\n
                                                      Example for a 4-core system:<\/strong><\/p>\n\n\n\n
                                                        \n
                                                      • Core 1 (Main):<\/strong> .\/afl-fuzz -i inputs -o syncdir -M fuzzer01 .\/target_app<\/code> (The -M<\/code> flag tells it to be the Master\/Main instance).<\/em><\/li>\n\n\n\n
                                                      • Core 2 (Secondary):<\/strong> .\/afl-fuzz -i inputs -o syncdir -S fuzzer02 .\/target_app<\/code> (The -S<\/code> flag tells it to be a Secondary instance).<\/em><\/li>\n\n\n\n
                                                      • Core 3 & 4 (More Secondaries):<\/strong>
                                                        bash .\/afl-fuzz -i inputs -o syncdir -S fuzzer03 .\/target_app .\/afl-fuzz -i inputs -o syncdir -S fuzzer04 .\/target_app<\/code><\/li>\n<\/ul>\n\n\n\n
                                                        All instances watch the syncdir<\/code> directory. If fuzzer02<\/code> finds a new interesting path, fuzzer01<\/code> will see it in the folder and add it to its own queue.<\/p>\n\n\n\n
                                                        3. Connection to your previous question (TLS)<\/h3>\n\n\n\n
                                                        This explains why the TLS instrumentation (tpidr_el0<\/code>) you asked about earlier is so important.<\/p>\n\n\n\n
                                                        Even though AFL++ itself<\/strong> is single-threaded, the Target Program<\/strong> you are fuzzing might be multi-threaded.<\/p>\n\n\n\n
                                                          \n
                                                        • If your target app spawns 4 threads, they will all try to write to the coverage map (the “Map” in your assembly code).<\/li>\n\n\n\n
                                                        • Without TLS (Thread Local Storage), Thread A and Thread B in the target<\/em> would overwrite each other’s prev_loc<\/code> variable, corrupting the coverage data.<\/li>\n\n\n\n
                                                        • The tpidr_el0<\/code> instrumentation ensures that even if the target is multi-threaded, the coverage reporting remains accurate for each thread.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
                                                          This code snippet is an implementation of the AFL (American […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42],"tags":[49,30],"class_list":["post-288","post","type-post","status-publish","format-standard","hentry","category-knowledge-base","tag-afl","tag-binary"],"_links":{"self":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/288","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=288"}],"version-history":[{"count":2,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/288\/revisions"}],"predecessor-version":[{"id":291,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/288\/revisions\/291"}],"wp:attachment":[{"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=288"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=288"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=288"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}