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.
How to break everything by fuzz testing
Published on Apr 26, 2020
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.
An introduction to containers
Published on Mar 1, 2020
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 Kotlin code with ProGuard
Published on Oct 21, 2019
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…
Debugging beyond the debugger
Published on May 8, 2019
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.