G3 L2 Accelerator

[likanen]

I went and got my TAM. After some burning CDs and failing, I was able to download everything I needed with Netscape 3.0 (remember my TAM has stock installed 7.6.1 so it didn't have browser installed by the OS. Luckily the install CD contained Internet Connection Kit as an extra). Time to start testing.

Changing HWPriv execution condition didn't enable / disable the accelerator. It did very little indeed. Replacing JSR with NOP did the same as with sheep shaver, and I ended up with 603ev. Conclusion is that Ptch 128 contains the code to the magic.

After some more fighting with Netscape (could not download it directly from macintosh repository site but had to put it on my MacBook and share from there) I managed to download and install MacsBug on TAM. While executing cmd-power on random I realised I can replace the HWPriv command with A9FF (Debugger trap). Following the code execution with and without the accelerator installed (so the address cmp was true everytime, regardless if the accelerator was installed or not) I kept going with MacsBug.

After the jump to A0 i.e. the Ptch 128 code, I was greeted with loads of code that does not exist in the Ptch 128 or any other Ptch resource (I tried searching for hex strings I was able to see in the MacsBug) and to exclude the accelerator somehow replacing the code, I ended up into the same code without the accelerator installed.

Going with stepping over (cmd-T) and stepping into (cmd-S) whenever MacsBug said the code will branch the code pretty much ended up into the same place regardless of the presence of the accelerator. This place called VInstall (http://mirror.informatimago.com/next/developer.apple.com/documentation/mac/Processes/Processes-77.html) and the MacsBug crashed.

That was pretty much the experience today. Learned how to use MacsBug but also ended up into a dead end as I currently don't know what code the INIT is executing after JSR (A0) so I can't go and put another debugger trap to get past the VInstall code.

Frustrating...

[likanen]

Frustration leads to anger and anger leads to... well trying again.

Looking at what the INIT does prior to loading Ptch 128 it indeed crawls through all Ptch and DRVR resources and will do an exclusive or (EORI) with hex long 12345678 and replace the original if the resource begins with word SNNT in hex.

Oh well, why oh why... It doesn't prevent anyone especially that you need provide your decryption logic in the same extension in 'plain' code.

Time to understand fully the decryption, decrypt the Ptch and replace the resources with decrypted code so I can hack it with ResEdit

Btw. While I was googling around I stumbled upon this http://vintageapple.org/macbooks/pdf/Debugging_Macintosh_Software_with_MacsBug_1991.pdf. It gave me more advanced instructions how debug certain extension (around pg 323-340). Might help some other newbies like me.

[likanen]

Played around with MacsBug some more and used the cool commands in the book above. If I trace it from INIT 31 breakpoint as described in the book, the code flow never(?) goes into the decryption part.

If I replace D5 = 5 assignment at the beginning of the INIT with debugger trap I can enter the code and execute the assignment from MacsBug. However tracing this will lead to Ptch 128 execution where the patch is not decrypted and it fails to move past the first illegal instruction.

I also tried XORring manually some of the first longs in the patch resource with 12345678 but didn’t get the same results which I can see when running it with the debugger.

I also tried the atb OpenResFile @@sp... command explained in the book but that only catches when desktop is loaded and the CODE resource is executed.

I was able try both INIT 31 breakpoint and debugger trap at the beginning of INIT and it was catched at the INIT 31 first. Then I had to leave.

[likanen]

Insanity kept me going back.

Trying to find the correct jump/branch from where to find the beginning of Sonnet extension INIT was a nightmare. I did however use the old HWPriv location debugger trap to dump the memory from A0 to a file (using log filename; dm a0 8000; log) before the subroutine to Patch 128 and behold I now have the decrypt code.

While it still is in text form, I can see the code makes sense and equals the code that is being executed.

Ptch 128 as shown by MacNosy (only couple of lines):

Code: [Select]

       0: 'SNNT..[T.|Ip.s.d'     data1    DC.W    $534E,$4E54,$914,$5B54,$C7C,$4970,$773,$8A64
      10: '.+.......Y..3...'              DC.W    $E2B,$A9B0,$DEB,$A9C0,$E559,$A9B3,$33F7,$1E17
      20: 'q...G.t..s...<..'              DC.W    $71C4,$B6A0,$478A,$74A0,$9873,$D592,$123C,$B5AD
      30: '.#..7[...s...9..'              DC.W    $223,$880B,$375B,$B806,$9873,$D592,$1239,$B5AD
Ptch 128 from a memory dump (the same lines):

Code: [Select]

  0039F030  4E56 FFBC 48E7 1F38  426E FFD0 42AE FFD8  NVˇºHÁ•8Bnˇ–BÆˇÿ
  0039F040  42AE FFC0 3C3C FFFF  7E00 486E FFDC A976  BÆˇ¿<<ˇˇ~•Hnˇ‹©v
  0039F050  554F 486E FFE3 4878  0007 A85D 101F 6610  UOHnˇ„Hx••®]••f•
  0039F060  554F 486E FFE3 4878  0004 A85D 101F 6708  UOHnˇ„Hx••®]••g•
