Linux Copy Protection, a first look

While one can see a ton of (mostly not functional ) code protection schemes in the Win32 world, I have not seen that many into Linux. Perhaps it might be due to most software for Linux is open source (and quite good, if I may add) but this is a research area that has been largely neglected.

I am currently working (free time of course, not company related) with a scheme of protecting functions. I took the inspiration from commercial CD protection schemes (SafeDisk, SecureROM, etc). The only requirement I put are these:

1. Superuser access will not be required
2. (kinda obvious from the above): No kernel level stuff

The first approach would be to simply pack (or encrypt and pack if you prefer) the whole binary. This is naive if it is the only layer of protection. Other people have tried it and eventually failed. If there is an automatic unpacker for your packing scheme, then it is trivial. If one dabbled with breaking copy protections from games then he might remember the unsafeDisc wrappers that were all the rage.

My second idea comes from the win32 world and is simple and effective. I will be using the term DLL but feel free to think of shared object (.so) if you are so inclined.

a) Create a .so object with the functions you want encrypted. Test that the unencrypted code works.

b) Encrypt the code using a custom made tool

c) In your code decrypt the .so

d) using dlopen(), load the relevant dll, load the function, call it (say supplying the serial as an argument), store the results or whatever (this is purely POC so far so it just checks for an argument).

e) dlclose(), Free the unencrypted .so from memory.

Some attack vectors off the top of my head:

• What if the user supplies his own .dll? (i.e. overwrite our DLL with his own stub that say always returns true?)
• At least for a while the whole .so will be in memory, if the guy knows where to look (place a breakpoint in dlopen()) and dumps the memory,voila. there is the unencrypted function.
• Tricks as anti-debugger protection, might be useful, but as with packing, they are only there to provide a gimmick, not to really prevent disassembly and patching of our function.
• dlopen expects the name of the function. Perhaps a way must be devised that this is not that trivial for an attacker to obtain? (Use serial as a decrypting key for a string perhaps?)

I have only been working on this one for a few hours at most but somehow I sense this will be a pet project for quite some time to come :). Watch this space for any updates and Merry Xmas y’all.

A Search Engine Traffic Related Post (OR Warez For The People)

0×00415bc1 <— this is the LATEST magic offset that all people seem to search about in this blog.

If you understand what this is about then ok (chances are you do not need it already), if not, you were not supposed to (or you are not a loyal reader )

Decompiling J2ME applications for fun. profit and stealing assets.

In the following article I will attempt to give some basic info about decompiling J2ME applications, with an emphasis to games. The reader is assumed to be familiar with Java and have a bit of idea about the whole J2ME platform. The research here was conducted in the Nokia Series40 (S40 from now on) platform but one cannot see why most of the concepts presented here should not be applicable to related architectures. Also, I will try to keep a conversational tone so bear with me

First some basic information about the nature of J2ME applications. They are distributed in the all familiar JAR files, which are nothing more than ZIP files. So using 7zip or any decompression program, you can easily expand it and see the contents of it. If you are lucky, you will see a bunch of .class files with meaningful names and a bunch of assets (i.e. png assets, amr assets etc). However, the catch with J2ME is that, while you can have quite a lot of heap memory in the platform (128Kb are not uncommon) but the actual JAR size is very limited (64Kb in S40). In layman’s terms, you have more RAM than actual filesystem space. As a developer then you have to reverse the process normally employed with game development (which is the exact opposite, a game can span several Gb of space while still being able to run on a run of the mill 1Gb PC so elementary caching techniques are out of the window) and start breaking traditional software development rules (especially Object Oriented Design, as the more classes you use, the more space you end up using from your already limited space budget).
The first rule is this: For every single file you add, it is going to cost you in terms of JAR space. Therefore, you have to encapsulate you data as much as possible, use resource management files (like iD’s .MDx for those familiar with it) and make do with as few files as possible (as said before, this also includes .java files and the resulting .class files). In practice I have seen games that, while made from serious companies and are ports of AA titles (remember, there is no such thing as a AAA title in J2ME games just yet), do not care to protect their assets and, even worse, do not even care to combine them.

Second rule is that obfuscation is your friend. For those unfamiliar with the term obfuscator it is a program that transforms your code from something like

[sourcecode language=’Java’]

