Linux Console Via Bluetooth

These days, I find myself hacking, reverse engineering, whatever, several mobile devices that run Windows Mobile. A really great tool that I've started using is called HaRET (Handset Reverse Engineering Tool). In most, it's necessary to get terminal access to them in order to perform low-level debugging. Sometimes, a mobile device will have Linux USB OTG support without any hassle, and I can use the g_ether kernel module to bring up usb0 as a network device at boot time, assigning a static IP address. Then, by using usbnet and other kernel modules on my workstation, I am able to communicate to the mobile device using telnet or ssh. Great!

However, in many cases, USB OTG does not work "out of the box". Furthermore, given that the LCD rarely ever works "out of the box", that leaves me with very few options for getting any type of feedback from the mobile device at all, aside from maybe generating morse code with the vibration unit - that's a joke... please believe me.

It's very necessary to have terminal access, or ICE access, to perform low-level debugging when porting Linux to a new mobile device. One option is to find unpopulated pads on the PCB, where a UART has possibly had pins brought out, and to solder some wires directly to those pads and create the appropriate level-shifter circuit, attaching an RS232 cable to the workstation. Another possibility is to use the JTAG port. In some cases, neither of those options will work because either a) the pins have not been brought out,  or b) the JTAG port has been fused (See my previous opinions on Fusing the JTAG port). In many cases, there is a debug port on the board, with an unpopulated header. Finding the appropriate header and FPC cable is sometimes possible, but in many cases it's like looking for a needle in a haystack. Luckily, I found that needle in my last reverse engineering project, and fabricated a small PCB to bring out the pins of the FFC connected to the UARTS of the embedded device.

When I don't find that needle, then I'm left having to do some very creative reverse engineering. My suggestion: Why not build a small daemon into the kernel that would actually bring up the system console over bluetooth? Most, if not all, mobile devices manufactured in the last decade have bluetooth hardware directly connected to one of the UARTS. I can't imagine that it would be terribly difficult to build something like this into the kernel. My only main concern would be missing valuable information that the Linux kernel spits out at boot time. To counter that, I would probably introduce a "consoledelay" boot parameter, that functioned much like the "rootdelay" boot parameter. Such a boot parameter would allow the underlying hardware of the console to initialize before performing any IO on it.

If anyone feels like funding me to build this into the kernel, I am very open to suggestions :)

Fusing the JTAG port

One thing has really been dwelling on my conscience since I interviewed with a certain mobile device manufacturer. They disclosed something to me which could very well be common practice for a large part of the industry, but really shouldn't be.

For those unfamiliar with JTAG, it's a programming / testing methodology for highly integrated circuits and chips on a circuitboard. Essentially, JTAG is a software-controllable circuit probing method that goes where hands cannot. Manufacturers have used it for a long time to mass-program their mobile devices. All of phone's firmware can be programmed at once through this interface, even if that firmware lives on multiple chips.

However, some chip and mobile device manufacturers have taken it upon themselves to actually fuse the JTAG port, so that once it's been programmed, that interface can be burned - made permanently, electrically disconnected. While this is good on some levels for security purposes, it has the awful side-effect that the device can never be re-used or refurbished. When a device can never be reused or refurbished, it often ends up in the scrap heap, just like billions of other mobile phones.

Aside from restricting the owner's freedom to do as he or she whishes with the mobile device, the Free Software Foundation would also term such manufacturing practices as 'defective by design'.

My FreeRunner Debug Board v3 Has Arrived

Well, I finally received the Debug Board v3 that I've been hounding Koolu for ever since I received my FreeRunner. The Dboard, as it's sometimes called, provides a JTAG interface to the Neo FreeRunner from OpenMoko / FIC and can also be interfaced with any other ARM device via the unpopulated 20-pin JTAG header at the bottom of the image. I'm particularly interested in trying out BeagleBoard debugging with my Dboard after I build a 20-pin to 14-pin adapter.

It's a good thing that I ordered my Dboard from OpenMoko directly because Koolu has publicly stated that they will not be offering the Debug Board to their customers because the FreeRunner is unbrickable. Although, by assuming that the Debug Board's only use is for bootloader debugging, it precludes all sorts of other uses for the board such as step-debugging with GDB through static firmware images, kernel debugging, or the potential of debugging, say, Android, NetBSD or any other OS.

I'm happy now that I have mine anyway. I hope that they don't stop mass production of the Dboard either, because it might be a more versatile alternative than the FlySwatter, although both offer freely available schematics.

If anyone out there has experience JTAG debugging with both the FlySwatter and the Debug Board v3, then I would be very happy to hear comments detailing the pros and cons of each.