Rooting, firmware analysis and persistent credentials of TP-Link TL-841N

2 Aug 2026

Now, fto maine conscionable preface this pinch a disclaimer:

… and get utilized to this puppo, arsenic you whitethorn spot this a fewer much times successful this station :’).

In ray of continuing my bumbling foray into the hardware hacking landscape, I bought a bottom-of-the-line $10 TP-Link TL-841N(EU) router disconnected a random chap connected Facebook Marketplace, successful a thrilling, high-stakes woody conducted successful the mediate of… a adjacent mall.

My volition down specified a daring speech was to practice the end-to-end process of pulling isolated an IoT device to flick astatine it, access debug logs, perchance get a guidelines shell, believe various kinds of firmware extraction (via UART & via on-chip flash memory), and moreover person a mosey astir the filesystem for immoderate imaginable information vulnerabilities later down the road.

Here’s a short overview of the travel truthful far, documented below:

Hang astir until the extremity for discovering what kinds of various plaintext, hardcoded creds from the erstwhile proprietor (censored) could beryllium recovered connected this device… 1 of which would past even a afloat “router reset”.

Yeah. Kinda… nary bueno?

Let’s excavation in.

I began by searching the router exemplary number up connected the FCCID to cheque for its datasheet, to get accusation connected the PCB, voltage levels & the disposable chips connected the board.

Opening it up and uncovering the very-well-labelled UART ports for serial/debug interface access was straightforward, pinch 1 quirk being that the flash was recovered connected the underside of my committee - exemplary number GD25Q64CSIG ( datasheet).

If your instrumentality isn’t arsenic friends pinch labelling, you tin besides usage a multimeter to probe each suspected UART larboard astatine footwear clip to find which pin is which - the device’s TX pin should person a fluctuating voltage during boot (due to it transmitting various footwear logs successful the shape of serial 1s and 0s, corresponding to fluctuations successful voltage), and the GND pin should beryllium 0V.

My trusty AliExpress USB-to-UART adapter (which I checked to corroborate supports some 3.3V and 5V output, truthful we don’t fry anything) had the pursuing pinout/wire colouring:

So, I connected the USB GND to the router’s GND larboard (or tin conscionable touch grounded metallic connected the board), USB RX to the discovered router’s TX port, and USB TX to router’s suspected RX larboard (which tin beryllium recovered by trying the remaining 2 pins, until you get a successful input by spamming a cardinal connected your keyboard erstwhile connected).

I soldered excavation successful for a better/persistent connection, & plug-&-play functionality 😜.

Once I identified what /mnt/dev instrumentality my USB-to-UART instrumentality was and sewage connected up pinch picocom -b 115200 --logfile bootlog-tplink.txt /dev/tty.usbserial-1210 (using the communal baud complaint of 115200, which worked), we tin spot we’re dropped into a guidelines ammunition erstwhile again! Too easy 😅.

Connecting my machine straight via 1 of the router’s LAN ports, we tin beryllium assigned an IP and entree the admin console arsenic expected:

So, now I could spot & navigate the filesystem, I wanted to dump & transportation it to my section instrumentality to execute immoderate preliminary analysis!

Listing the flash partitions astatine /proc/mtd, arsenic good arsenic a fewer different equine details, gives america a bully constituent to start:

Preparing our receiving TFTP server

So we tin transportation the firmware files over, I installed & started a tftp-now server pinch tftp-now service connected my Mac (with brew, arsenic americium connected pome silicon).

NOTE: Ensure to create a files successful your location directory corresponding to wherever you’re transferring the record from connected your router (for me, from ~/var), different you’ll get a “No specified record exists” correction erstwhile the tftp supplier attempts to put its distant record connected your machine (as it does truthful astatine the aforesaid way that it’s uploading it from, /var/).

To lick the (many) errors shown below, I created a impermanent var files wrong my ~ location directory to lucifer up pinch the record way the router’s tftp wanted to “put” to:

Now, link your study machine to the shelled router's LAN port, & cheque that it's gets assigned an IP (like `192.168.0.200`) truthful they tin talk to 1 another, contempt not having net access.

Switching backmost to our UART relationship to the router, and checking we tin statesman to create a dump of the first flash partition pinch a instrumentality for illustration feline (if your router doesn’t person dd, for illustration mine).

NOTE: Keep an oculus connected your router’s storage - if yours is besides afloat (like excavation was - usage df to check), constitute the firmware dumps incrementally into the /var directory, which is RAM-backed and my largest partition (still only ~6.4 MiB).

To debar overloading the RAM, for each partition dump, I utilized the beneath process:

1. **Dump flash partition pinch feline /dev/mtd0 > /var/boot.bin
2. Transfer it complete to the IP reside of your receiving study laptop pinch tftp -p -l /var/boot.bin 192.168.1.100
3. Delete transferred flash partition pinch rm /var/boot.bin, and repeat.

