7 August, 2018

Geohashing expedition 2018-08-07 51 -1

This checkin to geohash 2018-08-07 51 -1 reflects a geohashing expedition. See more of Dan's hash logs.

Dan cycling to a hashpoint. — Setting out by bike to the hashpoint.

Overgrown footpath. — This footpath is less overgrown than I feared it might turn out to be.

Dan in a field. — The first field I found myself in was – just about – navigable by a (pushed) bicycle.

Dan's bike by a narrow footbridge over a dyke. — But eventually my bike had to be left behind and I carried on alone.

Dan at geohashpoint 2018-08-07 51 -1. — Success! Silly grin engaged as I stand at the hashpoint.

First field on the geohash expedition. — The fields had recently been harvested of their corn.

Panorama around hashpoint 2018-08-07 51 -1. — It’s a whole lot of fields (panoramic photograph).

Surprise gasometer — On the way home, I spotted a gasometer and photographed/filmed it for my US friends (they’re even rarer in the US than here)!

Gasometer entry gate — For obvious reaosns, they don’t let idiots like me get up-close with enormous containers full of flammable gas, even when (like this one) they’re actually empty.

Screenshot from Geohashing app showing hashpoint reached — Success! Because I didn’t EXPECT to be hashing today, I didn’t have my GPSr and so didn’t make a tracklog, but my phone managed to get me there.

Location

A field South of Oxford

Participants

Dan Q

Plans

My meeting this afternoon got cancelled and my nearest hashpoint is only 6.5km (4 miles) away from my office. I can get this!

Expedition

After a productive morning’s work, I was genuinely slightly disappointed that a meeting I was scheduled to have this afternoon had to be rescheduled. But on the other hand… that meant that I could get away with extending my lunch break slightly and getting out to the hashpoint! I’d initially worried that it’d be inaccessibly buried on private land when Google Maps and satellite photography showed it to be deep in a block of cornfields, but OpenStreetMap came to the rescue and showed a public footpath somewhere in the very close vicinity of the target coordinates. And so, jumping aboard my bike, I set out!

600m from the coordinates I ran out of road and switched to the footpath, which I was pleased to discover was in reasonably-good condition: many underused local footpaths are not being very well-maintained at the moment and are often overgrown, but I was even able to bring my bike along this one and into the first field, although I had to push it rather than ride and I soon learned the error of my ways when the terrain got even rougher and I reached a narrow bridge – too narrow for my bike – spanning a dyke and entering the second field. Both fields had recently been cleared of corn, and whatever route the official footpath was supposed to take became rapidly unclear, but that’s probably for the best because I’m pretty sure I wasn’t on it by the time I reached the edge of the next field.

The hashpoint seemed to be along the fence somewhere so I followed it along – waving to some nearby cows – until my phone told me that I was under 3m from the spot. Hurrah! I snapped a panorama photo and started heading back, pausing a few times when I realised that I really, really couldn’t find where I’d left my bike. On the cycle home I passed a Gasometer which, because I’m told they’re super-rare in the USA, I thought I’d snap a picture of for those of you who ‘hash on the other side of the pond to oggle at.

Video

I actually remembered to shoot video of this expedition (well, all within a kilometre of the hashpoint and mostly within the last 350 metres!). It’s mostly just me rambling as I ramble, although there’s (brief) explanation of the Surprise Gasometer for those of you who live in countries where you don’t routinely see these interesting structures:

Photos

2018-08-07 51 -1 Geohashing Expedition

Read the full hashlog report and see photos.

Also available on YouTube and on QTube.

Intercepting HTTPS Traffic from Android Emulator

Mostly for my own benefit, as most other guides online are outdated, here’s my set-up for intercepting TLS-encrypted communications from an emulated Android device (in Android Emulator) using Fiddler. This is useful if you want to debug, audit, reverse-engineer, or evaluate the security of an Android app. I’m using Fiddler 5.0 and Android Studio 2.3.3 (but it should work with newer versions too) to intercept connections from an Android 8 (Oreo) device using Windows. You can easily adapt this set-up to work with physical devices too, and it’s not hard to adapt these instructions for other configurations too.

1. Configure Fiddler

Install Fiddler and run it.

Under Tools > Options > HTTPS, enable “Decrypt HTTPS traffic” and allow a root CA certificate to be created.

Click Actions > Export Root Certificate to Desktop to get a copy of the root CA public key.

On the Connections tab, ensure that “Allow remote computers to connect” is ticked. You’ll need to restart Fiddler after changing this and may be prompted to grant it additional permissions.

If Fiddler changed your system proxy, you can safely change this back (and it’ll simplify your output if you do because you won’t be logging your system’s connections, just the Android device’s ones). Fiddler will complain with a banner that reads “The system proxy was changed. Click to reenable capturing.” but you can ignore it.

2. Configure your Android device

Install Android Studio. Click Tools > Android > AVD Manager to get a list of virtual devices. If you haven’t created one already, create one: it’s now possible to create Android devices with Play Store support (look for the icon, as shown above), which means you can easily intercept traffic from third-party applications without doing APK-downloading hacks: this is great if you plan on working out how a closed-source application works (or what it sends when it “phones home”).

In Android’s Settings > Network & Internet, disable WiFi. Then, under Mobile Network > Access Point Names > {Default access point, probably T-Mobile} set Proxy to the local IP address of your computer and Port to 8888. Now all traffic will go over the virtual cellular data connection which uses the proxy server you’ve configured in Fiddler.

Drag the root CA file you exported to your desktop to your virtual Android device. This will automatically copy the file into the virtual device’s “Downloads” folder (if you’re using a physical device, copy via cable or network). In Settings > Security & Location > Encryption & Credentials > Install from SD Card, use the hamburger menu to get to the Downloads folder and select the file: you may need to set up a PIN lock on the device to do this. Check under Trusted credentials > User to check that it’s there, if you like.

Test your configuration by visiting a HTTPS website: as you browse on the Android device, you’ll see the (decrypted) traffic appear in Fiddler. This also works with apps other than the web browser, of course, so if you’re reverse-engineering a API-backed application encryption then encryption doesn’t have to impede you.

3. Not working? (certificate pinning)

A small but increasing number of Android apps implement some variation of built-in key pinning, like HPKP but usually implemented in the application’s code (which is fine, because most people auto-update their apps). What this does is ensures that the certificate presented by the server is signed by a certification authority from a trusted list (a trusted list that doesn’t include Fiddler’s CA!). But remember: the app is running on your device, so you’re ultimately in control – FRIDA’s bypass script “fixed” all of the apps I tried, but if it doesn’t then I’ve heard good things about Inspeckage‘s “SSL uncheck” action.

Summary of steps

If you’re using a distinctly different configuration (different OS, physical device, etc.) or this guide has become dated, here’s the fundamentals of what you’re aiming to achieve:

Set up a decrypting proxy server (e.g. Fiddler, Charles, Burp, SSLSplit – note that Wireshark isn’t suitable) and export its root certificate.
Import the root certificate into the certificate store of the device to intercept.
Configure the device to connect via the proxy server.
If using an app that implements certificate pinning, “fix” the app with FRIDA or another tool.