Bring your own Fix - Mr.D0x inspired variation of yet another "fix" attack

Whilst I was browsing Twitter, erhm I mean X today, I saw a cool tweet from Mr.D0x about a new variation of a “fix” attack by abusing the internet browser.

I jokingly replied inb4 “downloadfix” as I immediately thought hey we typically escape browsers in kiosk breakouts by for example navigating to the downloads folder. Whilst this started out as a joke, I thought to myself heh, this could be an interesting experiment.

Nowadays, when I have a crazy idea, I find myself grabbing a good ol’ LLM and pitch the idea.

Thanks ChatGPT for being super duper helpful!
Whilst ChatGPT wasn’t very fond of the idea, I found myself using AI Studio, as Gemini 2.5 pro is a boss. Guardrails can be weakened and it has a huge context window as well.

The conversation was interesting to say the least…
Below is an extract of the interesting part of the conversation with Gemini.

Here's how you can achieve this locally using "pure JS" in a sense, with the help of a Service Worker:

A Service Worker acts as a client-side proxy. It can intercept network requests made by your page (including download requests) and decide how to respond. This is the closest you'll get to "rugpulling" the download from the client-side.

How it would work:

1. index.html:

   • Registers the Service Worker (sw.js).

   • Has a button that, when clicked, initiates a download to a specific URL (e.g., /download-me-corrupted.zip). This URL doesn't have to exist as a real file on a server; the Service Worker will handle it.

2. sw.js (Service Worker):

   • Listens for fetch events.

   • If it sees a request for /download-me-corrupted.zip:

     • It starts fetching a real (larger) file from somewhere (could be a local path if you're serving your site locally with a simple HTTP server, or a public URL).

     • It gets the ReadableStream of the real file's response.

     • It constructs a new Response to send back to the page. The body of this new response will be a new ReadableStream that the Service Worker controls.

     • The Service Worker starts reading chunks from the real file's stream and writing them to its controlled stream.

     • After a short delay or a certain number of bytes, the Service Worker stops writing to its stream and/or explicitly errors out its stream.

     • The browser's download manager, which is consuming the stream provided by the Service Worker, will then encounter an unexpected end-of-stream or an error, leading to a "Failed - Network Error" or similar.

This was all I needed to make this work. Now below is just a PoC, but you could combine this information with “clickfix” or probably even “filefix” as well :)

The reason there is a relatively significant delay on the “repairtool” is because we want to bypass the “this website wants to download multiple files” prompt. There is no official “time” on how long it takes to get rid of it, so I just played it safe and set it to 10 seconds. You can probably find better ways to deal with it.

TLDR: With AI and inspiration, it becomes trivial to rapidly prototype new TTPs.
If you can “think of it”, you can build it usually within a few minutes or hours with some good prompting.

Source code here:

https://github.com/jfmaes/downloadfix