Tedious, but really it had to beryllium (unless performing an on/off-flash spot extraction, aliases you person a USB interface connected your router to constitute to).

However, for a CLI value of life boost arsenic stated successful this article, “we tin make our lives overmuch easier by uploading our ain fully-loaded BusyBox via the existing TFTP customer connected the device. You whitethorn find a precompiled little-endian MIPS BusyBox binary connected the official website.” This will springiness america entree to significantly much modular linux commands to usage connected the router.

Again, well, it should beryllium evident, but…

We’re learning. It worked successful the end. Firmware files extracted to my section machine complete tftp & UART!

An replacement measurement of analysing the filesystem is via an on-chip (or off-chip, if you want to desolder a mini IC and person a basking aerial gun) firmware extraction. For this, I utilized the " poor man’s flash extraction tool" - the CH341A.

I first recovered the flash spot - connected the backmost of the committee - and checked it was a flash spot pinch it’s exemplary number. This besides told maine that the flash rom voltage is astatine 3.3V ( datasheet) truthful the CH341A one person is safe to use. Some chips tally astatine 1.8V, not 3.3V, truthful earlier cautiously placing the clip connected the clip and plugging successful the programmer, check your chip’s voltage (via online datasheets aliases multimeter). If it’s 1.8V, usage a voltage adapter (bought pinch the adapter) to debar imaginable damage.

Also, guarantee the clamp-side’s reddish cord is successful statement pinch to PIN 1 of the router’s flash chip, which should beryllium (typically marked pinch a mini circle successful the corresponding corner).

Beginning of the spot exemplary number often corresponds to type: truthful for our 25Q64CSIG, the 25 astatine the commencement intends we would position our 8 pins complete the slots marked arsenic 25 SPI BIOS, whereas if our spot said 26, it would spell connected the EPROM I2C side.

After seating the PCB & connected cord successful the USB programmer with the RED cord connected the apical right, arsenic pictured below, double cheque that the reddish cord connected the clamp-side is attached to PIN 1 of the router’s flash chip (typically marked pinch a mini circle, arsenic mentioned before).

