Program Your Brain, Hack Your Way to Productivity

Most people wish they were more productive. Some buckle down and leverage some rare facet of their personality to force the work out. Some of them talk with friends. Some go on vision quests. There are lots of methods for lots of types of people. Most hackers, I’ve noticed, look for a datasheet. An engineer’s reference. We want to solve the problem like we solve technical problems.

It's got the cover equivalent of click-bait, but the centimeter thick bibliography listing research sources at the back won me over.
It’s got the cover equivalent of click-bait, but the centimeter thick bibliography listing research sources at the back won me over.

There were three books that gave me the first hints at how to look objectively at my brain and start to hack on it a little. These were The Power of Habit by Charles Duhigg, Flow By Mihaly Csikszentmihalyi, and Getting Things Done By David Allen.

I sort of wandered into these books in a haphazard path. The first I encountered was The Power of Habit which I found to be a bit of a revelation. It presented the idea of habits as functions in the great computer program that makes up a person. The brain sees that you’re doing a task over and over again and just learns to do it. It keeps optimizing and optimizing this program over time. All a person needs to do is trigger the habit loop and then it will run.

For example: Typing. At first you either take a course or, if your parents left you alone with a computer for hours on end, hunt-and-peck your way to a decent typing speed. It involves a lot of looking down at the keyboard. Eventually you notice that you don’t actually need to look at the keyboard at all. Depending on your stage you may still be “t-h-i-n-k-i-n-g”, mentally placing each letter as you type. However, eventually your brain begins to abstract this away until it has stored, somewhere, a combination of hand movements for every single word or key combination you typically use. It’s only when you have to spell a new word that you fall back on older programs.

Continue reading “Program Your Brain, Hack Your Way to Productivity”

Bridging the Air Gap; Data Transfer via Fan Noise

When you want to protect a computer connected to the Internet against attackers, you usually put it behind a firewall. The firewall controls access to the protected computer. However, you can defeat any lock and there are ways a dedicated attacker can compromise a firewall. Really critical data is often placed on a computer that is “air gapped.” That is, the computer isn’t connected at all to an insecure network.

An air gap turns a network security problem into a physical security problem. Even if you can infect the target system and collect data, you don’t have an easy way to get the data out of the secure facility unless you are physically present and doing something obvious (like reading from the screen into a phone). Right? Maybe not.

Researchers in Isreal have been devising various ways to transmit data from air walled computers. Their latest approach? Transmit data via changing the speed of cooling fans in the target computer. Software running on a cellphone (or other computer, obviously) can decode the data and exfiltrate it. You can see a video on the process below.

Continue reading “Bridging the Air Gap; Data Transfer via Fan Noise”

Continuing The Dialog: “It’s Time Software People and Mechanical People Had a Talk”

A while back I wrote a piece titled, “It’s Time the Software People and Mechanical People Sat Down and Had a Talk“. It was mostly a reaction to what I believe to be a growing problem in the hacker community. Bad mechanical designs get passed on by what is essentially digital word of mouth. A sort of mythology grows around these bad designs, and they start to separate from science. Rather than combat this, people tend to defend them much like one would defend a favorite band or a painting. This comes out of various ignorance, which were covered in more detail in the original article.

There was an excellent discussion in the comments, which reaffirmed why I like writing for Hackaday so much. You guys seriously rock. After reading through the comments and thinking about it, some of my views have changed. Some have stayed the same.

It has nothing to do with software guys.

being-wrong-quoteI definitely made a cognitive error. I think a lot of people who get into hardware hacking from the hobby world have a beginning in software. It makes sense, they’re already reading blogs like this one. Maybe they buy an Arduino and start messing around. It’s not long before they buy a 3D printer, and then naturally want to contribute back.

Since a larger portion of amateur mechanical designers come from software, it would make sense that when I had a bad interaction with someone over a design critique, they would be end up coming at it from a software perspective. So with a sample size too small, that didn’t fully take into account my positive interactions along with the negative ones, I made a false generalization. Sorry. When I sat down to think about it, I could easily have written an article titled, “It’s time the amateur mechanical designers and the professionals had a talk.” with the same point at the end.

Though, the part about hardware costs still applies.

I started out rather aggressively by stating that software people don’t understand the cost of physical things. I would, change that to: “anyone who hasn’t designed a physical product from napkin to market doesn’t understand the cost of things.”

Continue reading “Continuing The Dialog: “It’s Time Software People and Mechanical People Had a Talk””

The Dark Arts: Cross Site Scripting

