The HTC Dream, the first phone released running Android.
For the past decade I’ve exclusively used Android phones. I got the HTC Dream (aka the T-Mobile G1) shortly
after it came out, and dutifully upgraded every 1-2 years. In that timespan I used Android as the basis for my
Master’s Thesis, took a job on the Android team at Google, and eventually became a contractor specialising in
Android app development. So when I switched to using an iPhone earlier this year a few people were surprised.
The good old days
When Android was announced in 2007 – alongside the formation of the Open Handset Alliance – it was positioned
as a bastion of openness: it would be built on open standards and the operating system would be open source. At
the time iPhones were strongly coupled to iTunes and Apple was exercising strict control over what app developers
could do.
Fuzz testing is a bit like the infinite monkey theorem, but instead of Shakespeare you get crashes.
Fuzz testing, if you’re not aware, is a form of testing that uses procedurally generated random inputs to see
how a program behaves. For instance, if you were fuzz testing a web page renderer you might generate a bunch of
HTML - some valid, and some not - and make sure the rendering process didn’t unexpectedly crash.
Fuzz testing doesn’t readily lend itself to all types of software, but it particularly shines in cases where
some kind of complex user input is accepted and processed in some way - like the aforementioned web page
renderer. I was recently adding a library to parse EXIF data to images to an Internet-facing service and realised
it was a perfect opportunity to do some fuzz testing. Even if I didn’t find any issues, I’d improve my confidence
that the library was safe enough to expose to the Internet.
Breaking my EXIF library
I wrote a quick harness to run go-fuzz on the library, and
gave it some pre-existing demo files as sample input. The way go-fuzz works is that it instruments your code and
then mutates the inputs to try to improve the coverage. For example, if I had some sample data that had an EXIF
tag with a value of 1 then go-fuzz might change it to a 2 and see if the code follows a different path. In most
cases it won’t but when it does, they tend to be very interesting cases.
I’m a huge fan of (software) containers. Most people I know fall in to one of two camps: either they also use,
and are fans of, containers, or they haven’t yet really figured them out and view them as some kind of voodoo
that they don’t really want or need.
I’m writing this short guide to explain a little how containers work - and how running something in a
container isn’t really that much different to running it normally - to hopefully enable more people in that
second group to give them a try. It’s aimed at people who have a fairly good grasp of how Linux works.
Containers are often mentioned in the same breath as VMs, which is not a helpful comparison or analogy. Think
of containers as standard units of software, much like how Intermodal containers are standard units of freight
transport across the world. When a company internationally ships goods in volume there isn’t a question about how
they’re packaged - they go in an intermodal container. The same container can be deployed on a freight train, a
lorry, or a ship. The haulage company doesn’t need to care what’s in the container because they’re completely
standardised. Likewise, with software containers you don’t really need to care about what’s inside: the software
you’re deploying could be written in Go, Python2, Python3, Bash, PHP, LOLCODE, or anything.
Obfuscating code is the process of modifying source code or build output in order to make it harder for humans
to understand. It’s often employed as a tactic to deter reverse engineering of commercial applications or
libraries when you have no choice but to ship binaries or byte code. For Android apps, ProGuard is part of the default toolchain and obfuscation
is usually only a config switch away.
I was recently working on an Android library written in Kotlin that my client wanted obfuscated to try and
protect some of their trade secrets that were included. Not a problem, I thought: it’s just a few lines of
ProGuard config and we’re away. Four hours and lots of hair pulling later I finally got it working…
Most programming – and sysadmin – problems can be debugged in a fairly straight forward manner using logs,
print statements, educated guesses, or an actual debugger. Sometimes, though, the problem is more elusive.
There’s a wider box of tricks that can be employed in these cases but I’ve not managed to find a nice overview of
them, so here’s mine. I’m mainly focusing on Linux and similar systems, but there tend to be alternatives
available for other Operating Systems or VMs if you seek them out.
Networking
tcpdump
tcpdump prints out descriptions of packets on a network interface. You can apply filters to limit
which packets are displayed, chose to dump the entire content of the packet, and so forth.
