Posts on MOV r0

96boards Hikey eMMC hacks!

Mon, 18 Sep 2017 15:36:15 +0000

I currently own two Hikey development boards from 96boards.org. A 1GB and 2GB board, respectively. Recently I got to thinking as I was scanning through the schematics and hi6220 datasheet about the capabilities of the MMC controller. I discovered the Hikey has an DWC (Designware) MMC controller, which is very common on single-board computers, and found that the device supports eMMC up to version 4.5. The board itself supports up to HS200 mode and 150 MHz clock. As I sifted through the device tree for the board (based on my own mainline kernel, but is reflective of their current releases), the device tree was only setup for high-speed mode, and seemed to have 3.3v signaling enabled, whereas the board is capable of HS200 and 1.8v signaling, especially considering the signal lines are connected to LDO5_1V8. We can see that with the default device tree, the card is running in high-speed mode at 52 MHz. You’ll also notice that I have a 32GB eMMC chip on my Hikey, which I’ll touch on later ;) If we take a look at the device tree, we can see we are missing some important properties to reach the full potential of the eMMC and the board: Let’s take a quick peek at the device tree documentation for the MMC bindings: Here we find the missing culprits: mmc-hs200-1_8v and the paramter max-frequency (I’m not sure if this is necessary, but the hi6220 datasheet explicitly mentions the maximum frequency is 150 MHz for the controller, so I’ll be safe.) Before we add these parameters, let’s get a quick and dirty benchmark of the current mode: So we are looking at about 26 MB/s. While this isn’t a perfect or ideal benchmark, it’s good enough to get an idea of the transfer rate. Let’s give it a shot with our new parameters in the device tree, recompile the kernel, and see what happens: We can see the card was successfully detected in HS200 mode instead of the default high-speed mode. Wow! So now we’re looking at about 36 MB/s! That’s a pretty significant improvement. We can see the signal voltage is at 1.8v and the clock running at 150 MHz. I’m not sure why this hasn’t been enabled by default, but I’ve seen no issues or stability problems as a result. This is one of my favorite development boards, but I felt a little restricted by the 8GB eMMC… I had an SMD rework station sitting around and a couple spare eMMC chips I had from old devices and eBay. This board came with the KLMBG1GEAC chip (8GB Samsung eMMC), and I just so happened to have a KLMBG4GEAC (32GB) sitting around, so I figured why not give it a shot… As you can see, my impatience and inexperience led to damaging some of the pads. I was incredibly, lucky, as all of these pads were “NC” or not connected and not used, with the exception of two. They are in the inner square of pads in the bottom left corner. I had damaged a Vcc and Vss pad. Another stroke of luck, there are quite a few redundant grounds, and three other Vcc, which are tied together internally, which meant I could get by just fine without the damaged Vcc and Vss. Lesson learned, use tighter temperature profile, and have a little more patience in removal. After flattening the pads out with some flux and desoldering braid, then a touch up of isopropyl, I spent about 20 minutes trying to line the new eMMC chip up just perfectly (much more frustrating than you’d imagine…) After a few minutes of heat (slowly working my way up from ~180c, always preheat the board, it helps) I cooked the eMMC chip at around ~260-280c. I carefully watched for the chip to “drop” into place, when the solder balls melt and attach to the pads. I kept some heat on it for about 20-30 seconds after that occurred to ensure even and thorough heating. Afterwards, I allowed the chip to cool down and gave it some time to relax. My next concern (in hindsight) was that I needed to enable HWRESET in the ExtCSD of the chip, so the Hikey could properly initialize the chip, in addition to enabling the BOOT1 partition for booting in 8-bit mode. After some careful research, I discovered that the ’l-loader’ used to burn the chip did this for me, which was a big relief. I made sure to backup a few of the partitions from the old chip like ‘vrl’, ‘vrl_backup’, and ‘mcuimage’, and was able to flash those through the l-loader fastboot. Thereafter, I flashed the UEFI/boot partition and system partition with the 16.06 Debian release, and sure enough, it booted right up. I believe that makes this the first 32GB Hikey board! I’m very pleased with this new chip and the speed I’ve been able to squeeze out of it with HS200 and hope you find this information useful too!

Finding JTAG on the Odroid-C2

Tue, 13 Dec 2016 09:08:11 +0000

