Sometimes you need to hack on the go. [Supertechguy] has put together an interesting system for hacking on the hoof called the Pineapple Pi. This combines a Raspberry Pi 3 with a seven-inch touchscreen and a Hak 5 WiFi Pineapple into a handy portable package that puts all of the latest WiFi and ethernet hacking tools to hand. The package also includes a 20,100 mAh battery, so you won’t even need a wall socket to do some testing. It’s a bit of a rough build — it is held together with velcro, for instance — but it’s a good place to start if you are looking to make a portable, standalone system for testing WiFi networks.
Scotty Allen has a YouTube blog called Strange Parts; maybe you’ve seen his super-popular video about building his own iPhone “from scratch”. It’s a great story, and it’s also a pretext for a slightly deeper dive into the electronics hardware manufacturing, assembly, and repair capital of the world: Shenzhen, China. After his talk at the 2017 Superconference, we got a chance to sit down with Scotty and ask about cellphones and his other travels. Check it out:
The Story of the Phone
Scotty was sitting around with friends, drinking in one of Shenzhen’s night markets, and talking about how bizarre some things seem to outsiders. There are people sitting on street corners, shucking cellphones like you’d shuck oysters, and harvesting the good parts inside. Electronics parts, new and used, don’t come from somewhere far away and there’s no mail-ordering. A ten-minute walk over to the markets will get you everything you need. The desire to explain some small part of this alternate reality to outsiders was what drove Scotty to dig into China’s cellphone ecosystem.
Inside every modern CPU since the Intel Pentium
fdiv bug, assembly instructions aren’t a one-to-one mapping to what the CPU actually does. Inside the CPU, there is a decoder that turns assembly into even more primitive instructions that are fed into the CPU’s internal scheduler and pipeline. The code that drives the decoder is the CPU’s microcode, and it lives in ROM that’s normally inaccessible. But microcode patches have been deployed in the past to fix up CPU hardware bugs, so it’s certainly writeable. That’s practically an invitation, right? At least a group from the Ruhr University Bochum took it as such, and started hacking on the microcode in the AMD K8 and K10 processors.
The hurdles to playing around in the microcode are daunting. It turns assembly language into something, but the instruction set that the inner CPU, ALU, et al use was completely unknown. [Philip] walked us through their first line of attack, which was essentially guessing in the dark. First they mapped out where each x86 assembly codes went in microcode ROM. Using this information, and the ability to update the microcode, they could load and execute arbitrary microcode. They still didn’t know anything about the microcode, but they knew how to run it.
So they started uploading random microcode to see what it did. This random microcode crashed almost every time. The rest of the time, there was no difference between the input and output states. But then, after a week of running, a breakthrough: the microcode XOR’ed. From this, they found out the syntax of the command and began to discover more commands through trial and error. Quite late in the game, they went on to take the chip apart and read out the ROM contents with a microscope and OCR software, at least well enough to verify that some of the microcode operations were burned in ROM.
The result was 29 microcode operations including logic, arithmetic, load, and store commands — enough to start writing microcode code. The first microcode programs written helped with further discovery, naturally. But before long, they wrote microcode backdoors that triggered when a given calculation was performed, and stealthy trojans that exfiltrate data encrypted or “undetectably” through introducing faults programmatically into calculations. This means nearly undetectable malware that’s resident inside the CPU. (And you think the Intel Management Engine hacks made you paranoid!)
[Benjamin] then bravely stepped us through the browser-based attack live, first in a debugger where we could verify that their custom microcode was being triggered, and then outside of the debugger where suddenly
xcalc popped up. What launched the program? Calculating a particular number on a website from inside an unmodified browser.
He also demonstrated the introduction of a simple mathematical error into the microcode that made an encryption routine fail when another particular multiplication was done. While this may not sound like much, if you paid attention in the talk on revealing keys based on a single infrequent bit error, you’d see that this is essentially a few million times more powerful because the error occurs every time.
The team isn’t done with their microcode explorations, and there’s still a lot more of the command set left to discover. So take this as a proof of concept that nearly completely undetectable trojans could exist in the microcode that runs between the compiled code and the CPU on your machine. But, more playfully, it’s also an invitation to start exploring yourself. It’s not every day that an entirely new frontier in computer hacking is bust open.
Anyone who has spent much time reading Hackaday, or in the real world in or around a few hackspaces, will know that ours is a community of diverse interests. In the same place you will find a breathtaking range of skills and interests, people working with software, electronics, textiles, and all conceivable materials and media. And oftentimes in the same person: a bare-metal kernel guru might spend their time in a hackspace making tables from freight pallets rather than coding.
Through it all run a variety of threads, identities if you will, through which the differing flavours of our wider community define themselves. Words like “Hacker” and “Maker” you may identify with, but when I mention words like “Crafter” or “Artist”, perhaps they might meet with some resistance. After all, artists paint things, don’t they, and crafters? They make wooly hats and corn dollies! Continue reading “Art, Craft, Make, Hack, Whatever”
In the waning hours of 2010, a hacking group known as Lulzsec ran rampant across the Internet, leaving a path of compromised servers, a trail of defaced home pages, leaked emails, and login information in their wake. They were eventually busted via human error, and the leader of the group becoming an FBI informant. This handful of relatively young hackers had made a huge mess of things. After the digital dust had settled – researches, journalists, and coders began to dissect just how these seemingly harmless group of kids were able to harness so much power and control over the World Wide Web. What they found was not only eye-opening to web masters and coders, but shined a light on just how vulnerable all of our data was for everyone to see. It ushered in an era of renewed focus on security and how to write secure code.
In this Dark Arts series, we have taken a close look at the primary techniques the Luzsec hackers used to gain illegal access to servers. We’ve covered two them – SQL injection (SQLi) and cross-site scripting (XSS). In this article, we’ll go over the final technique called remote file inclusion (RFI).
DISCLAIMER: Fortunately, the surge of security-minded coding practices after the fall of Lulzsec has (for the most part) removed these vulnerabilities from the Internet as a whole. These techniques are very dated and will not work on any server that is maintained and/or behind a decent firewall, and your IP will probably get flagged and logged for trying them out. But feel free to set up a server at home and play around. Continue reading “The Dark Arts – Remote File Inclusion”
Hardware hacking is a way of life here at Hackaday. We celebrate projects every day with hot glue, duct tape, upcycled parts, and everything in between. It’s open season to hack hardware. Out in the world, for some reason software doesn’t receive the same laissez-faire treatment. “Too many lines in that file” “bad habits” “bad variable names” the comments often rain down. Even the
unsafest silliest of projects isn’t safe. Building a robot to shine lasers into a person’s eyes? Better make sure you have less than 500 lines of code per file!
Why is this? What makes readers and commenters hold software to a higher standard than the hardware it happens to be running on? The reasons are many and varied, and it’s a trend I’d like to see stopped.
Software engineering is a relatively young and fast evolving science. Every few months there is a new hot language on the block, with forums, user groups, and articles galore. Even the way software engineers work is constantly changing. Waterfall to agile, V-Model, Spiral model. Even software design methodologies change — from pseudo code to UML to test driven development, the list goes on and on.
Terms like “clean code” get thrown around. It’s not good enough to have software that works. Software must be well commented, maintainable, elegant, and of course, follow the best coding practices. Most of these are good ideas… in the work environment. Work is what a lot of this boils down to. Software engineers have to stay up to date with new trends to be employable.
There is a certain amount of “born again” mentality among professional software developers. Coders generally hate having change forced upon them. But when they find a tool or system they like, they embrace it both professionally, and in their personal projects. Then they’re out spreading the word of this new method or tool; on Reddit, in forums, to anyone who will listen. The classic example of this is, of course, editors like the vi vs emacs debate.
We all know that what we mean by hacker around here and what the world at large thinks of as a hacker are often two different things. But as our systems get more and more connected to each other and the public Internet, you can’t afford to ignore the other hackers — the black-hats and the criminals. Even if you think your data isn’t valuable, sometimes your computing resources are, as evidenced by the recent attack launched from unprotected cameras connected to the Internet.
As [Elliot Williams] reported earlier, Trustwave (a cybersecurity company) recently announced they had found a backdoor in some Chinese voice over IP gateways. Apparently, they left themselves an undocumented root password on the device and — to make things worse — they use a proprietary challenge/response system for passwords that is insufficiently secure. Our point isn’t really about this particular device, but if you are interested in the details of the algorithm, there is a tool on GitHub, created by [JacobMisirian] using the Trustwave data. Our interest is in the practice of leaving intentional backdoors in products. A backdoor like this — once discovered — could be used by anyone else, not just the company that put it there.