<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Great work!</div><div dir="ltr"><br></div><div dir="ltr">At some point, will you be able to compare your target Trampoline to the very final version released?</div><div dir="ltr"><br>On 5 Feb 2019, at 8:21 am, Max Poliakovski <<a href="mailto:maximumspatium@googlemail.com">maximumspatium@googlemail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Elliot,<div><br></div><div>thank you for your helpful suggestions!</div><div><br></div><div>After hours of downloading of historical development disks and searching them for MPW packages, I finally managed to find a MrC compiler that produces binary code very close to the code found in the Apple binary. That compiler is resided on the E.T.O #21 disk from 1996 and is a part of the MPW 3.4.2b3 pre-release. It identifies itself as "MrC C Compiler 2.0.2d1c6".</div><div><br></div><div>After playing a bit with this compiler and my code, I was able to produce near byte-perfect output for string.c and fully byte-perfect output for ofci.c!</div><div><br></div><div>The former contains seven functions; six of them are byte-identical to the Apple binary; the 7th - memchr() -contains two instructions where operands are swapped compared to Apple's code. I wasn't able to figure out why it happens.</div><div><br></div><div>When I say "byte-identical", I actually mean anything except TOC references and cross-module call offsets. These will be changed by PPCLink during the linkage of the final binary. Tweaking PPCLink to generate byte-identical output is a task on its own. I'm not sure I'll even succeed on it.</div><div><br></div><div>Anyway, round-tripping MrC has become feasible. Even if the 100% match cannot be achieved, it's still a good validation of the correctness of the decompiled code.</div><div><br></div><div>Stay tuned.</div><div><br></div><div>Cheers</div><div>Max</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mi., 9. Jan. 2019 um 05:22 Uhr schrieb Elliot Nunn <<a href="mailto:elliotnunn@fastmail.com">elliotnunn@fastmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Happy new year!<br>
<br>
MrC round-tripping sounds like a very hard slog. After all, RISC is<br>
sometimes said to stand for "Relegate the Interesting Stuff to the<br>
Compiler"! Mind you, with your intimate familiarity with the<br>
architecture, you could well enjoy some breakthroughs.<br>
<br>
I can't seem to find MPW 3.4 in my archives. Is it old enough even to<br>
have a RISC compiler? I think that the early ones were distributed as a<br>
separate SDK. I suggest downloading all the E.T.O. images that you can<br>
find. They are the best library of MPW tools that I have found.<br>
<br>
Have you built any bootable Trampolines? That would be a very powerful<br>
validation of your reversal.<br>
<br>
> On 8 Jan 2019, at 11:05 pm, Max Poliakovski <<a href="mailto:maximumspatium@googlemail.com" target="_blank">maximumspatium@googlemail.com</a>> wrote:<br>
> <br>
> Hi guys,<br>
> <br>
> happy new year!<br>
> <br>
> > Quoting Elliot's mail from 05-02-2018:<br>
> > I have had some success getting Apple's 68k C compiler to produce byte-accurate output. (A few things were in my favour here: simple C code, a simple C compiler and some sources for a previous version of the binary.) I always aim for byte-perfection after building my reversed sources (admittedly mostly assembly) because it lets me know when I've messed up. However, my approach is not always practical, and your focus on high-level hacking is likely to be more rewarding.<br>
> <br>
> I've played a couple of days with EMPW with the goal to get a byte-perfect output for the string.c module that consists of seven short functions (3-7 statements).<br>
> <br>
> As expected, I wasn't able to obtain byte-perfect output with MrC regardless different optimizations and even compiler versions.<br>
> <br>
> Below a short report:<br>
> <br>
> MrC 4.1.0 from MPW 3.5 GM emits code that is far from the code located in the Trampoline binary.<br>
> <br>
> I therefore downgraded to MrC 3.0.1 from 02-20-1997 that can be obtained here: <a href="https://www.staticky.com/mirrors/ftp.apple.com/developer/Tool_Chest/Core_Mac_OS_Tools/MPW_Website_Downloads/" rel="noreferrer" target="_blank">https://www.staticky.com/mirrors/ftp.apple.com/developer/Tool_Chest/Core_Mac_OS_Tools/MPW_Website_Downloads/</a><br>
> <br>
> With MrC 3.0.1, I was able to perfectly reconstruct strlen() and memset() - both are very, very simple functions. After playing with optimization settings abit, the code for strcpy() got very close to the Apple's binary except a small difference in the register allocation ($r11 and $r12 are swapped).<br>
> <br>
> I also tried MrC 4.1a1 but it seems to go in the wrong direction.<br>
> <br>
> I suspect that Apple might have used even an older compiler. The only possibility to check that out is to get a copy of MPW 3.4 (1995) which seems to be one of the first MPW versions including PowerPC compilers.<br>
> <br>
> Does somebody own MPW 3.4? I've seen only 3.3, 3.5 and PR so far...<br>
> <br>
> Cheers<br>
> Max<br>
> _______________________________________________<br>
> cdg5 mailing list<br>
> <a href="mailto:cdg5@ucc.asn.au" target="_blank">cdg5@ucc.asn.au</a><br>
> <a href="https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5" rel="noreferrer" target="_blank">https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5</a><br>
<br>
_______________________________________________<br>
cdg5 mailing list<br>
<a href="mailto:cdg5@ucc.asn.au" target="_blank">cdg5@ucc.asn.au</a><br>
<a href="https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5" rel="noreferrer" target="_blank">https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5</a><br>
</blockquote></div></div>
</div></blockquote><blockquote type="cite"><div dir="ltr"><span>_______________________________________________</span><br><span>cdg5 mailing list</span><br><span><a href="mailto:cdg5@ucc.asn.au">cdg5@ucc.asn.au</a></span><br><span><a href="https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5">https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5</a></span><br></div></blockquote></body></html>