PowerPC Liberation: May 2016

This is likely at least 3-4 years away, but h.264 is on its way out, now that h.265 (HEVC) has been adopted by more and more people. Just as XviD was dropped by most in 2012, the same fate is inevitable for h.264 within a few years.

There are two key issues that keep h.265 off PowerPC:

1. Playback - there are currently no available playback applications capable of playing the h.265 codec that would work on Mac OS PowerPC. VLC started supporting it in version 2.1.12, but this is irrelevant, since most h.265 is 2160p, and out of the range of even a quad G5. There is some 720p h.265 floating around that a quad could likely play if there was a playback option.

2. Encoding - and this is the bigger need, as there are also no Mac OS PowerPC encoding software capable of reading h.265 to transcode it to something else. Since most PowerPC hardware wouldn't be able to play most h.265 anyway, the best need to fill for us is to get an encoding app on PowerPC that can transcode h.265 to h.264 or XviD/DivX.

So we need a Mac developer to port a newer version of Handbrake (or any other equally capable encoder) to Tiger and Leopard PowerPC.

There is no point in wasting time on a player, as I already mentioned, since 90% of these files will not play on even a quad G5.

Even a Linux solution would work, but one for Mac OS would be a much broader brush stroke.

I wanted to bring this up long before it became a dire need.

Thoughts?

I have received numerous questions regarding the method of the CorePlayer crack. Now I would like to briefly describe the process.

PPC Reverse engineering on Mac OS can be an easy process if we know how to do it. There are several debugging and disassembler tools available for Mac OS that can be used for such purposes. In this case I only used OTX v.16b disassembler and a simple hex editor 0xEd.

For me the easiest way is to look into the code itself produced by OTX. It is a simple GUI application and produces a text file of the application that we want to disassemble. The CorePlayer binary itself is only 5 MB but the text output produced by OTX is nearly 21 MB.

A part of the output looks like this:

+188    0006e23c 409e0064    bne        cr7,0x6e2a0
+192    0006e240 813f0000    lwz        r9,0x0(r31)
+196    0006e244 a161003e    lhz        r11,0x3e(r1)
+200    0006e248 80490000    lwz        r2,0x0(r9)
+204    0006e24c a0020074    lhz        r0,0x74(r2)
+208    0006e250 7f8b0000    cmpw    cr7,r11,r0
+212    0006e254 40be004c    bne+        cr7,0x6e2a0
+216    0006e258 a0010040    lhz        r0,0x40(r1)
+220    0006e25c 2f800001     cmpwi    cr7,r0,0x1
+224    0006e260 40be0040    bne+         cr7,0x6e2a0
+228    0006e264 80010044    lwz        r0,0x44(r1)
+232    0006e268 80410038    lwz        r2,0x38(r1)
+236    0006e26c 7f801000     cmpw    cr7,r0,r2
+240    0006e270 419e0030    beq        cr7,0x6e2a0
+244    0006e274 a0010042    lhz        r0,0x42(r1)
+248    0006e278 805f00dc     lwz        r2,0xdc(r31)
+252    0006e27c 5409073e    rlwinm    r9,r0,0,28,31
+256    0006e280 7f824800    cmpw    cr7,r2,r9
+260    0006e284 419e0034    beq        cr7,0x6e2b8
+264    0006e288 3802ffff       addi         r0,r2,0xffff
+268    0006e28c 2b800002    cmplwi    cr7,r0,0x2
+272    0006e290 419d0010    bgt        cr7,0x6e2a0
+276    0006e294 3809ffff       addi         r0,r9,0xffff
+280    0006e298 2b800002    cmplwi    cr7,r0,0x2

Each line is one operation in the code. I do not want to go into details now of assembly coding. There are dozens of good sites dealing with programming.

So a very plain explanation of a line:

+240 0006e270 419e0030 beq cr7,0x6e2a0

+240                               reference line number within a program block
0006e270                        overall line number
419e0030                        machine hex code
beq    cr7,0x6e2a0          assembly code

The registration of CorePlayer is linked to the unique Mac serial number of a particular machine where the player is installed.

In the output of OTX we have to find the appropriate places where the software checks the registration status and decides whether it will run or not. CorePlayer uses a 3 level verification process:

