Questions about smeg_plus

[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)

[bousqi]

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

[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

[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).