Happy Birthday Lixtetrax

Looks like the idea to separate the blogs payed off! I have the other usual place for personal stuff and this one for thins a bit more techie (says on the tin).

So, a year and some change, how does it looks? Well, generally there are the cash-cow posts (that get linked from the craziest of places), a couple of big-hit for a day or so wonders and the rest stay relatively obscure.

So, lixtetrax is not going away anytine soon. At first I was a bit disappointed with the lack of traffic and comments but slowly, persistence paid off.

What is the aim of this blog? Is it to make a book out of it? Is it to pimp my trade? Is it going to be just an RSS aggregator with a couple of lines here and there?

NO!

It will stay about as it is now, a bit longer piece in long irregular intervals. Having a target of say X posts per week, is not applicable in our example. Quality over quantity.

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

Two war stories to show that the Greek IT market is doomed

(a quick intro: when I read this one, I really had to post about it)

War Story #1:

Navigate here

Check the prices for India. Check the cost of life in India. Check the average market rate for a Greek IT developer. Check the difference between cost of life in India and in Greece. QED

(yeap, I know that the prices quoted there include man in the middle fees, but still it looks pretty grim).

War Story #2:

Talking to a friend, he confided that once his company was needing to buy a software costing appx. 120K for a 5 seat license. The software vendor did a ROI analysis. When they got informed about the cost of developers, they exclaimed “Wow, Greece is cheaper than India!”.

So, dear IT managers. You do not pay well. In fact, you pay a bit better than India. You demand unpaid overtime. Don’t be alarmed when all the guys worth their salt either move out of the Greek job market or get snatched by the major players. Also, don’t be alarmed when you see that given your current skill field, you cannot get any innovative or highly paid projects, been stuck to the good ole fetch the data from backend, format it and present it $2000 t best projects. And for the love of God, don’t be alarmed when your company will die in a few years or become a “mpakaliko”.

Why constant overtime is bad for your IT company

(Some meta-info: after all these technical articles, I have decided to take a sidestep into the managerial aspect of things.)

Some managers still go by the good old “if you make your personnel work overtime, all the time, you will finish sooner”. By the same account, some people still believe that the Earth is not round. The overtime will eventually kill your company and here is why I believe so:

• People have lives. Even if you insist on hiring ambitious, single persons, they will be quickly fed up with it. If the employees have a family, you can forget about them.
• If you pay overtime, the costs mount. If you do not (legally) pay overtime, the personnel will soon feel ripped off (as in “Hey, those 4 extra hours a day kinda halve my paycheck”). If you do not pay overtime (the illegal version of it), you might have (and IMHO, you should) legal trouble.
• IT work is not like an assembly line. If you force a person to work say 12 hours a day, it does not mean that he will perform 24 man-hour work in 2 workdays. Chances are that overall fixes that will be required, will take a lot more than the extra day the poor fella “saved” your company.
• Even if the pay is good, persons will quickly fed up. After all, what use are money if you do not get to enjoy them? Even if they stick to it in a “come on, two more months of this and I get the new car”, trust me, they will leave, which leads us to…
• High turnaround. If your people are fed up with you and they have a relatively up to date skillset, prepare to say “Buh-bye” to them. Once a competitor approaches them with reasonable terms, off he goes one person who might know more for your day to day operations than your average middle manager.
• Speaking of managers, constant overtime is a sign of bad management. Even if you choose to ignore the above, if your sales people have no input from the workforce and systematically underestimate the time that is required for a given project, is bad management. If your managers have the slave-driver mentality, it is bad management. “Lowballing” projects is bad management. Hire an extra guy, even a Jr one will take some load off the other persons.
• If you still require overtime, then do the world a favor. Fire all your managers and hire competent ones. If something cannot be done in a normal 40 workweek but needs to be done within a week, you’re out of luck. Perhaps you will get away with it a few times but when you will not, it will hurt.
• While you are at it, why don’t you go ahead and fire some of the HR people? A stick in the mud (or a dick in the team) will hurt your productivity. Hiring only “cheap” persons will not save you money, as it is more likely than not that they will stall and waste time.
• 8 hours of work are usually enough for most day to day operations. Instead of asking people to work more hours, try to implement some in-house productivity measurement and have people work more those 8 hours instead. Try to identify problems in your processes and performance bottlenecks and eliminate them ASAP.
• [edit] If people do not have the time to do their own research (you did bother to hire people that do at least a bit of research in their own time, don’t you?) soon they will stagnate. OJT can only get your people so far, a bit of extra boost is needed. And yeah, if your people are working 50 hour workweeks, you can’t seriously expect them to devote hours in the weekend.

