Abstractions, Aspects, and PIC Modularity: The Compiler Subversion 1

Args Hook and argv Instrumentation

The argument path is separate from the base contract. phase5A builds the minimal argc/argv environment only when the source needs it, reading the context from Pill and not from additional ABI registers. The transpilador accepts both flag names: --ctx-args and --args-ctx.

• In materialized-argument mode, param_N and argvLocal are generated inside the function.
• In context-argument mode, Pill->CtxArgc and Pill->CtxArgv are read only if the loader provides a valid vector.
• The context vector is accepted when Pill exists, CtxArgv exists, and CtxArgc is between 1 and 64.
• If the context is not valid, a minimal local fallback is kept for argc and argv.
• If the source uses Argc or Argv, local aliases are created from argc and argv.

Control Structures and Unwanted Sections

Dense switch statements can be lowered into jump tables. In that case, the code no longer decides only with local comparisons: it computes an index, reads an entry from a table in .rdata, and jumps into a .text block. The typical object-level pattern is:

movslq (%rsi,%rdx,4), %rdx
add    %rsi, %rdx
jmp    *%rdx

The dependency proof appears in the relocations: .rdata contains relative entries into .text. If that section is removed, the indirect jump reads a missing or displaced table.

RELOCATION RECORDS FOR [.rdata]:
OFFSET           TYPE                  VALUE
0000000000000018 IMAGE_REL_AMD64_REL32 .text
000000000000001c IMAGE_REL_AMD64_REL32 .text
...
000000000000007c IMAGE_REL_AMD64_REL32 .text

In the current PIC flow, raj_flow_pic.py compiles phases with -fno-jump-tables to reduce this pattern. For especially dense sources, -fno-tree-switch-conversion can be added as extra frontend/GIMPLE hardening.

-fno-jump-tables
-fno-tree-switch-conversion   # optional when tree/GIMPLE conversions must be blocked

Even then, the final criterion is still COFF verification: the movslq/add/jmp *reg pattern and jump-table relocations from .rdata into .text must not remain if the final binary is intended to be .text-only.

CRT in the Flow

The CRT is the layer that turns a freshly loaded process into a stable C environment before main runs. Its final effect is not merely "startup"; it establishes runtime invariants so application code behaves predictably.

At startup, the CRT initializes global C-library state, prepares execution contracts (argc/argv/envp), configures runtime pieces used by libc functions, and chains global initializers/constructors. At exit, it coordinates orderly termination (atexit, destructors, and runtime-managed resource cleanup).

Replacing it with a minimal CRT reduces surface area and runtime dependency, but it also removes that guarantee framework: anything that depends on implicit initialization is no longer covered. In practice, the binary gains fine-grained control over the flow, but it must explicitly and locally materialize every initialization/termination step previously handled by the full CRT.

Minimal CRT Limitations in PIC Mode

• There is no full CRT initialization for global objects/constructors or standard termination paths (atexit and destructors).
• There is no complete argument/environment layer with classic runtime behavior (argc/argv/envp normalization and associated helpers).
• The full stdio/locale/printf library is not present; only the subset included in mincrt.h remains.
• Code that depends on internal CRT symbols, such as __main or runtime initializers, is no longer portable.

Data, Literals, and Imports When Converging to PIC/PILL

This block materializes the literal on the stack. JbLitL11Raw reserves 8 local bytes inside pinit(), Ptr writes the text byte by byte, and JbLitL11 becomes a C pointer to the \0-terminated buffer. The blob therefore does not need a static .rdata reference for that string: the data is born at runtime inside the active frame and consumed while pinit() is still executing.

unsigned char JbLitL11Raw[8];
char* JbLitL11 = ( char* ) JbLitL11Raw;
{
    volatile unsigned char* Ptr = ( volatile unsigned char* ) JbLitL11Raw;
    Ptr[0] = 0x4A;
    Ptr[1] = 0x65;
    Ptr[2] = 0x6C;
    Ptr[3] = 0x6C;
    Ptr[4] = 0x79;
    Ptr[5] = 0x62;
    Ptr[6] = 0x65;
    Ptr[7] = 0x00;
}

unsigned char JbLitL24Raw[4];
char* JbLitL24 = ( char* ) JbLitL24Raw;
{
    volatile unsigned char* Ptr = ( volatile unsigned char* ) JbLitL24Raw;
    Ptr[0] = 0x50;
    Ptr[1] = 0x49;
    Ptr[2] = 0x43;
    Ptr[3] = 0x00;
}

