According to the film companies in the UK, terrorists sell pirate DVDs to raise funds. So, forget all the benefits that I mentioned the other day, now, buying a DVD off the street means supporting terrorism. That really does it explain it all, eh? Pirates are painted as evil vile villains, and terrorists also fit that bill, so why not connect 'em? I'm just surprised it took someone so long to come find the link. I wonder how long it'll be until we learn Saddam has stockpiles of counterfeit DVDs, just waiting to flood the market and make the economy collapse... The industry makes it quite clear that there are more people than just terrorists (no, really?) who are pirates.

My favourite quote from the article was “By purchasing pirated DVDs, many consumers are unwittingly helping to fund hardcore criminals with links to people trafficking, drugs, guns and money laundering” -- wow. I'd hate to think what people who sell pirated copies of SQL Server do!

They also make a lame attack at the quality of pirated wares, saying “They were rubbish, they were shaky, out of focus, camerawork was bad, they had muffled sound”. Well, sir, it looks like you bought a SCREENER, something no decent pirate would sell. Oh wait, they're evil, vile criminals. So I suppose the moral of the story is: Don't buy unprofessional pirated DVDs 'cause they suck. Find a pirate who knows what they're doing, and in the process, stop funding terrorism.

For those of you who played D&D (here's a funny video to see what it's like), you might recall that there were magical tomes that could increase or decrease your abilities, just by reading them. Of course that's impossible in real life since we'd need powerful magic... right? Well, as I have unfortunately learned, no. A while ago, I had to maintain someone else's app. I believe in the process of reading this app's code, I have lost a few IQ points. Let's take a look, shall we?*

All the code in this app uses horrible variable names. In a 250 line block of code (a single method -- the writers must have thought there to be huge drawbacks to using methods), the first line starts off by declaring the variables. A sample looks this:

dim objconn,objrs,strDatabase,mysql,mysql1,sqlstring,rstemp,dbConn1,objrs1,query

This is a truncated line. They actually declare about double that much. Regardless on how you feel about declaring everything at the top of a file, this is bad. They don't use these variables at the same time. For instance, they'll open objrs, do something, and then close it, then open rstemp and repeat. There aren't actually two objects in use at once. They just declared extra variables for fun. Or maybe they thought they had to give the variables a rest. I don't know. And I don't think they did either. Of course, it's better than using no variable names at all.

They have a process to read values from a comma-delimited file. So, one line at a time, they use VB's split function, storing the result in a variable named “split“. So far so good. Then they proceed to use constants for the next 100 lines to refer to different fields, giving way to wonderful code as so:

if split(6) = “true“ then
  objrs1.open “SELECT * FROM Table WHERE Field1 = “ & split(2) & “ Field2 = '“ & split(9) & “'“
  split(4) = objrs1(“SomeField“)

At a few places in the app, a field is selected from the DB for absolutely no reason:

someId = Request.QueryString(“someId“)
rs.Open “SELECT SomeId FROM Orders WHERE SomeId = “ & someId, objConn1
someId = rs(“SomeId“)

That's right. They select a single field (an int), constraining it to the current value of their var, and then set the var to the same value. Maybe there's something special in SQL that I'm not aware of. To their credit, there's actually a check for rs.Eof first (omitted for clarity of stupidity).

Here's a brilliant idea for performance: Don't use SQL's COUNT. In quite a few places, they'll execute a semi-complex query that returns, on average, 10,000 rows. But why bother with SELECT COUNT, when we have SELECT *?

The entire app is built like this. The people who wrote this should have their text editors confiscated.

* Some variable names have been renamed to protect the innoce-- mentally challenged.

When I first heard about DVD technology, I was pretty excited. 9GB on a single CD-sized disc seemed pretty cool. Having video on it seemed just like any other application of this technology… you got space, so put something there. What I thought was cool is that we’d be able to jump to any area at a time (like CDs), and that there could be lots of extra information along with the video. Listen to it in a different language, have subtitles in 10 languages – cool.