Fortunately, while I have faced most of the above, I do not have to face them now so I consider myself lucky. This is not the case with everyone and while this is no Joel’s, read it

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 )

Optimizing Joomla Sites for Speed

As I have blogged before, I have the dubious honour to work as a web application developer/Linux administrator/general IT “Mr fix-it-all” guy at a Joomla based shop. (hey it pays the bills and it’s not like I will be here for long ). This is essentially a mom-and-pop store with a tight budget so one has to cut corners. In that light, the decision was to buy a linux VPS (Virtual Private Server, for the uninitiated). As my projects are not connected with the Joomla development team, I have left them happily turning one cookie-cutter page after another. Like many other techies, I am a content-over-style person so I felt that the graphics ladden pages were at least atrocious. But hey! its the customer’s wish so they get their money’s worth in .swf animations, animated .pngs, the works.

It came of little surprise when the pages viewed not in our Gigabit LAN but over a run-of-the-mill DSL line where slooooooooooooooooow. Guess who comes to the rescue. Since it is only logical that many other shops fail to hire web monkeys that adhere to web development best practices, I decided to share my experiences in trying to solve the problem (ok, I use the verb solve more in a “band-aid applied over multiple 7.62mm wounds” but I am sure you knew that already).

• When using CSS and Javascript, try to keep them in external files as much as possible (always for you and me). This way, they get cached and you save some precious user experience time by using that.
• PNGcrush is your friend. I cannot stress this enough. Even if you get only a 10% reduction in filesize for each .PNG, they quickly add up. Speaking from experience, I got reduction between 5% and 25% in each file, which was well worth it.
• Since you are using a database to store your content, turn RAM caching on (if you can afford it). While memory hungry (total memory consumption of our server is 280Mb), it gives a tremendous boost. MySQL documentation has an excellent section on how to do this and some consideration/poor man’s benchmarks. I can assume that your database has something relevant (between you and me, while MySQL gets the job done and has tons of support, it certainly is not the pinnacle of technological achievement in the open source database field).
• If you are using Joomla (or Mambo or a similar CMS), try to keep the number of modules to a bare minimum. Each module, even if it is lightweight in actual size, is at least one HTTP request so that bogs the performance down.

So, if you have to face the all-too-common “clueless management with incompetent web designer” syndrome and teaching (enforcing should be a more appropriate term) web design best practices is out of the question, the (kinda obvious, to be honest) tips above might squeeze an ounce of performance or two that can make a difference.

Simple (insecure) python password generator

Not the best point of my career, much of it is an extension of GPL cookbook code but it may come in quite handy to a few people so I decided to post it here.

# A simple password generator
# not very secure but will do in a pinch as one can
# predict the format of the password and has limited
# entropy but ok  

import string
import random

alpha=6
# numeric includes some symbols as well
numeric=4

digits = string.digits
vowels = ['a','e','o','u','i','y']
consonants = [a for a in string.ascii_lowercase if a not in vowels]
symbols = ['!','@','#','$','%','^','&','*','(',')']
ssymbol = string.join(symbols,'' 
digits += ssymbol

####################################
######### util functions ###########
####################################
def a_part(slen):
  ret = ''
  for i in range(slen):
    if i%2 == 0:
      randid = random.randint(0,len(consonants)-1) #number of consonants
      ret += consonants[randid]
    else:
      randid = random.randint(0,len(vowels)-1)
      ret += vowels[randid]
  return ret

def n_part(slen):
  ret = ''
  for i in range(slen):
    randid = random.randint(0,len(digits)-1)
    ret += digits[randid]
  return ret
####################################
fpl = alpha/2
if alpha % 2 :
  fpl = int(alpha/2) + 1
lpl = alpha - fpl

start = a_part(fpl)
mid = n_part(numeric)
end = a_part(lpl)

print "%s%s%s" % (start,mid,end)

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