I’ve decided that it’s time to launch Life 2.0 and actually get serious about my career and put more effort in to achieving some of my other goals.
I’ve been interested in reverse engineering malware since I taught myself 8086/8088 assembly language and bought what was probably my first I.T. book — The New Peter Norton Programmer’s Guide to The IBM PC & PS/2 (by Peter Norton and Richard Wilton, 2nd edition (C) 1988) — because it documented the ROM BIOS software interrupts that the Stoned virus was using. The book had an appendix at the end to talk about MS-DOS v4.0!
The Stoned virus had infected some of the school computers, but it was reasonably benign (it would occasionally print something along the lines of ‘Your PC is now stoned’ instead of booting) and I was curious as to what made it tick and how it spread.
I later had the pleasure of coming across the Michelangelo virus, which also infected some of the school computers, but it had more sinister motives. The Michelangelo virus used BIOS interrupt 0x1a to read the date from the real-time clock (it was checking for the 06th March), but it had a bug in that it didn’t actually check if the call succeeded. On the 06th March, it would start formatting hard disk sectors.
After discovering that these (boot block/MBR) viruses were spreading by ‘hooking’ BIOS interrupt 0x13 (disk services) — installing their own interrupt 0x13 handler which would infect the boot block of the disk being accessed before passing control to the real BIOS interrupt 0x13 handler — I developed some boot code of my own.
My boot code simply stored a copy of the original (clean) interrupt vectors (a table that specified the memory addresses of the various interrupt handlers) on disk, and checked it against the memory copy of the interrupt vectors. If a boot block virus was resident and hooking interrupts, my boot code would detect the modified interrupt vectors, restore them (so that the memory resident virus would no longer get control), and copy itself back to the MBR (Master Boot Record), thus cleaning the disk.
This was all nice and dandy, except it wouldn’t have worked if the virus knew of my boot code, as it would have been too easy to check for it and skip it, so it was a good theoretical exercise that wouldn’t have worked in practice (or not for long anyway).
I then came across file infecting viruses which, unlike most of today’s malware, would actually write their own code in to an existing executable file (usually .com files because there were more of them back then, and it was harder to modify a .exe file because of its headers and what not). File infecting viruses also used interrupt hooking, only with MS-DOS’ interrupt 0x21.
This curiosity and interest in viruses then naturally lead to an interest in #DFIR (Digital Forensics and Incident Response) — a way of keeping the mind busy by determining how viruses and malware managed to infect a system, and what they did once they had — but being employed as a UNIX system administrator wasn’t exactly allowing me to do much in the way of forensics/reverse engineering work, especially of Windows binaries!
That’s when I started doing forensics/reverse engineering as a ‘hobby’ by deliberately dangling a poor defenceless MS-Windows box out on an unprotected Internet link to see what happened. I’d wait for it to get infected (which generally didn’t take long back then), and then examine the system, any malicious files, and the network packets (to learn how shellcode — short snippet of code originally designed to start a shell on the target host — worked).
Things were progressing slowly, as I still had my UNIX admin day-job, so needless to say I jumped at a chance to use some credit my then employer had with SANS, by doing the SANS 508: Computer Forensics, Investigation, and Response (as it was back then).
Things still progressed slowly, as I wasn’t getting much time to do #DFIR work other than at home as a hobby, until, that is, I ended up resigning from my job so that I could head overseas to see a terminally ill relative who hadn’t been given much longer to live.
Upon returning from the trip, I was jobless. This was good though, as I suddenly had a lot more time to do #DFIR work, so I saw it as a chance to build my #DFIR skills up — something which I needed to do because malware, Windows, and, as it turned out, analysis techniques had advanced somewhat while I’d been busy doing other things. The only downside was that I wasn’t being paid to do it — something which, given I still had a mortgage, was eventually going to put a bit of a damper on the fun.
Now, if i was going to build my skills up I was going to need some malware to look at, so I built a virtual ‘lab’, set up a honeynet, and started this blog — that was just a couple of days past seven years ago now — to document my journey and to help any other budding malware analysts/forensic enthusiasts to learn with (or after) me.
The trouble is, I was still trying to analyse malware the way I’d always done it since the Stoned virus — loading it in to a debugger (ah, good old ‘debug.exe’!), disassembling it, and working out what it was doing from the disassembly, which is obviously a pretty slow process. I also noticed how long that process was taking me, and saw the rate at which my honeypot was collecting samples, and figured that I needed a better way.
So I bought some books, started reading, did some Internet searches, and discovered that malware analysis had also advanced somewhat while I’d been busy doing other things.
One of the advances that I discovered was that of a scriptable debugger (I think one of the books mentioned it) — winappdbg by Mario Vilas — so then when I noticed the same pattern of behaviour amongst a number of different malware samples — namely ‘unpacking’ code — I created my unpacking script, which would automatically save a copy of the unpacked code, along with some information about the location of the unpacking loop and the entry point of the unpacked code. You can read my introductory post for it, a follow-up post, and also a series on what it can tell you about CryptoLocker.
I’ve since added a number of features to my unpacking script — I need to tidy up a bit and push them to my github repository.
So, like I said, I’ve decided that it is time to launch what I’m calling ‘Life 2.0’, and get serious about pursuing a #DFIR career so that I can free up my non-work time for work like beekeeping and trying to convince vegetables to grow, and more traditional hobbies like music (I have a band performance at a major local sporting event in a few weeks and I’m not getting the time to practice — something which, if our last rehearsal is anything to go by, I really need to do!), unicycling, kayaking, and geocaching.
There are other goals that I’m not getting the time to achieve because I’m working full time as a security engineer and having to work on forensics and reverse engineering in my personal time. Goals like arranging music, maybe even composing some music, writing a book, remaking a movie, improving my cooking skills, doing some self-supported unicycle tours (including a charity ride), setting up large-scale vegetable production to help contribute toward a secure food supply, and general IT tinkering (which was how I started reversing malicious software).
Forensics and reverse engineering are work that I enjoy doing, something that I have been wanting to do for a very long time, and something that I want to be really good at.
I think I’m at a point in my career that’s comparable to the final year project in a university course — I’ve gained a lot of knowledge, and gained a lot of experience, now I want to see what I can do with it all.