In 2011, a group of hackers known as Lulzsec went on a two month rampage hacking into dozens of websites including those owned by FOX, PBS, the FBI, Sony and many others. The group was eventually caught and questioned in how they were able to pull off so many hacks. It would be revealed that none of the hackers actually knew each other in real life. They didn’t even know each other’s real names. They only spoke in secluded chat rooms tucked away in a dark corner of the internet and knew each other by their  aliases – [tFlow], [Sabu], [Topiary], [Kayla], to name a few. Each had their own special skill, and when combined together they were a very effective team of hackers.

It was found that they used 3 primary methods of cracking into websites – SQL injection, cross-site scripting and remote file inclusion. We gave a basic overview of how a SQL injection attack works in the previous article of this series. In this article we’re going to do the same with cross-site scripting, or XSS for short. SQL injection has been called the biggest vulnerability in the history of mankind from a potential data loss perspective. Cross-site scripting comes in as a close second. Let’s take a look at how it works.

XSS Scenario

Let us suppose that you wanted to sell an Arduino on your favorite buy-and-sell auction website. The first thing to do would be to log into the server. During this process,  a cookie from that server would be stored on your computer. Anytime you load the website in your browser, it will send that cookie along with your HTTP request to the server, letting it know that it was you and saving you from having to log in every time you visit. It is this cookie that will become the target of our attack.

You would then open up some type of window that would allow you to type in a description of your Arduino that potential buyers could read. Let’s imagine you say something like:

Arduino Uno in perfect condition. New in Box. $15 plus shipping.

You would save your description and it would be stored on a database in the server. So far, there is nothing out of the ordinary or suspicious about our scenario at all. But let’s take a look at what happens when a potential buyer logs into the server. They’re in need of an Arduino and see your ad that you just posted. What does their browser see when they load your post?

Arduino Uno in perfect condition. <b>New in Box</b>. $15 plus shipping.

Whether you realize it or not, you just ran HTML code (in the form of the bold tags) on their computer, albeit harmless code that does what both the buyer and seller want – to highlight a specific selling point of the product. But what other code can you run? Can you run code that might do something the buyer surely does not want? Code that will run on any and every computer that loads the post? Not only should you be able to see where we’re going with this, you should also be able to see the scope of the problem and just how dangerous it can be.

Now let us imagine a Lulzsec hacker is out scoping for some much needed lulz. He runs across your post and nearly instantly recognizes that you were able to run HTML code on his computer. He then makes a selling ad on the website:

Lot of 25 Raspberry Pi Zeros - New in Box - < script src="" ></script> - $100, free shipping.

Now as soon as someone opens up the hacker’s ad, the script section will load up the malicious off-site code and steal the victim’s session cookie. Normally, only the website specified in a cookie has access to that cookie. Here, since the malicious code was served from the auction website’s server, the victim’s browser has no problem with sending the auction website’s cookie. Now the hacker can load the cookie into his browser to impersonate the victim, allowing the hacker access to everything his victim has access to.

Endless Opportunities

With a little imagination, you can see just how far you can reach with a cross-site scripting attack. You can envision a more targeted attack with a hacker trying to get inside a large company like Intel by exploiting a flawed competition entry process. The hacker visits the Intel Edison competition entry page and sees that he can run code in the application submission form. He knows someone on the Intel intranet will likely read his application and guesses it will be done via a browser. His XSS attack will run as soon as his entry is opened by the unsuspecting Intel employee.

This kind of attack can be run in any user input that allows containing code to be executed on another computer. Take a comment box for instance. Type in some type of < script >evil</script> into a comment box and it will load on every computer that loads that page. [Samy Kamkar] used a similar technique to pull off his famous Myspace worm as we talked about in the beginning of the previous article in this series. XSS, at one time, could even have been done with images.

Preventing XSS attacks

As with SQLi based attacks, almost all website developers in this day and age are aware of XSS and take active measures to prevent it. One prevention is validating input. Trying to run JavaScript in most applications where you should not be will not only give you an error, but will likely flag your account as being up to no good.


One thing you can do to protect yourself from such an attack is to use what is known as a sandboxed browser. This keeps code that runs in a browser in a “box” and keeps the rest of your computer safe. Most modern browsers have this technology built in. A more drastic step would be to disable JavaScript entirely from running on your computer.

There are people here that are far more knowledgeable than I on these type of hacking techniques. It was my hope to give the average hardware hacker a basic understanding of XSS and how it works. We welcome comments from those with a more advanced knowledge of cross-site scripting and other website hacking techniques that would help to deepen everyone’s understanding of these important subjects.


