A high-performance HTTP/1.1 and HTTP/2 race condition testing tool designed for exploiting timing vulnerabilities in web applications. TREM enables security researchers to test race conditions in authentication flows, rate limiters, WAFs, and transactional systems with extreme precision and minimal computational overhead.

Race conditions occur when multiple operations access shared resources without proper synchronization, leading to unexpected behavior. TREM exploits these vulnerabilities by orchestrating multiple concurrent HTTP request chains with nanosecond-level timing precision. TREM uses handcrafted HTTP/2 and TLS state machines, by using TLS ClientHello randomization or HTTP/2 server to client sync datagram ignores, it allows TLS fingerprint evasions and special HTTP/2 race scenarios.

Classic Race Conditions (Sync Mode)

Multiple threads establish connections, synchronize at a barrier, then fire requests simultaneously. Exploiting classical TOCTOU (Time-of-Check to Time-of-Use) vulnerabilities in:

• Double-spend in financial transactions
• Coupon/voucher redemption bypass
• Inventory manipulation (overselling)
• Privilege escalation via concurrent role assignment

Havoc Race Conditions (Async Mode)

Default mode, it abuses in high-throughput race conditions, aiming to cause havoc (ad absurdum) in target state machine, where each thread processes requests independently without synchronization. For instance:

• Session puzzling: Rapid sequential requests exploiting session state inconsistencies
• Cache poisoning: Flooding requests to poison CDN/cache before legitimate traffic
• Racer Resource exhaustion: Sustained high-volume requests depleting server connection pools, leading to lost of concurrency managing
• Business logic abuse: High-speed coupon redemption, inventory manipulation without sync timing, leading to corruption of state status at any coupon/inventory manipulation

Single-Packet Attack (Block Mode)

Sends all requests in a single TCP write operation, exploiting the lowest possible timing window. Uses HTTP/1.1 pipelining or HTTP/2 multiplexing depending on protocol:

• Maximizes request simultaneity at the wire level
• Bypasses network-level timing variations
• Ideal for critical race windows under 1ms
• With -ka: all threads share single TLS connection, enabling true single-packet attacks across entire thread groups

Rate Limiter & WAF Bypass

Abuse the timing window between request arrival and counter increment. When N requests arrive within the same processing window, the rate limiter may count them as fewer attempts than actual, allowing:

• Bypass of login attempt limits
• Circumvention of API throttling
• Evasion of brute-force protections

Password Spray & Brute-Force Racing

Via FIFO-based value distribution, TREM injects credentials at wire speed while exploiting race windows in authentication systems. A WAF configured for "5 attempts per minute" may allow 50+ attempts if requests arrive faster than the counter synchronization interval.

TREM is engineered for minimal overhead and maximum throughput:

The architecture eliminates mutex contention through copy-on-write semantics and atomic operations, enabling thousands of concurrent requests with sub-millisecond coordination overhead.

# Clone
git clone https://github.com/otavioarj/TREM.git
cd TREM
go mod tidy

# Debug build
go build

# Release build :)
go build -ldflags="-s -w" -trimpath

• Linux ARM64 build runs on Android too :)
• Windows doesn't support FIFO mode yet :(

Single Mode (one group):

./trem -l "req1.txt,req2.txt,...,reqN.txt" -re patterns.txt [options]

Groups Mode (multiple independent groups):

./trem -l "req1.txt,req2.txt,...,reqN.txt" -thrG groups.txt [options]

• Flags
• ClientHello Fingerprints
• Operation Modes
  • Async Mode
  • Sync Mode
  • Block Mode
  • Keep-All Mode
  • Sync Barriers
• Thread Groups
  • Groups File Format
  • Cross-Group Value Sharing
  • NoFifo Groups
• Cross-Group Synchronization
  • Wait Keys
• Regex Patterns File
• Response Actions
• Universal Replacement
  • Static Mode
  • FIFO Mode
  • FIFO Distribution Modes
  • FIFO Key Distribution
