It’s very common to do so using a combination of QEMU user-space emulation, and chroot. For example:

sudo apt install qemu-user
sudo chroot /path/to/embedded/rootfs /bin/sh

On the Ubuntu version I run, this works because the qemu-user package also installs a systemd service that adds binfmt interpreters that invokes the qemu binaries to emulate execution of non-native binaries. The qemu-user binaries are statically compiled, allowing them to be used even within a chroot.

However, using chroot is somewhat sub-optimal because the processes in this environment run as real root on the host. Vendor binaries may end up trashing the state of the host (block devices, network interface states, etc…) as part of how they operate. They may also make other assumptions like init being PID 1.

I’ve found that a much nicer way is to use unshare to create an unprivileged container instead of using chroot:

unshare --fork \
    --user \
    --mount \
    --pid \
    --ipc \
    --uts \
    --time \
    --net \
    --map-root-user \
    --mount-proc \
    --root=/path/to/embedded/rootfs \
    /bin/sh

On Ubuntu, some hardening options may need to be relaxed to allow unprivileged users to create new user namespaces:

sudo sysctl -w kernel.unprivileged_userns_clone=1
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

This gives an environment where:

• The program run is given PID 1
• The program run appears to be running as root (but in actuality, is limited in privileges as the user running unshare)
• Host processes aren’t visible
• Host network interfaces aren’t accessible (if networking is needed, it’s always possible to pipe through a veth interface)
• Changes to the hostname/time don’t affect the host
• Calling reboot or poweroff merely shuts down the container, rather than the host.

This is much safer than giving full host root access, and is much closer to emulating a real execution environment for the firmware.

The final proof-of-concept exploit code is available at https://github.com/tangrs/cve-2026-1668-poc.

Popping a shell

The most common exploit payload is one that somehow gives the attacker interactive shell access to the vulnerable system (commonly known as shellcode). When exploiting remote systems, the most basic form of such a payload on Linux looks something like:

1. Somehow obtain a TCP socket that is connected to the attacker’s machine.
2. Redirect stdin, stdout and stderr (file descriptors 0, 1 and 2) to the socket using dup2.
3. Exec a shell binary in interactive mode (i.e. /bin/sh -i).

There are two approaches for obtaining a socket to the attacker’s machine:

• Listen for a TCP connection on an unused port, and wait for the attacker to connect to it.
• Make a TCP connection to an attacker controlled IP address (i.e. a reverse-shell).
  • This is useful in cases where there are firewalls preventing inbound connections to the vulnerable system, but allows outgoing ones.

The attacker can use netcat to either connect to or accept a TCP connection from the remote end and interact with the remote shell.

For the proof-of-concept, I chose to implement the former approach.

Payload crafting

The proof-of-concept payload has the following logical components:

• The data that we need to overwrite the connection state-tracking data in memory to trigger the exploit.
• The actual MIPS instructions (i.e. the shellcode) that will be executed upon triggering the exploit.
• Any static data that the shellcode needs.

While it’s possible to craft the payload entirely in a hex editor, doing so is incredibly time-consuming and error-prone. We can do much better by making good use of the GCC toolchain.

Using the assembler to encode data

The initial part of the payload are various bits of data that overwrite the necessary structures in memory. While we could hand-craft this in a hex editor, it’s much neater and maintainable to encode this in assembler for many reasons:

• We can have code comments that explain what each piece of data is doing.
• We can use assembler macros to generate data (e.g. generate padding with .fill).
• We can use linker symbols and expressions to avoid needing to calculate memory addresses by hand (e.g. .word start instead of .word 0x2c119c60 to refer to the address of the symbol start).

We start the file off with .section .data.head to tell the assembler to place the following assembly into a ELF section called .data.head. This allows us to place the data at the start of the final payload as defined in the linker script (described later).

The assembly may contain .word directives to place hard-coded integers/symbol addresses, or it can contain MIPS instructions. It’s important to be aware that the assembler synthesizes branch delay slots by default, so some MIPS instructions may actually end up being two instructions in the final output.

Developing the shellcode

At this point, we can simply define a start label and write the entire shellcode in MIPS assembly:

.global start
start:
# ...

At a high-level, our shellcode needs to make the following syscalls:

• socket to create a TCP socket.
• bind to an address (in our proof-of-concept, we bind to 0.0.0.0:8888).
• listen for connections.
• accept a connection.
• dup2 each of file descriptors 0, 1, and 2 to the new connection socket file descriptor.
• execve /bin/sh -i to actually pop the shell.

The process for making a syscall under Linux for MIPS is summarized as follows:

1. Set v0 to the requested syscall number.
2. Up to 4 arguments are passed through registers a0 - a3.
3. Execute the syscall instruction.
4. The return value is stored in v0. If a3 is non-zero, an error has occurred, and v0 contains the error number.

System call numbers can be found in the unistd.h Linux kernel UAPI header.

Developing the shellcode in C

While handcrafted assembly can be nice and compact, it would be neat if we could develop the shellcode in a higher-level language like C.

For this to work, the C compiler requires that, upon entry to a function, the stack pointer is correctly initialised, and that code calling the C functions obey the MIPS calling convention. Fortunately, our code is being called from the HTTP event handler as if it were a normal C function call, so the execution environment is already amenable to running C. This means our entry point can simply be a normal C function.

The major caveat here is that we mustn’t call any functions in the standard library that may come with our toolchain. We can’t assume that the functions from the toolchain’s standard library will work in the target process, since the functions’ implementations are often tightly coupled to the runtime environment provided by the toolchain’s startup code. To prevent accidentally including unwanted dependencies (e.g. the toolchain’s startup code), code should be compiled with the following flags: -nostdlib -ffreestanding.

The most straightforward and least-dependencies approach is to implement every single function that we need ourselves. We can perform syscalls using inline assembly, and structure definitions can be declared inline (or with very careful use of the Linux kernel UAPI headers described above).

Alternatively, if memory addresses of functions in the target process address space is known, we can use static function pointers to call functions in libraries that are already loaded in the target process. For example, if the address of execv is known to be at 0x0000c200, we can define a wrapper function as:

static inline int execv(char *path, char *argv[]) {
    return ((int (*)(char *, char *[]))0x0000c200)(path, argv);
}

Making use of linker scripts

We can use linker scripts to control the placement of all the components that will appear in the final payload. We also specify where in memory the start of the payload will be loaded (i.e. 0x2c10e154) so the linker can calculate absolute memory addresses for us correctly.

