For the last year and a bit, I’ve been using a SteelSeries Arctis Pro Wireless Headset for
gaming and talking to friends. It’s a fine headset, but because there’s an always-on receiver there’s no way to
detect if the headset is turned on or not from the desktop.
Whenever I start using the headset, I set my desktop’s sound to go to the headset, and then when I stop using
the headset I set it to go back to speakers. It doesn’t take more than a second, but some days I might put the
headset on a dozen times as I’m on calls, or if it’s noisy outside, etc. That means it’s probably worth at least a few hours of my time trying to automate it.
At first, I hoped I’d be able to tell from the state of the USB device whether there was a headset connected
but nothing at all changed when flipping it on and off. Then I went hunting for existing open source tools that
might work with it and found that while people have reverse engineered many of the older Arctis headsets, no one
has done the same for the Pro Wireless. I finished off with a search to see if anyone had documented the wire
protocol even if there was no nice open source software to go with it; I came up short there, too. Looks like I’d
have to do it myself.
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…