Recently, I purchased an Odroid-C2. This is a great little single-board computer by Hardkernel The device has an Amlogic S905 SoC. Complete with a quad-core Cortex-A53 @ 1.5Ghz, 2GB DDR3 RAM, and gigabit ethernet. It’s quite a powerful little board with plenty of GPIO and RAM to work with. My favorite part about this board is the eMMC connector on-board, which blows away even UHS-1 MicroSD speed. This makes it a heavy competitor to the Raspberry Pi 3 in my opinion. One of the first things I do when I get a new piece of hardware is identify the debug ports. A molex UART connector is available on most/all of Hardkernel’s products. However, sometimes debugging more in-depth is required, especially since this board is still stuck on the 3.14 kernel. Progress is being made to bring it up to 4.y, but it will be some time before all the drivers are finished. I had recently been reading an article about a vulnerability and exploit on the Amlogic S905 chipset here and found the lack of any authentication for secure boot beyond a simple SHA256 hash. The author of the article was able to dump the bootrom of the chip using this vulnerability. He had written a kernel module for issuing SMC calls to their implementation of TrustZone. Upon inspecting the u-boot source for this device, I discovered a good amount of the command IDs for various trusted functions. One that stuck out to me was for enabling JTAG. All the 0x820000xx values are command IDs for TrustZone. This is only a partial list of those that exist. The command simply issues an SMC call to TrustZone to enable one of four different TAPs. Two were power domains or system fabric possibly (still haven’t figured it out.) The other two were the Cortex-A53 (the main processor) and a Cortex-M3 (~~possibly a secure coprocessor?~~ System Control and Power) However, with little to nonexistent documentation, I felt it would be a good place to poke around this lesser known chip. Now, if you ask around the Odroid community, they’ll tell you that JTAG is only available through the SDIO pins using a special debug board. I had seen these before, but figured a quick look at the schematics would be worthwhile to see if there was another option rather than build this. A quick scan through the schematic revealed that TMS, TDO, TDI, and TCK were also routed to the I2S pins (which happen to have a header on this board, next to the heatsink.) I decided to connect those pins up to my JTAG adapter and give it a shot. No such luck. These are multi-function pins with a muxer, so I assumed maybe I hadn’t set the right alternative function on them. Another scan through the documentation revealed no information other than the pins exist. The documentation referred to a section that was omitted from the public datasheet. No matter, we’ll find a way. Using my UART console in u-boot, I tried using the command ‘jtagon apao’ which according to the comments in the code, should enable the Cortex-A53 DAP. Sure enough, that did the trick, and the A53 was now exposed. I was unable to actually halt the chip or inspect the chain successfully, for reasons I am unsure of at this point (~~could be security related, I know it’s possible to enable a password on the TAPs to prevent debugging.~~ issue was lack of ARMv8 support for OpenOCD and missing -ctibase since ARMv8 debugging requires CTI information for halt and resume) After repeated failed attempts to initialize the debug port on the A53, I decided to take a look at the other tap, the ‘SCP’ chip. I rebooted back into u-boot and issued the command ‘jtagon scpao’ and the Cortex-M3 DAP appeared. My first attempt, I was able to halt the chip! From this TAP, I could see the bootrom and I believe BL301 (this chip uses the standard ARM trusted firmware scheme.) Certain secure areas of memory were still inaccessible, which resulted in a reboot or lockup. To reiterate, all the JTAG command was doing in u-boot was issuing a simple SMC command, so I asked myself why I couldn’t enable this while the device was booted into Linux. Circling back to the S905 post about a secure boot vulnerability, the author wrote a debugfs driver that allows passing SMC calls. I realized a simple rewrite of this code would result in me being able to enable JTAG from Linux. You can see what I did here. (Inline assembly can be painful sometimes…) Upon my first try with the SCP chip, I was able to connect and halt right away. Unfortunately I still haven’t been able to connect the A53, or ~~fully understand the purpose~~ of the ‘SCP’ processor, but I had made some headway. When I get some free time (rare these days) I will take a look at the password checking mechanism, and if enabled, the password should be in the efuses. I’m hoping this post will serve as a resource for those looking to do JTAG debugging on this board or SoC, and possibly get it working. If you have any questions or comments, feel free to leave them in the comment section! UPDATE: I was able to start debugging the Cortex-A53 on this board using some ARMv8 patches for OpenOCD. It’s still experimental at this moment, but generally works well. The issue was related to lack of ARMv8/DAP support in OpenOCD. Since then, I can successfully halt and resume, and read memory. One side note, I’ve discovered that SCP stands for ‘System Control and Power’ which is pretty self-explanatory.

Use Raspberry Pi (2/3) as a JTAG/SWD adapter

Fri, 02 Sep 2016 10:15:09 +0000

Did you know that we can use the Raspberry Pi GPIO to bitbang the JTAG/SWD protocols? We can actually use our Raspberry Pi as a JTAG adapter for programming microcontrollers, FPGAs, or another Raspberry Pi! JTAG is a protocol similar to SPI, but works a little different. It’s commonly used for board bring-up, debugging, and programming in bare-metal environments. It’s incredibly useful because you have direct low-level access to hardware and peripherals, which allows things like reading and modifying CPU registers or reading/writing memory. SWD is a newer technology developed around Cortex-based processors which boasts a reduced pin-count vs JTAG (2 vs 4) and can actually be used over JTAG pins if the device supports it. While SWD doesn’t support things like boundary-scan, it’s perfectly suited for debugging and bare-metal programming. Let’s get started!

