Anyone who has a Raspberry Pi and an old Nintendo has had the same thought. “Maybe I could shove the Pi in here?” This ran through [Adam’s] head, but instead of doing the same old Raspberry Pi build he decided to put a Nexus Player inside of this old video game console, with great success. Not only does it bring the power of a modern media player, it still works as an NES.
If you haven’t seen the Nexus Player yet, it’s Google’s venture into the low-cost home media center craze. It has some of the same features of the original Chromecast, but runs Android and is generally much more powerful. Knowing this, [Adam] realized it would surpass the capabilities of the Pi and would even be able to run NES emulators.
[Adam] went a little beyond a simple case mod. He used a custom PCB and an Arduino Pro Micro to interface the original controllers to the Nexus Player. 3D printed brackets make sure everything fits inside the NES case perfectly, rather than using zip ties and hot glue. He then details how to install all of the peripherals and how to set up the Player to run your favorite game ROMs. The end result is exceptionally professional, and brings to mind some other classic case mods we’ve seen before.
When [Steve] received a notice from Google that a new owner had been added to his Google Search Console account, he knew something was wrong. He hadn’t added anyone to his account. At first he thought it might be a clever phishing tactic. Maybe the email was trying to get him to click a malicious link. Upon further investigation, he discovered that it was legitimate. Some strange email address had been added to his account. How did this happen?
When you want to add a website to Google’s services, they require that you prove that you own the actual website as a security precaution. One method to provide proof is by uploading or creating an HTML file to your website with some specific text inside. In this case, the file needed to be called “google1a74e5bf969ded17.html” and it needed to contain the string “google-site-verification: googlea174e5bf969ded17.html”.
[Steve] logged into his web server and looked in the website directory but he couldn’t find the verification file. Out of curiosity, he tried visiting the web page anyways and was surprised to find that it worked. After some experimentation, [Steve] learned that if he tried to load any web page that looked like “googleNNNNNNN.html”, he would be presented with the corresponding verification code of “google-site-verification: googleNNNNNNNN.html”. Something was automatically generating these pages.
After further investigation, [Steve] found that some malicious PHP code had been added to his website’s index.php page. Unfortunately the code was obfuscated, so he couldn’t determine exactly what was happening. After removing the new code from the index.php file, [Steve] was able to remove the hacker’s email address from [Steve’s] Google account.
This is a very interesting hack, because not only did it allow this one hacker to add himself to [Steve’s] Google account, but it would also have allowed anyone else to do the same thing. This is because each new hacker would have been able to fool Google’s servers into thinking that they had uploaded the verification file thanks to the malicious PHP code. It makes us think that perhaps Google’s verification system should use a separate randomized string inside of the verification file. Perhaps one that can’t be guessed or calculated based on known variables such as the file name.
Dr. Robert Hecht-Nielsen, inventor of one of the first neurocomputers, defines a neural network as:
“…a computing system made up of a number of simple, highly interconnected processing elements, which process information by their dynamic state response to external inputs.”
These ‘processing elements’ are generally arranged in layers – where you have an input layer, an output layer and a bunch of layers in between. Google has been doing a lot of research with neural networks for image processing. They start with a network 10 to 30 layers thick. One at a time, millions of training images are fed into the network. After a little tweaking, the output layer spits out what they want – an identification of what’s in a picture.
The layers have a hierarchical structure. The input layer will recognize simple line segments. The next layer might recognize basic shapes. The one after that might recognize simple objects, such as a wheel. The final layer will recognize whole structures, like a car for instance. As you climb the hierarchy, you transition from fast changing low level patterns to slow changing high level patterns. If this sounds familiar, we’ve talked out about it before.
Now, none of this is new and exciting. We all know what neural networks are and do. What is going to blow your mind, however, is a simple question Google asked, and the resulting answer. To better understand the process, they wanted to know what was going on in the inner layers. They feed the network a picture of a truck, and out comes the word “truck”. But they didn’t know exactly how the network came to its conclusion. To answer this question, they showed the network an image, and then extracted what the network was seeing at different layers in the hierarchy. Sort of like putting a serial.print in your code to see what it’s doing.
They then took the results and had the network enhance what it thought it detected. Lower levels would enhance low level features, such as lines and basic shapes. The higher levels would enhance actual structures, such as faces and trees. This technique gives them the level of abstraction for different layers in the hierarchy and reveals its primitive understanding of the image. They call this process inceptionism.
Be sure to check out the gallery of images produced by the process. Some have called the images dream like, hallucinogenic and even disturbing. Does this process reveal the inner workings of our mind? After all, our brains are indeed neural networks. Has Google unlocked the mind’s creative process? Or is this just a neat way to make computer generated abstract art.
So here comes the big question: Is it the computer chosing these end-product photos or a google engineer pawing through thousands (or orders of magnitude more) to find the ones we will all drool over?
The technique is deceptively simple. Dynamic RAM is organized into a matrix of rows and columns. By performing fast reads on addresses in the same row, bits in adjacent rows can be flipped. In the example image to the left, fast reads on the purple row can cause bit flips in either of the yellow rows. The Project Zero team discovered an even more aggressive technique they call “double-sided hammering”. In this case, fast reads are performed on both yellow rows. The team found that double-sided hammering can cause more than 25 bits to flip in a single row on a particularly vulnerable computer.
Why does this happen? The answer lies within the internal structure of DRAM, and a bit of semiconductor physics. A DRAM memory bit is essentially a transistor and a capacitor. Data is stored by charging up the capacitor, which immediately begins to leak. DRAM must be refreshed before all the charge leaks away. Typically this refresh happens every 64ms. Higher density RAM chips have forced these capacitors to be closer together than ever before. So close in fact, that they can interact. Repeated reads of one row will cause the capacitors in adjacent rows to leak charge faster than normal. If enough charge leaks away before a refresh, the bit stored by that capacitor will flip.
Cache is not the answer
If you’re thinking that memory subsystems shouldn’t work this way due to cache, you’re right. Under normal circumstances, repeated data reads would be stored in the processor’s data cache and never touch RAM. Cache can be flushed though, which is exactly what the Project Zero team is doing. The X86 CLFLUSH opcode ensures that each read will go out to physical RAM.
Wanton bit flipping is all fine and good, but the Project Zero team’s goal was to use the technique as an exploit. To pull that off, they had to figure out which bits they were flipping, and flip them in such a way as to give elevated access to a user level process. The Project Zero team eventually came up with two working exploits. One works to escape Google’s Native Client (NaCL) sandbox. The other exploit works as a userspace program on x86-64 Linux boxes.
Native Client sandbox escape exploit
Google defines Native Client (NaCL) as ” a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user’s operating system.” It was designed specifically as a way to run code in the browser, without the risk of it escaping to the host system. Let that sink in for a moment. Now consider the fact that rowhammer is able to escape the walled garden and access physical memory. The exploit works by allocating 250MB of memory, and rowhammering on random addresses, and checking for bit flips. Once bit flips are detected, the real fun starts. The exploit hides unsafe instructions inside immediate arguments of “safe” institutions. In an example from the paper:
Viewed from memory address 0x20EA0, this is an absolute move of a 64 bit value to register rax. However, if we move off alignment and read the instruction from address 0x20EA02, now it’s a SYSCALL – (0F 05). The NaCL escape exploit does exactly this, running shell commands which were hidden inside instructions that appeared to be safe.
Linux kernel privilege escalation exploit
The Project Zero team used rowhammer to give a Linux process access to all of physical memory. The process is more complex than the NaCL exploit, but the basic idea revolves around page table entries (PTE). Since the underlying structure of Linux’s page table is well known, rowhammer can be used to modify the bits which are used to translate virtual to physical addresses. By carefully controlling which bits are flipped, the attacking process can relocate its own pages anywhere in RAM. The team used this technique to redirect /bin/ping to their own shell code. Since Ping normally runs with superuser privileges, the shell code can do anything it wants.
Rowhammer is a nasty vulnerability, but the sky isn’t falling just yet. Google has already patched NaCL by removing access to the CLFLUSH opcode, so NaCL is safe from any currently known rowhammer attacks. Project Zero didn’t run an exhaustive test to find out which computer and RAM manufacturers are vulnerable to rowhammer. In fact, they were only able to flip bits on laptops. The desktop machines they tried used ECC RAM, which may have corrected the bit flips as they happened. ECC RAM will help, but doesn’t guarantee protection from rowhammer – especially when multiple bit flips occur. The best protection is a new machine – New RAM technologies include mitigation techniques. The LPDDR4 standard includes “Targeted Row Refresh” (TRR) and “Maximum Activate Count” (MAC), both methods to avoid rowhammer vulnerability. That’s a good excuse to buy a new laptop if we ever heard one!
When you think of a doorbell, you typically don’t think of anything very complicated. It’s a button that rings a bell inside your home. That’s about it. [Ahmad] decided he wanted to turn his doorbell up to eleven (Google Doc) with this build. Using a Raspberry Pi, he was able to cram in loads of features.
When the doorbell button is pressed, many different events can be triggered. In the demo video, [Ahmad] shows how his phone receives a text message, and email, and a tweet. The system can even be configured to place a voice call via Google Hangouts using a USB microphone. [Ahmad] demonstrates this and shows how the voice call is placed almost instantly when the button is pressed. This may be a bit overkill, but it does demonstrate many different options depending on your own needs.
For the hardware side of things, [Ahmad] purchased a wireless doorbell. He opened up the ringer unit and hooked up the speaker wires to a couple of pins on the Raspberry Pi through a resistor. The doorbell unit itself is powered off of the 3.3V supply from the Pi. The Pi also has a small LCD screen which shows helpful information such as if the Internet connection is working. The screen will also display the last time and date the doorbell was pressed, in case you weren’t home to answer the door.
On top of all of that, the system also includes a Raspberry Pi camera module. This allows [Ahmad] to take a photo of the person ringing the doorbell as a security measure. He can even view a live video feed from the front door by streaming directly to YouTube live. [Ahmad] has provided a link to his Pi image in the Google Doc so others can use it and modify it as they see fit. Continue reading “Raspberry Pi Doorbell is Fully Featured”→
It’s been a little while since we’ve heard about modular smartphones, but Google has just released the Module Developers Kit (MDK) for Project Ara. The development kit gives an overview of the inner workings of the project, and provides templates for building your own modules.
Once you’ve agreed to the license agreement and downloaded the MDK, you’ll find a large specification document. It explains how a phone will comprise of many modules loaded into an endoskeleton, giving mechanical support and electrical connections. An interface block provides each module with power and data over LVDS. Modules are held in place by an electro-permanent magnet which can be toggled by software.
When you’re finished with the specification document, you can dive into the reference designs. These include templates and actual modules for WiFi, thermal imaging, a battery pack, and more. Mechanical CAD is provided as STEP files and drawings, and electrical design files are provided as Altium projects and PDF schematics.
We discussed both Project Ara and Phonebloks on Hackaday in the past, but now we’re starting to see real details. Google’s Project Ara Developer Conference takes place on April 15th and 16th, and you can register to take part remotely for free. Is this the start of an open, modular phone? Let us know what you think.
To validate that the website you’re visiting is actually who they claim to be, your browser ensures that the certificate presented by the server you’re accessing was signed by a trusted CA. When someone requests a certificate from a CA, they should verify the identity of the person making the request. Your browser, and operating system, have a set of ultimately trusted CAs (called root CAs). If the certificate was issued by one of them, or a intermediate CA that they trust, you will trust the connection. This whole structure of trust is called a Chain of Trust.
With a forged certificate, you can convince a client that your server is actually http://www.google.com. You can use this to sit between a client’s connection and the actual Google server, eavesdropping their session.
In this case, an intermediate CA did just that. This is scary, because it undermines the security that we all rely on daily for all secure transactions on the internet. Certificate pinning is one tool that can be used to resist this type of attack. It works by associating a host with a specific certificate. If it changes, the connection will not be trusted.
The centralized nature of TLS doesn’t work if you can’t trust the authorities. Unfortunately, we can’t.