- [Video explaining the CH341A relationship process successful item (Matt Brown)](https://www.youtube.com/watch?v=6Z5aWu9tqmA&t=207s)

Then, simply instal & occurrence up flashrom, and tally the pursuing bid to extract the firmware!

Now we person modem.bin, which (being a afloat flash dump) should incorporate wrong it, the aforesaid manually-extracted flash partitions arsenic extracted via ftpd. However, to analyse it much meaningfully, we tin divided it up into the various boot, config, rootfs sectors for illustration earlier pinch dd.

Manually carving retired the flash sectors

Using the memory sizes/addresses recovered earlier pinch /proc/mtd erstwhile connected the router, we tin manually carve our modem.bin flash dump into the identified sectors for analysis.

To get our first sector, mtd0, which presumably contains U-Boot based connected our observed footwear logs, we tin usage dd to carve the specified chunk retired of modem.bin:

In this case, my U-boot assemblage wasn’t initially identified by binwalk automatically erstwhile I first analysed modem.bin, owed to apt being a customised, vendor-modified type of U-boot. Hence why I decided to carve retired the sectors manually according to the router’s /proc/mnt information, conscionable for immoderate further accuracy and organisation.

The beingness of a customised U-boot was confirmed pinch strings uncovering Ralink UBoot Version successful the mtd1 partition (the presumed linux kernel) erstwhile this portion was carved retired and analysed later on, indicating this was a Ralink-modified U-Boot version.

Anyway, moving the strings bid again connected the extracted suspected U-boot mtd0 partition confirms it is the portion of the flash containing U-Boot, and helps america place much info astir it, including U-Boot’s type number and behaviour.

I repeated the supra process to carve our each assemblage of the firmware dump, until I had each sectors, mtd0-mtd6, for analysis.

I asked the friends (?) neighbourhood AI chatbot to thief representation a ocular summary of the spot truthful far:

If we usage binwalk -e to extract what it tin automatically from the original modem.bin, it besides gives america the uncompressed kernel image (mtd1) successful the shape of decompressed.bin, which checks retired erstwhile looking astatine its identified magic bytes below:

Another logic that I had to carve retired and extract the mtd2 squashfs filesystem manually pinch dd was, erstwhile again, because I’m connected a mac. And the sasquatch bid initiated arsenic portion of binwalk’s extraction process (when extracting a squashfs sector) continued to neglect for maine (despite being installed…),

Oh well. At slightest we cognize what to do from supra to get and un-squash the rootfs for analysis:

Note: If you get errors for illustration create_inode: could not create characteristic instrumentality squashfs-root/dev/zero, because you're not superuser!, don’t panic. As the filesystem contains instrumentality nodes nether /dev, your machine (MacOS for example) whitethorn not licence a normal personification to create those typical instrumentality files. However, they’re (allegedly) not usually needed for firmware analysis, but you tin usage axenic Linux to unsquash this while preserving the instrumentality nodes pinch sudo.

(yes, one cognize this would’ve conscionable “all worked” connected linux. one americium waiting for my mediocre mac babe to dice earlier the last leap.)

Comparing the 2 extraction methods (left done via Method 1, tftpd, and correct via on-chip extraction, Method 2), we tin spot nearly identical copies of the filesystem to analyse!

Now, we tin proceed to analyse the dumped binaries/unsquashed filesystems utilizing strings, grep, and binwalk, to understand really the router useful and possibly moreover uncover immoderate juicy vulns later down the track…!

But, I’ll time off the groundbreaking vulnerability reversing to portion 2 (or much tin souls than I), arsenic this is getting long, but acknowledgment for sticking on for the ride! We’ve eztracted firmware from a router successful 2 ways; via tftp complete UART, arsenic good arsenic by utilizing flashrom for a nonstop on-flash-chip firmware extraction. \

But… we should person a peek earlier we go, shouldn’t we? Just a little?

NOTE: I americium conscionable poking astir present to study much astir what is/isn’t exposed & accessible connected a reasonably emblematic IoT instrumentality that I ain and person afloat authority over. The instrumentality was mill reset earlier being sold to me, and nary discovered credentials were utilized to entree immoderate unauthorised material.

Now, to present you to the inexpensive & nasty firmware analyst’s favourite tool: strings.

As stated connected it’s man page, strings "…looks for ASCII strings successful a binary file, object, aliases modular input.". So we tin quickly parse compiled .bin files and the for illustration for a soiled peek astatine immoderate readable strings that whitethorn beryllium within, which is astir apt to beryllium either matter the programme prints, aliases plaintext configuration values (depending connected compilation type, of course).

Examining the mtd3-config.bin first, wherever router-specific configs should live, pinch strings mtd3-config.bin | less, we tin really find the router’s hard-coded WPS password successful plaintext, i.e. the 1 printed connected the backmost of the router!

Well, uh, upon further research: we’ve stumbled upon what appears to beryllium a antecedently discovered “CVE” ( CVE-2026-4346), successful fact:

“The vulnerability affecting TL-WR850N v3 allows cleartext retention of administrative and Wi-Fi credentials successful a region of the devices flash representation while the serial interface remains enabled and protected by anemic authentication. An attacker pinch beingness entree and the expertise to link to the serial larboard tin retrieve delicate information, including the router’s guidance password and wireless web key. Successful exploitation tin lead to afloat administrative power of the instrumentality and unauthorized entree to the associated wireless network.”

(Although I’d say, if someone’s sewage hardware entree to your router’s serial interface/flash spot successful the first place, you’re already beautiful borked. And I wouldn’t telephone it protected by “weak authentication”… no authentication.)

Another gem uncovered by strings mtd3-config.bin | grep -ri "pass" are hardcoded credentials for what appears to beryllium erstwhile PPPoe ISP/router provisioning credentials (the @unitiair information powerfully suggesting an ISP/service-provider account).

Oopsies.

And for an moreover bigger oopsies/yikes, even aft performing a router mill reset, these credentials were still accessible via the freshly-dumped config partition of the firmware.

Given that I americium not the section mini business whose email is listed successful plaintext successful the un-redacted type of the image above, nor a customer of Unitiair, I don’t judge I should still beryllium seeing this aft the router was “reset”.

This intends that not moreover a FACTORY reset of the device (holding down RESET fastener for 10 seconds, and verifying reset was performed by checking footwear logs, arsenic elaborate successful the TP-Link documentation), which astir consumers would presume would swipe each personification OR ISP-modified settings from it, can genuinely erase the ISP PPPOe WAN credentials.

So, a mill reset leaves a erstwhile subscriber’s broadband authentication credential recoverable from persistent flash storage., successful Firmware Version: 0.9.1 4.16 v0001.0 Build 170622 Rel.64334n (the latest for my EU exemplary of the router)

Whilst you don’t look to beryllium capable to authenticate to this ISP itself (which, luckily for them, requires an relationship number to login, dissimilar my ISP which uses email), user/ISP modified credentials stored successful plaintext persisting aft a reset is… not a awesome privateness motion for what is considered a “factory reset” device.

Anyway…

Searching for much “sensitive” strings successful the extracted root-fs (mtd2), we get some the router login from ./web/help/RestoreDefaultCfgHelpRpm.htm, arsenic good arsenic the hashed password of the admin OS user.

So, we tin login to the router admin interface acknowledgment to the aureate keys of… admin:admin. Of course!

Additionally, arsenic we recovered an UNSALTED admin hash from /etc/shadow, we tin effort and ace the admin OS personification account’s password (whose permissions are mapped to root, GUID=0, truthful an relationship that’s kinda useful):

• Wordlists

Our maestro relationship password was, of course, cracked wrong a fewer seconds…

admin:1234 - fun times. i’m quaking successful my boots :’).

well, until adjacent clip - spot you for the squeakquel!