Posted by mgoodwin on Nov 04,2014

Building a WebRTC Robot

A child's mind (being free from such tiresome constraints as "not technically possible", "probably a bit dangerous" and "that'll be lots of hard work") is an excellent source of ideas and enthusiasm. I've seen many examples of this in recent years. One such example provided the starting point for this year's Mozfest adventure:

Child: "Next year, we should bring a robot."

Me: "A robot?"

Child: "A robot. With a camera. And a loudspeaker. That way it can ask people to help it with the lifts." (lift is britspeak for elevator)

More →

Posted by mgoodwin on Aug 15,2014

CSP: Inline Scripts in Static Content


I wrote a tool for generating hash-sources to make it easier to apply CSP to your static content.


CSP can be tricky to deploy, especially for sites that make use of inline scripts and styles. Also, sometimes people go to the effort of applying CSP to their web applications but forget to apply a CSP to static content on their websites; this can negate the benefit of CSP work done elsewhere (XSS on the same origin as you means you're XSSed whether you're using CSP or not).


The tool works by parsing documents using html5lib and generating hash-source values for script and style elements, as required.

E.g, do something like:

python --scripts --styles --htaccess --existing="img-src" files/*

to create an htaccess file containing a CSP based on the existing policy but with hash-sources for any scripts and styles in the specified files.

More →

Posted by mgoodwin on Aug 12,2014

3D Printing Tracked Vehicles - Making Tracks


Most people would agree that cheap 3D Printers are fun and exciting but there is a commonly held view that they're not really suitable for making useful things. We've been working on a robotics project that goes some way beyond most objects I've seen people print.


We wanted to build a robot lawnmower. It didn't take us too long to figure out you can't just go and buy parts for robot lawnmowers so we decided to build a 3D Printer (more on that another time) and make some.

More →

Posted by mgoodwin on Aug 01,2014

Gaia Hacking: some tips (part 1)

Over the past few weeks I've been doing a bit more with Firefox OS. While it's a fun platform to hack on with almost zero platform knowlege (it's just the web, mostly), it gets better with a few tips:

1) Use the Firefox Developer tools for certified apps:

It's possible to hack on gaia (the Firefox OS frontend) with just your text editor of choice and adb logcat - but you probably don't want to do that.

If you've tried writing your own WebApps for Firefox OS, you've probably come across the App Manager (if not, you should probably give it a try).

And heres the tip, you're not restricted to using App Manager for the apps you write; you can also debug certified apps by setting some prefs in your profile.

You can also enable this by default with a build option that we'll cover in a bit.

2) Use the Firefox Developer tools to debug the main process:

The above works for all applications on the device... but what if you want to get to bits of the actual runtime? Well you can do this too. Follow the same steps as above, but this time use Firefox with the pref set to true.

Connect to your device (using the App Manager) and on the Device screen, you'll see a "DEBUG MAIN PROCESS" button; click that and you can debug JSMs, run privileged JS in the scratchpad, accidentally destroy your device, etc.

3) Some convenient defaults

Running through the first time use setup every time you push a new version of gaia to a device can be a drag, and having to configure wifi, and setting the device to debug certified apps... and turn off the lockscreen, etc.

Setting some options when you build gaia saves many of these steps. E.g:

DEVICE_DEBUG=1 NOFTU=1 make reset-gaia

will keep your wifi settings, enable debugging of certified apps, disable the lockscreen, remove the prompt to accept debugger connections and turn off the first time use screen.

4) Use a proxy to inspect and manipulate HTTP / HTTPS traffic

Tools like Burp and ZAP have features which are useful if you're making or breaking stuff for the web. There's an MDN document describing one way of doing that here - but there's another way (yes, I'm going to update that article); Plug-n-Hack providers (like Burp, ZAP and some others) provide manifests containing information on how clients should configure themselves, including root certificates to install for TLS termination, etc.

This, combined with the 'debug main process' feature of the devtools, allows you to install your proxy's root cert onto your device by running some code from a scratchpad.

You can then connect to your proxy in one of two ways:

You can pull the default prefs from your device, change them to add the relevant proxy prefs, put them back.

Or, you could configure your tool to proxy HTTP and HTTPS transparently then set up iptables on your device to point to your proxy. E.g, to make HTTPS traffic go through your proxy tool:

adb shell iptables -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to-destination

And, to reset it when you're done:

adb shell iptables -t nat -F

But, if you find yourself doing this lots, there's a way that's even more conveient; set up a testing LAN where all traffic is proxied by default. This way, you can turn proxying on and off just by changing which wireless LAN you're connected to.

I built mine using a raspberry pi and steps similar to these. I changed the iptables rules to look like this:

:INPUT ACCEPT [49:3128]
:OUTPUT ACCEPT [37:3924]
-A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlan0 -o eth0 -j ACCEPT
-A PREROUTING -i wlan0 -p tcp -m tcp --dport 80 -j DNAT --to-destination <proxy_host>:<http_port>
-A PREROUTING -i wlan0 -p tcp -m tcp --dport 443 -j DNAT --to-destination <proxy_host>:<https_port>

my access point

More →

  • prev
  • 1
  • next