StringRipper, a free portable Windows exe, pulls live URLs and regex matches out of running processes' memory

Download managers have a bad habit. They watch the clipboard, and the moment a URL lands there, they grab it. StringRipper’s author built around that. The README says “export and send to editor write straight to disk and never touch the clipboard,” and gives the reason: “some download managers love watching the clipboard and immediately grabbing every URL they see.”

That one design choice tells you who the tool is for. You point it at a running process, it walks the memory that process lets you read, and it hands back the web addresses sitting in RAM. The README’s own pitch is plain: “Give it a process and it digs through readable memory looking for URLs or whatever regex you throw at it.” It also “unwraps one layer of Base64, hex or escaping along the way,” so a link tucked inside an encoded blob comes out readable.

Browsers are the obvious target, and the author knows it. An “All instances” option “scans every process with the selected name in one go,” and the README adds a dry aside: “Browsers like to spawn twenty of them.” One click covers all twenty.

The speed numbers come from the author’s own machine, and the author says so: “On my 32 core machine I currently get around 277 MB/s scanning URLs and ~37 MB/s with regex.” Regex scanning is slower because it runs “in overlapping 1024-char windows,” and hits over 512 characters aren’t returned. The regex mode has presets “for the usual stuff: email, IPv4/IPv6, GUIDs, API keys, file paths, download URLs,” or you can feed it your own ECMAScript pattern.

The tool also reads files and folders. “Drop files or folders on the window or straight on the exe,” the README says, and “several at once is fine, folders get walked.” Results land in one list with no pages. The same value found twice, in another memory region or another encoding, is folded into one row with a count like ×50, and hits from different sources stay separate.

Memory is noisy, so the author filtered on purpose. “I made the URL detector a bit picky on purpose,” the README says, because “the host has to look real, so random memory garbage containing :// doesn’t flood the results.” A “Crap filter (on by default in URL mode) drops placeholder and XML-namespace hosts.” If you want the raw bytes anyway, a byte inspector shows “offsets, hex and ASCII in three panes that scroll together,” with 4 KiB around the hit.

Exports write TXT, CSV, JSON or append to a SQLite session, “and only what the filter currently shows.” One detail shows someone has been burned: CSV cells that start with =, +, - or @ “get a leading quote so Excel doesn’t run them.” Anyone who has opened a CSV full of scraped strings in Excel is allowed to nod.

You can also end a process from inside it, with limits. “Kill… ends the selected process after asking,” and “Windows’ own core processes (System, csrss, lsass, winlogon and friends) are refused outright.” Other programs from the Windows folder and services get a second warning that defaults to No.

It isn’t a skeleton key. “It only reads memory the current user is allowed to open,” and “reading a higher-integrity process needs an elevated StringRipper.” The exe “asks for nothing at startup, it runs as whoever started it.” If the target is locked down, it says so and asks you to restart it as administrator yourself.

My guess is the interesting use is the unglamorous one. When a launcher, updater or browser extension phones a server you didn’t know about, “what URLs is this holding?” is the first question, and a one-file exe with a filter that hides junk answers it in a few clicks. The MIT license means anyone can bolt the same idea onto something bigger.

The build notes are worth reading before you plan on compiling. The README’s build section lists “MSVC C++ build tools and an FXChainPlayer checkout,” because the process reader comes from an earlier backend the author wrote for that project.

The download manager never gets a vote.