XSS Flash animation 1

XSS Flash animation 2

The Dark Arts: SQL Injection and Secure Passwords

As the year of 2005 was drawing to a close, a website known as Myspace was basking in popularity. With millions of users, the site was the most popular social networking site in the world. It was unique in that it let users use HTML code to customize their Myspace page. Most of us, c’mon…admit it….had a Myspace page. The coding part was fun! But not everything was changeable with code. You could only upload up to 12 images and the Relationship Status drop-down menu only had a few options to choose from. These limitations did not sit well with [Samy Kamkar], a 19 year old hacker out of Los Angeles.


It didn’t take [Samy] long to figure out how to trick the site to let him upload more images and change his relationship status to a customized “in a hot relationship”. After hoodwinking the Myspace site with some simple hacks, he realized he could do just about anything he wanted to with it. And this is where things get interesting. It took just over a week to develop a script that would force people who visited his page to add him as a friend. But that wasn’t enough. He then programmed the script to copy itself onto the visitor’s page. [Samy] had developed a self-propagating worm.

The script went live as [Samy] went to bed. He woke up the next morning with 200 friends requests. An hour later the number had doubled. [Samy] got worried and sent an anonymous email to the webmaster warning of the worm. It was ignored. By 1:30PM that day, he had over 6,000 friends request. And like any good hacker worth his weight in floppy drives, his sense of humor had him program the script to also add his name to each visitor’s Heroes List. This angered many people, who deleted him from their page, only to get reinfected moments later when they visited another (infected) page.

[Samy’s] script was raging out of control.  As the evening closed in, his friends count had reached 919,664. It would top the 1 million mark just before Myspace took their servers offline to figure out what was going on. Two hours later, the site was back up. [Samy’s] profile page had been deleted.

[Samy] had used a technique known as cross-site scripting (XSS) to pull off his hack. We’ll touch on XSS in a later article. For now, we’re going to stick to the basics – proper passwords and SQL Injection.

Continue reading “The Dark Arts: SQL Injection and Secure Passwords”

It’s Time the Software People and Mechanical People Sat Down and Had a Talk.

With the advances in rapid prototyping, there’s been a huge influx of people in the physical realm of hacking. While my overall view of this development is positive, I’ve noticed a schism forming in the community. I’m going to have to call a group out. I think it stems from a fundamental refusal of software folks to change their ways of thinking to some of the real aspects of working in the physical realm, so-to-speak. The problem, I think, comes down to three things: dismissal of cost, favoring modularity over understanding, and a resulting insistence that there’s nothing to learn.

Continue reading “It’s Time the Software People and Mechanical People Sat Down and Had a Talk.”

Frackers: Inside the Mind of the Junk Hacker

Hackers can be a diverse bunch. My old hackerspace had folks ranging from NSA employees (ahem, independent security contractors) to space-probe pilots to anarchist vegan punks. And we all got along because we shared a common love for what we’re doing. One summer night we were out late in Adams Morgan and my vegan-punk friend reaches into the trash can and pulls out a discarded pepperoni Jumbo Slice.

“Wait a minute! Vegans don’t eat pepperoni pizza with cheese.” But my friend was a “freegan” — a vegan who, for ethical reasons, won’t buy meat or milk but who also won’t turn it down if it’s visibly going to waste. It’s actually quite a practical and principled moral proposal if you think about it: he’s not contributing to the use of animals that he opposes, but he gets to have a slice of pizza just the same. And fishing a slice of pizza, in a cardboard container, off the top of the trashcan isn’t as gross as you’d imagine, although it pays to be picky.

A Fracker is Born

That was the night that we realized we all had something deeper in common: we were all “frackers”. If you’ve been around hackers long enough, you’ll have noticed this tendency, but maybe you’ve never put a name to it. Tearing something apart, even if you might break it in the process, isn’t a problem if you fished it out of the e-waste stream to begin with. If you’re able to turn it into something, so much the better. It’s all upside. Need practice de-soldering tricky ICs? Looking for a cheap target to learn reverse engineering on? Off to the trashcan! No hack is too dirty, no method too barbaric. It’s already junk, and you’re a fracker.

internet_radio_wrt54g-shot0008_featuredDo you have a junk shelf where you keep old heatsinks in case you need to cut some up and use it? Have you used a heat gun more frequently for harvesting parts than for stripping paint? Do you know that certain satisfaction that you get from pulling some old tech out of the junk pile and either fixing it up again or, better yet, making it do something else? You might just be a fracker too.

Continue reading “Frackers: Inside the Mind of the Junk Hacker”