Indian Motorcycle Forum banner

1 - 20 of 116 Posts

·
Registered
Joined
·
148 Posts
Discussion Starter #1 (Edited)
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
Original Post:

Today I decided to take a look inside the Ride Command Unit. Here are some pictures:

IMG_20200201_142055.jpg
IMG_20200201_142858.jpg
IMG_20200201_142904.jpg
IMG_20200201_150313.jpg

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:

  1. 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.
  2. 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.
  3. 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.
  4. Oddly there are 2 bluetooth modules, seems they might be using 1 just for WiFi and the other for Bluetooth.
  5. 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.
Update 1:

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 (y)

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:

swd.png

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.

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"
fi
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

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 zeros
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.

Continued here
 

Attachments

·
Registered
Joined
·
215 Posts
J is a typical prefix used on schematics for a connector. I believe it stands for jack, or junction, or jumper.
Don't give up yet on activity you found on the two UART TX lines. Try the typical setting,115200 baud, 8 bit, No parity, 1 stop, then all other baud rates beginning with 9600.
SWD (Serial Wire Debug) is still considered JTAG. It's the newer way to do it, takes less pins, and is nearly as fast. It connects to the same debug hardware in the CPU.
 
  • Like
Reactions: Davey

·
Diamond member
Joined
·
9,096 Posts
What the hell did all that just say?! I thought you English folks spoke English?
Just guffin, but seriously, very cool seeing the different types with different talents pushing things forward.
Very interesting.
 

·
Registered
Joined
·
148 Posts
Discussion Starter #11
Ah, well the end goal is to be able to modify and run whatever we like on the dash, in terms of what that might be then that's simply a case of what would you like?

Personally it'd be nice to have some GPS navigation considering the hardware is there, whether that is possible is a different question but I'd like to give it a shot.
 

·
Diamond member
Joined
·
9,096 Posts
Ah, well the end goal is to be able to modify and run whatever we like on the dash, in terms of what that might be then that's simply a case of what would you like?

Personally it'd be nice to have some GPS navigation considering the hardware is there, whether that is possible is a different question but I'd like to give it a shot.
10/4
A worthy endeavor if I do say so myself.
Good luck!
 

·
Registered
Joined
·
215 Posts
Added update 6.
Wow emantec! Great work! And thank you Rick K. and your manager for leaving the door open! A debug build with symbols! Better grab this up before the first update.

Possibly can we find the CAN bus object dictionary?

Can you send me a dump image? Binary is fine.
 

·
Registered
Joined
·
148 Posts
Discussion Starter #15
Wow emantec! Great work! And thank you Rick K. and your manager for leaving the door open! A debug build with symbols! Better grab this up before the first update.

Possibly can we find the CAN bus object dictionary?

Can you send me a dump image? Binary is fine.
Unfortunately that was just a string, not symbols, there aren't any defined functions you have to disassemble it manually.
The dump I have at the moment was for the smaller processor, I think it was incorporated to actually interact with the canbus. If you're still interested in that I can PM it?
 

·
Registered
Joined
·
215 Posts
The dump I have at the moment was for the smaller processor, I think it was incorporated to actually interact with the canbus. If you're still interested in that I can PM it?
Oh the smaller processor is the CAN bus interpreter?
I'd like to have a look at whatever you can download from it. I'll have a look at it with Hexworkshop first. Very curious to see.
Can u share a link on Dropbox? Thanks
 

·
Registered
Joined
·
148 Posts
Discussion Starter #17
Oh the smaller processor is the CAN bus interpreter?
I'd like to have a look at whatever you can download from it. I'll have a look at it with Hexworkshop first. Very curious to see.
Can u share a link on Dropbox? Thanks
I think you have PM's disabled, can you check under your account privacy settings you have "Start conversations with you" set to members?
 

·
Registered
Joined
·
148 Posts
Discussion Starter #19
Ya ... imagine this thing could run a Android Auto ... or Apple CarPlay

Sent from my SM-N976Q using Tapatalk
Could? Yes. Will? Unlikely.

Apple CarPlay is proprietary so I have no access to it, Android Auto is actually a closed source app developed by Google, which again, I have no access to.

It could theoretically run Android but porting would be a huge effort that I won't be undertaking.
 

·
Bronze member
Joined
·
2,223 Posts
Could? Yes. Will? Unlikely.

Apple CarPlay is proprietary so I have no access to it, Android Auto is actually a closed source app developed by Google, which again, I have no access to.

It could theoretically run Android but porting would be a huge effort that I won't be undertaking.
What a pity ... I was just dreaming about a Android Auto host on FreeRTOS :)

( yeah right ...the FreeRTOS is on the smaller sub system ... the main CPU is running a so far unknown OS)

Sent from my SM-N976Q using Tapatalk
 
1 - 20 of 116 Posts
Top