• HTTP/2 Support
• Looping
• mTLS Support
• Proxy Support
• Verbose Mode
• Stats Panel
• UI Controls
• Examples

Note: Modes 1-5 negotiate ALPN. Mode 0 automatically selects RandomizedNoALPN for HTTP/1.1 and RandomizedALPN for HTTP/2.

Each thread processes requests independently without synchronization. Best for high-throughput race condition exploitation.

./trem -l "login.txt,action.txt" -re patterns.txt -thr 5 -mode async

Threads synchronize at barrier points before sending requests simultaneously. Essential for classical race condition exploitation.

./trem -l "login.txt,race.txt" -re patterns.txt -thr 10 -mode sync

Default Flow (barrier on first request):

1. All threads establish TLS connections
2. All threads wait at barrier (request 1)
3. Barrier releases → simultaneous request transmission
4. Remaining requests proceed normally

Accumulates all requests and sends them in a single TCP write. This achieves the tightest possible timing window by eliminating network round-trip delays between requests.

./trem -l "r1.txt,r2.txt,r3.txt" -thr 10 -mode block -h2

Protocol behavior:

• HTTP/1.1: Uses pipelining (multiple requests in single write, responses read in order)
• HTTP/2: Uses multiplexing (multiple streams in single connection, concurrent responses)

Key characteristics:

• Ignores -d delay (all requests sent at once)
• Ignores -re patterns (no inter-request value extraction)
• Maximum buffer size controlled by -dsize (default 4KB)
• Best for exploiting sub-millisecond race windows
• With -ka flag: all threads share single TLS connection (see Keep-All Mode)

Use Cases:

• Single-packet attacks where timing is critical
• Bypassing rate limiters that count requests per TCP segment
• Testing race conditions in stateless operations

Extends block mode by sharing a single TLS connection across all threads in a group. Instead of each thread having its own connection, all threads accumulate requests into their local buffers, then a coordinator performs a global flush - concatenating all buffers and sending everything in one TCP write.

./trem -l "race.txt" -thr 50 -xt 100 -mode block -ka

Requirements:

• Requires mode=block
• All requests in the group must target the same host:port

Flow comparison:

Without -ka (normal block):
  Thread 1: buffer → flush → conn1    (50 connections)
  Thread 2: buffer → flush → conn2
  ...
  Thread 50: buffer → flush → conn50

With -ka:
  Thread 1: buffer ─┐
  Thread 2: buffer ─┼→ global flush → single conn (1 connection)
  ...               │
  Thread 50: buffer─┘

Behavior:

1. Single TLS handshake for entire group (connection stored in first thread)
2. Each thread accumulates requests in its local buffer
3. Coordinator waits for all threads to finish accumulation
4. Global flush: concatenate all buffers → single TCP write
5. Read responses in order, dispatch to respective threads
6. Repeat for each loop iteration (-xt)

Protocol details:

• HTTP/1.1: All requests concatenated, pipelined in single write
• HTTP/2: All requests encoded as frames with unique stream IDs, multiplexed in single write

Use Cases:

• True single-packet attacks: 50 threads × 100 iterations = 5000 requests through minimal TCP writes
• Maximum timing precision across thread groups
• Bypassing per-connection rate limits

Example: 100 threads, 50 iterations, all through single connection:

./trem -l "race.txt" -thr 100 -xt 50 -mode block -ka -h2

Sends 100 × 50 = 5000 requests through a single TLS connection, with each iteration's requests going out in one TCP write (if total size < -dsize).

By default, sync mode places a barrier only on the first request. Use -sb to specify which requests should trigger synchronization barriers.

Format: Comma-separated list of 1-based request indices.

# Barrier only on request 1 (default)
./trem -l "r1.txt,r2.txt,r3.txt" -re patterns.txt -mode sync

# Barrier on requests 1, 2, and 3
./trem -l "r1.txt,r2.txt,r3.txt" -re patterns.txt -mode sync -sb 1,2,3

# Barrier only on requests 2 and 4
./trem -l "r1.txt,r2.txt,r3.txt,r4.txt" -re patterns.txt -mode sync -sb 2,4

