Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
CorePlayer is no more! RIP
- Thread starter Veinticinco
- Start date
- Sort by reaction score
I must admit, hard-coding the license key into every binary is quite an odd, albeit novel method of doing things. I can confirm this as Nameci's key is already present when trying to install on my G4.
Now what's interesting is that the CorePlayer.app in the installer package is exactly the same as the one that ends up in your Applications folder, so it is obviously generated server-side (as has been pointed out) using information from the customer's machine. I need to read the developer docs on how the package installer works, but I imagine the license key is also hard-coded in the custom InstallerPane plugin which runs after the license agreement and checks your key is valid before installing.
Would someone who has purchased CorePlayer be kind enough to explain the process? Did you have to provide them with your Mac's serial number first? Did the site run a plugin to determine this information (highly invasive, and I'm not sure it's possible with Java etc., it would have to be a custom plugin the customer installed).
Some more info:
Picking through the hex of the CorePlayer and InstallerPane binaries was fruitless - they aren't stupid enough to encode the license key in plain-text. I don't currently have Xcode installed so I'm at a dead-end at the moment - I'll be getting it set up next week so hopefully I can trace the execution and see what's going on under the hood.
In the meantime, if someone else has a copy of their installer they could lend to the cause then that would be incredibly useful. I need to compare binaries from two different people to see if I can figure which section the license key is actually stored in.
As for how to progress from here, well: Somewhere in the code it will read your Mac's serial number and use this (possibly along with some other information) to generate a license key to compare with the one hard-coded into the binary. This algorithm will be the exact same one they use on the server to generate the installer, so if it can be deciphered from picking apart the PPC assembly (no debug symbols mind!) then it's possible to reverse engineer the algorithm and utilize it on other serial numbers. The other possibility is collecting a few serial numbers and corresponding license keys and trying to figure out what hashing scheme has been used to generate the serial. I'll admit I don't know much about the inner workings of hashing algorithms, but I know a few people who do.
With regards to changing the Mac's serial number, this would ok so long as it's 100% confirmed that this is the only metric they used to generate the license key. There's an Apple service disk floating around the web which allows the changing of serial numbers in NVRAM, but it's Intel-only. Changing the Mac's serial number is a worthwhile avenue of investigation then I will explore some other options such as hooking on to system calls which provide the serial number etc. etc.
Cheers.
EDIT: So after some further messing around, the license key check the installer performs can be circumvented by installing from the commandline using:
This results in the installation of CorePlayer.app to my Applications folder.
So we can ignore the custom InstallerPane, and concentrate on the CorePlayer.app itself. Though this was a non-issue really, because you can browse the contents of the package and extract the archive containing the app without touching the installer.
Now what's interesting is that the CorePlayer.app in the installer package is exactly the same as the one that ends up in your Applications folder, so it is obviously generated server-side (as has been pointed out) using information from the customer's machine. I need to read the developer docs on how the package installer works, but I imagine the license key is also hard-coded in the custom InstallerPane plugin which runs after the license agreement and checks your key is valid before installing.
Would someone who has purchased CorePlayer be kind enough to explain the process? Did you have to provide them with your Mac's serial number first? Did the site run a plugin to determine this information (highly invasive, and I'm not sure it's possible with Java etc., it would have to be a custom plugin the customer installed).
Some more info:
Picking through the hex of the CorePlayer and InstallerPane binaries was fruitless - they aren't stupid enough to encode the license key in plain-text. I don't currently have Xcode installed so I'm at a dead-end at the moment - I'll be getting it set up next week so hopefully I can trace the execution and see what's going on under the hood.
In the meantime, if someone else has a copy of their installer they could lend to the cause then that would be incredibly useful. I need to compare binaries from two different people to see if I can figure which section the license key is actually stored in.
As for how to progress from here, well: Somewhere in the code it will read your Mac's serial number and use this (possibly along with some other information) to generate a license key to compare with the one hard-coded into the binary. This algorithm will be the exact same one they use on the server to generate the installer, so if it can be deciphered from picking apart the PPC assembly (no debug symbols mind!) then it's possible to reverse engineer the algorithm and utilize it on other serial numbers. The other possibility is collecting a few serial numbers and corresponding license keys and trying to figure out what hashing scheme has been used to generate the serial. I'll admit I don't know much about the inner workings of hashing algorithms, but I know a few people who do.
With regards to changing the Mac's serial number, this would ok so long as it's 100% confirmed that this is the only metric they used to generate the license key. There's an Apple service disk floating around the web which allows the changing of serial numbers in NVRAM, but it's Intel-only. Changing the Mac's serial number is a worthwhile avenue of investigation then I will explore some other options such as hooking on to system calls which provide the serial number etc. etc.
Cheers.
EDIT: So after some further messing around, the license key check the installer performs can be circumvented by installing from the commandline using:
Code:
sudo installer -dumplog -pkg /Volumes/CorePlayer\ Installer.pkg -target /Volumes/Macintosh\ HDSo we can ignore the custom InstallerPane, and concentrate on the CorePlayer.app itself. Though this was a non-issue really, because you can browse the contents of the package and extract the archive containing the app without touching the installer.
Last edited:
Pretty tricky, if and only if I am not busy with things at my work, I would try to get my feet wet with this thing. It is quite interesting and we can learn some good stuff with this. It is for "educational purposes", 'ayt?
Unfortunately bud, I cannot recall anymore the process during my purchase.
I sent you my installer , my mac serial and the Coreplayer serial.
The purchase process was:
Logging into the site, put the mac serial number, pay by paypal, download the program.
Yes, I hope this will be purely for educational purposes. As I mentioned, I will be doing a full writeup of whatever is discovered, regardless if the license key check is defeated or not. Hopefully at some point this will include some proof-of-concept code etc. If people use this to go and write some keygen with a flashy UI and funky chiptunes and upload it to TPB, then so be it - we can't stop them. Unfortunately knowledge can be put to both good and bad use depending on an individual's intentions.
EDIT: Thankyou very much skinniezinho, I'll take a look at that and report my findings!
EDIT: Thankyou very much skinniezinho, I'll take a look at that and report my findings!
I worked in apple service for two years, from what I know, you can only write a new serial number when the board is blank.
No problem.I bought this software, but I will trade my G4 for a G5 wich means I can't use no more.
Support was non existent.And in my opinion a player that doesn't have the option of loading subtitles (.srt) is somehow worthless.
@Wildy,
You still need my PB's serial? I can only send you tomorrow morning HongKong time. I left my PB at work.
You still need my PB's serial? I can only send you tomorrow morning HongKong time. I left my PB at work.
That would be helpful, thankyou.
EDIT: Oh dear. Both the files provided have the same checksum, and both come up initially with the license key provided by Nameci, which means my initial analysis was a little rushed.
All installers are the same, the binary is not generated on the server. Now the reason why Nameci's license key was shown during the installer was because I tried running the app first, and entering the key there. When running skinniezinho's installer (which is identical), Nameci's key was present - thus when a license key is entered into the app, it must store it locally somewhere to make re-installations quicker.
I couldn't find any files in the obvious places, so I just created a new user account instead. Upon launching the installer (without entering a key into the app first), I am greeted by a blank license key field. This is nice because it means the key must be stored on the user account somewhere.
So, here are my latest thoughts: The Mac's serial number is still required (obviously) so they can generate a unique license key for the customer. This license key is either decoded and then the serial number checked with that of the machine it's running on, or the serial number is encoded and checked with the license key provided. Either way, it means that the only place to go from here is to follow the execution of the app with a debugger (most probably GDB), and see if it's possible to figure out what algorithm is being used to check for a valid license key. The first step is seeing if we can find an address containing data from the license key box; something like the 'invalid license key' text would be ideal. Once we know this we can see where this address is referenced and hopefully find the address of the license check function.
EDIT 2: A simple ls -a reveals that CorePlayer creates a hidden folder in the user's home to store the config (including serial number) and media database.
I'd have expect to find this file in the Library/Application Support folder, but I guess they didn't bother to adhere to standard OS procedures when they ported it. After all, it does have to work on quite a few platforms.
EDIT: Oh dear. Both the files provided have the same checksum, and both come up initially with the license key provided by Nameci, which means my initial analysis was a little rushed.
All installers are the same, the binary is not generated on the server. Now the reason why Nameci's license key was shown during the installer was because I tried running the app first, and entering the key there. When running skinniezinho's installer (which is identical), Nameci's key was present - thus when a license key is entered into the app, it must store it locally somewhere to make re-installations quicker.
I couldn't find any files in the obvious places, so I just created a new user account instead. Upon launching the installer (without entering a key into the app first), I am greeted by a blank license key field. This is nice because it means the key must be stored on the user account somewhere.
So, here are my latest thoughts: The Mac's serial number is still required (obviously) so they can generate a unique license key for the customer. This license key is either decoded and then the serial number checked with that of the machine it's running on, or the serial number is encoded and checked with the license key provided. Either way, it means that the only place to go from here is to follow the execution of the app with a debugger (most probably GDB), and see if it's possible to figure out what algorithm is being used to check for a valid license key. The first step is seeing if we can find an address containing data from the license key box; something like the 'invalid license key' text would be ideal. Once we know this we can see where this address is referenced and hopefully find the address of the license check function.
EDIT 2: A simple ls -a reveals that CorePlayer creates a hidden folder in the user's home to store the config (including serial number) and media database.
I'd have expect to find this file in the Library/Application Support folder, but I guess they didn't bother to adhere to standard OS procedures when they ported it. After all, it does have to work on quite a few platforms.
Last edited:
I read somewhere that cannot be mentioned
that it was impossible to make Coreplayer work in other computers, other than the one that purchased it.btw what a stupid move...
Good find. I thought to check for hidden files that were installed on the same day that I installed CorePlayer, but apparently I didn't check well enough. Agree that nothing seems to have changed in the binary of the application itself.
----------
Wildy, would it help you to have some more data points to work with?
At the moment progress is stuck until I can acquire Xcode, which won't be until sometime next week unfortunately.
More datapoints certainly wouldn't go amiss - although I do feel slightly guilty asking people for their serial numbers and license keys. I promise they're in good hands though and I'll be sure to keep them safe.
Cheers,
Mike
More datapoints certainly wouldn't go amiss - although I do feel slightly guilty asking people for their serial numbers and license keys. I promise they're in good hands though and I'll be sure to keep them safe.
Cheers,
Mike
Don't feel so guilty, because even if you have the serial, it won't work. This is more about educational purposes, I always thought that Microsoft Office should work like that, using mac address to stop piracy, I wonder why Microsoft doesn't do that.
Yep, that's itl
Yeah I'll confirm this one, there was a bootable CD that you'd use to write the serial number to a *blank* logic board. Had to be blank, you couldn't change this. Maybe there's a workaround if you boot into some kind of linux, to be able to change the serial number on the board when it's already got one? Or maybe you'd actually have to start physically screwing with the board..
Yeah coreplayer's support sucked, it had good performance, but visual quality sucked (it'd break up a lot), had no features, was buggy, ugly interface, etc.
I have a DMG which can change the serial number on intell macs, this has only be tested in early intel macs, and I do not know much about it. This has only had very tiny amounts of testing, and uses extremely low level EFI exploits; use it with care.
I am not responsible if this damages or bricks your computer.
I am not responsible if this damages or bricks your computer.
Seems to be Intel only, but thanks.. looks interesting, I'll stick it into an Intel Mac at some point.
Code:
Bad CPU type in executableI don't think this uses exploits, it is the same tool as on the disk I was talking about. I'm not in a hurry to start messing with the NVRAM though.
So a bit more progress on this. I still won't be able to trace the execution until I acquire developer tools next week, but I've made a bit of leeway which should hopefully speed things up.
I was trying to figure out at which point in the code the license check was performed by searching for various common text ('license', 'invalid' etc.), but no luck. I then remembered Mac apps are usually built with multi-lingual support. Doing a grep in the Resources folder led to the discovery of a massive list of strings and their associated reference names.
Diving back into the binary with a hex editor reveals a small cluster of these references associated with the license check, and a number of system calls. So now I have narrowed down roughly where the license check code lives, it should be easy enough to place a breakpoint on it and figure out exactly where the license check algorithm is stored. I don't know any PPC assembly, so I will need to delve through some reference manuals.
Progress!
I was trying to figure out at which point in the code the license check was performed by searching for various common text ('license', 'invalid' etc.), but no luck. I then remembered Mac apps are usually built with multi-lingual support. Doing a grep in the Resources folder led to the discovery of a massive list of strings and their associated reference names.
Diving back into the binary with a hex editor reveals a small cluster of these references associated with the license check, and a number of system calls. So now I have narrowed down roughly where the license check code lives, it should be easy enough to place a breakpoint on it and figure out exactly where the license check algorithm is stored. I don't know any PPC assembly, so I will need to delve through some reference manuals.
Progress!
Last edited: