The Trampoline (Inside booting the Mac with a microscope)

[ELN]

Probably a good time to offer a progress update. I've been pretty busy with my studies, but I've managed to get some things done in between.

I have neatened up my build stack quite a bit over the past couple of months. Pretty soon (say over the next month) I hope to have a few things to share with the community:

• Instructions for setting up a Netatalk 2.1 server on a Debian VM with a case insensitive FS (my MPW-compatible "MacSrc" server)
• A Python FUSE module allowing Git to work correctly with Mac-newline sources
• A fully annotated disassembly of all the low-level ROM-based Mac OS managers
• A reimplementation of the Apple build tool needed to postlink that disassembly (see patent US5546586 on "ROM vectorisation")

[nanopico]

You are correct that a minimal stdclib would be required.  For an early second stage boot loader like the trampoline, it would have no access to the any standard libraries unless they are directly built in.
Exciting stuff.

Just out of curiosity what did you use to decompile it to C?

[powermax]

Christmas in August, huh?

Why not?

How about you post an archive on this site, and we'll see what we can do about getting it to build.

I'd avoid posting RE'd or decompiled stuff closely matching copyrighted code in a public forum. Moreover, this way we had very limited possibilities for collaboration. I'd better set up a private repository and work from there.

I have concocted a slightly dodgy set of PPCAsm files that produce the Trampoline as an ELF *within* an XCOFF container.

IIRC, Apple's OpenFirmware implementation is capable of loading and executing XCOFF binaries directly. Does MPW compile to XCOFF?

[powermax]

Just out of curiosity what did you use to decompile it to C?

Well, I used the following toolchain: disassembler ==> custom Python decompilation script ==> manual postprocessing.

I worked at the function-level by converting the assembly into pseudo code. My Python script has been programmed to process function prologs/epilogs, some simple code idioms, conditional branches and simple expressions in a basic block. Anything beyond that need to be done manually.

I remember it was very tedious work (and a major hackage). I'd love to have a working decompiler for PowerPC but, unfortunately, I didn't see any...

[ELN]

Interesting approach! Mind putting your script on the repo so I can have a peek? My GitLab username is "elliotnunn".

For my NanoKernel disasm I wrote a Python disassembler based on Capstone. The NK actually doesn't use a call stack so there weren't many useful motifs to identify functions (and the NK uses the BL instruction "creatively", to boot). The last change I made to the script was to produce MPW-format binaries. Since then I have been tweaking the disasm by hand.

Here's the script:
https://github.com/elliotnunn/toolboxtoolbox

[Daniel]

MPW does compile to XCOFF. The initial register values are the same for both ELF and XCOFF, so it doesn't really matter which one is used. ELF files are preferred by Open Firmware because apparently some special section can be used to specify configuration variables or something (which isn't that useful because we can do that from the forth boot script). I assume that we would prefer XCOFF if it can work.

[nanopico]

IIRC, Apple's OpenFirmware implementation is capable of loading and executing XCOFF binaries directly. Does MPW compile to XCOFF?

Bootx is actually an xcoff.  If you look at the code for bootx it has a small utility with it to convert from mach-o format to xcoff. The default output of their build is mach-o which open firmware doesn't like.
As far a stdclib you could lift the code from bootx easily.
The assembler in MPW by default outputs to xcoff and the linker is what converts it to PEF.  Mac OS can actually load xcoff and PEF for user programs.  xcoff is almost never used though as it is much slower to load and link.  Of course there would be preferential treatment for their own format (PEF).

Just out of curiosity what did you use to decompile it to C?

Well, I used the following toolchain: disassembler ==> custom Python decompilation script ==> manual postprocessing.

I worked at the function-level by converting the assembly into pseudo code. My Python script has been programmed to process function prologs/epilogs, some simple code idioms, conditional branches and simple expressions in a basic block. Anything beyond that need to be done manually.

I remember it was very tedious work (and a major hackage). I'd love to have a working decompiler for PowerPC but, unfortunately, I didn't see any...

Sounds like the same thing I am doing, but most of the work after the disassembler is manual. I would say tedious is an understatement no mater which way you go. A boot loader like this is more difficult than other programs as there are no external libraries linked to help aid in identifying what is making external calls and there are no debug symbols. Oh god debug symbols would be the best thing in the world for this.
I'm starting to think it would be worth writing a decompiler.

[Daniel]

Hey Nanopico! I just found a new trick! Type the following into your open firmware prompt:

Code: [Select]

dev /openprom/client-services
true to cidebug?
mac-bootMake sure that you do this from telnet because you will end up with a bunch of lines that look like this

Code: [Select]

CIcall: 1198c8 finddevice deadbeef returned: deadbeef rets: ff83e940My only complaint is that the system takes a really long time to boot.

[nanopico]

Hey Nanopico! I just found a new trick! Type the following into your open firmware prompt:

Code: [Select]

dev /openprom/client-services
true to cidebug?
mac-bootMake sure that you do this from telnet because you will end up with a bunch of lines that look like this

Code: [Select]

CIcall: 1198c8 finddevice deadbeef returned: deadbeef rets: ff83e940My only complaint is that the system takes a really long time to boot.

Slow boot doesn't bother me.  I'm kind of used to it now with some of the things I've ended up with lately.
I'll try this when I get back to doing this.  A little slow lately.
Where did you find this or is it just in your head? 

[MacOS Plus]

What on earth is "deadbeef"?

[Daniel]

I was looking at /openprom/client-services to see if there was anything useful. I saw that there was a variable called 'cidebug?'. It was present on every New World Mac I had. I tried setting it to true, and here we are.

