HTTP/1.1 and HTTP/2.0 (experimental) race condition testing tool with request chaining support. Allows sequential requests where request N can extract values from response N-1 using regex patterns.

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

#Test HTTP2 mode
cd TREM
git checkout h2

# Debugging build
go build 

# Release? :P
go build -ldflags="-s -w"

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

Note: Modes 1-5 negotiate ALPN which may cause issues with HTTP/1.1 servers expecting no ALPN. Mode 0 (RandomizedNoALPN) works best for HTTP/1.1 raw requests. For proper ALPN support with modes 1-5, use the experimental h2 branch which handles ALPN negotiation correctly for both HTTP/1.1 and HTTP/2.

The h2 branch adds experimental HTTP/2 support. Request files remain in HTTP/1.1 raw format. TREM automatically converts them to HTTP/2 frames when -http 2 is specified.

Additional flag in h2 branch:

Usage:

./trem -l "req1.txt,req2.txt" -re patterns.txt -http 2 -th 10

How it works:

• Request files are always written as raw HTTP/1.1
• When -http 2, TREM parses the raw request and converts to HTTP/2:
  • Host header → :authority pseudo-header
  • Connection-specific headers (Connection, Keep-Alive, etc.) are stripped
  • Headers are HPACK encoded
  • Body is sent as DATA frames
• TLS ALPN is set to h2 instead of http/1.1
• In h2 branch, -cli 0 uses RandomizedALPN for HTTP/2 and RandomizedNoALPN for HTTP/1.1

Limitations:

• Flow control ignored: assumes server window ≥ 64KB (bodies > 64KB may stall)
• Server push ignored: PUSH_PROMISE frames are discarded

When to use HTTP/2:

• Target server only accepts HTTP/2
• Testing HTTP/2-specific race conditions
• Need multiplexed streams on single connection

Each thread processes requests independently without synchronization.

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

Threads synchronize at a barrier before sending the first request simultaneously - useful for race condition testing.

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

Flow:

1. All threads establish connections
2. All threads wait at barrier
3. Barrier releases → all threads send first request simultaneously
4. Remaining requests proceed normally

Each line in the pattern file corresponds to extracting values from response N to use in request N+1.

regex1`:key1 $ regex2`:key2
regex3`:key3

• Use backtick (`) before colon, not apostrophe
• Multiple patterns per line separated by $
• Regex must have one capture group ()
• Line 1 extracts from response 1 → used in request 2
• Line 2 extracts from response 2 → used in request 3

Use $key$ in request files to mark replacement points:

POST /api/action HTTP/1.1
Host: example.com
Content-Type: application/json

{"session": "$sessionId$", "type": "$actionType$"}

req1.txt - Login request:

POST /api/login HTTP/1.1
Host: localhost
Content-Type: application/json

{"username":"testuser","pass":"!aqui!"}

req2.txt - Transaction using values from login response:

POST /api/transaction HTTP/1.1
Host: localhost
Content-Type: application/json

{"userAccount":$userAccount$,"transactionType":"$transactionType$","amount":5000}

req3.txt - Report using value from transaction response:

POST /api/report HTTP/1.1
Host: localhost
Content-Type: application/json

{"reportType":"$reportType$","includeDetails":true}

regex.txt:

"userAccount": (\d{8}),`:userAccount $ "transactionType": "(PIX|TED)"`:transactionType
"reportType": "([a-f0-9-]{36})"`:reportType

• Line 1: Extracts userAccount (8 digits) and transactionType (PIX or TED) from response 1
• Line 2: Extracts reportType (UUID format) from response 2

Run with universal replacement:

./trem -l "req1.txt,req2.txt,req3.txt" -re regex.txt -u '!aqui!=secretpass123'

The !aqui! placeholder in req1.txt becomes secretpass123 at runtime.

Execute a subset of requests repeatedly for sustained race testing.

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

• -x 2: Start loop from request 2 (prepare.txt)
• -xt 100: Run 100 loop iterations
• -xt 0: Infinite loops (stop with Q)

Flow:

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

Replace a placeholder across all requests:

./trem -l "req1.txt,req2.txt" -re patterns.txt -u '!USER!=victim123'

All occurrences of !USER! in any request file become victim123.

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

Debug connection and TLS issues:

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

Outputs:

• TLS handshake details (ClientHello type, cipher suite, ALPN)
• Retry attempts with backoff timing
• Connection state changes
• Regex match failures
• Jitter and TLS latency metrics

The UI includes a stats panel showing real-time metrics:

Normal mode:

• Req/s: requests per second
• TotalReq: total requests sent
• HTTP Errs: errors by thread and status code (e.g., T1(400)x2)

Verbose mode (-v): adds:

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

Basic race condition test:

./trem -l "auth.txt,race.txt" -re patterns.txt -th 20 -mode sync -d 0

Sustained race with keep-alive:

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

Debug TLS issues:

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

Via Burp proxy:

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

HTTP/2 (h2 branch only):

./trem -l "req1.txt,req2.txt" -re patterns.txt -http 2 -th 10 -mode sync