Reverse engineering a 411 operating system

They go by many names, P01, P59, VPW, '0411 etc . Circa 1999 to 2006. All VPW OBD2 PCMs.
User avatar
Posts: 171
Joined: Fri Feb 02, 2018 3:13 pm

Reverse engineering a 411 operating system

Postby NSFW » Sat Jan 26, 2019 6:46 pm

Do we want to make our own customized operating systems? Of course we do.
How do we start? By finding the code that needs to be changed.
How are we gonan do that? I'm so glad you asked...

I started trying to disassemble the OS that came in my car a couple weeks ago, and have made enough progress that I think it's worth documenting how I did it, in case other people want to do something similar for other operating systems. I just put everything I've got so far on GitHub. It is admittedly not much, but there's enough that I'm pretty optimistic about where this is all going:

https://github.com/LegacyNsfw/12593358

A few things made it possible to make a lot of progress in a pretty short time.

1) Dimented24x7 disassembled a bunch of another OS a couple years ago, and posted his findings. That was especially helpful in the very beginning, so I've put a copy of his annotated disassembly in the GitHub repository.

2) IDA Pro. You can also do this kind of thing without it (Dimented didn't seem to be using it) but I'm a huge fan because if its ability to navigate around using cross-references and lists of named objects/variables/functions/whatever. It is kind of expensive, but I think it's money well spent.

The key thing in that GitHub repository is an IDC script file. After you load a bin file into IDA, you can run this IDC script to tag everything I've found so far.

3) An XDF for the operating system, thanks to cmaje72. I wrote a small Windows PowerShell script that reads the XDF and produces an IDC script, which IDA then executes. When that's done, all of the constants and tables that were in the XDF are labeled in IDA. Then you can use IDA's cross-referencing to find the code that uses the stuff documented in the XDF.

4) There's a table in the OS that maps OBD2 PIDs to functions. I haven't actually verified this for certain yet, but I am pretty sure that those functions read values from RAM, do a little bit of trivial arithmetic to convert to the desired units, and return the value that gets sent back over the OBD2 connection. I thought I was looking at a job scheduler at first (execute all of the functions in order, then start over if it runs out of time?) but then I remembered that Subaru's OS has a similar table of function pointers for OBD2 queries, and then I noticed that the values alongside the function pointers look an awful lot like OBD2 PIDs... So I wrote another PowerShell script, which processes this table to produce another IDC script, which gives names to all of the functions. From there, you can label the RAM locations.

All of the above is described in more detail in a wiki page at the GitHub repository.

I haven't achieved anything especially noteworthy just yet, but like I said, I feel pretty good about where this is going.

I've started a separate thread to document stuff that I find in the ROM:
viewtopic.php?f=42&t=6240
Please don't PM me with questions about tuning or flashing - start a thread instead. Thanks!

Posts: 3143
Joined: Mon Aug 02, 2010 6:35 pm

Re: Reverse engineering a 411 operating system

Postby Dylan » Sat Jan 26, 2019 7:00 pm

Awesome work you're doing there mate thanks for sharing

User avatar
Posts: 217
Joined: Sun Jan 25, 2015 4:21 pm
Location: Sydney

Re: Reverse engineering a 411 operating system

Postby j_ds_au » Sat Jan 26, 2019 10:55 pm

I second that!

Posts: 101
Joined: Sat Dec 15, 2018 7:38 am

Re: Reverse engineering a 411 operating system

Postby Gampy » Sun Jan 27, 2019 12:55 am

Amazing ... What a great and challenging experience!

I've been tinkering with osid 12208322 and a couple different disassemblers, getting nowhere in reality.
Not getting the arch right or something, it winds up with commands that the programmers reference I have doesn't show, though my reference may be wrong, it doesn't exactly match the chip ...

Check out ODA - The Online Disassembler, kinda lame but educational ...

Tried to buy IDA Pro awhile back (v5), didn't believe my name, wouldn't sell it to me unless I used my corporate name.
Also been told the guy is greedier now and not so picky ... Maybe I'll try again. Always hoped it would just land in my lap ...

Keep up the good work.

-Enjoy
: )_~

User avatar
Posts: 171
Joined: Fri Feb 02, 2018 3:13 pm

Re: Reverse engineering a 411 operating system

Postby NSFW » Sun Jan 27, 2019 8:35 am

When the CPU powers up, initializes the stack pointer with the value stored in the first four bytes of memory (0xFFCE00 in my case), and then it initializes the instruction pointer with the value in the next four bytes (0x440). The CPU data sheet is huge, and a lot of it is only interesting if you're designing a circuit board, but it's worth keeping a copy handy for tidbits like that.

