bousqi / smeg_plus Goto Github PK

SMEG+ Unit reverse engineering

Python 100.00%

reverse-engineering smeg vxworks smeg-firmware smeg-unit

smeg_plus's Introduction

SMEG+ Firmware Analysis

This repo will centralize few item founds on forums regarding SMEG firmware.

Thanks to @DarkSino and @pixx for their notes on SMEG inner mecanics. Thanks to @MWyann that developped a RaspberryPi USB key that acts as a connected key from PSA.

Rather than trying to understand vxWorks that seems to act similarly to a kernel in linux, I digged into the upgrade process which sets everything at it's right place. Thus it offers the perfect opportunity to understand how the SMEG works. Cherry on the cake, the upgrade binary is in ELF format, and consequently analysis will be far more easy !
Thanks to a first pass on upgrade proccess, now I'm able to analyze efficiently the vxWorks.bin

Thanks to the new GHIDRA SRE tool, I'll now be able to share my disassembly work on vxWorks and upgrade process. Feel free to contribute
GHIDRA archives are located in ghidra subdirectory.

SMEG+ Firmware Analysis

TODO

Switch to GHIDRA SRE
~~Create an RPi Zero0W hotspot for longer remote acess to shell~~
+ two mass storage luns (one for music, and another for automtic ZAR and Maps download from car)
vxWorks disassembly
- ~~parse and process embedded Symbol table~~
- ~~parse all strings~~
- ~~define shell commands structures~~
- find the correct r2 (TOC) value.
  LOOKING for a PowerPC expert to understand
~~Work on License file for maps update~~
- ~~identify format and location~~
- Test License file
List all USB devices supported : VID/PID + class (EEM/MS/any other)
List all internal commands (WIP)
~~test vxWorks commands~~ -> UPDATE of command list
Dig on 3333 port server (GPS related)
Dig on 20000 port server
Find U-Boot location + dump ?
Finish upgrade process analysis

Findings

License File (Activation Key)

Thanks to analysis of Upgrade process, it appears that any map upgrade that needs and Activation key to be typed on SMEG unit, can be skipped if the key is stored in a specific file.
Just create a text file SMEG_PLUS_UPG/DATA/Licence with the 16 char of the key.
No CRC files are required on this License file.
Tested and approved.

???? (others to come)

SMEG+ Hardware

-> version
VxWorks (for Freescale MPC5121E ADS (Rev 0.1)) version 6.7.
Kernel: WIND version 2.12.
Made on May 26 2017, 13:23:36.
Boot line:
usb(0,0)host:vxWorks h=192.168.10.2 e=192.168.10.1 u=5121 pw=5121 f=0x0 tn=DB600

Board reference on WindRiver
https://marketplace.windriver.com/index.php?bsp&on=details&bsp=6901

MCU reference on NXP
https://www.nxp.com/products/processors-and-microcontrollers/power-architecture-processors/mpc5xxx-55xx-32-bit-mcus/mobilegt-51xx-52xx/32-bit-power-architecture-microcontrollers:MPC5121e

Opened SMEG Unit (for physical UART connection)

SMEG+ Partitions

Based on TFFS (True Flash File System).
vxWorks creates the following parts :

Type	Device Name	Usage	Contents
7	/romfs	Internal NAND	Debug binaries for audio & scheduler.bin
3	/ram	RAM	Contains config files, but not readable from telnet
3	/sdhc:0	Internal µSD	Cartographie GPS + Cheat Codes x3 + TTS
3	/sdhc:1	Internal µSD	User Guide
3	/bd0	USB Mass Storage
3	/SYSTEM	Internal NAND ?
3	/SYSTEM_DATA	Internal NAND ?
3	/SYSTEM_TMP_DATA	Internal NAND ?
3	/USER_DATA	Internal NAND ?
3	/USER_DATA_BACKUP	Internal NAND ?
3	/EXTENDED_PARTITION

SMEG+ Memory Mapping

Offset	Binary	Comments
0x00010000	ELF files	Dedicated space to load ELF files
0x00200000	vxWorks.bin
0x01000000	f_BigQuick.bin@0x801	Nav Binary is located in f_BigQuick.bin. The later embeds for ZLIB part. The first is the Nav binary. It can be extracted with binwalk

SMEG+ Firmware

SMEG relies on U-Boot and vxWorks softwares.

U-Boot

To Fill : U-Boot version

This software part is stored in NAND Flash out of any filesystem at location 0x????????
For updates, this binary is located in "TBD", with a filename u-boot-nand.bin

vxWorks

(dedicated page)

FW Upgrade Process

This section details the Upgrade process for SMEG+ FW, based on upgrade.out located in the root of archive
(dedicated page)

MAP Upgrade Process

This section details the Upgrade process for MAPS / ZAR, based on UpgPlugin.out located in the root of archive

the upgrade process seems to be managed by the following function :

