Isn’t it great …

… when “leaked” exploit source code is

• Cleanly formatted, following a clean proper coding style, proper variable naming conventions, the works
• Properly commented, including “THIS IS PROPRIETARY SOURCE CODE OF JIMBOB HACKING CREW”
• Has a comprehensive listing of members, often including email addresses etc
• (last but not least), the word “PRIVATE” are repeated every 10 lines or so ….

More on the hypocrisy of Information Security to come … Perhaps making fun of the script kids and the fame seekers is an easy target. So, for the next “Isn’t it …” line of posts, we will be making fun of our friends, the IT security industry (to use a cliche, “modern age snake oil merchants”. And yes, it will be a “name and shame” game, so keep watching this space.

Don’t you just love it ….

When zines and tutorials continue to ignore what has been going on for the past three years or so. and still repackage “smashing the stack for fun and profit” from like 2 gens ago?

Bugs / KLOC ratio is useless (OR How to avoid snake oil merchants)

For the past few months, there is a lot of talk about software security metrics, even a book is out One very common metric is the identified bug per (kilo, mega, whatever is applicable to the size of your code base) lines of code. This method is seriously flawed. Why the astute reader may ask? Let’s demonstrate by example. Consider the following (rather contrived) C snippet

/* for the sake of argument let's assume that msg is controlled by the user and is gotten securely */

printf(msg);

/* ... rest of the program ... */

/* then someplace after our evil printf call */

printf(msg);

So Mr. Johnny Security Consultant gets a fat fee to run his favorite static analysis tool. The tool correctly states that there are two format string bugs. If the program is 100 lines of code, then we get a bug/LOC ratio of  0.02. Each of this bug might potentially lead to a complete application compromise.

Mrs Jane Outsourcer then steps in and does a bit of refactoring

/* this is contrived but it does demonstrate the point */

void myprintf(char *msg) {

printf(msg);

}

/* a bit within main() */

myprintf(msg);

/* a bit later in the code */

myprintf(msg);

Johnny charges yet again his fat fee and is happy to write in his report that the application now contains only one critical bug and the ratio has drop to 0.01.

Is the application any safer? No!

Is it easier to fix? In our example, perhaps.

Will a run of the mill static analysis tool fail to state that the application has still two vulnerable points? Yes

Using pure bugs/LOC can lull the development team into a false sense of security, especially if the program is not something trivial like the one above. Software security is a weakest link model, an application containing one critical vulnerability is not safer than one containing ten critical vulnerabilities.

So next time someone tries to sell you some software and spouts some statistics in your face, you will have a counterpoint.

Format String Attacks in a non-C/C++ environment

A ton of people are under the impression that format string attacks are only a C/C++ vulnerability (as in, if you code in a different language, you are safe).First, read this article

Second, try this bit of C#

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace FormatStringsC
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                // if I was a user inputted string you would be in trouble
                String fspec = "{1},{10}";
                Console.Write(fspec, "I don’t know but ", " I’ve been told ");
                // return 0;
            }
            //generic catch all
            catch (Exception e)
            {
                Console.WriteLine("Oops! Shutting down app\n");
            }
        }
    }
}

Third, keep watching this space for examples in other languages

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

Some thoughts about the future of computer security

Here is an extended version of the comment I have made over to EM Blog about bug hunting getting harder and harder and about the future of computer security

- VM Technology

The industry is moving towards a VM enviroment (.Net and Java are two instant examples that spring to mind). If you discover a flaw in say win32 JVM, chances are that it will affect other versions, giving great leverage on the flaw finder (and if he is malicious then one can relieve the era of mass-rooters and other tools of mass destruction). Combined with the hunt for data accessible from web applications, if you “own” the application and steal the data, it is mission complete. (provided the attacker has a clue about covering his tracks).

- Code Quality

Bug classes like format string bugs can be reduced to (almost?) non-existent by the use of automated tools combined with plain old manual checking. The average developer is much more security aware than the average software developer 10 years ago or so (assuming that he has some time to research the security implications of her code and is not constantly rushed by the management). Trivial buffer overflows tend be a thing of the past, but once in a while a ridiculous bug like Solaris telnetd shows the far reaching tentacles of human stupidity (not meant as an insult to Solaris developers who are more skilled than me but come on, this one was plain dumb).

- Open Source.

While open source is not the panacea of software security its advocates would led you to believe (i.e. there are tons of messy, insecure code out there, especially in the lesser projects), it helps security, not only with the usual peer review process, but by EDUCATING programmers. If you want a secure way of doing something, chances are you can find and study some open source code, see what works and what not. If the code is governed by a suitable license, then it can be freely incorporated into your programs (foe example: SecuRom copy protection (a pretty popular protection in the world of win32 games) is incorporating elements of OpenSSL software), saving time and effort.

- Modern Bug Hunter

Considering the above all is not lost for the bug hunter (professional or amateur). Today the average exploit hunter has more tools in his disposal. Imagine having something like Ida Pro back in the early 90s. How many bugs from closed software would have been rooted out? Methodologies for vulnerability discovering are common knowledge. This can work in favor of the attacker (he knows what to look for and how to look for it) and against him (if the developer actually took some time to test the code ). Thus “easy” bugs like the regular BO will become less and less common (again see point in Code Quality about human stupidity for an exception to the rule). A byproduct of this difficulty is that perhaps the dimestore security consultant (something that anti.security.is was against with their NO DISCLOSURE movement) will, if not go away, lessens its impact in the professional security scene and move a bit down the food chain.

Answering the original’s post question, vulnerability research will be here for a long time (I’d wager that since IT moves further and further into the everyday life (i.e. your modern cell phone has more power than some routers ), exploitation techniques will become more difficult over time but the use of tools will offset the effect of , say, kernel level mechanisms so the overall difficulty in the process will remain the same. I believe that there are undiscovered bug classes having yet to be explored and of course the new technologies will bring more bug classes (and perhaps revive old ones, ever heard of the new format string bugs in Java and Python? If not, look it up at Dr Dobbs magazine.).

Feel free to read the original article at EM Blog

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…