Hacking, Code & Open Source Reads

Reverse Engineering ISP Hardware - Inside the Sagemcom F@st 5370

Christian Lehnert • 2026-04-28 • ~5 min read

Your "router" is not a router.

Strip the marketing skin off a Sagemcom F@st 5370 and you find a managed enterprise CPE that happens to share an address book with a few hundred thousand of its identical siblings. The interesting part isn't the box. It's the configuration substrate underneath — a TR-181-flavoured data model addressed by a thinly-disguised JSON-RPC API that Sagemcom calls XMO, and that is bit-for-bit consistent across the company's DSL, DOCSIS and GPON product lines.

That last sentence is the whole post. The rest is evidence.

What the 5370 actually is

The F@st 5370 / 5370E is a quad-WAN universal gateway: ADSL2+/VDSL2 single line plus a gigabit Ethernet WAN port for FTTH. Inside sits a Broadcom BCM63169 SoC from Broadcom's xDSL/PON CPE silicon family, four-by-four dual-band 802.11ac radios, a four-port gigabit switch and USB 3.0. It was shipped most visibly by Telia in Sweden, and rebadged in various forms across European operators.

Userspace is SWAN — Sagemcom's in-house middleware riding on top of an OpenWrt fork. You don't have to take my word for that; the build paths leak straight out of the serial bootlog, with strings of the form BP_TELIA_5370_v0-58-x_…/openwrt/build_dir/target-sagemcom_5370e-telia_arm_uClibc-… printed during init by Samba and friends. The build system tells you what it is before you've even looked.

The platform, not the box

The 5370 is DSL/FTTH. The point of this post is everything else.

Sagemcom uses the same SWAN+XMO stack across its full F@st gateway range:

  • DSL / FTTH: F@st 5355, 5364, 5366, 5370, 5380 (G.fast/VDSL/PON)
  • DOCSIS: F@st 3686, 3686 V3, 3890, 3890AX
  • GPON / XGS-PON: F@st 5655, 5656, 5657, 5670, 5688AX
    Different PHY, identical control plane. Crack the 5370 and you have effectively cracked the 3890 and the 5688AX. Whether the WAN drops in via copper pair, GPON ONU or DOCSIS 3.1 channel-bonding is irrelevant to the management surface; the operator's ACS sees the same data model regardless of how the photons or volts arrived.

XMO

XMO is Sagemcom's internal configuration API. It is not documented for end users. It is, however, exposed in plain sight — because the router's web GUI is a single-page jQuery app that talks to the device's own backend via XMO calls. The entire wire format lives in your browser, hanging off $.xmo. Open the dev console. It's right there.

The data model is TR-181-flavoured: every value is addressed by an XPath-like string under a Device/... root.

1$.xmo.getValuesTree("Device/UserAccounts/Users")
2// → [{uid:1, Login:"internal"},
3//    {uid:2, Login:"acs"},
4//    {uid:3, Login:"1234"},
5//    {uid:4, Login:"admin"}]

Two primitives carry the entire surface:

1$.xmo.getValuesTree(path)               // read
2$.xmo.setValuesTree(value, path)        // write

A namespace catalogue lives at $.xpaths listing every well-known subtree the GUI knows about: gpon, cableModem, ethernet, dect, myCloud, firewall, internetConnectivity, mySagemcomBox, trafficStats, technicalLogFast. Note that catalogue: a single firmware image carries paths for both gpon and cableModem. The box always knew it was part of a wider family. The GUI just renders the subset relevant to the SKU you happen to hold.

Three observations from years of community work against this platform are worth internalising before you ever plug another ISP-issued box into your network:

  1. There is an acs user. It is a TR-069 service account for the ISP's Auto-Configuration Server. You did not create it. You cannot disable it from the GUI. It exists on every unit, on every operator, on every PHY.
  2. Device/UserInterface/AdvancedMode = true does not actually unlock advanced mode in most operator builds. The data path remains. The HTML in /www/ has been amputated. The capability lives one layer below the visible interface, which is the entire architectural point of XMO.
  3. SSH on the LAN is one setValuesTree away. Walk to Device/UserAccounts/Users/User[@uid='3']/RemoteAccesses/RemoteAccess[@uid='3']/{Enabled, Port, LANRestriction}, set Enabled=true, Port=22, LANRestriction=ACCESS_ENABLE_ALL, persist via maintenance.saveRestore.save, reboot, and you land on a dropbear shell. Persistent. No firmware mod. No serial console. Just the API the box already trusts.

So what

This is not a backdoor in the legal sense. It is the device working precisely as designed. The ISP designed it. And the ISP can — and routinely does — call the exact same XMO surface from upstream over TR-069: push config, harvest telemetry, override DNS, restore the acs account if you've disabled it, revert your customisations on the next firmware push. The Telia community uncovered the operator's plumbing the cleanest way available: by reading the JavaScript the operator shipped them.

If you treat your ISP gateway as "your router," you have misclassified the device and silently accepted a control plane you do not own.

The challenge

A clean conclusion looks too neat for this kind of work, so sharpen it instead. Three questions worth answering before you next plug an operator-issued box into your network:

  • Whose key signs the firmware images this device accepts, and whose ACS does it phone home to before it ever asks you a question?
  • Is your "router" a routing device, or is it a remotely-administered tenant endpoint sitting inside your NAT?
  • If the answer to (2) is the second one — and on every Sagemcom F@st it is — what is your gateway actually for?
    Bridge mode plus a router you own answers all three at once. Most people will keep the ISP box. That is also a choice; just make it on purpose.

Further reading

Tagged:
#networking #firmware #reverse-engineering
← Back to posts