Well, imagine my disappointment when I first got “The Matrix” on DVD. English only. What? Why on earth would they put only one language on it? Can subtitle files be that big? Then I was introduced to the utterly stupid system known as regional codes. Region codes were invented so that the movie studios could keep their current business model of releasing a film much later in other countries, by coding a DVD to work only with a certain coded DVD player. The idea is that in each region of the world, you can only obtain DVDs and players of a certain code. Why they have this business model is beyond me (it’s certainly not a logistical limitation). How they thought this had any chance in the world of actually being effective, is even further beyond me (wait, not it’s not, these people also fought VHS…). When I lived in Guatemala, I could rent DVDs at the local video rental store before they had hit cinemas in the u.s. let alone in Guatemala.

Region coding is such a horrible idea – it’s like programmers who think all text is ASCII (or who think there’s an 8-bit ASCII). When I watch movies with my wife’s family, many times we’ll have Spanish subtitles turned on. Everyone can enjoy the original voices (Mexican/Western dubbing is atrocious), as well as get clarity on parts they might not understand. Well, of course, under this system, that’s impossible. Also, my family doesn’t use Spanish at all, but they live in Guatemala. Half of the hardware/DVDs available (well, nearly everything in the retail market) won’t work on their equipment. Fortunately pirate sales are all over ($2 for a DVD!) and have region encoding removed.

I got the “Tonari no totoro” DVD, but guess what? Fox thought “who needs Japanese audio?” and left us only with a horrible English dub. So much for enjoying their product. But I could always get a foreign version with English subs and original audio… oh wait, but that’s region 2, so I won’t buy it. So much for the business model. One exception I did notice: “Dr. Strangelove (Or How I Learned To Stopped Worrying And Love The Bomb)“ (Special Edition) has 7 languages, including Spanish and Korean. *That's* how DVDs should be made.

To make things worse, the geniuses who invented the DVD virtual machine, thought it’d be cool to have “Prohibited User Operations”. This allows the designer of a DVD to decide that you can’t switch subtitles, audio tracks, or jump to a different chapter/title. I just received Lost in Translation DVD from Netflix. When you start to play it (and after the useless and annoying FBI warning), a screen comes up saying “You may fast forward to the menu”. Excuse me? Fast forward? What is this, a tape? Sure enough – they disabled all skipping, *forcing* the user to watch their previews (even at a high scan speed). On the player I was using, going to another title (there are 4 or 5 of them before the menu) takes the playback out of scan mode and sticks it back into play. So here I am, in 2004, repeatedly hitting “Fast Forward” to get to the menu of the DVD. Sigh. On the bright side, most DVD ripping software (to make copies) removes prohibited user ops, so anyone with a pirated copy might not have to sit though this.

What a strange world it is when pirates actually get things better of than those of us who pay. The MPAA blames the Internet as the reason why people pirate. Perhaps there’s another reason (hint: Regardless of what the RIAA says, pissing customers off is not good for business).

Well, after quite some time, we've finally sent out the first beta of InvisiSource. It's an encrypted loader/obfuscator that I've been working on for quite some time. The reason it's been taking so long is that when we approach obfuscation, we try to make the obfuscation break as many rules as possible, to make the code even harder to reverse engineer. Unfortunately, it's quite easy to break too many rules and end up with something that won't run in every scenario. Over the past while, I've discovered many tricks that'd throw quite a screwball at a potential cracker. Unfortunately, the conditions on them make them unsuitable for every app. Other factors that took a while: debugging encrypted code and obfuscated code is, by design, hard :).

Anyways, we're going to be giving out Xbox systems to the top three beta testers (which is a good amount, considering the size of the tester pool). So, head on over to www.invisiSource.net and sign up!

Two things that are often confused are safety and security. Aren't they the same? Well, no. The difference can be quite subtle in some cases, and not-so-subtle other times. Understanding the difference will help you see each for what it is, and not get a false sense of security.

