Help Getting Started With Ghidra For MPC562 ME9.6.1 VE E77 LY7

[hjtrbo]

Solid advice. I've learned something to. I've been kissed on the dick with everything I've ever done anchoring at 0x0.

[antus]

Yep. Its always gets harder as things progress and get more complex. My rule of thumb for software development in the regular forward direction is keep it simple. And the term "you ain't gonna need it" is words of wisdom too. So when you are reverse engineering the old stuff is simpler and easier to get your head around to learn the concepts and the tools. 68k PCMs do load the flash at 000000, and have a known vector table to find the code entry points. By this generation the difficulty is next level because of increased system complexity. That can bring more security, more safety and more efficiency, but it sure makes reverse engineering harder. What AI can do, is what you can do, and you give it solid guidance to do, so long as the complexity stays at a level it can comprehend. And it can do it faster. And it can also make tools. But it itself is a tool and a teacher. But it's not always right, it misses things, sometimes takes the wrong approach and the new ideas you can come up with are what can set you apart. When you are starting out it will be able to you a lot, especially if you open the thinking boxes and see why its decided to do what does. You can learn from that thought process to level up yourself. Over time you'll get to know what to do and sometimes click the stop button to save yourself money (if paid ai) because you can see its taken a difficult approach that it wont succeed or you can see its gone down a rabbit hole when the answer is right on the screen in front of you, and then you can pull it back and stay on target.

[hjtrbo]

viewtopic.php?t=9312

[Lucasperks06]

thanks for the replies, its starting to make some sense now with the base addresses and offsets. i thought we were offsetting the whole file x amount (like 400000) which wasnt making sense but setting the base address to where ive set it makes sense. if im getting this right, where the pointers are referencing, is where we want our base addresses to be (in that range anyway).

ive set the ghidra file up how youve said, from what your saying, how weve set it up now is to start at the r2 register, but really we want the file to begin at the boot block. what factor does having the boot block being located have? how does it help? ill have a look and see what i can find to be able to locate it, or what others have done for me9.
and yeah okay so start with finding obd pids, ill have a look into that too and see what i can find.
would using my xdf and finding already known maps help at all? if i can locate a very basic map with say rpm x load, would that potentially help in anyway, or not really.

also another question, ive only heard people talk about locating the r2, r12 and r13 registers, what about r3, r4 etc, what role do they play in all this?

also i loaded in that calram section as you said and theres thousands of references there, so thats good. what about the space in between the calram and the bin?

but so far making progress, even if its little

also with universal patcher, i have the e69 xml in the folder, but its not picking it up, also would using a e69 xml on a e77 even work properly?

[Lucasperks06]

and i bought claude ai for 7 days, so ill see how that goes, obviously ill be careful and not think everything its saying is 100% true

[hjtrbo]

You will have gaps. Depends how much of the memory map in the data sheet you want to include and how far you go depends on your goal. Discovering more about your tune or looking at getting into patching for example.

There is a universal patcher support thread, maybe make a post there. I'm running a version that's about 4 years old so there might have been some changes since.

Post a screen shot of your memory map.

Transferring maps you have already created is not a bad move. Up to you how you want to do it, by hand, hand curated python or AI python / mcp.

See if you have xref's into the can registers. Following those back will get you into the comm handlers. Poking around there can lead you to recognisable data patterns (structs) that can uncover the diag service handlers.

[Lucasperks06]

viewtopic.php?t=8487&start=20
this thread seems to have some good info, and makes me feel better about my r2 and r13 values as his are the exact same. althought he is on the mpc563, which has that extra .5mb that ive heard about.
and yeah id be happy to start transferring maps, even by hand just to start out, im in no rush haha. thats one of my main goals is to find maps in winols, and transfer them over to ghidra and sort of "study" them or be confident they are right, or just figure out how they work if im unsure of what it is, which ive got alot of them.

i also noticed he started his (im assuming flash) at 400000, whether this is the start of the bootloader im not sure. thought it was interesting though.

ive noticed too he set his ram at 600000 too, and made it 300000 long, ive done mine how gatecrasher said with a length of 8000, should this be changed or left as is? i dont see any harm in extending it?

