Friday, April 14, 2006

Why Perl?

I haven't actually been asked this question yet, but I'm anticipating it...why Perl? Why am I using Perl for the RAM dump parsing tools, and not C, Java, or C#?

Well, first of all, Perl is pretty ubiquitous...it's everywhere. Perl is not only used for system administration, but for Web-based (CGI) interfaces, and a wide variety of other activities. Perl is used in security projects such as The SleuthKit, the MetaSploit Framework, and used extensively throughout my book and the Real Digital Forensics book.

Perl is great as a quick prototyping tool. Starting from scratch, or by using some code you've already got, you can put together a tool for performing a specific task, and run it quickly. If there are any errors (yes, I know I need to use "-w" more), you can quickly open the file up, locate the error and fix it. As Perl is an interpretted language, you don't have to rebuild/recompile the script...you can run it as soon as you make modifications and save them.

Perl is pretty easy to read...when compared to other languages. I like to comment my code, and will sometimes have more comments in a script than I have lines of code. Perl is also a great educational tool, as you can clearly walk through your script, and show were different things are done; open files, write to a file, access an API, close a file, etc.

One other thing I like about Perl is that because Perl is available on other (Mac, Linux, etc.) systems besides just Windows (yeah, imagine that!), with a little care (predominantly toward endianness) the script I write on Windows can be run on those other platforms. What this means is that a forensic analyst isn't restricted to performing analysis of a Windows system on a Windows system. So, if you dump the contents of physical memory to a file and you're analyzing that file on a Linux system (or if you're Jesse Kornblum, on a Mac), then you're not stuck and restricted to only tools written for that platform. The same is true if you're analyzing an image of a Windows system, and you're on Linux.

Now, if you are on Windows and don't want to install Perl, I try to provide standalone executables of the Perl scripts via Perl2Exe or PAR. These aren't really executables in the sense of a C/C++ file compiled in to a PE file, but more of the Perl script wrapped up the Perl interpreter. So, the EXE files will be larger than a "normal" EXE.

As with my last post, I hope this makes sense.

1 comment:

Ryan Sommers said...

I use a number of languages in my everyday life; anything from Perl, C/C++, Awk, Java, etc. I view a language as a tool. No single language is The Programming Language; and I think language zealots tend to miss the boat on that. Different languages are suited for different tasks. Perl is very useful for writing quick scripts to do a specific task when speed isn't necessarily a factor. However, Perl isn't well suited for every task.

Speed is my biggest complaint. A quick search on Google yielded the following result http://furryland.org/~mikec/bench/. The page appears to contain a nice comparison between a few language. No amount of just-in-time compiling or other interpreted optimizations can compete with a compiled application. In the end, for me, speed is the biggest reason I don't use Perl for more tasks. It just can't compare to optimized C/C++.

I find the argument that Perl is a very readable language to be very odd. Perl is one of the most difficult languages to read. There are so many legal syntaxes. You can legally write: print "this is a test", or print("this is a test"). Misuse of these quickly leads to poor readability. Worse many of these syntaxes are not shared by other languages; which makes it more difficult for newcomers. I always found things like references in Perl to be very arcane compared to other reference/value paradigms. Or the fact that changing the $ @ or % can have catastrophic results.

People always want to point to the portability argument. I disagree. I’ve written software that compiles and runs equally well on any UNIX/Linux distribution and even Windows. And there are plenty of open source projects out there that achieve the same thing. The key to writing portable code in a compiled language isn’t the language but understanding the platform differences and using properly set levels of abstraction. These of course can be overcome with a virtual machine ala Java or .NET or an interpreter ala Perl or PHP. However, performance will suffer. But you have to remember, all modern (UNIX, Linux, Mac) Operating Systems are built on compiled languages.

An article I found at http://www.garshol.priv.no/download/text/perl.html points out these issues and more.