Several months ago, during a hardware device assessment, I encountered a TC58NVG2S0HBAI4 NAND EEPROM which hosted the firmware of the target device. The problem I had was that my MiniPro Universal Programmer did not support this specific variant. It did however, support several similar variants from the same vendor.
For those who may be unaware of the MiniPro, it is a cost effective universal programmer with support for 10’s of thousand of chips and variants. The latest MiniPro, the TL866II+, is available for around $50-$60 but also can come packaged with numerous adapters and sockets for around $100-$120.
The following is a quick on how to modify the MiniPro’s chip info .dll to change the necessary information to support this variant. Couple things to note first though. This method does not “add” support so much as it replaces an existing configuration meaning you’ll end up removing support for the source chip. Also, I make no guarantees that the offsets used here work for other chips, but the guess-and-check methodology should still apply. Lastly, I’ll refer to all TL866 models as MiniPro, same for the software. Where differences exist, I’ll note that then. Oh, and make backups, lots of them.
Modding the .dll
Before we get started, we need a few things. We need to find the .dll to modify and we need the datasheets for our source and target chip variants. For older TL866 models you’ll find InfoIC.dll in your MiniPro installation directory. For the newer TL866II+, you find InfoIC2plus.dll in the Xgpro installation directory. In my case, I installed both C:/. The datasheets for the chips are:
According to the first sentences of each datasheet, the primary differences were the sizes of pages and blocks. I also figured it was safe to assume that the pinouts were identical. The source chip info in MiniPro matched the datasheet.
Source Chip Info in Xgpro
Source Chip:
Page Size: 2048
Spare Size: 64
Pages Per Block: 64
Blocks: 4096
Target Chip:
Page Size: 4096
Spare Size: 256
Pages Per Block: 64
Blocks: 2048
I used IDA Pro, but any hex editor should do. Upon opening the .dll in IDA, I noted a very large data section. I opened the strings few to quickly find the section I wanted to modify.
IDA Strings View of Source Chip
Each chip’s info section appeared to be 73 bytes long and started with the chip name in ASCII. Here is the unmodified source chip:
If we check the locations in the chip info, we see that 0x44-0x45 equals 0x0800 or 2048. 0x48-0x49 and 0x4C-0x4D equal 0x40 or 64. And 0x5C-0x5D equal 0x1000 or 4096.
Modified each of those section to set the correct values for my target chip and successfully dumped the contents.
Reading target chip, contents not shown due to protect client
Methodology TL;DR
The methodology here is pretty straight forward. If you want to “add” support for a chip, simply look for another chip variant or at least something that would have the same pinout or physical form factor to use as your source chip.
Once you have a source chip, determine the differences by comparing datasheets.
Take your source values and convert to little endian base 16 and look for for those numbers in the source chip’s section of the MiniPro .dll. Be sure to make a backup first.
Save your edits, open mini pro, and confirm your changes are correct.
Dump contents of your target chip and profit or whatever.
Quick Note: This post assumes some knowledge of UART and U-boot, and touches slightly on eMMC dumping.
Many familiar with hardware hacking know that UART can be a quick and easy way to find yourself with a shell on a target device. Often times, especially in older home routers and the like, you’ll be automatically logged in as root or be able to log in with an easily-guessed or default password.
In other circumstances, you may need to edit some boot arguments in the bootloader to trigger a shell (such as adding a 1 for single-user mode or adding init=/bin/sh). With this initial shell, you can dump and crack passwords or modify the firmware to grant access without the modified bootargs (change password).
Recently, I came head-to-head with a device that had a slightly more complicated boot process with many environment variables setting other environment variables that eventually called a boot script from an eMMC that did more of the same.
Some Background
My target device was being driven by a cl-som-imx6; an off-the-shelf, bolt-on System on Module from Compulab. My target version of the cl-som-imx6 utilized a 16 gig eMMC for firmware storage that had two partitions: a FAT boot partition (in addition to U-boot on an EEPROM) and an EXT4 Linux filesystem.
cl-som-imx6 with eMMC removed
My first goal for this device was to get an active shell on the device while it was fully booted. Since I had multiple copies of my target device, I went for a quick win and removed eMMC then dumped it’s contents with the hope of recovering and cracking password hashes. While I was able to get the hashes from /etc/shadow, I was disappointed to see they were hashed with sha512crypt ($6$) and have yet been unable to crack them.
Without valid credentials, my next goal was to modify boot args to bypass authentication and drop me directly into a root shell, with the hope of being able to change the password. The classic init=/bin/sh trick.
It’s important to note that when modifying the bootargs with init=/bin/sh, the device will not go through its standard boot process, therefore it will not kick off any scripts or applications that would normally fire on boot. So, while you may have a root shell, you will not be interacting with the device in its normal state. It is also temporary and will not persist after reboot.
The Problem
This is where it started getting a bit tricker. In my experience, U-boot usually has an environment variable called bootargs that passes necessary information to the kernel. In this case, there were several variables that set bootargs under different circumstances. I attempted to modify every instance where bootargs were getting set (to add init=/bin/sh) to no avail.
During this time, I also discovered that there appeared to be some sort of watch-dog active that would completely reset the device after about 2 minutes of playing around in U-boot’s menu options.
As a note: I don’t believe this was an intended “Security” function but rather an unintended effect caused by the rest of the device (attached to the cl-som-imx6) after it failed to fully boot after X time.
After an hour or so reading the UART output during boot and attempting to understand the logic flow of the environment variables, I discovered that U-boot was calling a boot script before it touched any of my edited boot args. Luckily for me, this boot script was being called from the eMMC’s boot partition, which I had dumped previously.
Binwalk quickly identified the boot script’s location, but failed to extract it. Using the offset of the script as a starting point and the offset of the following signature as the end point, I used dd to extract the script. As luck would have it, the script was actually a script (plaintext) and not a binary.
# dd if=partition1.bin of=boot.script skip=5513216 count=4096 bs=1
4096+0 records in
4096+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0173901 s, 236 kB/s
The script was exactly 80 lines and contained several if/else statements, but most importantly, it had only one line setting the bootargs. At this point, my theory was that the only environment variables that mattered were being set by this script. I needed to modify this script to add init=/bin/sh.
The next hurdle was that I didn’t have a direct way of modifying the contents of the eMMC without removing it and that’s the easy part. Getting it back on the SOM would have been tougher work than I was willing to tackle at the time.
The Solution
Without a simple way to modify the boot script, I decided to try to manually copy and paste each line of the script into the U-boot menu shell and, if necessary, remove all other environment variables.
I ran into two problems with this approach. First, any line over 34 characters that I tried to paste got truncated to 34. This was likely just caused by the ft232h buffer or something else with the serial connection. Second, and more annoying, was the watch-dog reset. There was simply no way I was going to paste in 80 lines (especially as many would require multiple c/p’s due to the 34 char limit). Even after removing as much as possible
My only answer was to automate the process. I had previously been playing around with the idea of bruteforcing simple 4 digit security codes, so I already had the outline of a script ready.
I modified the script to read lines from an input file and write them to the serial device, where any line over 32 (to be safe) characters would be chucked up. To ensure data was sent at the correct time, I put made sure the script waited for the shell prompt to return before sending the next line, with an additional .5 second sleep for good measure. Also, since the script would take over my ft232h, I needed to make sure it stopped autoboot at the correct time to enter the U-Boot shell.
This approach worked perfectly and I was dropped into a /bin/sh shell as root. I then took control of my ft232h again so I could interact manually. With a quick passwd, I changed the root password and rebooted. As the modified environment variables didn’t persist through reboot, the device booted as normal and presented me with a login prompt. I entered my newly set password and I was in.
Serial and script output ending in shell
Changing password
I’d post a screenshot of the final successful login after full boot, but I’d have to redact too much stuff that it doesn’t make any sense.
As a note: So I could keep an eye on everything, I used a second ft232h to watch the target’s TX pin and since it echoed everything back, I could also see my script’s input. Also, the watch-dog was still in effect since the device didn’t boot as it should have, therefore I had to be quick on the passwd.
The Script
Below is the script exactly as I used it. With a touch of modification to the until1 and until2 vars, it should be useable for other targets.
#!/usr/bin/env python
# By Mike Kelly
# exfil.co
# @lixmk
import serial
import sys
import argparse
import re
from time import sleep
# Key words
until1 = "Hit any key to stop autoboot:"
until2 = "SOM-iMX6 #"
# Read from device until prompt identifier
# Not using resp in this, but you can
def read_until(until):
resp = ""
while until not in resp:
resp += dev.read(1)
return resp
def serialprint():
# Get to U-Boot Shell
read_until(until1)
dev.write("\n")
# Wait for U-Boot Prompt
read_until(until2)
sleep(.5)
dev.write("\n")
with open(infile) as f:
lines = f.readlines()
for line in lines:
# Lines < 32
if len(line) < 32:
read_until(until2)
sleep(.5)
print "Short Line: "+line.rstrip("\n")
dev.write(line)
# Break up longer lines
else:
read_until(until2)
sleep(.5)
for chunk in re.findall('.{1,32}', line):
print "Long Line: "+chunk.rstrip("\n")
dev.write(chunk)
sleep(.5)
dev.write("\n")
print ""
print "Done... Got root?"
exit()
if __name__ == '__main__':
# Argument parsing
parser = argparse.ArgumentParser(usage='./setenv.py -d /dev/ttyUSB0 -b 115200 -f infile.txt')
parser.add_argument('-d', '--device', required=True, help='Serial Device path ie: /dev/ttyUSB0')
parser.add_argument('-b', '--baud', required=True, type=int, help='Serial Baud rate')
parser.add_argument('-f', '--infile', type=str, help="Input file")
args = parser.parse_args()
device = args.device
baud = args.baud
infile = args.infile
# Configuring device
dev = serial.Serial(device, baud, timeout=5)
# Executing
serialprint()
My wife is the Assistant Director at Cottonwood Center for the Arts, a local non-profit art center here in Colorado Springs. As a small non-profit, everybody has many different responsibilities. One of her’s is marketing and social media. A project she has been interested in piloting is a podcast and/or video series to help introduce the public to the many things that happen at Cottonwood.
As the former producer for the Exoticliability (RIP) podcast, I figured I could help her with the technical aspects of setting up equipment and recording. As a non-profit, budget is tight especially for a pilot project, but her MBP already has Garageband and we were able to find a couple cheap USB Mics that came with stands. That should be everything she needs to get started.
The Problem:
As we were getting everything hooked up, we discovered a problem. OS X seemed to recognize both USB mics, but would only use the most recent one plugged in. After much googling and almost finding an answer, it was determined that the problem stemmed from the fact that both Mics had identical USB descriptors, including serial number.
(the following screenshot only shows one mic because I “fixed” the first one already)
The simple solution was to buy a new USB microphone from a different brand. We would pay for the new one and I’d keep one of the originals. But, where’s the fun in that?
Can I Fix it?
If I’m gonna buy a new mic, I might as well check this one out in depth. I took the microphone apart to find a pretty small little board. The mic really only had two things of interest, an SOC and an EEPROM.
The SOC was a CM6327A (datasheet), an apparently common SOC for USB mics, and the EEPROM was labeled MX24C02.
The first page of the datasheet immediately tells us that:
Serial EEPROM programming interface supports customized
VID/PID/Product string/Manufacture string for device
name changed and configuration
This led me to believe that all I should need to do is change the data stored on the EEPROM and that should be enough for OS X to recognize it as a separate device.
The Mini Pro software did not have an option for an “MX24C02” but it did have an “M24C02”. Figuring that EEPROMs are all pretty much the same, I went with that option. Luckily there was no read protection set so I was able to view the data with no problems.
As you can see in the screenshot above, the data on the EEPROM matches the USB descriptors as reported by OS X. All that’s needed is to change some data and it should be good. I probably only needed to change the serial number (201505), but just incase, I changed all the ASCII data, but made sure the lengths never changes.
I programmed the changes…
and returned the EEPROM to it’s original location on the USB mic’s board. I plugged the mic back into the MBP and checked the descriptors.
And there we have it, a brand new CAD LOL1337USB Licrophone. While I don’t have a screenshot of it, I can confirm that OS X now recognizes both microphones separately and they can both be used in Garageband at the same time (after some aggregate device stuff you have to do, which is required for multiple simultaneous inputs no matter what).
In the end, this solution saved me about $50, since I had all the tools necessary already, and I got a quick blog post out of it. But I am left with a little curiosity about what I could put in all the unused space of the EEPROM and what OS X might think of it. There’s also a ton of space inside the microphone. Could probably fit a small USB hub and a rubber ducky, but that’s a post for another day.
