A few weeks ago I wrote about software development and hacking, and this is a loose follow-up. The image of hackers presented in films – Swordfish is a fair example, or GoldenEye – is of rather scruffy individuals who type incredibly quickly with keyboard at arms length, undeterred by all kinds of enticing distractions around them.
But most often, a successful hack is the result of careful analysis into some existing code, and a good dollop of insight into what kinds of precautions developers forget to take. In that, it shares a great deal in common with my own trade of QA. Effective software testing is not really about repeating hundreds of test cases which regularly pass – there are automated ways of dong those – it’s about finding the odd situations where proper execution fails. This might be because some developer has copied and pasted the wrong code, but it’s much more often because some rare but important set of circumstances was overlooked.
Missing values, extra-long pieces of text, duplicate entries where only one was expected, dates in weird formats – all these and many more keep us QA folk in work. And problems can creep in during the whole life of a product, not just at the start, Every time some change is carried out to a piece of software, there is the risk of breaking some existing behaviour, or introducing some new vulnerability which can be exploited by somebody.
It has been said that a great many of these things persist through laziness. One particular hack exploit – “SQL injection” – has been around for something over 15 years, in essentially unchanged form. You would think that by now, defences would be so automatic that it would no longer be an issue. But it is, and systems still fall prey to a relatively simple trick. I have worked with a lot of different computer languages, and find that pretty much the same problems turn up in any of them. As computer languages get more sophisticated and more robust, we expect them to do more interesting and more complicated things,
QA and hacking are at different parts of a spectrum, and a fair proportion of hackery goes on specifically to help firms and charities find weaknesses in their own systems. The legal distinction of when an activity crosses a line has to do with intention of malice, though a number of governments take a much stricter line where there own systems are concerned.
What has this to do with fiction? Well, Mitnash and Slate spend a lot of their time tracking down and defending against hacking in the area of finance. Their added complication is that the physical locations they travel to are scattered all around the solar system, with journey times of weeks or months, and signal times of hours. It is interesting to think about how hacking – and the defence against it – might evolve in such a situation.
In Timing, due for release in the late summer or early autumn, they are first sent to Jupiter to resolve a minor issue. It doesn’t seem very interesting or important to them. But then a much larger and more serious matter intrudes. To their dismay, the hackers – malicious ones in this case – have designed a new form of attack which our two heroes don’t really understand. They need help, and aren’t very sure they can trust their new-found helper.
To finish with, I can’t resist adding one of NASA’s pieces of artwork concerning the Juno probe, now successfully in orbit around Jupiter. It’s a great achievement, and we can look forward to some great science emerging from it.