Use Cases:

Example: Two-phase race condition

Testing a scenario where you need to synchronize both authentication and the vulnerable action:

./trem -l "login.txt,setup.txt,transfer.txt" -re patterns.txt -thr 20 -mode sync -sb 1,3

Flow:

1. All threads sync → send login.txt simultaneously
2. Each thread processes setup.txt independently (no barrier)
3. All threads sync → send transfer.txt simultaneously

This is useful when the race condition requires both authenticated sessions established at the same time AND the vulnerable action triggered simultaneously.

Thread groups allow you to define independent execution units where different subsets of requests run with their own thread count, mode, timing, and patterns. This enables complex attack scenarios like:

• Parallel authentication + exploitation flows
• Multi-phase attacks with different timing requirements
• Coordinated multi-endpoint race conditions

When -thrG is used, the following flags are ignored (they're defined per group): -thr, -mode, -x, -xt, -sb, -re, -ka

Each line defines one group:

req_indices thr=N mode=sync|async|block s_delay=N [r_delay=N] [x=N] [xt=N] [sb=N,M] [re=file] [nofifo] [ka] [wk=_key1,_key2]

Note: mode=block ignores r_delay and re= parameters.

Note: Request indices can be duplicated across groups, allowing different groups to process the same request with different configurations.

# groups.txt
# Group 1: Authentication (requests 1,2) - async with 5 threads
1,2 thr=5 mode=async s_delay=0 r_delay=10 re=auth_patterns.txt

# Group 2: Race exploit (requests 3,4,5) - sync with 20 threads, starts 100ms later
3,4,5 thr=20 mode=sync s_delay=100 sb=1 x=1 xt=0 re=race_patterns.txt

./trem -l "login.txt,setup.txt,race1.txt,race2.txt,race3.txt" -thrG groups.txt

Flow:

1. Group 1 starts immediately (s_delay=0): 5 threads process login.txt → setup.txt
2. Group 2 starts after 100ms: 20 threads sync on race1.txt, then process race2.txt, race3.txt
3. Group 2 loops infinitely (xt=0) from request 1 (x=1) within its group

Groups can share values using static keys (keys prefixed with _):

1. Group 1 extracts $_session$ from login response (via its re= file)
2. Value is stored in globalStaticVals
3. Group 2 automatically receives $_session$ in its requests

This enables patterns like: authenticate once in Group 1, spray exploits in Group 2.

Groups with nofifo flag don't participate in FIFO value distribution. Their threads:

• Don't receive FIFO channel (no buffered values)
• Still have access to static keys (_key) via globalStaticVals
• Useful for groups that only use regex-extracted values or static keys

Example:

# groups.txt
# Group 1: Auth - doesn't need FIFO values, only extracts session
1,2 thr=5 mode=async s_delay=0 re=auth.txt nofifo

# Group 2: Spray - uses FIFO for passwords
3 thr=50 mode=async s_delay=100 x=1 xt=0

Group 1 extracts $_session$ which Group 2 uses, but Group 1 threads don't waste channel capacity receiving FIFO values they don't need.

The wk= (wait keys) parameter enables fine-grained synchronization between thread groups by blocking a group until specific static keys become available in globalStaticVals.

When a group has wk=_key1,_key2,..., all threads in that group will wait indefinitely for those keys to appear before processing requests that need them. This creates a dependency chain between groups.

Format: Comma-separated list of static keys (must start with _)

# groups.txt
# Group 1: Auth flow - extracts _vtoken from response
1,2 thr=1 mode=sync s_delay=0 re=auth.txt

# Group 2: Exploit - waits for _vtoken, then races
3 thr=50 mode=block s_delay=100 xt=100 ka wk=_vtoken

Flow:

Group 1: r1 → r2 → extracts _vtoken → globalStaticVals.Store("_vtoken", "eyJ...")
                        ↓
Group 2: [blocked waiting _vtoken]
                        ↓
Group 2: _vtoken available → r3 × 50 threads × 100 iterations

Key characteristics:

• Only static keys (_key) can be waited on
• Wait is infinite (no timeout) for keys in wk= list
• Multiple keys can be specified: wk=_token,_session,_csrf
• Group starts processing only after ALL wait keys exist

1. Dependent authentication flows:

# r1: initial login (uses initial _token from -u)
# r2: refresh token (extracts new _vtoken)
# r3: exploit action (needs _vtoken from r2)

1,2 thr=1 mode=sync s_delay=0 re=rx.txt
3 thr=100 mode=block s_delay=0 xt=50 ka wk=_vtoken

2. Multi-phase coordinated attacks:

# Phase 1: Setup - extracts _session and _csrf
1,2 thr=5 mode=async s_delay=0 re=setup.txt

# Phase 2: Wait for setup, then race (waits for _session AND _csrf)
3,4,5 thr=50 mode=sync s_delay=0 sb=1 wk=_session,_csrf

3. Shared request with different tokens:

# Same request (r1) used in both groups, but with different tokens

# Group 1: Uses initial token, extracts new token
1,2 thr=1 mode=async s_delay=0 re=auth.txt

# Group 2: Same r1 but waits for extracted token
1 thr=50 mode=block s_delay=100 xt=100 ka wk=_newtoken

The most powerful combination for race condition attacks:

# groups.txt
1,2 thr=1 mode=sync s_delay=0 re=rx.txt
3 thr=100 mode=block s_delay=500 xt=50 ka wk=_vtoken

./trem -l "login.txt,refresh.txt,exploit.txt" -thrG groups.txt -u "_token=eyJ..."

Result:

1. Group 1 authenticates and extracts _vtoken
2. Group 2 waits for _vtoken
3. Group 2 sends 100 × 50 = 5000 exploit requests through single TLS connection
4. Each iteration's 100 requests sent in one TCP write (true single-packet attack)

The patterns file defines how values are extracted from responses and injected into subsequent requests. Each line corresponds to a request transition (line N extracts from response N to populate request N+1).

regex`:<key> $ regex2`:<key2> $ ... regexN`:<keyN>

• regex: Golang regular expression with capture group
• <key>: Placeholder name (will replace $<key>$ in next request)
• $: Separator for multiple patterns on same line (space-dollar-space)

Given requests: login.txt, setup.txt, verify.txt, action.txt

# patterns.txt
Set-Cookie:\s*session=([^;]+)`_session $ name="csrf" value="([^"]+)"`_csrf
:

