Joined
·
148 Posts
This discussion started in another thread but to avoid hijacking that one I'll post progress here now.
With the lack of updates from Indian regarding the Ride Command/Dash I decided to start investigating the hardware behind it and hopefully find a way into the system so we can modify it ourselves.
Previous Updates
Continued here
www.indianmotorcycles.net
With the lack of updates from Indian regarding the Ride Command/Dash I decided to start investigating the hardware behind it and hopefully find a way into the system so we can modify it ourselves.
Previous Updates
Original Post:
Today I decided to take a look inside the Ride Command Unit. Here are some pictures:
I was mainly interested in the flash, due to the lack of any updates from Indian getting a copy of the firmware would allow for some homebrew development. Unfortunately it's a BGA chip and not surface mount. If it wasn't a £1000 part I'd happily desolder it (and attempt to resolder later) or manually trace the pin outs but I don't have that amount of cash to throw away and I'm not risking it. That said, if anyone does come across a written off FTR with the command module going second hand drop me a message.
For any techies out there interested in this sort of thing I noted down the main chips and identified them.
s9keaz128a - 48 MHz Arm Cortex-M0+
wl18modgi - Texas instruments 8 Dual-Band Industrial Module – Wi-Fi Bluetooth and Bluetooth Low Energy
PF0100 - NXP Power Management
EMMC32G-W525 - Kingston 32GB BGA flash
se868-v3 - Telit GNSS GPS module
CC2564MODN - Texas instruments Dual-mode Bluetooth CC2564 module
Some things to note:
Taken a closer look today and there appears to be a emmc connector to the on the back:
![574584]()
Going to hook it up to a logic analyser tomorrow and see if I can identify the pin out.
I've also noticed several other unpopulated connectors dotted around the board with the prefix "J", possibly indicating JTAG points. Slightly cautious about what I start poking and prodding though!
Update 2
Not much luck so far, UART 1 seems to be completely disabled, Unable to find a connector for UART 0 I soldered right onto pins 33 & 34 (according to the datasheet). Although there is data flowing through one of them which would indicate TX it appeared as junk data, nothing legible. I encountered the exact same thing with "J3".
The datasheet suggest these pins can be repurposed for communication with other components which I'm guessing is what's occurring here.
![574703]()
Also took a look at the potential emmc connector and oddly I can't see any data flow on any of the pins, at this point I'm not sure if it's because they're not being used or simply because my logic analyser isn't quick enough. I'll continue to poke around some of the other connectors but suggestions are welcome, anyone capable of opening it up themselves and taking a look even better
Full datasheet is here for anyone wanting to do some reading
https://www.nxp.com/docs/en/reference-manual/KEA128RM.pdf
Update 3:
Further reading through the datasheet its apparent that this device doesn't implement JTAG and instead uses SWD (A newer protocol designed for ARM devices that only uses 2 wires).
I've worked out the pin out for this:
![Electronic engineering Electronics Electronic component Technology Computer hardware]()
I've not yet been able to confirm if these are actually enabled (They get disabled if the CPU is set to secure mode or they have been disabled/reused by the firmware).
I'm going to try and hook them up to a Raspberry Pi configured for SWD debugging and see if I can get any output. That said, compared to JTAG SWD doesn't prove as useful, even if it does work it's designed for debugging not hardware diagnostics so it's limited to setting breakpoints, watches and reading memory. There doesn't appear to be any way to access the NAND from SWD which is what I'm really after.
Update 4
SWD debugging is up and running!
![574835]()
Never used SWD before so going to poke around and see what I can find...
Update 4 Cont.
Dumped the firmware (That is the 128kb of CPU flash). Well, now we know who built it
![574841]()
Update 5
The more I looked into the Cortex-M0 chip, it's firmware and simply the location of the 32gb flash I was convinced it couldn't be running the show. There's simply not the resources for it to load and handle the dash GUI and the flash was uncharacteristically far away (you want them close normally to reduce latency).
Taking a closer look at the board again I decided there must be something under the RF shields I'd previously ignored assuming they were simply for the GPS/Bluetooth antenna or something. On previous boards I've looked at the shields have been soldered down, luckily it looked like you can prise this one off.
Lo and behold, the main CPU & RAM were under there!
![574843]()
Wish I found this earlier but a case of live and learn!
The ID was very hard to read but I've identified them as the following
CPU - MCIMX6U5EVM10AC - NXP i.MX 6 series 32-bit MPU, Dual ARM Cortex-A9 core, 1GHz, MAPBGA 624
RAM - K4B4G1646D-BYK0 - Samsung DDR3 SDRAM 4Gbit 256Mx16 1.35V/1.5V 96-Pin FBGA (2x as there's another one soldered on the reverse)
Time to trawl through another datasheet
Update 6
Having found the main CPU I went back to some of the jacks I skipped previously due to their location.
One of them appears to be a JTAG port as detected by jtagulator
![574884]()
Using these pins the pinout is the following:
![574886]()
I'll attempt to get this hooked up to openocd to confirm.
Update 7
Got JTAG successfully hooked up using my Olimex Arm USB OCD-H
![574947]()
Currently dumping the 2Gb of ram (Going to take a while!).
Update 8
Trawling through memory dump I've come across the update script, seems they're encrypted using a locally stored key (SWUpdate.pem). Unfortunately I don't have access to the file system through JTAG. Doing some tests to see if I can break into shell during the update script, seems to be fairly well locked down though.
Update 9
Unfortunately I've still had no luck finding the main CPU UART which would make all this a lot easier, on the plus side I have managed to extract the encryption keys used for decrypting the firmware updates from memory via JTAG by crafting a fake update file (that gets rejected) but loads the keys into memory. Halting the CPU at just the right time allowed me to grab them.
The next issue though is that there isn't yet a firmware update for me to decrypt, I was hoping the release of the FTR rally might have prompted one but nothing available yet.
I'm going to craft an encrypted update file with the keys and see if I can get anything to execute, the updates appear to be signed as well as encrypted using a private key (which we don't have, only the public key used for confirming the signature is authentic) so chances are it'll just get rejected to but will see.
Update 10
If you connect a USB to Ethernet adapter you can connect the ride command to the network and it obtains an IP address.
Port scanning gives the following results
The ssh is using certificate authentication which I can't see any way into. The server has the public key and we need the private one in order to connect.
Today I decided to take a look inside the Ride Command Unit. Here are some pictures:
I was mainly interested in the flash, due to the lack of any updates from Indian getting a copy of the firmware would allow for some homebrew development. Unfortunately it's a BGA chip and not surface mount. If it wasn't a £1000 part I'd happily desolder it (and attempt to resolder later) or manually trace the pin outs but I don't have that amount of cash to throw away and I'm not risking it. That said, if anyone does come across a written off FTR with the command module going second hand drop me a message.
For any techies out there interested in this sort of thing I noted down the main chips and identified them.
s9keaz128a - 48 MHz Arm Cortex-M0+
wl18modgi - Texas instruments 8 Dual-Band Industrial Module – Wi-Fi Bluetooth and Bluetooth Low Energy
PF0100 - NXP Power Management
EMMC32G-W525 - Kingston 32GB BGA flash
se868-v3 - Telit GNSS GPS module
CC2564MODN - Texas instruments Dual-mode Bluetooth CC2564 module
Some things to note:
- Besides being screwed together by the hulk himself (I've never encountered a device with screws so tight) it was pretty easy to disassemble. There's no warranty stickers or anything.
- It's clearly been designed to be waterproof but very oddly there's a white sticker on the back which covers some small holes in the casing. Not sure if this is to help prevent moisture or something.
- The grey pad in the top picture is shielding which is glued to the outer casing. You have to prise it off to get it open.
- Oddly there are 2 bluetooth modules, seems they might be using 1 just for WiFi and the other for Bluetooth.
- The GPS module is certainly good enough for a navigation system (Accuracy of 0.01 m/s) which makes it even stranger that Indian have ignored implementing this on the FTR when the hardware is very much capable.
Taken a closer look today and there appears to be a emmc connector to the on the back:
Going to hook it up to a logic analyser tomorrow and see if I can identify the pin out.
I've also noticed several other unpopulated connectors dotted around the board with the prefix "J", possibly indicating JTAG points. Slightly cautious about what I start poking and prodding though!
Update 2
Not much luck so far, UART 1 seems to be completely disabled, Unable to find a connector for UART 0 I soldered right onto pins 33 & 34 (according to the datasheet). Although there is data flowing through one of them which would indicate TX it appeared as junk data, nothing legible. I encountered the exact same thing with "J3".
The datasheet suggest these pins can be repurposed for communication with other components which I'm guessing is what's occurring here.
Also took a look at the potential emmc connector and oddly I can't see any data flow on any of the pins, at this point I'm not sure if it's because they're not being used or simply because my logic analyser isn't quick enough. I'll continue to poke around some of the other connectors but suggestions are welcome, anyone capable of opening it up themselves and taking a look even better
Full datasheet is here for anyone wanting to do some reading
https://www.nxp.com/docs/en/reference-manual/KEA128RM.pdf
Update 3:
Further reading through the datasheet its apparent that this device doesn't implement JTAG and instead uses SWD (A newer protocol designed for ARM devices that only uses 2 wires).
I've worked out the pin out for this:
I've not yet been able to confirm if these are actually enabled (They get disabled if the CPU is set to secure mode or they have been disabled/reused by the firmware).
I'm going to try and hook them up to a Raspberry Pi configured for SWD debugging and see if I can get any output. That said, compared to JTAG SWD doesn't prove as useful, even if it does work it's designed for debugging not hardware diagnostics so it's limited to setting breakpoints, watches and reading memory. There doesn't appear to be any way to access the NAND from SWD which is what I'm really after.
Update 4
SWD debugging is up and running!
Never used SWD before so going to poke around and see what I can find...
Update 4 Cont.
Dumped the firmware (That is the 128kb of CPU flash). Well, now we know who built it
Update 5
The more I looked into the Cortex-M0 chip, it's firmware and simply the location of the 32gb flash I was convinced it couldn't be running the show. There's simply not the resources for it to load and handle the dash GUI and the flash was uncharacteristically far away (you want them close normally to reduce latency).
Taking a closer look at the board again I decided there must be something under the RF shields I'd previously ignored assuming they were simply for the GPS/Bluetooth antenna or something. On previous boards I've looked at the shields have been soldered down, luckily it looked like you can prise this one off.
Lo and behold, the main CPU & RAM were under there!
Wish I found this earlier but a case of live and learn!
The ID was very hard to read but I've identified them as the following
CPU - MCIMX6U5EVM10AC - NXP i.MX 6 series 32-bit MPU, Dual ARM Cortex-A9 core, 1GHz, MAPBGA 624
RAM - K4B4G1646D-BYK0 - Samsung DDR3 SDRAM 4Gbit 256Mx16 1.35V/1.5V 96-Pin FBGA (2x as there's another one soldered on the reverse)
Time to trawl through another datasheet
Update 6
Having found the main CPU I went back to some of the jacks I skipped previously due to their location.
One of them appears to be a JTAG port as detected by jtagulator
Using these pins the pinout is the following:
I'll attempt to get this hooked up to openocd to confirm.
Update 7
Got JTAG successfully hooked up using my Olimex Arm USB OCD-H
Currently dumping the 2Gb of ram (Going to take a while!).
Update 8
Trawling through memory dump I've come across the update script, seems they're encrypted using a locally stored key (SWUpdate.pem). Unfortunately I don't have access to the file system through JTAG. Doing some tests to see if I can break into shell during the update script, seems to be fairly well locked down though.
Code:
#Extract board type from hwrevision file:
board=`/bin/sed 's/\(.*\)[ \t].*/\1/' /etc/hwrevision`
#Extract current rootfs partition from kernel "root=" command-line argument:
cmdline=`cat /proc/cmdline`
part=`/bin/sed 's/.*root=\/dev\/mmcblk[0:1]p\([0-2]\).*/boot\1/' /proc/cmdline`
if [ "$part" == "$cmdline" ]; then
# Handle case if not booting from eMMC
part=`/sbin/fw_printenv 2>/dev/null | /bin/grep mmcpart= | /bin/sed s/mmcpart=/boot/`
fi
if [ -z $part ]; then
# Handle case if eMMC was not previously initialized
part="boot2"
fi
config="-e $board,$part"
if [ -e /www ]; then
server="-w \"-document_root /www -listening_ports 8088\""
fi
if [ -e "/etc/ssl/certs/SWUpdate.crt" ]; then
cert="-k /etc/ssl/certs/SWUpdate.crt"
fi
if [ -e "/etc/ssl/certs/SWUpdate.pem" ]; then
key="-K /etc/ssl/certs/SWUpdate.pem"
fi
# Export these parameters as arguments for manually invoking swupdate:
export SWUPDATE_ARGS="-v $cert $key $config"
# environment file used by swupdate systemd service:
echo SWUPDATE_ARGS="-v $server $cert $key $config" > /tmp/swupdate.env
boot_recovery=`/bin/cat /proc/cmdline | /bin/grep boot_recovery`
if [ -n "$boot_recovery" ]; then
# Start recovery splash screen:
/usr/bin/psplash &
# Ensure backlight is turned on:
backlights="`/bin/ls /sys/class/backlight/*/brightness`"
for backlight in $backlights
do
/bin/echo 100 > $backlight 2>/dev/null
done
# Wait for udev device enumeration (e.g. sdcard, USB ports)
/bin/udevadm trigger
/bin/udevadm settle
/bin/usleep 250000
# After first-pass, re-trigger required to enumerate USB mass-storage device(s), if applicable
/bin/udevadm trigger
/bin/udevadm settle
/bin/usleep 250000
# Additional trigger to allow time for disk-mount (e.g. fuse-exFAT) to finish...
/bin/udevadm trigger
/bin/udevadm settle
/bin/usleep 1000000
/bin/echo -e "\x1B[1;32m**********************************************************************\x1B[0m"
/bin/echo -e "\x1B[1;32m********************* SWU RECOVERY MODE DETECTED *********************\x1B[0m"
/bin/echo -e "\x1B[1;32m**********************************************************************\x1B[0m"
# boot_recovery2 = "force" (re-install, even if same version already installed)
boot_recovery2=`/bin/cat /proc/cmdline | /bin/grep boot_recovery2`
# Detect current installation:
installed_version=`/bin/cat /etc/version 2>/dev/null`
board_type=`/bin/sed 's/\(.*\)[ \t].*/\1/' /etc/hwrevision`
board_rev=`/bin/sed 's/.*[ \t]\(.*\)/\1/' /etc/hwrevision`
swu_files=`/bin/ls -At /media/*/* 2>/dev/null`
swu_secure=0
# Detect if secure swupdate image is required:
if [ -e "/etc/ssl/certs/SWUpdate.pem" ]; then
swu_secure=1
fi
/bin/echo -e "\x1B[1;32mInstalled version: $installed_version ($board_type, Rev$board_rev)\x1B[0m"
# Search for installable images on external storage device(s):
msg="No SWU file(s) found on media!"
cd /tmp
for swu_file in $swu_files
do
# Check if file is CPIO container and has expected 'sw-description' info
/bin/cpio -i -F "$swu_file" sw-description 2>/dev/null
if [ $? -eq 0 -a -n /tmp/sw-description ]; then
# Parse sw-description for compatible board type and revision
swu_desc=`/bin/cat sw-description | /usr/bin/tr -d ' \n'`
/bin/rm -f /tmp/sw-description
encrypted=`/bin/echo $swu_desc | /bin/grep -ci 'encrypted=True'`
swu_version=`/bin/echo $swu_desc | /bin/sed 's/.*version="\([^"]*\).*/\1/'`
swu_hw_type=`/bin/echo $swu_desc | /bin/sed 's/.*hardware-compatibility=\[.*\];\([^={]*\).*/\1/'`
swu_hw_revs=`/bin/echo $swu_desc | /bin/sed 's/.*hardware-compatibility=\[\(.*\)\].*/\1/' | \
/bin/sed 's/,/ /g' | /bin/sed 's/"//g'`
/bin/echo
/bin/echo -e "\x1B[1;32mFound file: $swu_file\x1B[0m"
/bin/echo -e "\x1B[1;32mVersion: $swu_version ($swu_hw_type, Rev$swu_hw_revs)\x1B[0m"
compatible=0
if [ "$board_type" = "$swu_hw_type" -a $swu_secure -eq $encrypted ]; then
for swu_hw_rev in $swu_hw_revs
do
if [ "$board_rev" = "$swu_hw_rev" ]; then
compatible=1
break
fi
done
fi
if [ $compatible -eq 0 ]; then
/bin/echo -e "\x1B[1;32m--> Not Compatible\x1B[0m"
/usr/bin/psplash-write "MSG Skipping: $swu_version [Not Compatible] ..."
msg="SWU file(s) incompatible or already installed"
elif [ -z "$boot_recovery2" -a "$swu_version" == "$installed_version" ]; then
/bin/echo -e "\x1B[1;32m--> Already Installed\x1B[0m"
/usr/bin/psplash-write "MSG Skipping: $swu_version [Already Installed] ..."
msg="SWU file(s) incompatible or already installed"
else
if [ -n "$boot_recovery2" ]; then
# Check if eMMC is already partitioned:
# Partition/format eMMC, if necessary:
if [ $? -ne 0 ]; then
/bin/echo -e "\x1B[1;32mFormatting storage...\x1B[0m"
/usr/bin/psplash-write "MSG Formatting storage ..."
/usr/sbin/emmc_init.sh
# Mount /data, now that it is initialized:
/bin/mount /dev/mmcblk0p3 /data
/bin/sync
fi
fi
/bin/echo -e "\x1B[1;32m--> Installing...\x1B[0m"
/usr/bin/psplash-write "MSG Installing: $swu_version ..."
/usr/bin/progress -p -w -c &
. /usr/bin/swupdate-env
/usr/bin/swupdate -v -i $swu_file $SWUPDATE_ARGS
status=$?
/usr/bin/killall progress 2>&1 >/dev/null
if [ $status -eq 0 ]; then
# Immediately "finalize" newly-installed /rootfs:
# - ensure /data partition is fully populated for successful reboot
/bin/echo -e "\x1B[1;32mFinalizing install...\x1B[0m"
/usr/bin/psplash-write "MSG Finalizing install ..."
/bin/mkdir /tmp/installed_rootfs 2>/dev/null
/bin/umount /tmp/installed_rootfs 2>/dev/null
mmcpart=`/sbin/fw_printenv 2>/dev/null | /bin/grep mmcpart= | /bin/sed s/mmcpart=//`
/bin/mount /dev/mmcblk0p$mmcpart /tmp/installed_rootfs 2>/dev/null
/tmp/installed_rootfs/usr/bin/swu-finalize.sh 2>/dev/null
/bin/umount /tmp/installed_rootfs 2>/dev/null
/bin/rmdir /tmp/installed_rootfs 2>/dev/null
/bin/echo -e "\x1B[1;32mRestarting...\x1B[0m"
/usr/bin/psplash-write "MSG Restarting ..."
/sbin/reboot
# ******* if successful, boot ends here... (system reboot)
else
msg="Update Failed!"
fi
break
fi
fi
done
# Fall-through, if recovery fails:
/bin/echo -e "\x1B[1;32m$msg\x1B[0m"
/usr/bin/psplash-write "MSG $msg"
# Delay for last message on screen:
/bin/usleep 1500000
# Stop recovery splash screen:
/usr/bin/psplash-write "QUIT"
fiUnfortunately I've still had no luck finding the main CPU UART which would make all this a lot easier, on the plus side I have managed to extract the encryption keys used for decrypting the firmware updates from memory via JTAG by crafting a fake update file (that gets rejected) but loads the keys into memory. Halting the CPU at just the right time allowed me to grab them.
The next issue though is that there isn't yet a firmware update for me to decrypt, I was hoping the release of the FTR rally might have prompted one but nothing available yet.
I'm going to craft an encrypted update file with the keys and see if I can get anything to execute, the updates appear to be signed as well as encrypted using a private key (which we don't have, only the public key used for confirming the signature is authentic) so chances are it'll just get rejected to but will see.
Update 10
If you connect a USB to Ethernet adapter you can connect the ride command to the network and it obtains an IP address.
Port scanning gives the following results
Code:
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6 (protocol 2.0)
| ssh-hostkey:
| 2048 5c:42:f2:b6:b0:f9:52:d5:b2:d8:72:0b:e3:d7:91:c1 (RSA)
| 256 e6:4b:aa:7d:a9:ff:1e:49:df:ef:af:61:3e:42:05:42 (ECDSA)
|_ 256 f0:eb:d9:25:ce:5f:79:f8:78:85:0c:55:d8:ad:ae:b2 (ED25519)
5355/tcp open llmnr?
MAC Address: (removed) (Realtek Semiconductor)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
Uptime guess: 0.024 days (since Fri Feb 21 13:12:30 2020)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: All zerosContinued here
Ride Command Hardware
This is like the second thread I have seen this jackassery from this guy. One more and that's strike three. You gotta work hard to earn the jackass award. I think this cat is trying to get it done all in the same day. If you are speaking of who I believe you are, I don't see him as anything but...
www.indianmotorcycles.net
