Jack Bishop is a young and impressive computer programmer fresh out of college and deeply in love with his medical doctor girlfriend, Catherine. He’d known for some time that the day would come when she would set off on her life’s dream to help the poorest of the poor, but when she boards that plane bound for Haiti leaving him behind to await her return, it leaves him feeling more than alone. It leaves him feeling empty. He desperately wants to find some way that he too can help, but how is a computer programmer – even one as talented and devoted as Jack – supposed to benefit the starving and sick poor?
Then one day the company’s security team approaches him about a programming problem and Jack becomes obsessed with learning everything he can about Trojans, and viruses, and IRC server channels. Partly he’s obsessed to fill the void Catherine left in his life, but soon the seed of a plan begins to germinate. Jack can use his new-found knowledge to build his own code – a code to help the charities that help in places like Haiti.
Part techno-drama, part instruction manual, The Hacktivist by R.J. Webster is a book with three agendas; entertain with a realistic cyber-crime story, educate the reader about the legitimate risks of surfing the web in today’s hacker-rich environment, and maybe – just maybe – inspire some people to throw a little scratch at such worthwhile charities as Doctors Without Borders and justgive.org.
As an instruction manual, it succeeds very well. The premises are complicated and highly math-based, but Webster explains the concepts in ways which are very accessible. As a techno-thriller it falls just a little flat. There are few real episodes of high tension or perceived danger. The characters are all believable but just a little one-note. Even the relationship between the counter-hero protagonist and his lady love is mostly seen in rough sketches and long distance emails. There are also a number of walk-on characters who are clearly there only to advance the tech-manual aspect, but they all seem to speak in the same voice using the same kinds of accessible verbal shorthand.
Additionally, a few side stories are introduced but don’t really go anywhere. In one episode, a Paris Hilton/Kim Kardashian-type celebrity is victimized by an early iteration of the virus, and vows to go on an O.J.-like quest for the “real” hacker, but nothing ever comes of it. Hints are dropped throughout the story that Jack’s dog, Argus, will somehow trip up Jack’s well-laid plans, but again, that plotline just sort of peters out.
The story also might have benefited from a few more true-life examples of Haitian suffering if the author really wanted to compel casual readers to action. A few asides into Catherine’s and her peers’ day-to-day lives might have accomplished that and added some genuine depth to her character.
There are clever flashes through the story, however. A very clever example which I really enjoyed involves an FBI agent who could use the PATRIOT Act to great advantage but decides to be a person instead. I don’t usually rate the stories I review, but in this case, I’m giving The Hacktivist an “A” as a learning tool, a “B” on the Sarah McLaughlin-style PSA, and a “C++” for the story and characters.
10% of the proceeds from this book will go to Partners in Health to help the poor in Haiti. The Hacktivist is available on Amazon for the Kindle.
Steve turned to John and explained, “Scheuerman’s been doing the dynamic reverse engineering of the bot and has been watching the most recent command and control server for us. You probably want to hear this too.”John waved Scheuerman in, “What have you got?”“Well, the C server sent out an update command, a major update. That is pretty normal, we were seeing updates about once every week or two for a while and then it went quiet for a few weeks and now this. The update command told the bot client to go to a website we have not seen used before. It then downloaded an executable file from there and ran it. As you know, we have one infected system that we are letting just do its thing so it went ahead and updated itself. Well after the update we watched it closely but it did nothing that we could detect. Nothing at all happened. It has stopped trying to communicate. It dropped out of the Command and Control server. The normal behavior was that it would stay connected to the chat room waiting for a command from the C. After this last update completed, it closed the connection and went silent. We have been watching it for over 24 hours now and it has done nothing at all.”John asked, “Did it shut itself down, or is the viral process still running on the computer?”Scheuerman told them that it was still running that they could still see the process running though it took quite a bit of effort. The rootkit made it difficult to detect this particular process by normal means.John turned to Steve, “Well what do you think, could it be laying low because it knows we’re watching somehow? We’ve seen that before, some logic that can detect a lab environment. Or do you think it might have a new way to communicate, maybe periodically instead of an up all the time connection?”They had all seen viruses that refused to run when in a monitored environment. There were tricks that viruses used to detect if they were running in a virtual environment or in a debug environment. Some viruses were simply smart enough to detect when they were running in the kind of testing environment that the police used to unravel a virus’s mysteries. When they found they were in such an environment, they would simply shut down or refrain from functioning. It was more and more common for a virus to check first to see if the coast was clear before running. And many debug environments are easy to detect. A debug program is a tool that can run another program inside of itself, controlling how it runs. It can allow an engineer to run a program, a virus in this case, one precise machine code command at a time if necessary, stepping through the program with incredible slowness in order to learn all the things that the malware might be capable of doing. Consider that CPU speeds are often measured in millions of instructions per second, MIPS, and with a debugger you can do them one at a time.Debugging a normal program wasn’t too hard if you understood machine code. Computer programs frequently make decisions from a set of available choices. They decide what they want to do next. The code might check its data and then choose a branch of code based on the data it sees. Some branches might never run if they don’t see the required data. When a program is run in a debugger by someone like Scheuerman, the investigator can force it to try every possible branch of execution to see all the possible things it might be capable of doing. The engineer can change the code of the program too. He can force data or commands into the program, he can basically lie to the program to force it to take each branch. But viruses these days are almost always encrypted in some way. They contained dummy logic and false paths of execution that led nowhere. Modern encrypted viruses might have lots of reverse engineering protections. They are often packed, that is compressed in some way, obfuscated and then encrypted. They only unencrypt themselves a little at a time. Often the only thing the investigator can see at first is a little bit of code in the beginning of the program which might contain jumps to seemingly random places in the virus file. Eventually, this jumping around process executes code to try to detect if it is being run in a lab. If the coast is clear, the virus can decrypt more of itself to memory and see if it is capable of running normally. If it is not, it leaves what’s left of its code encrypted and shuts down. Steve’s technical guys sometimes spent days removing protections or trying to understand the logic of obfuscated programs and then even more time trying to figure out how to decrypt them or convince them to decrypt themselves. What was worse no one wanted to do this kind of work forever so usually by the time someone got really good at it they wanted to move on to something else.