token="([^"]+)"`token

Behavior:

1. Line 1: Extract _session and _csrf from login response → used in setup.txt
2. Line 2: Fire & Forget - setup.txt sent, response not read
3. Line 3: Empty - verify.txt response read but no extraction
4. Line 4: Extract token from verify response → used in action.txt (but line 3 is empty, so this extracts from verify.txt response for action.txt)

Note: Static keys (prefixed with _) persist globally and can be shared across thread groups.

Response actions allow you to execute commands when a regex matches the response at specific request indices. This enables automated detection of successful exploitation, evidence collection, and controlled termination.

Format: Each line in the action file follows:

indices:regex`:action1, action2, ...

Where:

• indices: Comma-separated 1-based request indices where the regex will be checked
• regex: Golang regular expression to match against response
• actions: One or more actions to execute on match

# actions.txt
2,3:"success":true`:sa("/tmp/poc.txt"), pra("EXPLOITED!"),pat e

When response 2 or 3 contains "success":true:

1. Save request+response to /tmp/poc.txt
2. Print "EXPLOITED!" to all threads
3. Exit gracefully

Provides dynamic value injection into requests via static assignment or FIFO pipe.

./trem -l "req1.txt,req2.txt" -re patterns.txt -u "token=abc123"

Replaces every $token$ in all requests with abc123.

Note: Values extracted by regex patterns (via -re) take priority over -u static values. This allows -u to provide initial values that can be overridden by extracted values in subsequent requests or loops.