Being safe means that you are free from harm via accidents. Being secure means being free from harm via attacks. What's the difference? Engineering a safe building might mean that it won't fall over if 100 extra people get in it, or if an earthquake occurs. Designing a secure building might mean that it won't fall over if someone fires a missle into it, for instance. The sandals I just bought have safety features (non-slip soles), but I don't expect them to be secure against someone leaving caltrops out on my balcony.

Most things we encounter in daily life are designed for safety. Even things sold for “security” are sometimes designed more with safety in mind: consider a can of mace. The models I've seen are designed so that it's actually a tad more difficult to fire them, as well as being weakened for “civilian” use. As civilians, we're under much more threat of accidents than attacks. I'm more worried about some drunk driving a car into me than an assassin waiting to run me down. This is a good thing: in real life, being secure from attacks is quite difficult.

Kidnapping/robbing/killing/whatever someone in most places is easy. The threat of punishment and an effective enforcement is what acts as a deterrent. In places that lack enforcement, say, where I used to live, such things occur much more frequently, not because they are any easier to do, but because there's no penalty. My dad was kidnapped down there, and almost executed. Our neighbours had something similar happen, but they weren't so lucky :(. However, even there, a bigger worry is a bus like this, this, or this.

However, in computer systems, the equation does not hold up. Users can delete their own documents. Or pour coffee on their keyboards. However, when connected to a network, you can get attacked from around the globe, millions of times per second. People are being blackmailed simply via sending a single email. And electronic attacks, unlike physical attacks, are usually harder to prosecute. If you have worked in IT for a while, you probably have a story or two where you could have made quite some money by breaking a law or two (my favourite is the bank that called me for some work: they had one network with all their data on it. This network also had an NT4 machine running Exchange, and was directly connected (just a router) to the Internet.). These attacks would have been much harder in the physical world. In the real world, the bank should probably worry more about clearly marked emergency exit lights than someone driving a car through the wall.

Deciding how safe or how secure a system should be becomes very difficult. A classic example: data backup. On one end, we want our users to quickly recover from any problem. However, each backup copy made introduces yet another item to be secured. Your data would be safe from accidental deletion if you burned a CD with it and mass-mailed it ala AOL. However it wouldn't be very secure. You can secure it be encrypting everything with no unencrypted backups and a single key, but if you lose the key, your data remains secure, but not safe from loss.

How should a file delete function work? Safety says that the file shouldn't be wiped, just marked as deleted (or in the Windows Recycle bin case, just moved to another folder). Security says the area where the file is should be at least zeroed out.

AntiVirus software (for instance) is almost completely a safety product. It helps stops a user from accidentally running something bad. It does nothing if someone deliberately crafts an attack at them. It'll detect if a 10-yr-old installs NetBus on your machine. It won't do anything if a 16-yr-old first plays with the NetBus executable with a hex editor.

”Disabling” VBS and WSH scripts on your computer doesn't really increase your security. It just lowers the safety problem of someone accidentally clicking a script that is known to be harmful. It won't help if someone compiles that script into x86 and throws a .exe extention on it. On most modern PCs, there is no secure way to run arbitrary code (although managed code/virtual machines should alleviate this eventually).

People who place trust in these fake-security measures are being deceived by safety measures. It works because real-world counterparts are hard to come by. While this is good for the makers of such software, it can be devastating if it's not taken for what it actually is. For instance: If your computer is infected with some virus/trojan/whatever, cleaning it with AV software is *not* secure. The only secure action at that point is to re-install (or at least verify) that the entire OS and configuration is correct. For all you know, the trojan could have modified the Windows' kernel, the AV interface, and everything else.

Fortunately, many times safety software won't actually hurt your security. Just running AV in a proactive mode doesn't make you less secure. It's the improper use and faith in this software that's dangerous. So, as always, getting a secure system can be really difficult. This is just one more potential pitfall to watch out for.

If you've dealt with symmetrical algorithms, such as DES, 3DES or Rijndael, you're probably aware that you must supply a key and and IV to encrypt/decrypt. If you're not aware of this, you shouldn't be writing code that works with cryptography :). Everyone knows what the key is, but what's the IV? IV stands for initialization vector. IVs are used to “jump start” the cipher stream. Not clear? It helps to understand how to look at a cipher.