Do you guys use / know another disassembler than MacNosy? One which I could use the text file as an input and on a modern Mac?

[ELN]

There is a tool included with MPW called DumpCode, which disassembles 68k code. It will very likely run on a modern Mac using ksherlock's mpw runtime.

[likanen]

On a side note, if you run the computer with the accelerator installed but without the extension, the accelerator does not get hot at all... so I guess there is something that kicks the accelerator up and running in the extension.

[likanen]

My TAM has been in pieces for some time (CD-ROM drive is broken, and I have hard time to find a replacement). However, I managed to dump the 'decrypted' code from memory (never got into understanding how it worked in as MacsBug wasn't able to catch it properly or I lacked the skill).

Here you go: https://pastebin.com/raw/Dr5nNmHB

As far as I know, one should be able to replace the existing Ptch128 with the decoded one and the code should still work (as the loader code checks if the Ptch128 is encoded). I don't know how to easily write the memory dump into a resource fork with a modern Mac.

If somebody has an idea, I'll happily give it a try.

[likanen]

Ended up copy-pasting it to ResEdit

Decompiled stuff: https://pastebin.com/raw/PNrA9Eks

[Daniel]

Cool. I still can't read assembly all that well, but I can sort of follow what it is doing by looking at the various traps. Most of them seem reasonable for accelerator code to call.

Does the decrypted code actually work in place of the regular Patches?

[likanen]

It does, at least in sheepshaver (I.e. no acceleration but the banner loads). The code above is only a piece of it as it seems that MacNosy splits it per procedure. Something you can see from it memory dump already is that there is ShowINIT code (responsible for showing the banner?) and some Open Firmware script (boot /APPL,ROM).

[likanen]

Actually the banner is shown by proc11 (if you use Nosy to disassemble). Using resedit one can disable the animation from the main Ptch128 304: 4EBA 1204 and change these two to NOPs (4E71). The banner animation disappears.

The proc11 of Ptch128 is here: https://pastebin.com/raw/55FfwNgY

[likanen]

After some tedious trial and error with sheepshaver, it seems that the following lines in proc11 are responsible for selecting the correct PICT resource:

Code: [Select]

    167C: 3F04           '?.'             PUSH    D4
    167E: A9BC           '..'             _GetPicture ; (picID:INTEGER):PicHandle
The PICT resource is important as it shows Crescendo G3 on TAM, Crescendo G4 on sheepshaver. If one can deduct how D4 is built, one finds the logic for determining which upgrade is installed.

The value of D4 should be 136 (or 130 for different size) and banner for Crescendo G3 is 134 (or 128). If I could reduce 2 from D4 it should load different banner.

Only rows I find that modify the value in D4 are

Code: [Select]

    156C: 383C 0080      '8<..'           MOVE    #$80,D4

Code: [Select]

    157A: 5444           'TD'             ADDQ    #2,D4

Code: [Select]

    158C: 5444           'TD'    lal_2    ADDQ    #2,D4

Code: [Select]

    15B2: 5244           'RD'             ADDQ    #1,D4

Code: [Select]

    15BA: 5C44           '\D'             ADDQ    #6,D4

Code: [Select]

    1612: 5244           'RD'             ADDQ    #1,D4
Let's iterate these lines and see if can change the banner. As said earlier NOP (4E71) is quite good replacement for all http://68k.hax.com/ADDQ

[likanen]

And so it is. Line

Code: [Select]

    157A: 5444           'TD'             ADDQ    #2,D4
when changed to NOP, changes the banner to Crescendo G3. This line is guarded by:

Code: [Select]

    1574: 0C40 010C      '.@..'           CMPI    #$10C,D0
    1578: 6514           100158E          BLO.S   lal_3
If D0 is lower than 10C it would skip adding 2 to D4. Okay, we are getting closer, but what is in D0 and how did it get there?

Code: [Select]

    150E: 48E7 1F38      'H..8'           MOVEM.L D3-D7/A2-A4,-(A7)

Code: [Select]

    1570: 302A 000E      '0*..'           MOVE    14(A2),D0
If I understand asm right, A2 value is copied from D3, where D3 comes from should be looked from the main procedure of Ptch 128. Then D3 is replaced with the value at 12 indices advanced from the memory location pointed by A2 (i.e. the original D3). OR then I don't understand assembler right.

[Daniel]

It appears that the MOVEM is saving a bunch of registers on the stack. Maybe. I am not all that familiar with 68k assembly.

Right below the MOVEM is:

Code: [Select]

1512: 246E 0008      2000008          MOVEA.L param2(A6),A2
So A2 is some parameter passed in from the calling function. That address is some kind of data structure that contains info about the cpu?

[ELN]

Yep, that MOVEM is pushing multiple registers to the stack, probably at the start of a function call. So then, what's calling the function?

[likanen]

Thanks Daniel, I missed that line (ha, that's what happens when you do this kind of stuff after long day at work and 2 hour IKEA visit).

Code: [Select]

param2    VEQU  8
so the value we are looking for from the calling code (https://pastebin.com/raw/PNrA9Eks) is the first thing that was pushed right?

Code: [Select]

     300: 3F06           '?.'             PUSH    D6
     302: 2F0B           '/.'             PUSH.L  A3
     304: 4EBA 1204      100150A          JSR     proc11
IF it is D6 then it is written in

Code: [Select]

      14: 3C3C FFFF      '<<..'           MOVE    #$FFFF,D6

Code: [Select]

48: 4EBA 0A72      1000ABC lab_2    JSR     proc7
      4C: 3800           '8.'             MOVE    D0,D4
      4E: 3C04           '<.'             MOVE    D4,D6
I don't know if proc7 (https://pastebin.com/raw/xQmM5FZu) has anything to do with the value of D0. However it (lab_2) is executed if

Code: [Select]

      32: 486E FFE3      200FFE3          PEA     vab_10(A6)
      36: 4878 0004      'Hx..'           PEA     4
      3A: A85D           '.]'             _BitTst ; (bytePtr:Ptr; bitNum:LongInt):BOOLEAN
      3C: 101F           '..'             POP.B   D0
      3E: 6708           1000048          BEQ.S   lab_2
IF it is A3 then

Code: [Select]

       8: 426E FFD0      200FFD0          CLR     vab_6(A6)

Code: [Select]

     22E: 486E FFD0      200FFD0          PEA     vab_6(A6)
     232: 4EBA 0708      100093C          JSR     proc6
     236: 584F           'XO'             ADDQ    #4,A7


Code: [Select]

     24A: 302E FFD0      200FFD0          MOVE    vab_6(A6),D0
     24E: 48C0           'H.'             EXT.L   D0
     250: 4680           'F.'             NOT.L   D0
     252: E580           '..'             ASL.L   #2,D0
     254: 2030 0800      ' 0..'           MOVE.L  0(A0,D0.L),D0
     258: 2D40 FFD4      200FFD4          MOVE.L  D0,vab_7(A6)
     25C: 2040           ' @'             MOVEA.L D0,A0
     25E: 2050           ' P'             MOVEA.L (A0),A0
     260: 2668 0014      '&h..'           MOVEA.L 20(A0),A3
Proc6 is here (https://pastebin.com/raw/jseXCtr1).