{"id":351,"date":"2026-04-08T21:31:39","date_gmt":"2026-04-08T21:31:39","guid":{"rendered":"https:\/\/thered0ne.com\/?p=351"},"modified":"2026-07-01T00:45:57","modified_gmt":"2026-07-01T00:45:57","slug":"reverse-engineering-nokia-beacon-3-1-part-1","status":"publish","type":"post","link":"https:\/\/thered0ne.com\/?p=351","title":{"rendered":"Nokia Beacon 3.1: Reverse Engineering (Part 1)"},"content":{"rendered":"\n

<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Introduction:<\/h1>\n\n\n\n

Hello again, fellow hackers and researchers. Today I\u2019m starting a major series: a deep dive into my reverse engineering journey with the Nokia Beacon 3.1. This router is remarkably hardened, and getting shell access required overcoming significant obstacles. While my research into potential vulnerabilities is ongoing, I\u2019m ready to share the roadmap for accessing root account and exploring the filesystem. If you\u2019re looking to conduct your own security research on this hardware, here is how the journey begins.<\/p>\n\n\n\n

Nokia Beacon 3.1 – Key Features:<\/h1>\n\n\n\n

This device is typically made for easy whole home Wi-Fi extension and is praised for reliable performance and simple app based setup. It’s known by its Mesh Networking, its advanced Wi-Fi features. <\/p>\n\n\n\n

The internals are:<\/p>\n\n\n\n

1x Gigabit WAN
2x Gigabit LAN.
Dual core 1.6 Ghz CPU
512 Mb DDR.<\/p>\n\n\n\n

The problem & mission<\/h1>\n\n\n\n

At first, I wasn\u2019t very surprised that the UI looked limited and not very user-friendly. I assumed this router was designed for regular users who just want to connect to Wi-Fi and not do much with advanced options. The lack of documentation was also problematic. I found in the user manual that there is a superadmin account, but I didn\u2019t have access to it because each router has its own password, and the same applies to the superadmin account as well.<\/p>\n\n\n\n

I called the ISP and asked for the superadmin password. To my surprise, the process was smooth and I obtained it easily. However, the victory was short-lived. once logged in, I found the configuration options were almost identical to the standard user UI. The mission then became clear: I had to find a way to gain true control over the device. It was frustrating to realize that, despite owning the hardware, I was still locked out of my own machine.<\/p>\n\n\n\n

Reconnaissance: Mapping the attack surface<\/h1>\n\n\n\n

A visual inspection reveals this beautiful cup shape:<\/p>\n\n\n\n

\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n<\/figure>\n\n\n\n

I was impressed by the build quality. The electronics are packed and supported by a heatsink.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n
\"\"<\/figure>\n\n\n\n

It\u2019s clear from the outside that this isn’t a budget router, but does that premium feel extend to the internal software? To truly own this device, I had to find out if the brain was as high performance as the body. <\/p>\n\n\n\n

I assume you already know how the UI looks. However, something important I noticed really annoyed me at first: all the payloads in POST methods are encrypted. The frontend is Angular based, and all the traffic between the frontend and the local backend is encrypted. A JavaScript function uses a public key stored in local storage during the browser session to encrypt the data.
I asked myself why they did that, since JavaScript can be modified at runtime using DevTools. What\u2019s the purpose of this?<\/p>\n\n\n\n

I came up with two possible answers:<\/p>\n\n\n\n

    \n
  1. Ensure the traffic is secure, since almost all routers use HTTP, which makes traffic visible in clear text on the LAN.<\/li>\n\n\n\n
  2. Security through obscurity. I think they also want to make things a little harder for hackers.<\/li>\n<\/ol>\n\n\n\n

    In a standard setup, HTTPS handles the transport, but you can still see the JSON in the clear in your Network tab. Here, they’ve added a custom application layer encryption that turns every interaction into an unreadable blob of ciphertext. I have to admit this was the first time I saw the body of POST requests encrypted.<\/p>\n\n\n

    \n
    \"\"<\/figure>\n<\/div>\n\n\n

    The First Wall : Body Encryption<\/h1>\n\n\n\n

    So the idea is simple, when I’m in front of a router, I try a command injection in ping\/traceroute to see if it’s vulnerable. This is a classic approach that every hardware hacker knows. However, to achieve that we have to bypass the first wall which the encryption. The approach is intercept the data before encryption, change it and encrypt it after.<\/p>\n\n\n\n

    I opened devtool and search for encrypt function in the source code and I found the function responsible to encrypt data. I put a breakpoint in the return instruction and I pressed the “Start test” in the diagnostics page.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    As you can see, now it is possible to see the body in clear text before encryption. The payload was this:<\/p>\n\n\n\n