public class aLongClassName {

private static int doNothingUseful(int Jenna) {

return (Jenna <<

}

}

[/sourcecode]


to

[sourcecode language=’Java’]

public class A{

private static int b(int c) {

return (c <<

}

}

[/sourcecode]

Ofcourse, obfuscating can get much more complicated than that, but I am sure you get the idea. For more information (thus more ideas how to bypass it) check your obfuscator’s documentation.
Keeping that in mind, let’s go fetch the tools of the trade

JAD - The fast Java Decompiler. Old but reliable (at least in the cases I have used it)

JODE . Have not used it so I cannot comment. Supposedly slower but a bit more reliable than JAD.

7-zip - A free Win32 ZIP archiver (but any one will do).

So let’s pick up a target and start seeing what we can do. I have picked a successful game that will remain anonymous to protect the innocent. Once we have the JAR, let’s create a directory and decompress it there.

What strikes our interest is that we have a few .mid files, a few .png files that do not include the graphics used during gameplay, some .class files with the cryptic names C.class, Z.class, I.class and cMidlet.class and some binary files.

What if the developer tried to implemented the “security through obscurity” method and just use plain PNG files minus the extension? Nope, the use of file command under a unix system just says its a binary file. So let’s start decompiling the .class files.
It is obfuscated but in this case it really does not matter because it is really a very small class. It is a relatively simple J2ME Midlet lifecycle manager so the real work is performed by the other classes. Let’s go and examine the source code we got by using JAD (mind you, the source code might not be 100% accurate BUT I believe it is good enough for most cases).

We have deducted what our binary encrypted packages are so let’s see where they are referenced in our code. By searching the file I.java we get a call like the following

setColor(24, “/BINARY_FILE_OF_INTEREST”);

[sourcecode language = ' java' ]

inputstream.read() & 0xff
[/sourcecode]

but it is only a way of converting a signed {short

regular} int to an unsigned one.Why go through all this trouble? Learn how to do something (how often you see at least semi proficient software developers giving you their source code?), write decryptors, patch classes (assuming that you fix the often encountered decompilation errors), what not

Greek spies plant rootkit in a phone exchange

via Techworld.com

A highly sophisticated spying operation that tapped into the mobile phones of Greece’s prime minister and other top government officials has highlighted weaknesses in telecommunications systems that still use decades-old computer code.

The spying case, where the calls of around 100 people using Vodafone’s network were secretly tapped, remains unsolved and is still being investigated. Also complicating the case are question marks over the suicide in March 2005 of a top engineer at Vodafone Group in Greece in charge of network planning.

A look into how the hack was accomplished has revealed an operation of breathtaking depth and success, according to an analysis on IEEE Spectrum Online, the website of the Institute of Electrical and Electronics Engineers.

The case includes the “first known rootkit that has been installed in an [phone] exchange,” said Diomidis Spinellis, an associate professor at the Athens University of Economics and Business, who wrote the report with Vassilis Prevelakis, an assistant professor of computer science at Drexel University in Philadelphia.

A rootkit is a special programme that buries itself deep into an OS for some malicious activity and is extremely difficult to detect.

The rootkit enabled a transaction log to be disabled and allow call monitoring on four switches made by Telefonaktiebolaget LM Ericsson within Vodafone’s equipment. The software enabled the hackers to monitor phone calls in the same way as law enforcement agencies would do, but without the normal required court order. The software allowed for a second, parallel voice stream to be sent to another phone for monitoring.

The intruders covered their tracks by installing patches on the system to route around logging mechanisms that would alert administrators that calls were being monitored. “It took guile and some serious programming chops to manipulate the lawful call-intercept functions in Vodafone’s mobile switching centres,” the authors wrote.

The secret operation was finally discovered around January 2005 when the hackers tried to update their software and interfered with the way text messages were forwarded, which generated an alert. Investigators found hackers had installed 6,500 lines of code, an extremely complex coding feat.

“The size of the code is not something that somebody could hack in a weekend,” Spinellis said. “It takes a lot of expertise and time to do that.”

The investigation, which included a Greek parliamentary inquiry, netted no suspects, partly because key data was lost or was destroyed by Vodafone, the authors wrote. It is not known if the hack was an inside job.

Vodafone may have been able to discover the scheme sooner through statistical call analysis that could have linked the calls of those being monitored, to calls to phones used to monitor the conversations, they wrote. Carriers already do that sort of analysis, but more for marketing than security reasons.

But the defense against rogue code, viruses and rootkits is complicated because of the way the telecom infrastructure has developed. “Complex interactions between subsystems and baroque coding styles (some of them remnants of programmes written 20 or 30 years ago) confound developers and auditors alike,” the report said.

Cracking Introversion software’s titles

I am a huge fan of www.introversion.co.uk

In an age of multi million dollar budgets in game development, the aforementioned company creates small scale, game play based games. They offer downloads for most major platforms (win32, linux, macosX) but they neglect one small thing …

Protecting their IP. Let’s assume that user A has download either Uplink or DEFCON and wants to play without having a valid serial (in essence making these games shareware). First obstacle she faces is that they are not standard PE files, they are compressed. However, they are compressed using UPX, an open source packer so its only a matter of upx -d A.exe to get it in uncompressed form. Once its there, IDA Pro (or the disassembler of your choice) and OllyDbg (once again, the disassembler of your choice)can be successfully deployed. No self-modifying code, no nothing. In fact, it is very easy to get rid of the authentication screen in Uplink altogether and easy enough to unlock full game characteristics for DEFCON (once again, for single user play only, or at least this is how far I got).

These guys are nothing short of brilliant when it comes to gameplay ideas and making games in a shoestring budget. Shame they didn’t went the extra mile to properly protect their software (single player mode at least).

I might be e-mailing them about that and see if they are interested in hearing some ideas…