Category: Security

"Weaponized" Quadcopters

For a long time, I’ve been thinking it would be possible to strap a small explosively-formed penetrator (EFP) to a quadcopter. Then you feed the GPS coordinates of your enemy’s apartment or office into the on-board navigation system, and the quadcopter flies over to their place and fires a hypersonic slug of copper through their window.

Leaving aside the ethical concerns, there are a couple of issues with this. The main one for asymmetric warfare enthusiasts is that it destroys your quadcopter and leaves bits of it at the scene, which wastes resources and gives clues to whoever you were trying to shoot.

Then I saw this little post over at Hackaday. If you put a high wattage diode laser on a quadcopter, you can have it set fire to things. It could probably shoot through a glass window and set fire to things on the inside of the window. Once the place is nicely in flames, you just fly the ‘copter away again, leaving no trace.

So, about that re-distillation prevention on PDFs…

I got a PDF of my transcript from a university I used to attend. I won’t say which, but it’s in Salisbury and not very imaginatively named. The transcript had a variety of password-protection baloney on it, which I didn’t want.

Stripping the password is easy if you know it, because you can open the PDF in acrobat reader, select “print”, “print to file” and print to a postscript file (with a .ps extension). That removes the password protection, giving you a clear postscript file, which, in theory, you can distill back to PDF.

Unfortunately, the postscript file is marked as unredistillable (if that’s even a word). There is a fix for this, though: the exact opposite of what is described here.

Find the lines that say:

%ADOBeginClientInjection: DocumentSetup Start "No Re-Distill"
%% Removing the following eleven lines is illegal, subject to the Digital Copyright Act of 1998.
mark currentfile eexec
%ADOEndClientInjection: DocumentSetup Start "No Re-Distill"

and cut them out of the file. Yes, the file says this is illegal, and it might even be true, but that’s how it’s done.

Drinking with Robots

I am building a drink-dispensing robot. It has 5 pumps internally, so I want to find the set of five liquids that will produce the largest variety of mixed drinks. To do this, I’m going to need a huge set of drink recipes. I got a bunch from a cocktail database that esquire maintains, but the biggest list I’m aware of is The Webtender. Unfortunately, that database isn’t in a form that permits me to make queries to find out what is the maximal set of drinks that I can make, given the constraint of 5 liquid ingredients. So instead of the web interface, I want the raw data.

This means I want to download every single drink recipe from The Webtender. The URLs there are of the form, so the obvious thing to do would be to write up a little bash oneliner that just wgets each of the files in turn. It would probably look something like this:

for (( i=1; i <= 6217; i++ )); do wget$i; done 

But it may be that The Webtender issues a 403 Forbidden error if you use wget, probably to prevent just this sort of hijinks. Unfortunately for them, wget can be configured to claim to be something else. These instructions provide the config file to cause wget to claim to be Mozilla on Windows NT, which The Webtender should have no problem with.

For my next trick, I'll use BeautifulSoup to turn the HTML files from the webtender and Esquire into a SQL database, and probably perform some form of normalization on the data, such as making all the measurements be in the same units.

HTTP status codes

I was reading up on HTTP status codes, and I got a bad idea. There are a small number of official status codes, like the ubiquitous 404 (file not found), an even smaller number of less-official status codes, like 418 (I am a teapot), and a lot of undefined status codes.

So what happens if a browser gets an undefined status code? What if it gets a malformed code? Writing a simple test for this would be easy. It would just be a web app framework that returns whatever you pass it on the URL as the error code, so would get you HTTP OK, while would get you the undefined code 499.

I would hope that the browser runs the code past its short list of defined codes, doesn’t recognize it, and shows an error page to the user saying something like “The server returned an invalid error message. It may be misconfigured. Please try back later.”

However, some browsers may mishandle the message, and hand anything that starts off with, say, 2xx to the page renderer, whereupon things might go horribly awry. I hope modern browsers are immune to this sort of shenanigans, but it may be no one has beaten on them in that particular way.