Questions

[vidarrt9]

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

[bousqi]

That's a good point. Let me check this. I'll get back to you in one week (no access to laptop this week)

[assarbad]

Hi, any news perchance? Thanks.

[bousqi]

I'll have a look tonight. From what I remember, I was working on 5.43.A.R2, but to be confirmed.

[bousqi]

So I just checked, and I confirm I was working on 5.43.A.R2, but not in the directories you list. I've been disassembling the one in root dir This one as the SHA-256 : 1A19F739B55242676E4FE21A426ACF2EB7B1A9ABCFB80666FD62ECFDB16A24CB

[bousqi]

I lost the .gar archive... I just remember that at some point in the time, the archive where to big to be uploaded on GIT. Thus I might have keep updating it without pushing it on GIT. I'll double check.

I just retrieve the .gar file I was not able to upload. Uploading ongoing on an external hoster SMEG_2019_04_15.gar

It requires a simple pssword like : SMEG_PLUS

[bousqi]

@vidarrt9 & @assarbad, keep me updated. If you have any questions, fell free to ask.

[vidarrt9]

Thanks, I'll have a look in a bit. Keep in mind that I was extracting the file from the .gar in order to figure out which version you were subjecting to the Ghidra treatment. So I suppose it's the same. Now that I know I can compare if anything was patched, perhaps.

[bousqi]

@vidarrt9 , are you looking for something specific in SMEG units ?

[vidarrt9]

@vidarrt9 , are you looking for something specific in SMEG units ?

Hey, nothing specific as such, no. I am an experienced reverse engineer with other OSs and CPU architectures, but never dabbled in VxWorks for starters and only very little on PowerPC so far. I have a T9 myself, so that sort of makes sense, too. I also found a few bugs in the software running on the SMEG+ and would love to be able to fix those. But generally it's just curiosity. Since the cheat codes are loaded from the SD card instead of the NAND I also expect those to be an inroute into the device, but only time will tell.

So no, nothing specific. Just curiosity and the desire to share the finding. Because being also a software developer I know that bugs aren't god-given, they are developer-imposed. And the fact that PSA doesn't care about its obligations under GPL (U-Boot source for exactly whatever they built to run on the SMEG+) or about feedback regarding the software running on those units means they are negligent about their own software, IMO (and yes, I am aware that they sort of outsourced this to Magneti Marelli, presumably the one site of MM which is located in France). But outsourcing development doesn't really mean you have less of a responsibility toward your customers/users.

One of my first goals is to get this to run either in Qemu or Unicorn Engine and then we'll see where it goes from there.

[bousqi]

Interesting, I had the same approach in mind. I guess you have seen my VxWorks document that was the bigger part. I spent most of my time on VxWorks. However, I met some troubles with Ghidra to disassemble efficiently (related to the TOC register).

I would be definitely interested in runing VxWorks in QEMU, but I'm pretty sure it won't be so easy, at least if you are trying to run the one from SMEG (many peripherals will be missing). I'll track your repo for updates.

[vidarrt9]

Interesting, I had the same approach in mind. I guess you have seen my VxWorks document that was the bigger part. I spent most of my time on VxWorks. However, I met some troubles with Ghidra to disassemble efficiently (related to the TOC register).

I saw your comments, yes.

I would be definitely interested in runing VxWorks in QEMU, but I'm pretty sure it won't be so easy, at least if you are trying to run the one from SMEG (many peripherals will be missing). I'll track your repo for updates.

I don't think that Qemu will be easy either. But Unicorn Engine is more like what IDA offers with Bochs, if you know what that is. Obviously Bochs doesn't offer PPC as an architecture, so it won't work unchanged. However, Unicorn Engine looks promising. The biggest obstacle will be to get rid of all of those places where it expects some peripherals or somehow mock those.

On another note: have you tried using the UART on a SMEG+ unit to find ways into it? I have yet to use those soldering pads on the one that's in my car or find a way to get the one that I have on my desk to run outside a car, but I think that unlike the Telnet access you can gain, the UART access may be more privileged. Just haven't verified that assumption as life constantly hands me other important stuff that's not quite as geeky 😉

As I understood it, the NAND is part of the SoM, so no way to use the usual tactics of trying to read it out with Bus Pirate or some such. Or do you have contradictory intelligence about the location of the NAND?

[bousqi]

QEMU seems to already have support for MPC8544ds, which based on name, is not so far from MPC5121E. At least both are based on e500 core. That was just a 2 minutes investigation, but it looks like QEMU could be a potential client. I never heard about Unicorn Engine, I'll look at this.

Regarding the UART, I did not took the risk to extract the Unit from my car :) (I still use it). However, I just merge a pull request from @P208PUG that shared a picture of an opened SMEG Unit with UART Pins. Maybe he did some testing.

About the NAND, I can't remember the datasheet for this system. I guess the most promising idea is using UBoot to dump, which might definitely require a UART access rather than a Telnet one.

Just haven't verified that assumption as life constantly hands me other important stuff that's not quite as geeky 😉 I know that... I totally understand, same on my side.

[vidarrt9]

QEMU seems to already have support for MPC8544ds, which based on name, is not so far from MPC5121E. At least both are based on e500 core. That was just a 2 minutes investigation, but it looks like QEMU could be a potential client. I never heard about Unicorn Engine, I'll look at this.

Unicorn Engine uses code from Qemu under the hood. The main point here is that Qemu can either emulate a system or emulate instructions of a foreign binary with a compatible syscall interface (i.e. you can use binfmt support to register a Qemu binary as interpreter for PowerPC ELF files, for example). Unicorn engine allows you basically to execute blobs of code of a given architecture and get introspection. This is for cases like ours where you can't emulate the whole system (e.g. in absence of certain peripherals). IDA with Bochs allows something similar. Haven't used it in a while, for all I know they may have removed it. It was useful for investigating bootkits on the x86.

My worry isn't so much whether Qemu would be capable of emulating this particular CPU. I'd expect the obstacles in other places, but perhaps I'll stand corrected 😁

Regarding the UART, I did not took the risk to extract the Unit from my car :) (I still use it). However, I just merge a pull request from @P208PUG that shared a picture of an opened SMEG Unit with UART Pins. Maybe he did some testing.

Alright, I'll try to get in touch.

And getting it out wasn't really hard at all. I did it to exchange the μSD card which, unfortunately, is really deeply embedded in the SMEG+ unit of my T9. I actually need to do it again, because I lost the Jukebox in the process of upgrading the disk space.

I think I should indeed document the aspect of getting it out here in a Wiki on GitHub.

About the NAND, I can't remember the datasheet for this system. I guess the most promising idea is using UBoot to dump, which might definitely require a UART access rather than a Telnet one.

Hmm, I'm not sure that this will yield much, though. It's one way but it's going to be tedious, slow and error-prone. I've done something like this in the past with a 32-core MIPS-based system and the dump I got was malformed in several places (obviously due to the issues with UART/serial in general).

But let's see. After all if we're lucky some of the networking capabilities of U-Boot are left intact and then we can use those to transfer stuff more easily by "wire" (or even wireless).