So anyway, I extracted the bytes from 0x440-0x45F and pasted them into ODA (I had not heard of it, but it's kinda neat). With the CPU set to M68K:CPU32, the disassembly comes out fine.

I used the bin2hex utilty here to convert the whole bin file to a text file in hex:
https://github.com/LegacyNsfw/PcmHacks/ ... F02%2F17.1
That just produces raw hex data, and for this kind of thing it would be helpful to have a column with the address of the start of each line, so I'm sure there are better tools out there. But that was the first thing that came to mind.

So then I uploaded the whole .bin file (default endian, by the way), scrolled to 0x440, and converted to code... The bar at the top indicates that disassembled a couple of kilobytes, which is also what IDA did too - I guess that's basically the boot code. However if I jump to 0x20000 (the start of the OS segment) it shows disassembly, not just data, so maybe it got further than that. ODA got pretty slow at that point, so I didn't go further.

Here's where I left off:
https://onlinedisassembler.com/odaweb/Pqoog1pg/0

References to RAM variables look at little weird in ODA, there are a ton of leading FFs displayed, as if there was a 64-bit address space. If there was a way to tell it that RAM starts at FF0000 that would be nice.

The biggest things it's missing, compared to IDA, are navigation and scripting. It's really nice to be about to double-click and address to go to it, or press X to see all references to it. I do a LOT of jumping around like that, constantly. And the ability to label known RAM and ROM addresses from a file (IDC) saves a ton of manual work. I guess that doesn't require a scripting language necessarily, it could also just use a CSV file or something like that.

The purchase process when I bought IDA was bizarre. I had to find a reseller to take my money and then ultimately Hex-Rays (makers of IDA) insisted on contacting me at my work address, even though I was using it strictly for personal projects. Makes me wonder what kind of weird stuff must have happened to make them think that was so important. That was in 2011 though, so it's been a while. I have version 6.1.
Please don't PM me with questions about tuning or flashing - start a thread instead. Thanks!

Posts: 101
Joined: Sat Dec 15, 2018 7:38 am

Re: Reverse engineering a 411 operating system

Postby Gampy » Sun Jan 27, 2019 6:07 pm

Tidbits like that are everything, I like em ... Thanks!

Yea, it does get a bit slow with 512k in it ... The only way to navigate is via the slider at the top, trying to scroll pages is painful.

So, You used bin2hex then uploaded the hex file?
I just let it load the bin fresh off PcmH.

I have contacted the author to suggest the ability to work with ranges. working one line at a time is painfully slow.

-Enjoy
: )_~

User avatar
Posts: 171
Joined: Fri Feb 02, 2018 3:13 pm

Re: Reverse engineering a 411 operating system

Postby NSFW » Sun Jan 27, 2019 7:16 pm

There's an option to load the whole bin file as-is, I think that was under the File menu at the top of the page. I didn't notice that until after I used bin2hex to load that first little section of the bin.
Please don't PM me with questions about tuning or flashing - start a thread instead. Thanks!

Posts: 2
Joined: Mon Feb 11, 2019 12:48 pm

Re: Reverse engineering a 411 operating system

Postby jlvaldez » Mon Feb 11, 2019 12:50 pm

Thanks for the work you've got here. I've been following it.

I don't have a good disassembler, so your comments you've left in your assembly file have been really helpful.

Posts: 101
Joined: Sat Dec 15, 2018 7:38 am

Re: Reverse engineering a 411 operating system

Postby Gampy » Mon Feb 11, 2019 8:27 pm

I guess the ODA author is unwilling to accept it's anything but perfect ...

Has anyone played with Dismot68. Two pass Motorola 6833X disassembler from usbjtag.com?
It probably has the clearest most accurate output I've found yet, it is not syntactically correct, but it does parse parameters the best I have found.

If you got it handy and want to test something I sure would like knowing the outcome ...
Rename a project (.bin and .def) to mini.bin and mini.def. (Anything like *ini.bin, *ini.def or even ini.bin and ini.def)
Open DISMOT68, Open mini.bin
What is the 'Disassembled File' name.

I've told the author, I get no response on that issue, just ignores it, though does willingly answer all other questions, so I suspect he knows and doesn't care.
What a shame, It is a wonderful piece of work. wish he would fix up some minor details (or allow someone else too) and make it o so fine.

Still looking for a decent 68k disassembler ... IDA ain't happening, I refuse to give them corporate info for a personal license.

IMNSHO a good disassembler's output should be able to be recompiled with minimal or no rework, if not then whats to say it's accurately disassembled.

-Enjoy

Posts: 2392
Joined: Sun Aug 02, 2009 9:16 pm
Location: Bayside, Melbourne, Victoria

Re: Reverse engineering a 411 operating system

Postby VX L67 Getrag » Tue Feb 12, 2019 7:27 pm

NSFW wrote:When the CPU powers up, initializes the stack pointer with the value stored in the first four bytes of memory (0xFFCE00 in my case), and then it initializes the instruction pointer with the value in the next four bytes (0x440). The CPU data sheet is huge, and a lot of it is only interesting if you're designing a circuit board, but it's worth keeping a copy handy for tidbits like that....


So how do you figure this section out, as there's some programmers out there that are making request's bounce back as unknown request... so I'm thinking they're changing this section which no other software will write to with the unknown request... but there software will ignore that request & then read/write regardless.

I could be wrong but there's got to be something in it, yet if you bench read obviously it will just read direct from BDM... but not all controllers can be bench read.

BTW I'm loving the work going into this & pcmh!

Next

Return to GM LS1 512Kbyte and 1Mbyte

Who is online

Users browsing this forum: No registered users and 1 guest