Convert Raspberry Pi (1/2/3) to F2FS

Fri, 19 Aug 2016 16:01:07 +0000

What is F2FS? From Wikipedia:

F2FS (Flash-Friendly File System) is a flash file system initially developed by Samsung Electronics for the Linux kernel.[2] The motive for F2FS was to build a file system that, from the start, takes into account the characteristics of NAND flash memory-based storage devices (such as solid-state disks, eMMC, and SD cards), which are widely used in computer systems ranging from mobile devices to servers.

Basically, F2FS was a file system designed from the ground up for NAND-based devices. Motorola even started using F2FS for their Android smartphones. It’s designed to help reduce wear on the device, and improve performance on this type of storage medium. Since the Raspberry Pi was designed to run off of an SD card, it makes it a perfect candidate to play around with F2FS. It’s currently supported in the 4.4.y kernel so no need to compile your own kernel this time. For this project, you will need a USB flash drive or SSD/HDD via a USB adapter (You will lose all data on your USB device, back it up!) Let’s begin. First we’ll want to upgrade our kernel and firmware to the latest available. Let’s update all of our packages first:

Compile Raspberry Pi (2/3) kernel from source with BFQ

Thu, 18 Aug 2016 10:47:13 +0000

Today we are going to learn how to compile the Raspberry Pi (2/3 only) kernel from source and then patch the kernel with BFQ IO scheduler support. As of today (8/18/16) the latest kernel is 4.4.17. I am using the latest (Jessie) Raspbian release. So what is BFQ?�More about BFQ

BFQ is a proportional-share storage-I/O scheduler that also supports hierarchical scheduling with a cgroups interface.

BFQ provides low latency for interactive and soft real-time applications, high throughput, and strong fairness guarantees. The code is fairly mature�and it has been around for awhile. I especially�prefer BFQ on mobile and embedded devices. Let’s dive in. (Note that this guide only covers native compiling, if you are cross-compiling from another arch, check out�this�article for more information.)

SHA256 Hash Cracking with Hashcat and Mask Attack

Wed, 25 Nov 2015 08:26:00 +0000

SHA256 is a cryptographic hash function, commonly used to verify data integrity, such as its use in digital signatures. Passwords are frequently hashed and saved, without needing to store a password in plaintext. This provides an extra layer of security as a hash is not �reversible.� It�s a one-way function, and each hash is unique (with the exception of collisions, but that�s out-of-scope for this tutorial.) For this instance, let�s say we�re trying to recover a password (Apples123) that�s been hashed with SHA256 (a5fca64a1ecdce7bbf5cd75d59e302776cfea0c202ed82d6ef42e37ef3d34479). We want to recover that password because we forgot it. There�s many different types of attacks we can use against a hash, namely dictionary attacks and bruteforce. Let�s say that we have a rough idea of how long the password was, and we know that there are no special characters (!@#$^*). If we wanted to run a plain bruteforce attack, this would take ages. Because of the data that we know, we are able to optimize a much more efficient attack at calculating the original value of the hash. We are able to set a custom character set, and set a specified range of possible lengths of our password. Using a mask attack (when applicable) can significantly improve your odds at recovering the password. We can reduce the cracking time from thousands of years to a couple hours. Enter Hashcat/OclHashcat (Ocl is the CUDA/OpenCL implementation of hashcat, accelerated by a GPU to utilize it�s parallel processing ability and hundreds-to-thousands of cores.) Hashcat is also able to utilize multi-threading, in addition to certain instruction sets that are advantageous to this type of operation (Intel: AVX/2 and AMD: XOP.) Let�s start out by grabbing a copy of Hashcat from their website here. I�ll start out by running a benchmark to get a ballpark idea of how fast we can crack our hashes. Benchmarking CPU with Hashcat I used the following command (I chose the AVX2 binary because of my i5 processor, and you may use the standard hashcat or the XOP for AMD):

How To JTAG Raspberry Pi 2 (Without custom kernel)

Thu, 15 Oct 2015 14:16:48 +0000

Welcome to MOV r0, and my first blog post. The goal of this article is to teach you how to JTAG the Raspberry Pi 2 without having to compile a custom kernel to enable the GPIOs to do JTAG. Let’s begin! The tools and equipment I’ll be using today are as follows:

TIAO USB Multi-protocol JTAG adapter. This device is like a BusPirate on steroids. It’ll do everything. It’s got an FT2232H chip inside, and supports dual-MPSSE. That means we can use UART/JTAG simultaneously, or SPI1/SPI2, or SWD. It’s really an amazing device at a great price. You can find it here (Link)
Raspberry Pi 2 running Raspbian (Jessie)
Female-to-female jumper wires (Can’t ever have enough of these)
Host system is using Ubuntu Mate 15.04, with latest OpenOCD and FTDI support

Grab the latest build of OpenOCD (On your host machine, not your Raspberry Pi, these directions are specific to an FTDI JTAG adapter)