1. is there a valid serial number entered and stored in the Users/user/.CorePlayer/config.xml file,
2. is there a valid user based on the Mac serial number and CorePlayer serial number to run the program and start the GUI,
3. is there a valid user based on the Mac serial number and CorePlayer serial number to start video playback.

As I had the valid CorePlayer serial numbers from the start I only had to find the places in the code where the Mac and CorePlayer serial number checks were executed. This is the hardest part but if someone has some experience in assembly language then it is relatively easy to find these places in the code. In this case for me the starting point was the place where the registration dialog is called:

+1176    000139b0 7f801000    cmpw    cr7,r0,r2
+1180    000139b4 409e0030    bne        cr7,0x139e4
+1184    000139b8 a001005a    lhz        r0,0x5a(r1)
+1188    000139bc 805d00dc    lwz        r2,0xdc(r29)
+1192    000139c0 5409073e    rlwinm    r9,r0,0,28,31
+1196    000139c4 7f824800    cmpw    cr7,r2,r9
+1200    000139c8 419e00c0    beq        cr7,0x13a88
+1204    000139cc 3802ffff       addi    r0,r2,0xffff
+1208    000139d0 2b800002    cmplwi    cr7,r0,0x2
+1212    000139d4 419d0010    bgt        cr7,0x139e4
+1216    000139d8 3809ffff       addi    r0,r9,0xffff
+1220    000139dc 2b800002    cmplwi    cr7,r0,0x2
+1224    000139e0 409d00a8    ble        cr7,0x13a88
+1228    000139e4 807e0044    lwz        r3,0x44(r30)
+1232    000139e8 3ca05549    lis        r5,0x5549
+1236    000139ec 3c80001f     lis        r4,0x1f
+1240    000139f0 38c00000     li        r6,0x0
+1244    000139f4 38845f94     addi    r4,r4,0x5f94    serialdialog
+1248    000139f8 60a54744     ori        r5,r5,0x4744    'UIGD'
+1252    000139fc 481556e5     bl        0x1690e0
+1256    00013a00 7c7f1b79     or.        r31,r3,r3
+1260    00013a04 4082001c    bne        0x13a20
+1264    00013a08 48000068    b        0x13a70
+1268    00013a0c 7fc3f378    or        r3,r30,r30
+1272    00013a10 38800000    li        r4,0x0
+1276    00013a14 38a0020c    li        r5,0x20c
+1280    00013a18 4bfff879    bl        0x13290
+1284    00013a1c 4800006c    b        0x13a88
+1288    00013a20 3c400001    lis        r2,0x1
+1292    00013a24 93c10058    stw        r30,0x58(r1)
+1296    00013a28 38800217    li        r4,0x217
+1300    00013a2c 38a10054    addi    r5,r1,0x54
+1304    00013a30 38423290    addi    r2,r2,0x3290

If we do not want to call the registration dialog then we have to tell the program to jump over the registration call. So the actual place that we have to alter is before the dialog call:

+1180 000139b4 409e0030 bne cr7,0x139e4

I have found 6 places where these or very similar verifications were executed and called. The basic pattern of the code looks like this:

+240    0006e270 409e0030    bne        cr7,0x6e2a0
+244    0006e274 a0010042    lhz        r0,0x42(r1)
+248    0006e278 805f00dc     lwz        r2,0xdc(r31)
+252    0006e27c 5409073e    rlwinm    r9,r0,0,28,31
+256    0006e280 7f824800    cmpw    cr7,r2,r9

The easiest way is to alter the program flow and negate the relevant operations. In this way it skips the appropriate parts and will accept any Mac serial numbers and a valid CorePlayer serial number. In order to negate the operation we have to change the line:

0006e270 409e0030 bne cr7,0x6e2a0

into

0006e270 419e0030 beq cr7,0x6e2a0

We have to use the hex editor to change the code at 6 different places in the binary and save the altered code. After this entering a valid serial will produce a fully working CorePlayer.

If someone wants to dive deeply into this topic I would recommend starting with this site: https://reverse.put.as/

PowerPC Liberation

Looming on the horizon

CorePlayer details

CorePlayer file association icons