It sucks, sort of!

Let me rewind to the beginning.
I was very curious about this one because it was announced with great fanfare. I interpreted it as something more robust than it really is – maybe I was over enthusiastic with the “we know this will be cracked someday” sentence.
Some brief comments:

  • There are no anti-debug measures.
  • There are no binary integrity protections – patch whatever you want!
  • It has an annoying constant polling for the license file (I observed at least 5 hits per second – what a meaningless waste of CPU). This can be patched without any problems.
  • If you patch the polling, the program continues to work. What this means? License is read once and sets something somewhere (you should know what is the real meaning of this). This is bad, real bad!
  • class-dump is able to extract the license structure, although the fields sequence seems incorrect.
  • It has a buffer overflow at getenv – doesn’t check the size of HOME environment variable before strcpy it to an allocated buffer. Bang! It is just a detail. Maybe that something somewhere can be taken care with a “proper” HOME variable – that would be a cool crack (never saw this against a real target).

Audio scene groups usually have great crackers so this will be a nice feast to them. Alliance guys, you must raise your efforts, seriously!

You can find below the source code to a license file decryptor, in case you are curious about its format.
I thought a while about this and I really think there is NO great harm in releasing this code. It doesn’t crack anything and the decrypted version of the license is too damn easy to dump from memory.
Alliance, if you are reading this and disagree please tell me.

This was sort of fun (I am disappointed!) and it’s time to move to more interesting things.
If you are using this protection to protect your assets, make some pressure to be improved!

Enjoy,
fG!

decrypt_pa_licensefilev0.2.c.gz
SHA256(decrypt_pa_licensefilev0.2.c.gz)= 071458084a22f91b126389490737e33bb3a6f0d047e205545b0c36f21c8a7ba0

Update:

I noticed (again) that what I call 1st stage in the decryption code is just decoding of a binary encoding format (modified base64?). I had this in mind the first time I approached this but got sick in between and never remembered this again. I was closing the hex-editor and my brain connected the dots again. It went into plain disassembly reverse without caring of what was behind (not that I care much now). Just a lame detail, too late in the night.