Posts Tagged ‘Hacking’

My Life As a Hacker

Friday, June 25th, 2010

Many of you probably know by now that a pet peeve of mine is books that get the computer stuff wrong at a fundamental level. For some reason I was thinking lately about an incident at a previous day job. I’ll tell you guys about it because it was kind of funny in a Dilbert sort of way.

The company I worked for used a third party application that was a POS (by POS I do NOT mean Point of Sale I mean something else). The back end of the app was SQL Server ( a very expensive database). Oh my god this app was a nightmare. Poorly designed, and worse, designed with obfuscation in mind. There is a saying Security By Obscurity which any reasonably adept techie knows is a completely stupid way to design anything. You won’t stop the people with the skills to do you damage…

Anyway, one of the things this application did was assign documents an identity — like ZZ578490894 except every single document began with the same 2 character alpha prefix and there was (supposedly) no way to change that prefix (because, as I discovered, it was hard coded in the application software layer, not in the database where it belonged.)

We had a production version and a test version because, doh, you don’t want to train people or test new things against your production database. The problem was that there was an overly complex and error prone method for connecting to the test version which we could do nothing about because of the way the app was designed. Sad. Users would open up the test version of the software, but the series of stupid and complex steps that switched the users’ database connection from production to test often failed and they remained, unknowingly, connected to prod.

One thing that happened all too often was that people THOUGHT they were connected to test when, in fact, they were connected to prod, and production documents would get overwritten by test documents. ACK!!! We complained bitterly to the application developers and met with scorn. Seriously. It was not their fault, the vendor said, if our users were inattentive and perhaps not very smart and besides, their process never failed anyway. Why, it always worked if you followed all the steps! They also did not understand why we would ever want to have a different document prefix.

Sidebar: If you are generating an ID that always contains some bit of information that is always the same no matter what, then why waste the processing cycles to generate the identical bits? Why waste the database storage space? (For database geeks only: the field was defined as CHAR 12 or 14, I can’t recall which). Why do this at all? The information is, by definition, meaningless.

Anyway, I had the brilliant idea that we would find a way to change the letter prefix of the document ids such that when someone was connected to the test application, no test document could ever be generated with the same ID as one in production because the prefix would be different. Genius!! Research revealed the above mentioned hard-coded values in the software layer.

But I am not so easily deterred in the face of idiot rules and results.

I did a SQL profiler until I found the SQL code that executed during the generation of a document ID, then looked at the SQL code and derived the likely candidates for this software layer bit. I then searched through the application dlls, downloaded a hex editor and opened up all the likely candidates until I found the one that contained the hard coded values. Then I changed the values and, with the assistance of someone who knew more about dlls than I did, recompiled the file and copied it into the test application directory, replacing the original dll. This took all of 15 minutes, not including the research time.

Voila! In our test application, documents were now generated with a different prefix ID. Of course, we were unable to admit we’d done this as it was (ahem) not exactly legal in the eyes of the application vendor. But we were now preventing serious production errors and saving the time to attempt to recover or recreate the original documents.

Sometime later, in meetings with the application vendor, the subject of generating different document prefixes came up. The vendor stressed how useful this feature would be (which they had previously scorned) and that it would be worth it for us to pay them thousands of dollars to write the upgrade to their code. There were many zeroes attached to their proposal. We declined.


Oh, and the ironic beauty of this is that no one ever suspected the girl of having done this.


More Computers for writers: hacking 99

Monday, January 25th, 2010


Reading another book where a writer has used the already egregiously wrong stereotypes of about computers to show a character who is supposedly a computer expert. In this case, a (airquotes)hacker(airquotes).

First off, hacking is in some ways ridiculously easy and in other ways quite complex. I can’t even begin a 101 level discussion. From what I’ve seen most writers would be lucky to reach the remedial level. What they are right now is woefully ignorant. It’s every computer user’s right to be ignorant about their computer. I happen to believe that users have every right to expect their computers to simply freaking work without putting their security at risk. That is, alas, not reality.

But if you’re writing a story that includes computers, please. TV and movies are simply not a resource you can rely on.

So here’s some horrifically high level facts about hacking. Consider these jumping off points for your research. I am leaving out massive amounts of information. LOTS!

If you’re going to write a book about a hacker, then please subscribe to 2600. As mentioned in a previous post, it’s quite possible you can’t get to that website at work, even though it’s not dangerous to your computer. 2600 will quickly educate you on the mentality of people who do this sort of thing for good, evil or neutral. Every word of the magazine is a clue and reference material. EVERY FREAKING WORD!

Hacking is not what you think. It’s not the stereotype you read in the newspapers, see on TV or hear about anywhere else in mainstream media. Seriously.

Criminal hackers are a different matter as nowadays it’s often organized crime, but 2600 will educate you about that too.

It’s not enough to know there’s such a thing as a firewall and that there are ways to get around one (or perhaps more accurately, through one).

How do the bad guys Do Bad Stuff?

It’s not magic. There are programs written specifically to exploit known vulnerabilities. Some of them have good purposes (penetration testing for example) but, like anything, such programs can be used for evil. And some were written specifically to do bad things.

It is possible to write your own.

The key point is the bad person is not just jumping on the internet and looking at web pages and then stuff just happesn. They are firing up programs that look for open ports and then sending commands to those ports that will accomplish evil things.

If a website was put together without considering security, then there WILL be commands from a web browser that can get you into a server. That, by the way, is typically the goal. The bad person wants to get from the computer serving up the webpage to the server that has the database, or to the domain controller or some other internal server.