Think of a cipher as a random mapping from a piece of plaintext to a piece of ciphertext. Most modern ciphers are block ciphers: they work on n-bit blocks of plaintext at a time. Thus we can imagine a cipher such as Rijndael (which uses 128-bit blocks) to have a huge dictionary: one entry for every possible plaintext and it's corresponding ciphertext. In reality, there's not that much memory available, so instead the ciphertext is computed.

So lets take a sample message: “Hi Bob, how are you?” We'll split that into blocks: “HiBob HowAr eYou?”. With a particular key, the ciphertext might be “LaAHz IAtXm LyJxr”. Everything's nice and safe. Now, let's send another message: “Hi Bob, game?” This becomes “HiBob Game?”, and ciphertext “LaAHz KozhW”. Notice a problem? Since the first two blocks have the same plaintext, they will have the same ciphertext. If an attacker knows the format of the message, he can start to guess the first part of our messages (since “HiAlice” and “HiEve” would have different first blocks). This can get worse.

Imagine that the messages are orders, and the first block is the item number, the second the price, and the third the quantity. Now an attacker can determine (say by entering an order and looking at the output -- called a chosen plaintext attack) which ciphertexts correspond to which items/prices/quantity. Modification of the messages can be stopped by a digital signature algorithms. But what about reading? Enter the cipher mode.

The cipher mode I've been describing is ECB, Electronic Code Book. It's exactly as it sounds -- basically a big lookup. Each block is processed by itself. As shown, this isn't very secure for most applications. The most basic improvement is the CBC mode. (There are other modes as well, but CBC works for this article.)

CBC stands for Cipher Block Chaining. CBC takes the ciphertext of the previous block, and XORs it with the current plaintext block before encrypting it. Thus the ciphertext block for “10000” won't always be the same, but it'll depend on what the preceeding plaintext is. So, the message “12345 10000 29500” will have completely different ciphertext than “54321 10000 29500”.

So, using the previous block is easy, but what about the first block? This is where the IV is used. The IV is the “previous encryption“ for the first block. So when we encrypt “HiBob“, we're going to first XOR “HiBob“ with our current IV.

IVs are not sensitive. You do not need to hide the IV. Many times, a unique message ID is used as an IV, since many applications require a unique ID anyways. It's perfectly fine to send along the IV as the first piece of ciphertext. Thus, we read the first block, and use that as the IV when decrypting. This makes managing the IV very simple, since it's right there with the message.

However, just remember to never reuse an IV! If you reuse an IV, it defeats the purpose, since the benefit of the IV is negated. Any given plaintext will always be the same with a given key and IV. But since IVs aren't sensitive, and easy to manage, this shouldn't be an issue.

Are you a strong ASP.NET tester or developer? If so, I might have a job for you. We're currently looking for a tester with strong development skills who can create and automate test cases for an ASP.NET application. Strong coding skills in C# as well as understanding of ASP.NET, HTML and SQL are required. We're also looking for strong developers to join an existing team and work on a medium-sized project.

If you are interested, drop me a line: mgg AT atrevido . net.

Quite some years ago (8 or 9?), I played a game called One Must Fall, a cool robot melee fighter game. Now they released a new version with cool effects, Internet play, and so on: One Must Fall:Battlegrounds. I just recently learned it was shipping (they did good job of press before it shipped, but I never heard about it after it shipped). My copy finally arrived in the mail today. I start it up, check it out, and after winning a level, the game quits with this message box:
---------------------------
Protection Error
---------------------------
Debugger detected  - please close it down and restart! Windows NT users: Please note that having the WinIce/SoftIce service installed means that you are running a debugger!
---------------------------
OK  
---------------------------
This is wrong. I work from home, as well as play games from home. I've got a few debuggers installed (not SoftICE though). At the time, I had Visual Studio closed, and hadn't been running the debugger since my machine started. But what's worse is that apparently they thought this perfectly acceptable! Note that this doesn't stop piracy *AT ALL*. Experienced crackers are going to crack the game, and serious “pirates” are going to apply patches. Having a CD check stops “casual piracy”. Having a debugger check stops wannabe crackers from cracking. That's it!