SECTIONS
{
	.data 0x2c10e154 : {
		*(.data.head)

		/* ... */

The *(.data.head) line means that the .data.head section must appear as the first thing in our final payload. Some other sections must be added to support running C code, but their placement is otherwise unimportant in this particular case.

We also discard all unnecessary sections (e.g. automatically generated debug information, or build IDs), since we don’t want them appearing in our final output.

	/DISCARD/ : { *(*) }
}

Testing the payload

To test the payload without having to perform an entire exploitation cycle, we can compile a very minimal executable containing only the payload that can be run under QEMU user-space emulation on the host: mips-linux-gnu-gcc -O3 payload.c -e start -nostdlib -ffreestanding -o test

Previewing the final output

The output of all of our compilation and linking is an ELF file. We can use mips-linux-gnu-objdump -D input.elf to view the final disassembly of our payload. We should expect that the memory addresses match where we want all of our data and code to be placed in the target process.

Dumping the raw memory image

We can convert our output ELF file into a raw memory image using: mips-linux-gnu-objcopy -O binary input.elf output.bin.

Conclusion

With our final payload, we can perform the exploit, connect to the socket listener that we opened in the shellcode, and be greeted with a root shell:

/bin/sh: can't access tty; job control turned off
/etc # busybox id
uid=0(root) gid=0(root)
/etc # 

HTTP server event loop

It is first helpful to understand the the high-level architecture of the firmware’s HTTP server.

The server is event-driven and can hold state for up to 16 connections simultaneously (though it appears that it can only serve one at a time). The event loop repeatedly loops over all the active connections and services any that are ready.

A simplified summary of the event-loop looks roughly like the following:

1. Read all active connection slots and collect socket file descriptors.
2. Call select on the file descriptors with a 5 second timeout.
3. Loop over all the active connections slots.
4. If the associated socket has activity (as indicated by the results of the select call), service the request. Otherwise, check if the last activity was too long ago, closing the connection if so.
5. If there was an error servicing the request for whatever reason (including timeouts), call the error notification callback function, and close the connection.

The fields of the connection state-tracking structure relevant to this exploit are:

• Socket file descriptor number
• Unix timestamp of the last activity on this connection
• Enum representing the state of the connection tracking entry (i.e. whether it is active or free)
• Pointer to the error notification callback function

Each connection state-tracking entry also has an associated per-connection memory pool for allocating temporary buffers in the HTTP request handler. The memory pool structure immediately follows the associated state-tracking structure in memory.

Both the memory for the connection state-tracking structure and the per-connection memory pool is pre-allocated at init time.

Hijacking the control flow

The out-of-bounds write happens from within the per-connection memory pool and gives us the ability to overwrite anything in the memory that follows.

The goal here is to overwrite some part of memory that will affect the control flow somehow. The most straightforward way is to look for function pointers, since they let us hijack the control flow to arbitrary locations. Conveniently, the memory that follows the per-connection memory pool contains a connection state-tracking structure, and the most obvious candidate within that structure is the error notification callback function pointer.

We can combine overwriting the function pointer and the last activity timestamp to hijack the control flow. We set the error notification function pointer to the memory location we want to eventually jump to, and the last activity to a timestamp in the past (e.g. 1970-01-01 00:00:00). This represents a timeout condition, causing the error notification function pointer to be called upon the next iteration of the event-loop.

Here is a diagram summarising the memory layout (addresses are in ascending order):

          ...
~                     ~
+---------------------+
| Connection State #2 |
| |-> last_activity   |
| |-> error_notif_cb  |
+---------------------+
| Allocator  Metadata |
+---------------------+
|    Connection #2    |
|   Request Handler   | -+ [ Start of out-of-bounds write ]
|     Memory Pool     |  |
+---------------------+  |
| Allocator  Metadata |  |
+---------------------+  |
| Connection State #1 |  |
| |-> last_activity   |  |
| |-> error_notif_cb  |  |
+---------------------+ -+ [ End of out-of-bounds write   ]
| Allocator  Metadata |
+---------------------+
|    Connection #1    |
|   Request Handler   |
|     Memory Pool     |
+---------------------+
~                     ~
          ...

Putting it all together

Interestingly, connection state-tracking entries appear to be allocated in reverse order of memory (that is, older connections use entries at higher memory addresses compared to newer connections). Unfortunately, it is currently unclear to me why this is the case. The code for the event handling loop has been heavily optimized by the compiler, making the logic difficult to follow.

In practice, this does not matter because the placement and the values of the connection state-tracking entries on new connections is highly deterministic (at least on a fresh boot). Thus, I did not feel the need to accurately reason about the event-handling logic for the purposes of making this exploit work.

To set up the target memory in a way that lets us hijack the control flow, we first open a connection to reserve a connection state-tracking entry (connection #1 in the diagram below). Note that this is merely acts as a placeholder and we don’t actually write anything to it.

We then open a second connection (connection #2 in the diagram below), which is allocated the entry immediately before connection #1 in memory, and then write a carefully crafted payload. This overwrites the values in the connection #1 state-tracking structure with values that we need in order to hijack the control flow.

Once the HTTP handler on connection #2 returns (e.g. through a premature connection closure), the event loop will find that connection #1 has “timed out”, and calls the error notification callback (whose address we just overwrote).

Now that we have control over the program counter, we can redirect execution to any executable region in memory.

But where?

Let’s see if there are any candidate executable memory regions that we can usefully redirect execution to.

We’re able to dump a list of memory mappings and their associated permission bits using GDB. Here is the output with the less interesting parts elided:

(gdb) info proc mappings
process 257
Mapped address spaces:

Start Addr End Addr   Size       Offset     Perms File 
0x00400000 0x0047f000 0x7f000    0x0        r-xp  /tplink/image/usrImage/app/sbin/httpd 
0x0048e000 0x00498000 0xa000     0x7e000    rw-p  /tplink/image/usrImage/app/sbin/httpd 
0x00498000 0x004d2000 0x3a000    0x0        rwxp  [heap] 
0x2aaa8000 0x2aaaf000 0x7000     0x0        r-xp  /lib/ld-uClibc-0.9.33.so
...  
0x2ba19000 0x2c291000 0x878000   0x0        rw-p
...
0x7fa99000 0x7faae000 0x15000    0x0        rwxp  [stack] 
0x7fff7000 0x7fff8000 0x1000     0x0        r-xp  [vdso] 

All of the memory associated with HTTP request handling, and connection metadata tracking is located in the 0x2ba19000-0x2c291000 region, which, unfortunately, does not have the execute permission bit set. This is rather unfortunate because it seems like we can’t simply load in shellcode along with the payload, and jump directly to it.

I was considering employing some sort of return-oriented programming to get around this. Or, find a way to get shellcode loaded somewhere predictable in the heap or stack (which for some reason, has execute permissions).

An amusing note on memory permission bits in MIPS

On a hunch, I decided to test what would happen if I did attempt to execute code in a non-executable memory region. Surprisingly, it worked!

My guess, which seemingly turned out to be correct, was that the 4KEc MIPS core on the SoC does not implement the Inhibit Execute bit. The 4KEc MIPS core implements an older revision of the ISA specification without the IX bit.

Amusingly, this means that there is literally no hardware mechanism for enforcing the execute memory permission bit. For all intents and purposes, we can simply ignore it, which greatly simplifies exploitation.

Conclusion

We have now turned an out-of-bounds write vulnerability into a primitive that allows us to gain arbitrary code execution. In the next post, we explore some ways of crafting a useful exploit payload.

Notes

It’s worth mentioning that modern hardening mechanisms would have made exploitation much less straightforward (perhaps even impossible):

• Almost all commonly used modern CPU architectures have support for preventing executing code in non-executable memory regions.
  • We would have had to find some other way to obtain arbitrary code execution.
• Modern compilers and operating systems employ address space layout randomization.
  • This would have made crafting the payload much more difficult, since we wouldn’t know exactly where our payload was loaded in memory.

This was reported to security@tp-link.com, and in mid-March 2026, a fixed version of the firmware was made available. TP-Link has also published a security advisory, recommending users to update their firmware on affected devices. If you have an affected device, I recommend you update the firmware immediately.

It is now 90+30 days after the initial report and a fix is available. It’s time to discuss the vulnerability in more detail.

The vulnerability

The vulnerability exists in the httpJsonPost function of the httpd binary, which reads and returns the body of a POST request as a C string. Here is the relevant excerpt of decompiler output from Ghidra that shows the logic:

pcVar1 = (char *)httpMimeHdrGet(req,0,"Content-Length");
contentLength = strtoul(pcVar1,(char **)0x0,0);
if (contentLength != 0) {
  p = (mem_pool_t *)httpReqMemPartIdGet(req);
  buf = (char *)memPoolAlloc(p,contentLength + 1);
  if (buf == (char *)0x0) {
    wmError(-100,"httpJsonPost: unable to allocate mem for entity");
    return -1;
  }
  n = 0;
  i = 0;
  do {
    readBytes = httpBlockRead(req,buf + n,contentLength - n);
    i = i + 1;
    n = n + readBytes;
    if ((readBytes == -1) || (contentLength == n)) break;
    usleep(2000);
  } while (i != 0x14);
  buf[contentLength] = '\0';
  if (out != (char **)0x0) {
    *out = buf;
    return 0;
  }
}

At a high-level, the logic does the following:

1. Reads the Content-Length header value as a string.
2. Use strtoul to parse the string into contentLength, as an unsigned integer.
3. Check whether contentLength is zero (i.e. the request included a correctly-formatted, non-zero integer as the Content-Length).
4. Allocate contentLength + 1 bytes of memory to store the request + null byte to terminate the buffer into a C string.
5. Check whether the memory allocation failed.
6. Read up to contentLength bytes of data into the allocated buffer.

The problem with this logic is that it does not take into account of integer overflow. If contentLength is set to 4294967295, it passes the length check, but overflows to zero once incremented. Thus, memPoolAlloc is actually called with an argument of zero, and the implementation happily returns a pointer to a zero-sized block of memory. At this point, any write to the returned pointer is an out-of-bounds write.

For non-HTTPS requests, httpBlockRead is essentially a wrapper around a read syscall. On the Linux kernel version running on the device, the read syscall is happy to take a large size (i.e. 4294967295) parameter, and just do short reads (we do not need to actually send 4294967295 bytes of payload). FWIW, this did not work when I tested this under QEMU emulation - instead, read just immediately returns an EFAULT error.

Unfortunately, on HTTPS requests, httpBlockRead ends up calling the OpenSSL SSL_Read function, which treats the size parameter as a signed integer and fails the early length-check for negative sizes (because 4294967295 in interpreted as -1). Because of this, I have not found a way to trigger this vulnerability when using HTTPS. However, this is a moot point because the firmware still responds to HTTP API requests on a default installation of the latest firmware at the time.

The fix

This vulnerability was fixed by improving the length checking. Previously, it was simply a comparison for zero, allowing for overflow when evaluating contentLength + 1:

if (contentLength != 0)

The improved logic now checks that the result of contentLength + 1 will never exceed 0x20000:

if (contentLength - 1 < 0x20000)

Having looked at the assembly code, this is indeed an unsigned integer comparison, so the check should work even if contentLength - 1 underflows. The comparison will be against 0xFFFFFFFF, which is greater than 0x20000, failing the check as intended.

As far as I can tell, this improved length checking is sufficient for patching the vulnerability.

Triggering the vulnerability

The most convenient way to trigger the vulnerable httpJsonPost function is via the /data/login.json HTTP endpoint because it does not require any authentication, and is always available.

We can send the following HTTP request to trigger the vulnerability:

POST /data/login.json HTTP/1.1
Content-Type: application/json
Content-Length: 4294967295

Any data we include in the body of the POST request can be used to overwrite whatever happens to be in memory below the buffer.

In the next post, we will look at how we can exploit this vulnerability to gain arbitrary code execution.

Disclosure timeline

• 2025-11-22: Vulnerability reported to security@tp-link.com.
• 2025-11-26: TP-Link acknowledged receipt of the report, pending initial triage.
• 2025-12-23: Sent a follow-up email, asking for updates.
• 2026-01-10: TP-Link acknowledged the vulnerability, pending verification and remediation.
• 2026-01-15: Sent a follow-up email, confirming the vulnerability is still exploitable on the latest firmware, and asking for an update on remediation.
• 2026-01-26: Sent another follow-up asking for updates, after no reply.
• 2026-01-28: TP-Link claimed the vulnerability has been addressed in their development build.
• 2026-01-29: TP-Link sent a pre-release firmware image for verifying that the vulnerability has been sufficiently addressed.
• 2026-01-29: Sent confirmation that the vulnerability appeared to be sufficiently addressed.
• 2026-01-30: Vulnerability assigned to CVE-2026-1668.
• 2026-02-12: TP-Link asked for an extension to the disclosure deadline.
• 2026-02-12: Granted extension until 2026-03-16.
• 2026-02-20: 90 days elapsed since initial vulnerability report.
• 2026-03-14: TP-Link made fixed firmwares public, and published security advisory.
• 2026-03-22: 90+30 days elapsed since initial vulnerability report.

Similar bugs in other TP-Link devices

• CVE-2026-0918 seems to describe a similar bug in Tapo C220 and C520WS devices.
  • TP-Link Security Advisory
• CVE-2025-14299 describes a similar bug in Tapo C200 devices.
  • Blog post by evilsocket.
  • TP-Link Security Advisory

The core requirement I have for my personal data is: total compromise of a single TrueNAS machine should not be able to compromise previous backups stored on the other TrueNAS machine.

In practice, I belive this means:

• Snapshots must be pulled by the backup machine, rather than pushed by the target.
  • This prevents a potentially compromised target from compromising backups on the backup machine.
• The credentials used by the backup machine must not have privileges that exceed what is required (i.e. no write access on the target).
  • This prevents a potentially compromised backup machine from compromising data on the target.

TrueNAS offers functionality for implementing the former and it is built into the web UI.

However, the default snapshot replication functionality offered by TrueNAS typically requires the use of a privileged user on the target (presumably in order to run zfs commands). The best built-in mitigation offered seems to be to use an otherwise-unprivileged user that has sudo access limited to the zfs command. Unfortunately, still seems too broad of a privilege, since it doesn’t preclude write-access.

The good news is that TrueNAS does seem to bless the use of zfs allow commands to implement finer-grained controls (it is mentioned in the tooltip for the “Use Sudo For ZFS Commands” option), despite the warnings to the contrary shown when you open a shell. The bad news is that there doesn’t seem to be much clear guidance in the TrueNAS manuals on how to implement this.

Here is how I ended up implementing low-trust snapshot replication:

Create an unprivileged backup user on the target:

• It should not be a member of any groups, or have an SMB account.
• It should have a real shell (i.e. not nologin).
• It should have a home directory somewhere (in order to store a ~/.ssh/authorized_keys file).
• sudo access should not be allowed (not even for zfs).

Grant the backup user privileges to send snapshots:

With an admin account, open a shell and use the following command:

sudo zfs allow <user> send,hold

Add backup credentials on the backup machine:

1. On the backup machine, navigate to Credentials > Backup Credentials.
2. Create an SSH keypair.
   • Add the public key to the list of Authorized Keys for the backup user on the target.
3. Create a new SSH connection.
   • Change Setup Method to manual.
   • Populate the fields, using the backup user on the target as the Username.
   • Select the Private Key created previously.
   • Populate the SSH host key of the target.
     • This is the output of cat /etc/ssh/ssh_host_*.pub on the target.
     • If the network between the backup machine and target is trusted, the “Discover Remote Host Key” button can also be used for convenience.
4. Save.

Finally, when setting up a replication task on the backup machine, use the SSH connection established previously. Use “On a different system” for the source location (i.e. a PULL configuration), and do not accept the use of sudo for running ZFS commands.

Recently, I have investigated into how the signature verification works exactly.

From looking at some code in the tp-link-decrypt project on Github, and reverse engineering the firmware code responsible for verification, we indeed find that the final 128 bytes at the end of the firmware image is an RSA signature.

The signature is verified against an RSA public key that is hard-coded into the firmware as a base64 string:

BgIAAACkAABSU0ExAAQAAAEAAQBhVXK3wF79A6cXXFu0Y0wKz0dPQWi2dWPE7p8eY9e6PAqc5BBT
QPxi2/N1OotrUN11Q6cBXA0gmflRusUiJtdARng43tSWz2pZueskCC5kH9/+1/ACi2ZY1WlK5TVu5B
h0YCzAfvlmsbuPjk/W4S3Jco+ISDOrpF5wwuxlCHI2vQ==

The key is encoded in Microsoft’s PUBLICKEYBLOB format. openssl supports decoding such keys:

 % echo 'BgIAAACkAABSU0ExAAQAAAEAAQBhVXK3wF79A6cXXFu0Y0wKz0dPQWi2dWPE7p8eY9e6PAqc5BBT
QPxi2/N1OotrUN11Q6cBXA0gmflRusUiJtdARng43tSWz2pZueskCC5kH9/+1/ACi2ZY1WlK5TVu5B
h0YCzAfvlmsbuPjk/W4S3Jco+ISDOrpF5wwuxlCHI2vQ==' |\
  base64 -d |\
  openssl rsa -pubin -text
Public-Key: (1024 bit)
Modulus:
  00:bd:36:72:08:65:ec:c2:70:5e:a4:ab:33:48:88:
  8f:72:c9:2d:e1:d6:4f:8e:8f:bb:b1:66:f9:7e:c0:
  2c:60:74:18:e4:6e:35:e5:4a:69:d5:58:66:8b:02:
  f0:d7:fe:df:1f:64:2e:08:24:eb:b9:59:6a:cf:96:
  d4:de:38:78:46:40:d7:26:22:c5:ba:51:f9:99:20:
  0d:5c:01:a7:43:75:dd:50:6b:8b:3a:75:f3:db:62:
  fc:40:53:10:e4:9c:0a:3c:ba:d7:63:1e:9f:ee:c4:
  63:75:b6:68:41:4f:47:cf:0a:4c:63:b4:5b:5c:17:
  a7:03:fd:5e:c0:b7:72:55:61
Exponent: 65537 (0x10001)
writing RSA key
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9NnIIZezCcF6kqzNIiI9yyS3h
1k+Oj7uxZvl+wCxgdBjkbjXlSmnVWGaLAvDX/t8fZC4IJOu5WWrPltTeOHhGQNcm
IsW6UfmZIA1cAadDdd1Qa4s6dfPbYvxAUxDknAo8utdjHp/uxGN1tmhBT0fPCkxj
tFtcF6cD/V7At3JVYQIDAQAB
-----END PUBLIC KEY-----

The code at the tp-link-decrypt seems to suggest a bespoke signature encoding scheme. However, upon closer inspection, the algorithm described is simply the PKCS#1v1.5 encoding scheme, specifically the sha1WithRSAEncryption variant.

The data that is being signed is actually the MD5 hash of the (encrypted) firmware image bytes (without including the signature at the end). It’s not clear why TP-Link chose to sign a MD5 hash (which is then hashed again using SHA1 as part of the RSA signature algorithm), instead of just signing the firmware image itself.

Yet, even knowing the above, my first attempt at re-implementing the signature verification routine in Golang fails. Here’s a self-contained test case to demonstrate:

func TestVerifySignature(t *testing.T) {
  pub := &rsa.PublicKey{
    N: big.NewInt(0).SetBytes([]byte{
      0xbd, 0x36, 0x72, 0x08, 0x65, 0xec, 0xc2, 0x70, 0x5e, 0xa4, 0xab, 0x33, 0x48, 0x88, 0x8f, 0x72,
      0xc9, 0x2d, 0xe1, 0xd6, 0x4f, 0x8e, 0x8f, 0xbb, 0xb1, 0x66, 0xf9, 0x7e, 0xc0, 0x2c, 0x60, 0x74,
      0x18, 0xe4, 0x6e, 0x35, 0xe5, 0x4a, 0x69, 0xd5, 0x58, 0x66, 0x8b, 0x02, 0xf0, 0xd7, 0xfe, 0xdf,
      0x1f, 0x64, 0x2e, 0x08, 0x24, 0xeb, 0xb9, 0x59, 0x6a, 0xcf, 0x96, 0xd4, 0xde, 0x38, 0x78, 0x46,
      0x40, 0xd7, 0x26, 0x22, 0xc5, 0xba, 0x51, 0xf9, 0x99, 0x20, 0x0d, 0x5c, 0x01, 0xa7, 0x43, 0x75,
      0xdd, 0x50, 0x6b, 0x8b, 0x3a, 0x75, 0xf3, 0xdb, 0x62, 0xfc, 0x40, 0x53, 0x10, 0xe4, 0x9c, 0x0a,
      0x3c, 0xba, 0xd7, 0x63, 0x1e, 0x9f, 0xee, 0xc4, 0x63, 0x75, 0xb6, 0x68, 0x41, 0x4f, 0x47, 0xcf,
      0x0a, 0x4c, 0x63, 0xb4, 0x5b, 0x5c, 0x17, 0xa7, 0x03, 0xfd, 0x5e, 0xc0, 0xb7, 0x72, 0x55, 0x61,
    }),
    E: 0x10001,
  }
  md5sum := []byte{0x6e, 0x47, 0xb8, 0x83, 0x4c, 0x9c, 0x0b, 0x61, 0x51, 0x1f, 0x13, 0x0d, 0x88, 0x8f, 0xd3, 0x3f}
  sig := []byte{
    0xf1, 0x29, 0x1d, 0xae, 0x71, 0xf0, 0xd3, 0x47, 0x3b, 0x4b, 0x26, 0xf4, 0x4f, 0x0c, 0x75, 0xc1,
    0x19, 0xa1, 0x8e, 0x04, 0x1b, 0x64, 0xe1, 0x2f, 0x50, 0xe2, 0x5a, 0x6e, 0x58, 0xda, 0x12, 0x42,
    0x91, 0x0f, 0x33, 0xa1, 0xa8, 0x4d, 0xd7, 0xd4, 0x2e, 0xac, 0xac, 0x92, 0xf4, 0x1f, 0x39, 0x8e,
    0xc3, 0x3c, 0xb7, 0xe0, 0x2a, 0x0d, 0x84, 0xed, 0xd0, 0xbb, 0x7a, 0x32, 0xed, 0xb5, 0xf8, 0x33,
    0x9a, 0xdd, 0x9b, 0x0e, 0x66, 0x1a, 0x90, 0xd2, 0xf4, 0xbb, 0x83, 0x72, 0x7e, 0x71, 0xc5, 0x1a,
    0xcf, 0x1e, 0x0a, 0x44, 0x56, 0x54, 0x33, 0xbd, 0xe8, 0x1c, 0xce, 0x61, 0x74, 0xbb, 0x08, 0xd6,
    0xb0, 0x7a, 0xda, 0x8d, 0x89, 0x60, 0xa7, 0x14, 0xb0, 0xb2, 0x30, 0xf0, 0xc4, 0xd5, 0x5c, 0x80,
    0xca, 0x10, 0xc5, 0x29, 0x7f, 0x83, 0x6a, 0xfc, 0x74, 0x34, 0xb1, 0x10, 0xc2, 0xd6, 0x08, 0x30,
  }

  hash := sha1.Sum(md5sum[:])
  if err := rsa.VerifyPKCS1v15(pub, crypto.SHA1, hash[:], sig); err != nil {
    t.Errorf("VerifyPKCS1v15(...): err = %v, want nil", err)
  }
}

VerifyPKCS1v15(...): err = crypto/rsa: verification error, want nil

It turns out, for whatever reason, the firmware (and the code in the tp-link-decrypt project) reverses the bytes of the signature before attempting verification. It’s unclear to me whether this is a normal part of validating RSA signatures, but it does seem odd to me. My guess is that the signature was generated by software that uses little-endian representation of integers, whereas many other RSA libraries use big-endian representations. This is consistent with the fact that Microsoft’s PUBLICKEYBLOB stores the modulus in little-endian.

Adding a slices.Reverse(sig) call to the above code makes the signature verification pass without issues.

Summary

To perform signature verification on the firmware image:

1. Split the firmare image into the data (the first total_length - 128 bytes) and signature (the last 128 bytes).
2. Calculate the MD5 hash of the data.
3. Reverse the ordering of the bytes of the signature.
4. Use the PKCS#1v1.5 sha1WithRSAEncryption signature algorithm to verify the signature against the MD5 hash of the data.

First attempt: attaching a debugger on the system binary

My first attempt was to get GDB working so I could set breakpoints and see exactly what the system binary was doing regarding PoE.

More specifically, I wanted to get gdbserver working on the target and perform debugging remotely. gdbserver has fewer dependencies and should be easier to cross-compile. The frontend of gdb can run on my host computer.

Even with its fewer depedencies, compiling gdbserver wasn’t quite as straightforward as I hoped. The toolchain included in TP-Link’s GPL source code release was quite old, and didn’t support many of the newer compiler features that the newer versions of GDB requires at build-time. To work around this, I compiled the last version of GDB before C++11 support was made mandatory (which turned out to be version 7.12 - about 9 years old at time of writing). I also had to separately compile a copy of gdb that supported MIPS for my host computer, since the precompiled gdb binary that came with TP-Link’s toolchain required a bunch of 32-bit libraries that my version of Debian no longer packages.

After compiling, I scp’d gdbserver onto the switch, and attempted to attach it to the main system binary. Unfortunately, for whatever reason, it seems the stock firmware seems to freeze up if the main system binary gets paused/stopped, even for a short length of time. There just didn’t appear to be enough time to attach the debugger, then immediately continue. Network connectivity gets lost, and the switch becomes no longer responsive.

Bummer…

My guess is that there’s some kind of watchdog mechanism that’s shutting down the system if the main system binary doesn’t seem responsive. No idea if that’s actually the case. In any case, it wouldn’t really help, so I didn’t bother looking any deeper.

Second attempt: writing a program to dump I2C registers

For my second attempt, I took a more black-box approach. Perhaps I could dump out the register state of the controller chip, then compare the values between configuration changes in the Web UI.

Interacting with the I2C controller

Sadly, the stock kernel doesn’t implement proper I2C drivers, so I couldn’t just run something like i2cdump. Some digging in the stock firmware revealed a proprietary kernel module called rtcore.ko was being used to arbitrate access to the switch hardware - including implementing the GPIO bit-bang’d I2C bus on which the PoE controller chip lives. The way that the system binary interacts with this kernel module is through opening a magic character device under /dev/rtcore and making special ioctl calls.

With the help of Ghidra and some header files found in the source code, I was able to construct a function from scratch that does something functionally identical to what the system binary does:

struct ioctl_i2c_read {
        int32_t ret;
        uint32_t drv_type;
        uint32_t dev;
        uint32_t reg;
        uint32_t data;
};

int32_t drv_gpio_i2c_read(uint8_t drv_type, uint32_t dev, uint32_t reg, uint32_t *data) {
        int fd = open("/dev/rtcore", O_RDWR);
        if (fd < 0)
                return -1;

        struct ioctl_i2c_read req = {
                .drv_type = drv_type,
                .dev = dev,
                .reg = reg,
        };
        ioctl(fd, 0xc0045251, &req);
        close(fd);

        *data = req.data;
        return req.ret;
}

The parameter names are the same names used in the header files included with the source code release. It’s not immediately clear what drv_type does, but the system binary always seems to set this to zero. dev is the I2C address of the device. reg is the register number to be read.

(Incidentally, I found the choice of data types odd. I2C addresses are typically 7 bits, and register numbers and values are typically 8 bits, yet all the data types representing them are 32-bit integers).

The userspace code populates the structure containing the parameters for a I2C read request, and makes the magic ioctl call. The ioctl handler executes the request and populates the return code and data from the I2C transaction (or zero if it failed).

Dumping the hardware register state

The address of the PoE controller chip can be determined with the help of the datasheet and careful inspection of the circuit board. The top 3 bits of the address are fixed, and the bottom 4 bits are determined by whether certain pins are pulled high or low.

Now that both the method for interacting with the I2C bus and the address of the PoE controller was known, writing a short C program to exhaustively dump all the registers was relatively trivial.

Using that program, I dumped the hardware register state, and saved the output to a file. Then, I made a change in the Web UI changing a port’s power limits, and dumped the hardware register state again, saving the output to a file.

Interestingly, the diff revealed no differences in the current limit configurations. Regardless of the power figures configured in the Web UI, the hardware per-port current limits remained identical. The only differences appeared to be differences in status register values and the ADC readings of voltages and currents. If any per-port power limiting was being enforced, it didn’t appear to be done in hardware.

Clearly more investigation was warranted.

Third attempt: strace

Since it’s now known that the I2C transactions are faciliated using ioctl syscalls, there wasn’t really a need to attach a full debugger onto the system binary process and risk locking the system up. We can use strace to show all the I2C-related ioctl calls and the contents of any data that is read or written.

Like with gdbserver, I had some trouble cross-compiling some of the more recent versions of strace, so I also needed to find an older version (more specifically, version 6.7 which was about 1.5 years old at time of writing).

Partial success

I invoked strace and attached it to the process of interest with ./strace -f -e trace=ioctl -p 104. Note that it’s important to filter to ioctl syscalls only, since I found tracing everything would occasionally pause the process long enough to lock up the system.

The good news was that this showed a bunch of lines that were of interest:

[pid   612] ioctl(86, _IOC(_IOC_READ|_IOC_WRITE, 0x52, 0x51, 0x4), 0x30724e10) = 0

There were all sorts of ioctls that were related to I2C transactions - both reads and writes to the PoE controller.

The bad news was that strace does not understand the custom ioctl numbers, and thus doesn’t know how to decode the argument. It just prints a raw pointer value, which isn’t helpful at all since we’re interested in the data that the pointer points to. It would be nice if we could actually see exactly what data the syscall was returning with.

Patching strace

I ended up patching my version of strace to print out the struct field values for the ioctls of interest (instead of just a raw pointer value). I was pleasantly surprised to find how little code I had to hack to make this work:

--- strace-6.7/src/ioctl.c	2023-02-26 08:00:00.000000000 +0000
+++ strace-6.7-modified/src/ioctl.c	2025-10-01 15:22:21.861449958 +0000
@@ -320,6 +320,43 @@
 	return rc;
 }
 
+struct rtcore_i2c_op {
+	int32_t ret;
+	uint32_t drv_type;
+	uint32_t dev;
+	uint32_t reg;
+	uint32_t data;
+};
+
+static int
+rtcore_ioctl(struct tcb *tcp, const unsigned int code, const kernel_ulong_t addr)
+{
+	if (entering(tcp)) {
+		return 0;
+	}
+
+	struct rtcore_i2c_op op;
+	switch (_IOC_NR(code)) {
+	case 0x51: // drv_gpio_i2c_read
+	case 0x52: // drv_gpio_i2c_write
+		if (!umove_or_printaddr(tcp, addr, &op)) {
+			tprint_struct_begin();
+			PRINT_FIELD_D(op, ret);
+			tprint_struct_next();
+			PRINT_FIELD_X(op, drv_type);
+			tprint_struct_next();
+			PRINT_FIELD_X(op, dev);
+			tprint_struct_next();
+			PRINT_FIELD_X(op, reg);
+			tprint_struct_next();
+			PRINT_FIELD_X(op, data);
+			tprint_struct_end();
+			return RVAL_IOCTL_DECODED;
+		}
+	}
+	return RVAL_DECODED;
+}
+
 /**
  * Decode arg parameter of the ioctl call.
  *
@@ -385,8 +422,9 @@
 		return mtd_ioctl(tcp, code, arg);
 	case 'O':
 		return ubi_ioctl(tcp, code, arg);
-	case 'R':
-		return random_ioctl(tcp, code, arg);
+	case 'R': /* 0x52 */
+		//return random_ioctl(tcp, code, arg);
+		return rtcore_ioctl(tcp, code, arg);
 	case 'T':
 		return term_ioctl(tcp, code, arg);
 	case 'V':

Points of interest:

• The ioctl type number was already being used by a different ioctl, so decoding is technically ambiguous.
  • Not really a problem in our particular case since I don’t believe the other ioctl ever gets used by the system binary.
• We only decode the struct arg upon exiting the syscall.
  • The system binary doesn’t initialize the ret or data fields on reads, since it’s expecting the ioctl call to populate them.
  • If we decode the struct arg prior to entering the syscall, those fields contain garbage, making the output more difficult to reason about.
• It turns out that the ioctl to write to the I2C device uses an identical structure, so also supporting decodes of write ioctls was trivial.

Success

With a patched strace, we get far more meaningful output:

[pid   612] ioctl(87, _IOC(_IOC_READ|_IOC_WRITE, 0x52, 0x51, 0x4){ret=0, drv_type=0, dev=0x21, reg=0x2c, data=0}) = 0

Nice.

The (not so) exciting conclusion

The strace output turned out to be consistent with our hypothesis that per-port power limits weren’t being enforced in hardware.

There was a handful of status registers that were being polled repeatedly, almost as quickly as if it were done in a tight loop. Once a PoE device was connected, per-port voltages and currents values also started being polled repeatedly.

From this, I concluded that per-port power limits were enforced entirely in software (or not enforced at all). My guess is that it’s repeatedly sampling the instantaneous voltage and current to calculate the instantaneous power figure, and manually shutting down the port if it goes over the configured limits.

In any case, this is enough information for me to write a safe Linux driver, so I will declare success for now.

I recently bought a cheap TP-Link switch in hopes that it would be able to run OpenWRT. Unfortunately, it seems like I bought the V3 variant of the board, whereas the existing OpenWRT port only supports the V1 variant.

However, from poking around the firmware and looking at the board, the only difference appeared to be the PoE controller chip. The V1 has the TPS23861 chip, whereas the V3 has an MP3924. A reasonably fully-featured OpenWRT port to the V3 variant doesn’t appear terribly difficult if we can somehow support the different PoE controller. Unfortunately, at the time of writing, the MP3924 has no Linux driver support.

In order to write a driver that would operate safely, I wanted to first find out how the stock firmware configures the PoE controller (more specifically, how it configures the power limits).

In particular, the stock Web UI allows setting custom power limits on individual ports in watts, but the datasheet for the MP3924 seems to suggest that the over-current protection limits must be configured in milliamps. I’m guessing that the firmware assumes a input voltage, and uses that to work backwards from a power figure to a current figure. However, I wanted to make sure, since this could end up being a safety-related issue if the driver does not correctly configure the over-current protections for this particular hardware.

The plan

1. Get a root shell into the stock firmware to faciliate experimentation.
2. Make a change in the Web UI regarding power limits.
3. Somehow read back the hardware registers to see what changed.
4. Go to step 2.

In this particular post, I will be focusing on step 1.

Hardware modifications

I don’t know of any software vulnerabilities in the current firmware version that would allow us to get root via purely software means so my plan was to obtain root by modifying the firmware image using a hardware flasher. To faciliate this, I desoldered the flash chip, and soldered a socket that would allow me to easily move the flash chip to/from a hardware flasher.

Furthermore, when working on embedded platforms, it’s always useful to have a serial port for debugging, so I also soldered on pin headers. Unfortunately, the serial port header also requires adding solder bridges (or 0 ohm resistors) to some pads, and I wasn’t able to get a solder bridge to form reliably. I ended up soldering a bodge wire instead.

The stock firmware boot process

The onboard flash has roughly the following partitions:

• Bootloader
• Kernel
  • The kernel has a built-in initramfs, which appears to be a standard buildroot root filesystem.
  • Houses TP-Link’s custom init script.
• Two squashfs images
  • These images contain all of TP-Link’s proprietary binaries.
  • There are two since the switch supports “dual booting”, presumably to allow recovery from a bad firmware update.
  • I didn’t look too closely, but there’s likely some boot variable that the start-up script reads in order to pick the right image.
• A JFFS2 filesystem
  • This looks like where user settings are persisted.

At a high-level, the stock firmware boot process does the following:

1. Mount one of the two squashfs images, depending on which is the “active” one.
2. Mount the JFFS2 filesystem, containing the persisted user settings.
3. Run the proprietary TP-Link startup binary located in the squashfs image.

The full startup script can be found in TP-Link’s GPL source code release for the firmware.

Hijacking the boot process to run an SSH daemon

To me, the most straightforward approach to getting a root shell was to modify the squashfs image to include a statically compiled SSH server that we can use to log in as root. Dropbear is a commonly used and favoured SSH server for embedded devices due to its size and simplicity, so that’s what I used.

To hook into the startup process, I replaced the normal TP-Link startup binary with a wrapper script that starts dropbear, then execs the real startup binary:

#!/bin/sh

mkdir -p /tplink/usrapp/dropbear
ln -sf /tplink/usrapp/dropbear /etc/dropbear
ln -sf /tplink/image/dropbear/dropbearmulti /sbin/dropbear
ln -sf /tplink/image/dropbear/dropbearmulti /bin/scp
ln -sf /tplink/image/dropbear/dropbearmulti /bin/dropbearkey
ln -sf /tplink/image/dropbear/dropbearmulti /bin/dropbearconvert
ln -sf /tplink/image/dropbear/dropbearmulti /bin/dbclient
cp /tplink/image/dropbear/shadow /etc/shadow

/sbin/dropbear -E -p 1234 -R

exec /tplink/image/usrImage/app/sbin/core.real

In high-level terms, the script does the following:

1. Creates a folder on the JFFS2 persistent storage for storing dropbear config (if it doesn’t already exist).
   • We use persistent storage here to avoid having to generate a new host key on every boot.
2. Creates symlinks under /sbin and /bin to the dropbearmulti binary.
3. Overwrites /etc/shadow with a copy where root has a known password.
4. Runs the dropbear daemon on an unused port.
5. Execs the real startup binary.

(Note that the squashfs image is mounted under /tplink/image, and the persistent JFFS2 filesystem is mounted under /tplink/usrapp).

Building dropbear

Cross-compiling dropbear was relatively straightforward using the precompiled toolchain found in TP-Link’s GPL source code release. Note that you may need to install 32-bit libraries if running on a x86_64 system. On Debian, this is just sudo apt install ia32-libs.

export PATH="${PATH?}:/path/to/gpl/source/omada_switch/20161108_WebUI_upgrade/tplink/buildroot-realtek/ext-tools/msdk-4.3.6-mips-EB-2.6.32-0.9.33/host/usr/bin/"
./configure --host=mips-linux --enable-static --disable-zlib
make PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp" MULTI=1 -j8

Generating a new /etc/shadow

For this, I just copied the existing /etc/shadow and generated a password hash for root. This password hash can be generated using openssl passwd -1 <your password>.

root:$1$tie/0Ymw$9ucfZx.CpHktEDumfb13D1:10933:0:99999:7:::
bin:*:10933:0:99999:7:::
daemon:*:10933:0:99999:7:::
adm:*:10933:0:99999:7:::
lp:*:10933:0:99999:7:::
sync:*:10933:0:99999:7:::
shutdown:*:10933:0:99999:7:::
halt:*:10933:0:99999:7:::
uucp:*:10933:0:99999:7:::
operator:*:10933:0:99999:7:::
ftp:*:10933:0:99999:7:::
nobody:*:10933:0:99999:7:::
default::10933:0:99999:7:::

Notes on patching the squashfs image

I performed all image manipulation (unpacking, modifying, re-packing) all in a single fakeroot session in order to preserve ownership and permissions. Real root is not required.

The image can be unpacked with unsquashfs /path/to/image.bin. This extracts the image to a folder called squashfs-root. Check that the exit code is zero to ensure that all permissions and ownership bits were preserved in the extraction process (it will have an exit code of 2 if it failed to do so).

Once the filesystem tree is patched, the image can be re-packed with mksquashfs squashfs-root/ squashfs.bin -comp lzma.

Once the squashfs image has been re-packed, it can be spliced into a flash dump for writing back into the onboard storage. I didn’t look too hard into how the startup script chooses which image to mount, so I just replaced both:

dd if=squashfs.bin of=flash-modded.bin seek=1792 bs=4096 conv=notrunc
dd if=squashfs.bin of=flash-modded.bin seek=4352 bs=4096 conv=notrunc

Getting root

Once the switch finished booting, I was able to get root access through SSH 🎉:

 % ssh root@192.168.0.1 -p 1234
The authenticity of host '[192.168.0.1]:1234 ([192.168.0.1]:1234)' can't be established.
ED25519 key fingerprint is SHA256:kBKqsC8m0s0OPQlkNiNtLJ4fCAQSchJeTRqcb0smwu8.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[192.168.0.1]:1234' (ED25519) to the list of known hosts.
root@192.168.0.1's password: 












        Welcome to Layer 2 Managed Switch












  Press <Enter> to continue...
~ # busybox id
uid=0(root) gid=0(root) groups=0(root),10(wheel)
~ # uname -a
Linux streamOs 2.6.32.58 #2 Fri Aug 18 20:12:27 CST 2023 mips GNU/Linux
/ # exit
Connection to 192.168.0.1 closed.

I was also able to scp a test file 🎉:

 % scp -O -P 1234 test root@192.168.0.1:/ 
root@192.168.0.1's password: 
test                                          100%    0     0.0KB/s   00:00    

Having root access and being able to scp arbitrary files to the switch should make it much easier to poke around on the stock firmware. I plan to document the actual reverse engineering of the PoE controller in the next post.

The simpler, but somewhat tedious solution would be to desolder the flash chip from the board and read the unencrypted firmware image from there. However, I didn’t have access to the tooling to do so at the time. Thus, I looked to see if there were other ways to get the unencrypted firmware image.

I figured that whatever encryption mechanism was being used, the key material was likely embedded inside the firmware image itself since the device would need to somehow decrypt the image before flashing it. This presents an issue, since we would need access to the unencrypted firmware image in order to find the decryption key.

The good news is that TP-Link used GPL’d code, and thus has published the source code for their firmware. It looks to be using an extremely old version of Linux (2.6.32!!), and a buildroot root filesystem (overlayed with a custom init script, and TP-Link’s proprietary system binaries). Some of the READMEs suggests that the source code is sufficient to build a full firmware image (albeit unencrypted).

I popped a few of the TP-Link binaries into Ghidra and was able to quickly find that the firmware image was being encrypted using DES-CBC with a hard-coded key + IV.

Incidentally, I found the choice of algorithm interesting. From the fact that an old and known-insecure encryption algorithm was being used with a hard-coded key and IV, I can only conclude that this is merely an obfuscation mechanism intended to prevent casual reverse-engineering of firmware images rather than a serious attempt to protect the contents of the image. Even if the source code wasn’t available, the key and IV can always be dumped from a physical device.

Nonetheless, I will follow the lead of other similar projects, and not directly publish the keying material. Instead, I have included a shell one-liner below to extract the key material from the source code available on TP-Link’s website.

tar -xzf rtk-maple_gpl.tar.gz -O omada_switch/20161108_WebUI_upgrade/tplink/buildroot-realtek/board/realtek/common/skeleton/tplink/lib/libservice.so.0 |\
    tee /dev/null |\
    od -j 907888 -N 16 -t x1 -A n |\
    tr -d '[:space:]' |\
    sed -r 's/^([a-f0-9]{16})([a-f0-9]{16})$/Key: \1  IV: \2\n/'

Note: the above is only tested with a rtk-maple_gpl.tar.gz having the following SHA256 hash: 6941bc1e4b979ecd7bd5c1a4d17f933f525a87e08004cd3efdec218ba581d34e

The firmware can be decrypted using the following OpenSSL command:

openssl des-cbc \
    -provider legacy \
    -d -nopad \
    -K "${KEY?}" -iv "${IV?}" \
    -in encrypted.bin \
    -out decrypted.bin

It’s also worth noting that knowing the encryption key does not appear to be sufficient for crafting a valid firmware image. I did not confirm this, but the code does appear to perform an RSA signature check before proceeding with flashing a firmware image. It’s also not-yet-clear where this signature is located in the firmware image (likely at the end), but the signature does appear to be 128 bytes in size, suggesting a 1024-bit RSA signing key.

I hope this is useful for anyone hoping to conduct research on these firmware images.

On start-up, the PWM signal to control the fan speed is fixed at 20%, which seems adequate at idle. However, when the drives are under load, the reported temperatures seems to average around the 40C to 45C mark. Toshiba seems to recommend keeping drives below 40C, so it seems prudent to bump the fan speed a little, even though the drives themselves are probably rated up to 60C.

Unfortunately, as I mentioned in my previous post about controlling the status LEDs and LCD display in TrueNAS, the IT8625E Super I/O chip (which control the fans) is not currently supported in the mainline Linux driver.

There are out-of-tree drivers that do support the chip, such as the asustor-platform-driver, which seem to work well for people. However, like in my previous post, I wasn’t comfortable running 3rd-party drivers on my NAS for a variety of reasons.

Having looked at the datasheet for the built-in fan, it looks like it’s capable of pulling a decent amount of air. Even at the current fixed 20% fan speed, it doesn’t seem to be performing terribly. I figured just a minor bump might still keep the machine quiet without dynamic fan control, but still shave off a few degrees on the drives.

Luckily, there’s only just one register that needs to be changed, and it can also be done easily with a single isaset call. As usual, use the following at your own risk:

isaset -y 0xa35 0xa36 0x63 <PWM duty cycle (0x00 to 0xff)>

By running the above as a pre-init command, it can be used to set the fan percentage on startup.

For convenience, I’ve precalculated PWM duty cycle values for common fan percentages:

For me, I’ve found that 30% was a good balance between lower temperatures while still remaining relatively silent.

Closing thoughts

As I mentioned in my previous post, ideally the Super I/O chip would be supported in the upstream Linux drivers so we wouldn’t need to directly write to hardware registers from user-space. Until then, I’ll be using the above.