_DWORD C_UPGRADE::UpgradeTask(C_UPGRADE *__hidden this)

As a summary, the upgrade procedure is made of many steps, no details to share so far.
However, at some point in the time, the following steps applies :

CheckCompatibilityTask(); - which initialize callback in plugin instance
CheckPresenceOfDRMOnMedia(this); - Check if DRM id available on SD
It verifies of the following file exists SMEG_PLUS_UPG/DATA/Licence
CheckDRMMedia(this); - check DRM content and validity if DRM available on SD
and finally starts the upgrade.

smeg_plus's People

Contributors

Stargazers

Watchers

Forkers

alexmayo j5boot p208pug vidarrt9 gitmesam skikkato serhiizahuba

smeg_plus's Issues

CDC_EEM

Hey @bousqi

sorry for bothering you again.

In VXWORKS.md you claim that VxWorks appears to be waiting for a CDC_EEM device.

You are then listing:

USB to Ethernet devices supported (TBC)

	.string "ADMtek ADM8515 USB Ethernet"
	.string "ADMtek ADM8513 USB Ethernet"
	.string "ADMtek ADM8511 USB Ethernet"
	.string "D-Link DSB-650TX USB Ethernet Adapter"
	.string "Belkin F5D5050 USB Ethernet"
	.string "NETGEAR FA101 USB Ethernet Adapter"
	.string "IO DATA USB Ethernet Adapter ET/TX-S"
	.string "3Com USB Ethernet 3C460B"
	.string "SpeedStream USB Ethernet"
	.string "SMC 2206 USB Ethernet"
	.string "SmartNIC USB Ethernet Adapter"
	.string "Microsoft MN-110 USB Ethernet Adapter"
	.string "Linksys USB10T Ethernet Adapter"
	.string "Linksys USB Ethernet Adapter USB100TX"
	.string "Linksys USB10TXX USB Ethernet Adapter"

While you make that statement, I didn't find any reference as to how you come to that conclusion?

Or do you mean to say that the VxWorks device simply supports these CDC_EEM devices? Your wording suggests that there may be a delay specifically to connect such a device:

vxWorks kernel seems to always expect for CDC_EEM devices. Thus any damage performed in file system that would brick SMEG, might be fixable if shell could be reached through CDC_EEM rather than BT Internet sharing (that requires interactions on screen).

... am I reading too much into it? If not, could you point me to the file which made you draw this conclusion?

During the weekend I plan to start experimenting with GreatFET and a Beaglebone Black in an attempt to get into the SMEG+.

Thanks for any insights you can share - and again for your prior work on all this. It really helps being able to look through what you've done to look for clues for what I am attempting.

Firmware Flashing?

Hello, I'm hoping not to bother after a very long period of inactivity...

My SMEG broke after a battery fault, it's stuck on the peugeot logo, which makes me think it's probably a firmware corruption or something. I also had a look at the HU board and nothing looks burnt.
I already tried flashing firmware with the usb method, which doesn't seem to be working. I was wondering if you know of a more barebones method maybe with UART or by connecting directly to the board anyway. Thanks!

Questions

Hi @bousqi,

I intend to work on this a bit more and I have a few questions. Thanks for your work so far.

When extracting the upgrade.out from the (restored) .gar file I get a SHA256 hash of d965a901d33ee9be320f728035e00adf99cc1c11f69805977454ba1fb4a51e30. However, out of the following SMEG+ firmware update packages I had at my disposal not a single ELF file matched the extracted file.

5.2.C.R1
5.4.B.R8
5.42.B.R4
5.42.C.R2
5.43.A.R2

I looked high and low and it looks as though you don't give the version (or hashes) of the files you reverse engineer. This makes colaboration a little harder than necessary. Could you please add that information. If you add it in a comment here, I'll send a pull request.

Or did you perhaps patch the file somehow in Ghidra and when exporting I get your patches as well? Unfortunately I am not as familiar with Ghidra as with IDA and Hopper, so I am not sure how to find out and fix it for me.

Thanks,

Viðarr

For reference I am including the hashes of the PowerPC ELF files I've got:

$ find -type f -exec file {} +|grep 'ELF 32-bit MSB'|grep PowerPC|cut -d : -f 1|sort -u|while read fname; do sha256sum ${fname#./}; done|tee ELF.SHA256SUMS
a2ef7a3c06662129abd1aaaaa9995e24bf1e950901856fafccf1e892cd69ab08  5.2.C.R1/SMEG_PLUS_UPG/NAV/DB_DWNL/db_dwnl_gl.out
f320bf457dd09a3afd97ca079ff210ff150e06a8341b88305a340452be9f1842  5.2.C.R1/SMEG_PLUS_UPG/UpgPlugin.out
a3c6c9c16d04d4fd431449cb5c230ed25ffdf56ccd4b7f968160691e02b52205  5.2.C.R1/SMEG_PLUS_UPG/upgrade.out
4195acad39872ce0eed3f59b917f462a07a7c3b7e89a38306d46ce28e4021e5f  5.2.C.R1/SMEG_PLUS_UPG/upgrade_256.out
63d31a5cd17d5bb5439ac6167b5df6d0e383c71b92785fa18107b90891408319  5.2.C.R1/SMEG_PLUS_UPG/upgrade_lib.out
a2ef7a3c06662129abd1aaaaa9995e24bf1e950901856fafccf1e892cd69ab08  5.4.B.R8/SMEG_PLUS_UPG/NAV/DB_DWNL/db_dwnl_gl.out
53a487c81555eed6ea4b6630b8181c0c4828689a3952a488e24dd675c0415f92  5.4.B.R8/SMEG_PLUS_UPG/UpgPlugin.out
1a19f739b55242676e4fe21a426acf2eb7b1a9abcfb80666fd62ecfdb16a24cb  5.4.B.R8/SMEG_PLUS_UPG/upgrade.out
33c4dfebab68d6adac9421aa2ab8391aaee212e44d798030a1d4416e60596682  5.4.B.R8/SMEG_PLUS_UPG/upgrade_256.out
63d31a5cd17d5bb5439ac6167b5df6d0e383c71b92785fa18107b90891408319  5.4.B.R8/SMEG_PLUS_UPG/upgrade_lib.out
a2ef7a3c06662129abd1aaaaa9995e24bf1e950901856fafccf1e892cd69ab08  5.42.B.R4/SMEG_PLUS_UPG/NAV/DB_DWNL/db_dwnl_gl.out
53a487c81555eed6ea4b6630b8181c0c4828689a3952a488e24dd675c0415f92  5.42.B.R4/SMEG_PLUS_UPG/UpgPlugin.out
298f6a3a3f6f2377a348193cdc43424401d90af6191d094729b923986d6d2277  5.42.B.R4/SMEG_PLUS_UPG/upgrade.out
a94663eac39831aef77e8bf0587936bd1f8216f718d2076b04099b0cee309985  5.42.B.R4/SMEG_PLUS_UPG/upgrade_256.out
63d31a5cd17d5bb5439ac6167b5df6d0e383c71b92785fa18107b90891408319  5.42.B.R4/SMEG_PLUS_UPG/upgrade_lib.out
a2ef7a3c06662129abd1aaaaa9995e24bf1e950901856fafccf1e892cd69ab08  5.42.C.R2/SMEG_PLUS_UPG/NAV/DB_DWNL/db_dwnl_gl.out
53a487c81555eed6ea4b6630b8181c0c4828689a3952a488e24dd675c0415f92  5.42.C.R2/SMEG_PLUS_UPG/UpgPlugin.out
1a19f739b55242676e4fe21a426acf2eb7b1a9abcfb80666fd62ecfdb16a24cb  5.42.C.R2/SMEG_PLUS_UPG/upgrade.out
33c4dfebab68d6adac9421aa2ab8391aaee212e44d798030a1d4416e60596682  5.42.C.R2/SMEG_PLUS_UPG/upgrade_256.out
63d31a5cd17d5bb5439ac6167b5df6d0e383c71b92785fa18107b90891408319  5.42.C.R2/SMEG_PLUS_UPG/upgrade_lib.out
a2ef7a3c06662129abd1aaaaa9995e24bf1e950901856fafccf1e892cd69ab08  5.43.A.R2/SMEG_PLUS_UPG/NAV/DB_DWNL/db_dwnl_gl.out
53a487c81555eed6ea4b6630b8181c0c4828689a3952a488e24dd675c0415f92  5.43.A.R2/SMEG_PLUS_UPG/UpgPlugin.out
1a19f739b55242676e4fe21a426acf2eb7b1a9abcfb80666fd62ecfdb16a24cb  5.43.A.R2/SMEG_PLUS_UPG/upgrade.out
33c4dfebab68d6adac9421aa2ab8391aaee212e44d798030a1d4416e60596682  5.43.A.R2/SMEG_PLUS_UPG/upgrade_256.out
63d31a5cd17d5bb5439ac6167b5df6d0e383c71b92785fa18107b90891408319  5.43.A.R2/SMEG_PLUS_UPG/upgrade_lib.out

Harmony

Hi!

First of all - great work on unpacking SMEG PLUS! I have a 2017 DS4 and have been spending the past few weeks trying to alter the Harmony 'Rubis' using an update USB stick. I can change the image within the harmony, however once it is packed up and placed onto a USB stick, the system does now allow the update to complete, most likely because the CRC no longer validates. Could you explain how I could go about generating the CRC found within BIG_SKIN_NAV.bin.inf that is located within HARMONY/BigHarmony_6 in the latest update file for SMEG +IV2?

Best,
Alex