with his cal area hes added, hes " put base address as 0x5c2000 and offset 0x1c2000 and length 0x3e000", wouldnt that start it at 6c4000?
and another thing too with the cal area, so every single OS for ME9.6 and 9.6.1 ive seen, starts its cal in that 1c2000 region, whereas every bin ive put into winols says the cal starts at around 1A2000, a -20000 offset.
but heres the wierd part, when using hp tuners user defined parameters, its says the cal starts at 1c2000 for my OS. and if i add 20000 to the offset on my xdf, and use it in hp tuners, everything shows up perfect.
but my main question for that is i wonder if that will affect locating maps in ghidra, im assuming it wont be hard to figure out which address it starts at though.

so by the looks hes imported his bin with no changes to base address and offsets, then hes added his 512kb file (i may just have to add in my same 2mb) and set the base address to 400000, then added the 2mb file again, and set it up for calibration area, and ram.

and yeah okay with those gaps it makes sense, which i thought too just wanted to double check. and that may be the reason why it might just be a newer version and it wont work properly.

and what is a can register too? how would i go about locating it?

Screenshot 2026-06-14 185913.png

Screenshot 2026-06-14 184303.png

this is his memory map not mine*

Screenshot 2026-06-14 183919.png

[antus]

try and get claude hooked up to ghidra, and ask if it can see your project. Then you can start doing things like cut n paste that image with the segments and ask if you have ghidra set up correctly. Find out what it can and cant see. Then you can start using a combination of human insight and machine insight. You need to make sure it doesn't do anything stupid like trying to disassemble bytecode manually, that'll blow tokens for something you already have a tool for. But you can try things like "identify which routine builds the response to an iso get rpm request", and then watch the thinking prompt to see if it's makeing sense and see if it can find the routine for you. Stop it if it isn't. Then you can ask it to add annotations. I'm not sure what it'll do on PPC or in Ghidra, but I have been having a good run lately with it doing tasks like these for 68k in ida and even the older hc11 binaries directly in a shell on my system.

@hjtrbo - that MCP fork is a great piece of work, prefect!

[Lucasperks06]

yeah okay ill see if i can get that figured out man thanks.

im having a drama with this bin file, i beileve that its missed the first 20000 bytes when its converted it from hpt to bin. but whats weird is every single hpt file does this when converted to bin, but only for my SW number. every other e77 and e55 go from 0 - 2000000, mine goes from "0x20000 - 0x1FE000", and it would explain why my cal area is 20000 offset from where it should be.
does anyone have a hpt to bin convertor thats different to mine? the one im using is called "software hpt to bin"
i wonder if a different software would read it properly, or if someone has a bin already.
cause i dont see a point in continuing if its an improper bin.

[Gatecrasher]

i also noticed he started his (im assuming flash) at 400000, whether this is the start of the bootloader im not sure. thought it was interesting though.

Stop and go back to the datasheet. Don't go any further until you understand this. Page 97 or 1-13. The MPC563 has that extra 512k, which is why his starts at 0x400000. You have a 562, so you don't have that 512k of built-in flash. If you had a full read, including the boot block, yours would still start at 0x480000. If you wanted to visualize it, you could go into your memory map and create an empty placeholder block from 0x480000 to 0x4A0000. It's not really necessary though.

ive noticed too he set his ram at 600000 too, and made it 300000 long, ive done mine how gatecrasher said with a length of 8000, should this be changed or left as is? i dont see any harm in extending it?

Again, go back to the memory map on page 97. 0x600000 would put the "RAM" start right in the flash block. Making it 0x300000 long would encompass all of the control registers and the actual RAM, and a bunch of empty space that doesn't even exist after the RAM. This will work, but it won't be very helpful. If you build it his way, and see a cross reference to 0x7071D6, it'll just look like some random RAM reference. If you do it the right way, you'll see that it's a reference to CAN controller A's message buffer number 13. If you're hunting around for CAN information, that distinction is going to be huge.

The correct, albeit tedious, way to do this, would be to create memory map sections for every one of those blocks on page 97. That's something an AI could probably be a big help with. Ask it to write a Ghidra script to create and name those memory regions and individual registers based on the data sheet. I really need to do this myself for some of my projects.

Don't worry about not having the boot block in your HPT read. I've found they can be helpful to have, but they're not mandatory for most things. The boot block is mainly there to do initial hardware setup, check to see if OS and cals are loaded, and if not, build just enough framework to communicate with a tool to accept a reflash. The OS often overwrites a bunch of hardware and RAM settings once it boots anyway.