I've emailed support with my current plan of action: Try a pirated version and if that doesn't work, return it for a refund (something publishers don't like). Sigh.

Update: Well, I reluctlantly installed a crack from a game backup site. And guess what? It works just fine. No more debugger complaints (and I get to take the CD out too).

Last update: Got in touch with one of the developers. At first, they thought it was a problem with DirectX, or the video card or likewise, since their code doesn't do any checking. However, they were using SafeDisc (which is less safe than rolling your own, since there are a few tools that instantly remove SafeDisc). However, after I told them that a pirate crack makes the game run, he said he'd get me an unprotected version. Hey, at least their support is good!

At the PDC '03, and the time after it, it seemed like Microsoft was really liking ATI. I remember using their cards a long time ago, and it was a very bad experience. So, I've been quite loyal to nVidia for the past while, since they hadn't disappointed majorly... until a few days ago. I just left for a trip, and was counting on using Remote Desktop to get access to VS, Outlook, etc. while on the road.

I connect to my machine from my laptop. User... pass.. applying settings -- window closes. Try again. On another machine. Try with a different user (perhaps the profile was messed up...). All the same. After login, the window closes.

Google group search for “remote desktop closes”... and tada! Are you using nVidia's drivers? Guess what? Their drivers install a service and yep, that service kills remote desktop. Stop the service, and you're set. Well, I'm 3000 miles away from my computer, so that's pretty hard (two firewalls, so I can't connect to SQL Server and run a extended procedure or likewise).

Apparently, this is nothing that new (judging from Google groups), but I don't remember nVidia mentioning this in their release notes. Why can't hardware vendors just make drivers? That's all I need. Drivers and an optional configuration app. Seems like this trend is only getting worse...

I've been very, very busy lately, and my wrists have been hurting (spend over $100 getting a “keyboard manager”). However, among the things I've been doing, I've been involved in a usability study with the Visual Studio team. Basically, we meet over live meeting with my desktop shared, so they can watch how I use Visual Studio. This helps figure out if I'm using the new features correctly, or if the design could be clearer. I like it cause I can make very direct feedback and hopefully improve the product for others! Speaking of feedback, the new default for strings in Whidbey is maroon (at least on the build I just installed) -- I made this suggestion to someone who works in that area about two months ago -- so they ARE listening! :)

Whidbey has a host of new features. So many aspects have been fixed up so when you use it, you just have to say “Oh sweet, that's nice!”. There's been a lot of coverage of the “big” new features, like generics and in C#, refactorings, and that's well deserved. However, there's been a ton of work on the day-to-day stuff as well. The #1 top thing I miss when using Everett is auto-Intellisense, for lack of a better name. In VS2005, Intellisense activates on a single keystroke (most of the time), and the list is complete: even keywords are listed. I think preprocessor directives are the only things not available (I've put in a wish :)). It might not seem like a big deal, but it is definately the top thing I notice line-by-line when working in VS2003. CodeRush (www.devexpress.com) helps a bit, but still doesn't come close to how great Intellisense is in VS2005.

Ever write a short main method to test something out? You try something, and write the output to the console. Or perhaps you have extra debugging info going to the console while your program runs. I've been annoyed a lot when I run my console app, and VS opens a new console window for 1 second, and then the program closes, and I can't see the result. I also hate having to switch back and forth between VS and the console app while running.

Visual Studio 2005 takes care of this, with the new “Console” debugging window. As far as I can tell, the console streams are mapped to this pane inside Visual Studio, so you can dock it, have it as a document window, or however you want. Afrer your program runs and exits, the data will still be there.

Do note that not all the new Whidbey console features are supported, since it's not a “true” console window (you can't use the Win32 console functions on it). But for basic console work, it does the trick.