LockAjar — A dive into embedded linux IoT Part 1.5
Hello everyone, I’ve been hard at work with my schooling as usual. I’ve been putting my health first as well as looking at my skillset in both technology and security. I’m working on some more metaverse content with an interesting tech stack; Wwyse audio encoder, Oculus’s XR toolkit and Sweethome for building physical 3d rooms. If you want a demo I have a video of my earliest build HERE. I’ve also come back from Bsides Roc 2022 and an online metaverse convention with a great deal of new experience. With some networking at Bsides I’ve also received some encouragement to continue with the project. Said project will be the topic of today’s blog as we dig into the 2nd part of my lockly reverse engineering journey.
It was a joy talking to Adam about the project from Toool Rochester. A software engineer by trade, Adam was welcome to hearing my progress and struggles with the lock. They were rather impressed with how my documentation had covered Bluetooth enumeration, and I’ve reached out to see if the team would be interested in assisting me further here. I’ve not heard back, so this will be an area to follow up with should time allow itself between my schedule.
I find in IT that simply being involved with a community gives me the push needed to pursue my passions. When I was working in the restaurant, finding that I had supportive coworkers who encouraged me to find creative solutions to the technical problems was something that made me feel at home. Finding an air mouse solution for my boss’ security cameras showed him there was an easier way to use navigation on the device’s own embedded system, making the system more effective for its purpose. Talking about my first dedicated bug found in a popular program back in 2020 encouraged me to further dig into the tools used with debugging the software. Finding that the documentation mentioned specific versions and resources available online showed me that these types of hacks are a threat vector for large organizations hoping to keep their software’s proprietary mechanisms safe, secure and compliant and could in fact be utilized for malicious purposes. Having committed to bug bounty for a year, I now see that my interest, presence and knowledge in cybersecurity on the surface only scratches the potential I have as a technical professional. To follow that my peers encourage, this is the mindset which I approach IT as of now.
The confidence here pushes me to continue the lockly project independently. I’ve compiled and outlined the challenges of it, the risks and the resources and directions available and hope to present my findings once things are much more complete. My collected ideas and thoughts of this so far are outlined below.
The current ongoing Ukrainian war tensions between US and Russian organizations presents a unique opportunity for software to break away from Non-allied powers in terms of software, including software used to monitor countries under sanctions. Because the lockly smartphone app contains push notification callback abilities with .ru domains, the idea to put this aside in favor of independent, open source software is key to ensuring a secure, compliant and open platform for IoT devices in the lockly ecosystem.
On top of that, the marketplace and tooling for designing custom PCB’s is well established online. Stores such as tindie, jlcpcb and crowdsupply offer makers the opportunity to design and host custom PCB’s including but not limited to embedded linux systems made to replace everything from light fixtures to adding Bluetooth into Casio watches.
Due to the nature of the chip itself being a STM32 Embedded linux microcontroller, none of the above factors would be possible. However, this does mean that one needs to get the system off the board itself, thus extracting the current image is going to be necessary to effectively reverse engineer the drivers and other software essential for the components.
Another challenge here is a lack of experience with STM32’s dev environment. It’s far friendlier than most embedded system architectures, with gui and cli tools available, but is still an embedded system. In my investigation, I have found no clear signs of a debugging board available, so hot leads along with an additional controller are needed to access the device, making it not as user friendly of a hack for everything aforementioned.
The thing I’m most interested in reverse engineering is the Bluetooth to wifi device. The device is sold separately. However, connecting the device to an ESP32 is a more effective and cost efficient way to achieve wireless and remote management capabilities.
I used a Bluetooth sniffing tool based on the specs for the BT controller found. Nordic semiconductor makes available an app for testing Bluetooth functionality, and you can further dig in with other embedded micro controller tools. nRF connect is the name of the tool and it was the start of me sniffing out how to connect to and manipulate the onboard hardware.
The STLink tool while robust isn’t as simple as the windows based stm32 console tool. I found this one more useful to tell me what I needed to know. Because I couldn’t find the debug pinouts yet, I’ve yet to really grasp this one. Perhaps a development board would be best to start with.
The act of extracting a debug file from android is very easy via the use of an ADB command. This process is as simple as making a webserver on a jailbroken iOS device. Both of these capabilities were key to extracting files from my devices.
I also discovered that Windows Subsystem for Linux recently got a project to enable USB serial bus connections bridged into the system. While there are clear screaming impacts for docker security here, caution to the wind tells me this tool is amazing for development purposes. Simply swap a connected USB bus to the PC with an update to the base WSL firmware and a script and it works. It’s functional on both windows 10 and 11 despite Microsoft’s insistence on using 11 only. Now if only something like this existed for Hyper-v, oh wait it in fact does.
While setting up an iPhone to jailbreak for extracting the ICA file, I found that there a couple of nasty bugs in the popular checkra1n method. Firstly, you have to run if not through a tool like WSL, as it will never detect, the same goes for virtual machines without 1:1 USB emulation, so baremetal is the way to go. Atop that, you must use an intel based CPU as AMD doesn’t accurately function with this resource. I’ve found AMD to be a hassle for system administration purposes in the past such as with Nested virtualization needs, and now this. While Ryzen is great for the Fast and Cheap side of things, more cores for more rendering of metaverse projects, it fails to deliver as a hypervisor without a specificity like.
I hope to focus on this project more as time goes on, considering the depth of involvement and past experience. Since I’ve been running Linux based systems for over 15 years, it only makes sense to start working deeper on embedded linux project as I design one for an IoT smartlock. This project is going at a slower pace than many of my other cybersecurity projects prior. This may be due to the hardware-centric nature, but also because embedded linux has a lot of odd factors which complicate the debugging experience. Perhaps this is the reason many embedded linux devices are chosen over their counterparts that are closer to baremetal and low-level code processing tools. I’ve only recently learned that I’ll need a separate breakout board may be needed to investigate the system’s internal chipset. Applying good pentesting tools and practices has allowed me to gain a high-level view of the opportunities and risks a project like this one presents.
Putting a full embedded system in an IoT lock isn’t as efficient as making it run from an ESP32 directly, but darn if development time doesn’t go from months to weeks without this method. On top of that, Embedded creation tools such as the Yocto project are readily accessible, available and used in making linux from scratch even less of a hassle. Finding tools like this for make files beyond linux, including docker and Kubernetes deployment files, automates the whole build process itself at best, meaning that you can make an embedded image just like you would create a specific application container or Kubernetes pod. This skill is key for system administration, development and engineering to keep everything running optimally.
Thus concludes a look at the process behind IoT embedded OS project thus far. I’ll keep things updated as this project evolves, but this may mean longer gaps between blog posts. Until next time.
Stay safe.