# Terminal 1: Start TREM
./trem -l "login.txt" -re patterns.txt -u /tmp/fifo -thr 50 -fmode 2

# Terminal 2: Feed credentials from a file
cat passwords.txt > /tmp/fifo
# Or from another program
python generate_spraypass.py -in passwords_masks.txt -out /tmp/fifo

FIFO file format:

pass=password123
admin123
letmein
qwerty
123456

The first line defines the key (pass), subsequent lines are values for that key. Each value of pass generates a new request when matching and replacing the key in a given request. Although FIFO keys don't use $key$ format in feed/consumption, the find&replace algorithm always uses key in format $key$ in requests! So the FIFO key pass will replace request key $pass$. FIFO also accept static keys and mutators, as:

_user=admin
pass=password123
admin123
letmein
qwerty
123456

The key _user is globally available (see Cross-Group Value Sharing) to all groups threads (see Thread Groups), while the values of passare shared following the FIFO Distribution Modes.

Round-robin example with 3 threads:

FIFO input: pass1, pass2, pass3, pass4, pass5, pass6
Thread 0: pass1, pass4
Thread 1: pass2, pass5
Thread 2: pass3, pass6

Keys starting with underscore (globally static values) are also never consumed in the FIFO, persisting across all loops, with the updated value if needed:

_bearer=eyJhbGciOiJIUzI1NiIs...
pin=1234
5678
9012

• _bearer is set once and used in every request
• pin values are consumed normally (one per request)

This enables scenarios like: authenticate once, then spray PINs. The _key can still be updated later:

_bearer=eyJhbGciOiJIUzI1NiIs...
pin=1234
5678
9012
....
_bearer=eyJhbGciOiJSUzI1NiIsIn...

When multiple keys have multiple values in the same batch (64 lines), TREM generates all combinations:

user=admin
guest
pass=123
456

Generates 4 requests:

• admin, pass=123
• admin, pass=456
• guest, pass=123
• guest, pass=456

By default in group mode, TREM analyzes each group's request templates and only sends FIFO keys to threads that actually need them. This subscription-based distribution prevents threads from receiving keys they never use, optimizing channel capacity and reducing overhead.

Note: In single mode (without -thrG), key distribution is always disabled (all threads process all requests, so they need all keys).

How it works:

1. Before starting, TREM parses all request templates for each group
2. Extracts non-static keys ($key$, not $_key$) from each group's requests
3. Builds a subscription map: which threads need which keys
4. FIFO dispatcher only sends keys to subscribed threads

Example scenario:

# groups.txt
# Group 1: Auth - uses $_session$ (static, always available)
1,2 thr=5 mode=async s_delay=0 re=auth.txt

# Group 2: Spray - uses $pass$ from FIFO  
3 thr=50 mode=async s_delay=100 x=1 xt=0

With -fkdist=true:

• Group 1 threads (0-4): Don't receive pass values (not in their templates)
• Group 2 threads (5-54): Receive pass values via round-robin

With -fkdist=false:

• All 55 threads receive pass values, but Group 1 threads waste them

Benefits:

• Reduced channel congestion for threads that don't need certain keys
• More efficient round-robin distribution (values go only to threads that use them)
• Lower memory usage (smaller per-thread buffers)

Complexity:

Where T = total threads, S = subscribers for that key (typically S << T).

TREM supports HTTP/2 natively with a handcrafted protocol implementation. Request files remain in HTTP/1.1 raw format - TREM automatically converts them to HTTP/2 frames.

./trem -l "req1.txt,req2.txt" -re patterns.txt -h2 -thr 10 -mode sync

Conversion process:

• Host header → :authority pseudo-header
• Connection-specific headers stripped (Connection, Keep-Alive, etc.)
• Headers HPACK encoded
• Body sent as DATA frames
• TLS ALPN set to h2 (with http/1.1 fallback)

Block mode with HTTP/2:

• Uses multiplexing instead of pipelining
• All requests sent as separate streams in single TCP write
• Responses can arrive out of order (handled by stream ID correlation)

