Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

In a previous post, the author broke the firmware encryption that was using Wireless Trusted Module (WSM) on a printer. This time, they target WSM itself.

They didn't have a root shell on the device from their friends previous backdoor. So, they looked around and used an N-day reported by Synacktiv. The lbtraceapp binary has setuid permissions and functions similar to ftrace. By passing it a program, such as /bin/bash, you get root for free. Unfortunately, root doesn't mean all access with capabilities.

The lbtraceapp ran as root but didn't have the CAP_SYS_MODULE capability. When looking around at various processes, they found that some shellscript executes sleep which DOES have the capability we need. Since we are root, we can write to the location in /proc/pid/mem with some shellcode to hijack the process.

With this, it was time to poke around at the WTM module for real. They didn't feel like cross compiling though. So, they wrote a small daemon that forwards TCP traffic from their machine via the wtm Python client to the device. At first glance, the commands look almost identical to the Trusted Platform Module (TPM) specification with context loading and such.

WTM encryption stores customer key information in an encrypted blob on the file system that is then loaded to the chip. In theory, the chip should have a super duper secret key to make it impossible to decrypt offline. What they learned is that some data is preserved between execution of stores and loads of the context.

This is super helpful! The file system encryption key is actually wrapped by a different key other than the super duper master key. Since this key is still leftover on the chip, we're able to leak the wrapped key. Why is this helpful? This gives us the ability for offline root filesystem decryption.

Can we get code execution in the kernel firmware itself? It turns out that the chip does NOT have its own decided DRAM! By simply writing to /dev/mem, we can overwrite the processor code itself! To do this, they overwrote a virtual unused command to give them an arbitrary read/write primitive that could be accessed via their Python client. They dumped OTP fuses that shouldn't be dumpable. The next step would be dumping the super duper secret AES key!

Overall, an awesome series of blog posts on the kernel. To me, it was eye-opening to see how important the permissions of files, memory and other things were for security. If these basic things are messed up then you're in a world of hurt.