deadbeaf is a hexadecimal number that is often used as an indicator to programmers. In decimal it is 3735928495. All of the cidebug logs had the constant deadbeaf in them for some reason. That particular one had very little useful information, but some of the other ones have useful addresses in them.

Code: [Select]

CIcall: 1198c8 getprop deadbeef 100 106e58 1024ea returned: deadbeef rets: 31
CIcall: 1198c8 getprop deadbeef 8 116990 102512 returned: deadbeef rets: 4
CIcall: 1198c8 getprop deadbeef 8 116990 102519 returned: deadbeef rets: 4
CIcall: 1198c8 finddevice deadbeef returned: deadbeef rets: ff83c1c8
CIcall: 1198c8 getprop deadbeef 8 116990 102557 returned: deadbeef rets: ffffffff
This is only an excerpt. If you try this yourself you will get a very very long list of lines like these. I got around 4000 of them.

All the addressses beginning with 1 point somewhere inside the Trampoline code or data structures.

For the uninitiated, this is a debugging feature of open firmware that records useful data every time the Trampoline asks it to do something. I probably should have stuck this at the beginning of this post 

[MacOS Plus]

Okay, I looked up what that was all about.  I gather that the main point of "deadbeef" and other such things is that it makes for items that are easily caught by eye in a sea of hex code:

https://en.m.wikipedia.org/wiki/Hexspeak

It doesn't explain what the original inspiration for that phrase was, but at least I understand the concept.  In a mildly ironic twist relevant to our forum, it's also the name of a music player app:

http://deadbeef.sourceforge.net/

Computer programmers are curious creatures!

[nanopico]

It (as a lot of others) is funny. If you dig around a lot you will find these things go way back as jokes.
But deadbeef is common and if you think about it. You are trying access/use a dead piece of something. add beef to be funny and there you go.

[nanopico]

I was looking at /openprom/client-services to see if there was anything useful. I saw that there was a variable called 'cidebug?'. It was present on every New World Mac I had. I tried setting it to true, and here we are.

deadbeaf is a hexadecimal number that is often used as an indicator to programmers. In decimal it is 3735928495. All of the cidebug logs had the constant deadbeaf in them for some reason. That particular one had very little useful information, but some of the other ones have useful addresses in them.

Code: [Select]

CIcall: 1198c8 getprop deadbeef 100 106e58 1024ea returned: deadbeef rets: 31
CIcall: 1198c8 getprop deadbeef 8 116990 102512 returned: deadbeef rets: 4
CIcall: 1198c8 getprop deadbeef 8 116990 102519 returned: deadbeef rets: 4
CIcall: 1198c8 finddevice deadbeef returned: deadbeef rets: ff83c1c8
CIcall: 1198c8 getprop deadbeef 8 116990 102557 returned: deadbeef rets: ffffffff
This is only an excerpt. If you try this yourself you will get a very very long list of lines like these. I got around 4000 of them.

All the addressses beginning with 1 point somewhere inside the Trampoline code or data structures.

For the uninitiated, this is a debugging feature of open firmware that records useful data every time the Trampoline asks it to do something. I probably should have stuck this at the beginning of this post 

 Are you seeing lines that don't return deadbeef as well?
This will definitely help with working out how the trampoline is loading parcels and how it determines what ones to load.

[Daniel]

Either all the lines contain deadbeef or I haven't looked closely enough at ~4100 boring lines that all contain roughly the same thing

That 1198c8 is almost certainly the address that is returned to after the client interface call is complete. It is probably near the end of the Trampoline function that actually makes the client interface calls. That would be an interesting place to look.

[nanopico]

Either all the lines contain deadbeef or I haven't looked closely enough at ~4100 boring lines that all contain roughly the same thing

That 1198c8 is almost certainly the address that is returned to after the client interface call is complete. It is probably near the end of the Trampoline function that actually makes the client interface calls. That would be an interesting place to look.

That is interesting. Most of all of the trampoline code starts at 0x00200000 and goes up to roughly 0x00210260.
Though who knows how it rearranges it's self.

[Daniel]

Only one way to know for sure.

Code: [Select]

0 > 1198b0 30 dump
001198b0:
DEFAULT CATCH!, code=300 at   %SRR0: ff80b1c0   %SRR1: 0000b030 Nothing is there before the Trampoline is run. Now to check inside a client interface call...

Code: [Select]

dev /openprom/client-services
true value cifirst?
: finddevice cifirst? if false to cifirst? 1198b0 30 dump then finddevice ;
mac-boot

Code: [Select]

CIcall: 1198c8 finddevice deadbeef
001198b0: 00 00 00 00 00 00 00 00 ff 80 a2 90 de ad be ef |................|
001198c0: 00 00 00 00 00 11 98 b8 00 10 07 21 00 00 00 01 |...........!....|
001198d0: 00 00 00 01 00 10 24 e2 00 00 00 00 00 00 00 00 |......$.........|returned: deadbeef rets: ff83e940
So the Trampoline must be inserting something there. Presumably those are valid powerpc instructions, but I have no idea.

[Daniel]

Here is that location after the Trampoline is loaded, but before it is run.

Code: [Select]

: go ;
mac-boot

Code: [Select]

001198b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
001198c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
001198d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
So that location is allocated when the Trampoline is loaded but is initialized by the Trampoline itself. Maybe it is in the .bss segment?

[nanopico]

It might actually be parcel code that is getting loaded. Further investigation required I guess.

[Daniel]

It could be. Hard to say.