Intended Limitations:

• Flow control assumes server window ≥ 10MB
• Server push (PUSH_PROMISE) frames discarded

When to use HTTP/2:

• Target server requires HTTP/2
• Testing HTTP/2-specific race conditions
• Leveraging multiplexed streams on single connection
• Block mode attacks (better server compatibility than HTTP/1.1 pipelining)
• Keep-All mode (-ka) for maximum single-connection throughput

Execute a subset of requests repeatedly:

./trem -l "login.txt,setup.txt,race.txt" -re patterns.txt -x 2 -xt 100

• -x 2: Loop starts from request 2 (setup.txt)
• -xt 100: Run 100 iterations
• -xt 0: Infinite loops (stop with Q or via response action exit)
• -x -1: No looping (default)

Flow:

1. Execute requests 1 → 3
2. Loop 100×: requests 2 → 3

Combined with response actions:

./trem -l "login.txt,race.txt" -re patterns.txt -x 2 -xt 0 -ra actions.txt

Loops infinitely until a response action triggers exit.

For targets requiring client certificates (Mutual TLS):

./trem -l "req1.txt,req2.txt" -re patterns.txt -mtls /path/cert.p12:password

The certificate must be in PKCS#12 format.

Route traffic through HTTP proxy (e.g., Burp Suite):

./trem -l "req1.txt,req2.txt" -re patterns.txt -px http://127.0.0.1:8080

Save all thread tabs output (TUI) to files for post-analysis:

./trem -l "req1.txt,req2.txt" -re patterns.txt -thr 2 -dump

Creates files: g1_t1_15-30.txt, g1_t2_15-30.txt, etc.

Format: g<GroupID>_t<ThreadID>_<Hour-Minute>.txt

Debug connections, TLS, and regex issues:

./trem -l "req1.txt,req2.txt" -re patterns.txt -v

Outputs:

• TLS handshake details (ClientHello, cipher, ALPN)
• Retry attempts with backoff timing
• Connection state changes
• Regex match failures
• Jitter and latency metrics
• HTTP/2 frame debugging

Real-time metrics in the UI, it uses a windows of events (-sw) to control how many events are collected to display metrics, e.g., -sw 25 will use 25 events (i.e., request sent) to display, default is 10, normal mode, although it can be increased to better granularity if needed. When using verbose mode (-v) windows size is set to 50 if -sw is lower than 50.

Normal mode:

• Req/s: requests per second
• TotalReq: total requests sent
• HTTP Errs: errors by group/thread and status (e.g., G1T1(401)x5)
• Univ.: current FIFO path and last value

Verbose mode (-v) adds:

• Avg Jitter: latency variance
• TLS latency and retry averages
• I/O totals (bytes in/out)

The UI displays a TreeView on the left showing all groups and their threads. Click or navigate to select a thread and view its output.

Basic race condition (sync mode):

./trem -l "auth.txt,race.txt" -re patterns.txt -thr 20 -mode sync

Single-packet attack (block mode with HTTP/2):

./trem -l "r1.txt,r2.txt,r3.txt" -thr 10 -mode block -h2

True single-packet attack (keep-all with HTTP/2):

./trem -l "race.txt" -thr 100 -xt 50 -mode block -ka -h2

Sends 100 × 50 = 5000 requests through single TLS connection, each iteration in one TCP write.

Multi-barrier sync race:

./trem -l "login.txt,setup.txt,race.txt" -re patterns.txt -thr 20 -mode sync -sb 1,3

Password spray with FIFO and success detection:

./trem -l "login.txt,dashboard.txt" -re patterns.txt -u /tmp/creds -thr 50 -fmode 2 -ra actions.txt

Sustained race with keep-alive and auto-exit on success:

./trem -l "login.txt,setup.txt,race.txt" -re patterns.txt -thr 10 -mode sync -k -x 3 -xt 0 -ra actions.txt

HTTP/2 race condition with evidence collection:

./trem -l "req1.txt,req2.txt" -re patterns.txt -h2 -thr 10 -mode sync -ra actions.txt