The difference is clearer in the object file. In the upper area, the literal no longer appears as a pointer to static data: the compiler emits mov BYTE PTR [rsp+...] writes that rebuild JellyBee and PIC inside the active frame. In the lower area, the .rdata dump shows the same content when it lives as static data: 50494300 4a656c6c 79426565 00000000, meaning PIC\0JellyBee\0.

JB_PILL_LOG(): Controlled Pill Output

JB_PILL_LOG() is not a real blob function: it is a macro emitted by phase7 when log usage or minimal stdio is detected. The macro routes text into JbtoLogDispatch(), which writes into the JbSwarmPill buffer received by pinit().

In the final source this is visible directly in pill/main_pill_phase9.c: the macro is defined near the beginning of the file and later consumed like a normal call, for example JB_PILL_LOG( 1, JbPillCallCtx, JbLitL203 );.

#include "runtime/mincrt.h"
#ifdef JB_PILL_LOG
#undef JB_PILL_LOG
#endif
#define JB_PILL_LOG(wide, out_ptr, fmt, ...) JbtoLogDispatch((out_ptr), (wide), (fmt), ##__VA_ARGS__)

...

if ( !BuildLdapFilter( pszSearchFilter, 260 * 2, filter ) )
{
    JB_PILL_LOG( 1, JbPillCallCtx, JbLitL203 );
    return _HRESULT_TYPEDEF_( 0x80070057 );
}

The real output channel is JbSwarmPill. The loader passes it to pinit() through RCX; JbtoBindOut( Pill ) validates the buffer, sets Length = 0, writes L'\0', and registers that context for the thread.

typedef struct
{
    wchar_t* Buffer;
    size_t   Capacity;
    size_t   Length;
    int      CtxArgc;
    char**   CtxArgv;
} JbSwarmPill;

Literal Matrix and Log Pooling

{
  "tags": {
    "<a>": "[+] KLIST result: "
  }
}

The Log Pooling detector reads candidates from ast_scan.json. The current rule looks for literals that start with [+], [-], [*], [x], or [X]. A typical case would be:

printf("[+] KLIST result: ");

From __imp_MessageBoxA to Hash-Based Resolution

phase1 normalizes the source and labels it with short markers so later phases do not depend on ambiguous searches. In the base case, it creates main_pill_phase1.c with API, literal, macro, and name tags:

#include <windows.h>

int main( void )
{
    MessageBoxA/*<A1>*//*<N1>*/( NULL/*<M1>*/, "Jellybe"/*<L11>*//*<L1>*//*<L23>*//*<L3>*/, "PIC"/*<L24>*//*<L2>*/, MB_OK/*<M2>*/ );
    return 0;
}

{
  "targets": [
    {
      "tag": "<A1>",
      "kind": "API",
      "value": "MessageBoxA",
      "json_pointer": "/detections/api_calls/0",
      "matches": [
        {
          "file": "JB_msgbox_callspoof/qa/PIC_1/pill/main_pill_phase1.c",
          "offset": 46,
          "line": 6,
          "column": 5,
          "length": 11,
          "match_type": "identifier"
        }
      ]
    },
    {
      "tag": "<N1>",
      "kind": "NM",
      "value": "MessageBoxA",
      "json_pointer": "/detections/nm_undefined_clean/0",
      "matches": [
        {
          "file": "JB_msgbox_callspoof/qa/PIC_1/pill/main_pill_phase1.c",
          "offset": 46,
          "line": 6,
          "column": 5,
          "length": 11,
          "match_type": "identifier"
        }
      ]
    }
  ]
}

With those detections, phase4 builds the final API and DLL list. Then Phase4BuildHashesHeader emits runtime/api_hashes.h using the ror13-lowercase algorithm. For this case, the result is JB_PILL_HASH_MessageBoxA 0xFC4DA2D0u. The DLL list is emitted as JB_PILL_DLL_LIST using JB_PILL_STACK_STR(...). In this example, the associated module is user32.dll.

  ULONG_PTR ( *JbApiMessageBoxA )() = JB_PILL_APIHP( MessageBoxA, ULONG_PTR ( * )() );

  JbApiMessageBoxA( ( ( void * ) 0 ), JbLitL11, JbLitL24, __MSABI_LONG( 0x00000000 ) );

How hashes are consumed: the transformed source replaces the original call with JB_PILL_APIHP( MessageBoxA, ... ). That macro falls into JbRequireApiByHash( JB_PILL_HASH_MessageBoxA ), then into JbResolveApi, and finally into JbFindExportByHash to compare the hash against the candidate module's EAT. If the export is a forwarder, JbFindExportByHash detects that the address falls inside the export-directory range and branches into JbResolveForwarder. There, DLL.Symbol is parsed, Symbol is rehashed with the same ror13-lowercase scheme, and the final target is resolved with another call to JbFindExportByHash.