New Perl Hate

You don't work with a language every day without building up a "things I hate in language X" list. Well, I have a few hates of Perl, but they've all been fairly well covered in other blogs and cover the usual topics (pre-Moose OO, getting bitten by scalar/list context, etc), however yesterday I came across a new one. Here is a one-liner demonstrating the problem:

$ perl -MData::Dumper -le'@a=qw/a b c/; @foobar = map { $_ } @a[0..7]; print Dumper \@a'
$VAR1 = [
          'a',
          'b',
          'c',
          undef,
          undef,
          undef,
          undef,
          undef
        ];

Fairly obviously, I have created a list with 3 elements in it, tried to slice it with 8 values and assign that to a different list, however when printing the contents of the original list, it has now been padded out to 8 values with undefs. Ok, I thought perhaps doing a slice on a list had that kind of destructive behavior but I had just never noticed it before and had never heard about it previously. So I tried another one-liner to perhaps prove that theory:

$ perl -MData::Dumper -le'@a=qw/a b c/; @foobar = @a[0..7]; print Dumper \@a'
$VAR1 = [
          'a',
          'b',
          'c'
        ];

Nope. Bug? Or expected behavior for some reason that I cannot figure out? This was on Perl 5.8.9

Diving into Reverse Engineering

Last year I read a blog entry (linked below) about a programmer who edited a component of Skype to fix a bug which was causing problems for many users. The blog entry then showed a very simple example of how to edit programs using OllyDbg without the source code. Even though I always knew the basic idea, I had never seen, or even searched for, any clear examples because I had no immediate need to know the details.

There is a MMORPG that I play on the weekends and recently there was discussion on our guild's forum about client tweaks. In the back of my mind, I knew I could probably apply a little reverse engineering to remove annoying art that clutters up the screen, change font colors to be easier on the eyes, and on top of that, maybe figure out how to fix a few bugs which we have been pushing the developers to fix for months, with no results. The problem was that I had no idea how to reverse engineer a program.

Of course, knowledge of how programs work and assembly language was required. Luckily the former was taught fairly well during my course at university, and although we were taught assembly language for the Motorola 68k processor, it never really clicked for me, or I never had an "ah hah!" moment with it and thus never did anything practical with that knowledge.

But now I did! So for the past ten days I have almost gone blind reading articles about reverse engineering and looking at assembly code.

Despite the moral questions, it has been a very interesting exercise and I'm happy that I've found a practical exercise for reverse engineering and assembly language that interests me. So far I've managed to fix one, semi-annoying bug and modified the layout to remove various things that get in the way of seeing what I'm trying to do/click on..

Below is a link to the initial blog entry that piqued my interest and some of the more useful resources I came across over the past ten days:

• Patching a Program Without Source Code: How to be like the Skype Hacker for Newbies
• Under the Hood: February 1998
• Under the Hood: June 1998
• x86 Win32 Reverse Engineering Cheat Sheet [PDF]