Fire & Forget with selective response reading:

# patterns.txt:
# session=([^;]+)`_session
# :
# (empty line - reads response, no extraction)

./trem -l "login.txt,trigger.txt,verify.txt" -re patterns.txt -thr 5
# login: extract session
# trigger: fire & forget (response not read)
# verify: read response but no extraction

Multi-group coordinated attack:

# groups.txt:
# 1,2 thr=5 mode=async s_delay=0 re=auth.txt
# 3,4,5 thr=50 mode=sync s_delay=50 sb=1 x=1 xt=0

./trem -l "login.txt,setup.txt,race1.txt,race2.txt,race3.txt" -thrG groups.txt -ra actions.txt

Multi-group with nofifo optimization:

# groups.txt:
# 1,2 thr=5 mode=async s_delay=0 re=auth.txt nofifo
# 3 thr=100 mode=async s_delay=100 x=1 xt=0

./trem -l "login.txt,setup.txt,spray.txt" -thrG groups.txt -u /tmp/fifo -fmode 2
# Group 1: Auth only, doesn't need FIFO values
# Group 2: Spray with all 100 threads receiving passwords via round-robin

Cross-group synchronization with wait keys:

# groups.txt:
# 1,2 thr=1 mode=sync s_delay=0 re=auth.txt
# 3 thr=100 mode=block s_delay=100 xt=50 ka wk=_vtoken

./trem -l "login.txt,refresh.txt,exploit.txt" -thrG groups.txt -u "_token=eyJ..."
# Group 1: Auth flow extracts _vtoken
# Group 2: Waits for _vtoken, then races with 100×50=5000 requests via single connection

Shared request across groups with different configs:

# groups.txt:
# 1,2 thr=1 mode=async s_delay=0 re=auth.txt
# 1 thr=50 mode=block s_delay=500 xt=100 ka wk=_session

./trem -l "action.txt,setup.txt" -thrG groups.txt
# Group 1: Uses r1 (action.txt) with initial auth, extracts _session
# Group 2: Same r1 but with extracted _session, races 50×100 times

mTLS with client certificate:

./trem -l "req1.txt,req2.txt" -re patterns.txt -mtls ./client.p12:secret

Debug TLS issues:

./trem -l "req1.txt,req2.txt" -re patterns.txt -cli 1 -v -retry 5

Via Burp proxy with output dump:

./trem -l "req1.txt,req2.txt" -re patterns.txt -px http://127.0.0.1:8080 -dump

Infinite spray with persistent auth token and auto-exit:

# passwords.txt (feed to FIFO):
# _token=eyJhbG...
# pass=123456
# password
# admin123

# actions.txt:
# 1:"success"`:sre("/tmp/winner.txt"), e

./trem -l "verify.txt" -re patterns.txt -u /tmp/spray -thr 100 -xt 0 -fmode 2 -ra actions.txt

Complete exploitation workflow:

# 1. Sync login and critical action
# 2. Loop the exploit infinitely  
# 3. Auto-save evidence and exit on success

./trem -l "login.txt,setup.txt,exploit.txt" -re patterns.txt \
  -thr 50 -mode sync -sb 1,3 -x 2 -xt 0 \
  -ra actions.txt

With actions.txt:

3:"exploited"\s*:\s*true`:sa("/tmp/poc.txt"), pa("SUCCESS!"), e

Complete exploitation with keep-all and wait keys:

# 1. Auth and extract token in Group 1
# 2. Race exploit with keep-all in Group 2
# 3. Auto-save evidence and exit on success

# groups.txt:
# 1,2 thr=1 mode=sync s_delay=0 re=auth.txt
# 3 thr=50 mode=block s_delay=100 xt=0 ka wk=_token

./trem -l "login.txt,setup.txt,exploit.txt" -thrG groups.txt -ra actions.txt

With actions.txt:

3:"exploited"\s*:\s*true`:sa("/tmp/poc.txt"), pa("SUCCESS!"), e