SQL Injection, for example, involves tacking on certain commands to the end of a browser URL that will open up the database. From there, on a server that was not set up with thought to security, you could get to many other servers internal to a company.

Also, please remember that it’s unlikely that a hacker will be using a Windows computer to do evil. It’s fairly certain he or she will be using one of the flavors of Unix/Linux. The reason is beyond the scope of this post, but I think we could stop at, it’s a matter of pride. It’s possible. Of course.

An accomplished hacker, one whom you hope to portray as evil and/or heroic is going to have a customized set of tools and scripts, some of which he/she has likely written on his/her own.

Such a person could sit at a random computer and accomplish evil things. But they’ll be using telnet or the command prompt — that person would have to be VERY GOOD INDEED because they will have had to memorize really a lot of arcane commands. Or they could plug in their flash drive containing their toolset.

A evil person could sit around looking for websites vulnerable to SQL Injection, for example. But there are easier ways to find the low hanging fruit.

What they’re not doing is jumping onto the World Wide Web and bypassing firewalls [waving of hands in magical incantation].

Understanding Firewalls

I am flying at a high level here, OK? There are also many many other ways to do evil than what I describe here. This is incredibly basic.

The Internet depends on a series of protocols — rules that have been agreed upon regarding how one computer communicates with another computer. There are many different protocols. Here are 4 common ones:


You should recognize the second protocol: http

If you don’t, look up at the top of your browser. If you’re reading this directly from my website, you should see etc. You could substitute (And I suppose you could try to guess the login and password set for ftp services at If you did that, you would not see my lovely website because websites are written for the rules of the http protocol. ftp does not understand the rules for http. To do anything you would need to know the commands for ftp or be using an ftp shell program that will send those commands for you. Once you’ve guessed the login and password for my ftp site.

The Well Known Ports

Each protocol has been assigned its own port number. There are a set of agreed upon port numbers for each of a series of internet protocols. They are cleverly called The Well Known Ports. You can see the list here: IANA List of Well Known Ports

Side Note: The port numbers tend to be assigned in pairs of ports called TCP and UDP. If you care, traffic sent over the TCP port gets a return acknowledgment. I sent this. Yup, I got it. Traffic send over UDP is not acknowledged. I sent this.

The http protocol has been assigned the Well Known Port of 80.
FTP is 20
Microsoft SQL Server is port 1433

Your email is almost certainly being sent over port 25 (Simple Mail Transfer Protocol or SMTP).

Really Simple Example

So there you are at your computer. Your computer could send traffic over any and all of the ports using any of the agreed upon protocols. If you want, you can think of the ports as doors that reside on your computer. Corresponding doors exist on any other internet connected computer.

But certain doors (ports) may be locked on your end, from the inside (you can’t get out that door) or from the outside (others cannot get into your door.) It’s also true that on any other computer, certain ports may or may not be open from the inside or outside.

You are on the World Wide Web, looking at That’s because your computer sent an http request to over port 80 that said, please show me the page at responds to your http request by displaying my home page to you over port 80 on your computer.

Now, suppose you have a firewall. A firewall is designed to stop traffic from going out and/or coming in. For your firewall, you have to decide which doors are open to outgoing and incoming traffic.

Side Note: What if you don’t have a firewall? Then anything can go out and ANYTHING can get in. If you don’t have a firewall installed, you should be worried.

If you don’t have SQL Sever installed on your computer, when someone comes to your computer from elsewhere on the internet and wants inside via port 1433 nothing will happen. But what if you do? Anyone from the outside can talk to your SQL Server. Uh oh.

Now, suppose your firewall blocks all OUTGOING traffic on port 80. Will you be able to see anything on the World Wide Web?

No, you will not.

Your request to see will never get to the server that hosts my website.

Now suppose your firewall blocks all INCOMING traffic on port 80. Will you be able to see anything on the World Wide Web?

No, you will not.

Your request to see will reach my server and my server will say, you betcha. Here’s the page. The page will be sent to your computer over port 80 but port 80 on your computer will be CLOSED so you can’t see it.

If incoming and outgoing traffic is blocked over port 80, then the WWW is dead to you.

So practically speaking, nobody blocks port 80 because then you can’t see any lovely webpages. And what would be the point of that?

Suppose, though, that you had an internet connected computer whose only job was to receive and serve up FTP related commands. In that case, you might set up a firewall to block port 80. Unlikely, but possible.

But there are all these other ports that can provide a way into an internet connected computer. Hackers know this. The information is COMMONLY known. It has to be otherwise the internet wouldn’t work as designed.

You need a firewall to keep out the folks who scan for open ports. There are some high value, if you will, ports that will have juicy stuff on the other end. Since each port is allotted to a defined protocol, what you do when you find one that’s open depends on what port it is.

You can, if you like, think of the protocols as different languages. If I only understand French, it does no good to speak to me in Chinese. I will never understand.

So, suppose I am port 1433 (SQL Server). If you send traffic to port 1433 that is designed for FTP (port 20) nothing happens. But if you send traffic to port 1433 and you speak SQL Server to it …. ooh la la. You will get an answer. If you are a good person, then hey. But what if you are bad? What if you are looking for the information in the SQL Server database on the other end of that open port 1433? That is not so good.

One of the things hackers do is scan for open known ports. When they find one, they will execute an attack known to work against whatever is at the other end of that port. (It’s more complicated than this, OK? There are things you can do to protect against that. etc.)

I think if I keep going, brains will asplode.