Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Back in the day, there was a device called the TV Guardian. The idea was that captions and spoken word with foul language could be removed from a stream in real time using this device. How does this actually work? Ben Eater takes apart the device to find out!

They reverse engineer the board to get a good idea of what each chip does. From there, the author removes an EEPROM chip from the board by removing a large amount of the solder then using a hot air gun to pull off the chip. Dead bug debugging time!

They find the documentation for this specific chip and begin trying to understand how it works. While reading the docs, the author is unsure what addressing mode it is using. However, by looking at the traces on the PCB where the chip was at, pins 5-7 are all connected! This tells us that the 8-bit memory organization is set and the the program enable pin is disabled.

The author puts the chip onto a breadboard and hooks up the pins. First, they connect GND and power to the proper locations. After that, they connect the Memory Organization Pin and Program Enable Pin to ground, just as it was on the actual board. Finally, they hook up the reminder SPI interface pins to GPIO pins on an Arduino.

Ben writes up an implementation of the protocol in an Arduino sketch, but this could also be done via a standard EEPROM reader too. This is done by reading the documentation and putting the GPIO pins high and low at specific times to emulate the SPI interface. For a read command, the opcode 10 is sent, followed by an 11 bit address. Following this, the chip will send back 8 bits of data.

Simply writing to the GPIO lines with the protocol implemented will simulate the SPI interface. In order to make this work, we have to make sure the Serial timing is correct. Luckily for us, since we are now the controller, we control the clock rate and how fast data is sent out.

After running this and using a hexdump, a bunch of words appear! In particular, most of them are obscene words that children shouldn't be hearing. After the bad words was a list of good words, likely used for the replacements.

However, the format was a little weird. Each word was followed by a small value (0, 1 or 2) then a larger byte. The author throws all of the data into a spreadsheet then analyzes what the bytes actually mean. Excel has some pretty powerful functions for quickly testing stuff!

In the list of words, some of the phrases are explicitly allowed. The author noticed that all words with a 1 in the 6th most significant bit were allowed. Secondly, there are exactly 32 replacement words - which can be represented in 5 bits. The final 5 bits of the strange byte are an index for the replacement words. For instance, ass goes to tail.

The most significant bit is always set. The 2nd most significant bit determines if the word is ONLY restricted in strict mode or not, such as religious things or butt. There are still some things that Ben doesn't understand about the format though.

Overall, awesome post showing off the capabilities of an Arduino, dumping memory and pattern matching. Thanks for all of the work Ben!

Recently, the author of this post received an Arcade cabinet as a gift. Different cabinets have emulators for different older consoles, such as NES, Atari and many others.

The physical device had already been torn down, allowing other ROMs being played. The author was curious what the actual ROM looked for the games looked like. So, they started reviewing the board for the different components.

On the board, next to the chip with the emulator on it, is a Winbond 25Q16VNIQ SPI FLASH chip. This is a super standard chip with a standard SPI FLASH interface, off the shelf tools can be used to communicate with this chip.

First, they hooked up an Arduino. They wrote a super simple SPI implementation to send read commands via the GPIO pins. However, this took a ton of time and had many faults in it.

The second go was using the swiss army knife tool Bus Pirate. There is an open source tool called FlashROM that can be used to extract EEPROM memory. The SPI flash interface is universal as well.

The author hooked up a SOIC clip onto the SPI flash chip. Then, they mapped the pins from the clip onto the bus pirate for SPI. From there, simply using the flashroom interface with the bus pirate configuration dumps the memory!

At the very end, they open up the blob in a hex editor to view the dump of the Rampage NES rom. They compare it to the actual Rampage NES rom. The ROM is included twice on the chip for a backup method. Overall, good post from a solid hardware hacker.

The PHP info page is used for displaying information about the current installation. Normally, this is considered a low information disclosure finding.

A mitigation for Cross Site Scripting (XSS) is using the HTTPOnly flag on cookies. This prevents the cookie from being used in JavaScript directly. Since session information is commonly stored in cookies, this prevents the stealing of the cookie.

The PHP Info page outputs a ton of information about the environment. The weird one to me is that the HTTP_COOKIE field can contain HTTPOnly only cookies!

Now, an XSS bug can make a request to the PHP info page in order to get the cookies reflected in the request. This allows for the stealing of HTTPOnly cookies, which is a huge deal in the context of web exploitation. In particular, the PHP session cookie PHPSESSID can be stolen.

Overall, a context dependent HTTPOnly bypass within PHP by chaining a normal low severity issue.

Here's the problem statement: "Retrieve an article from Wikipedia without revealing which article was fetched." Although this seems impossible, the article demonstrates how to do this using homomorphic encryption.

I don't understand all of the math and things here. Storing in my notes to read about later if a solution for a client is required.

The Renesas R7F701381 is a microcontroller for safety critical applications. It contains a second core with a lockstep core (runs instructions in parallel) to check the first core. Additionally, the instruction cache and RAM has ECC as well. Even though the chip has read out protection, the author wants to bypass this on the chip.

Renesas chip supports a two wire protocol that can be hooked up with a 5V USB-TTL cable. In order to enable debug mode, a pin needs to be pulled high. However, there was an external watchdog to prevent this was happening. The watchdog would pull the reset line low in order to reset the chip whenever the debug mode was entered. So, the author of the post added a 100 ohm resistor to the 5V line to overpower the watchdog.

While in the debug mode, the author tried to connect via the flash programmer for the chip put got an error message from the flasher. Instead of moving on, they decided to analyze the protocol and see if it was the tool deciding it was done or if a custom implementation of the protocol could bypass the protections. The hooked up a logic analyzer and read through documentation of other chips to see what was going on.

The documentation of a different chip gave the author a good insight: the command waiting phase is the only location where the device checks if the programmer is allowed. If this stage could be skipped then we would be allowed to use the programmer. Since there was no direct vulnerability in the implementation, the author turned to fault injection.

Fault injection is the act of causing the CPU to behave strangely by forcing it outside the normal ranges of operation. For instance, changing the operating voltage, clock frequency or adding in electromagnetic signals. The authors choice was to perform a voltage glitch on the power circuit of the device to modify the course of the program. In particular, they decided to glitch the portion where the synchronize command was being received and checking if debugging was enabled.

The datasheet shows a block diagram of the power supply circuit. Inside of the CPU core, there an internal 1.25 voltage regular. To stabilize this, an external pin is attached to a capacitor (VCL). This pin is where the author decided to put the glitch at, since the stability would be affected.

Since the RH850 is used for safety critical operations there is a second core being used. As a result, there is a VCL pin for each core! So, the idea was to remove the capacitors for each of these pins to prevent the smoothing out and glitch these cores at the same moment! By doing this, the cores won't go out of sync.

The author hooked up an N-FET switch for each of the cores, along with a Raspberry Pi Pico to actually perform the glitching. The Pi would drop the voltage for very small time intervals on the GPIO, which was super controllable. Additionally, the author had reimplemented the protocol with a Python script. Upon each glitch, they would check to see if the debug protocol was returning successfully. After a day of finding the proper parameters, they had a successful debug mode! Each attempt after this only takes 5 to 30 minutes, since we know the parameters now.

With this memory can be read out to dump the entire firmware! This was a complete bypass of the functionality in place. Afterwards, they attempted the glitch on ONLY one of the pins. For whatever reason, only glitching the main core works as well, which doesn't make sense to the author. Overall, great post on fault injection which really gets into the interesting details of it.

Transparency, Consent and Control (TCC) is a feature for privacy protection in Apple products. A user has to explicitly allow access to particular folder and files via authentication in order to prevent arbitrary applications from accessing sensitive data.

The directory ~/Library/Application Support/MobileSync/Backup is protected by TCC since backups contain photos, contacts and other things. However, using the built in utility AppleMobileBackup to make a backup at a custom location completely bypass the TCC check. The service has Full Disk Access rights, apparently, which allows it to write/read to this location without consideration.

The bypass was initially fixed by removing the --root flag from the utility in order to prevent the custom mounting of a directory for the backup. This came with some problems though.

The stupid bypass is copying the binary from Monterey and rerunning it. Since it still has the flag and is likely signed, it works fine. Second, the utility DeviceLink has the capability of setting the root directory, allowing for the choosing of the mount point still. The author didn't verify these were fixed properly though.

The author completely forgot their SIM pin on their phone. Since they were tired, they forgot the PIN 3 times and had to use the PUK code to unlock the device in order to get it to work again. They used this, set a new PIN code and all was good. Or was it?

Upon the fresh boot the fingerprint icon was showing instead of a lock screen PIN or a password to decrypt the device. Is this real life? After coming across this anomaly as a hacker, they decided they had to replicate this issue. They played around with variations of what they had done. Turn off the phone, change SIM... until they found something that was consistent.

The attack goes as follows:

1. Force the phone to require a SIM card PIN code.
2. Replace the SIM card in the phone toin order to know the SIM code.
3. Use phone SIM code incorrectly 3 times.
4. Enter in the SIM code.
5. Lock screen is bypassed!

The bug had already been reported to Google but couldn't be reproduced. After showing this to a Google engineer at a bug bounty conference, they decided to reward this engineer with the bounty since the issue was now reproducible. How does a bug come across like this? Surprisingly, this was a very complicated fix.

When a security screen (password entry screen, SIM PIN, etc.) is rendered, it is essentially put onto a stack of devices on top of each other. When a security screen was done, it would call the dismiss() function to get rid of the current screen. But, this was vulnerable to a race condition. Something in the background was changing current screen state to the original, while the dismiss() call would remove the new current screen!

By entering in only the one PIN code for the SIM, it would sometimes bypass the lock screen PIN as well. A pretty crazy bug! In order to fix this, the calls to dismiss() are now targeted at a particular screen and not generic. For instance, you would dismiss the SIM PUK screen instead of the screen in general.

Overall, great write up with a fun story to tell! To me, takeaways are be observant and look into weird things that happen. Second, be persistent, as you may get the bounty if you provide more service than the other hacker.

Mark of the Web (MOTW) is used on Windows to say if something was downloaded from the internet. For executables, zip files and other things, this is an important thing to mitigate many attack vectors. In practice, browsers will add an Alternate Data Stream (ADS) named Zone Identifier.

The author noticed a video on Twitter demonstrating a vulnerability where a downloaded zip file was not getting the MOTW flag. One of these was tricky using other file extensions that use zip under the hood (APK, ISO, etc.) and the other was simply a zip file. Microsoft had let the 90 day deadline pass so the video was posted. The author of this post wondered - can I replicate this?

From the video, the extraction bug ONLY occurs when explorer.exe is doing the handling. Additionally, from the video, the zip file itself has the MOTW but the extracted files do not. By looking at hooks and functions being executed, the author found the function ExtractFromZipToFile() within the DLL zipfldr.dll.

To find out what function was responsible for the MOTW functionality, they reverse engineered things and NOPed out a few function calls. From doing this, they noticed that if the function CheckUnZippedFile was skipped then the MOTW flag wouldn't be added to the files. So, how do we skip this function or bypass the flag adding?

The author attempts to trigger errors via weird characters, long file names and other things in order to bypass the flag adding to the files. Since none of these worked, the author found a live sample of this bypass and reverse engineered the sample.

Reverse engineering the sample led them down a rabbit hole of different functions. Eventually, when they found Alice, they came out of it with an interesting note: the files that were not getting flagged were marked as Read Only. Since the flag is technically writing to the file, the flag writing would occur with an access denied error.

The bug turned out to be very simple but required a good understanding of zip and Windows Internals. Overall, a good writeup with some good Windows reverse engineering tips.

The TRACE method is used for debugging applications. When a request is made with this method, it will send the full request with the specified verb and reflect this in the response.

The HTTPOnly cookie flag makes the cookie inaccessible from JavaScript. This is to prevent XSS from causing even worse damage, such as getting auth cookies.

What happens when we put these together? If a request was made with TRACE, then the cookie with the HTTPOnly flag would be sent back in the response, bypassing the protection. As a result, TRACE and TRACK were banned from browser requests. But, this was years ago.

This vulnerability is a variation of the HTTPOnly bypass. Instead of simply making a request via TRACE and TRACK, we can force the verb to change on the server-level. There is a non-standard but common header called X-HTTP-Method-Override.

Using the header will bypass the original security protection and send back the HTTPOnly cookie in the response. Pretty good blast from the past on this one!

Cache poisoning vulnerabilities are typically complicated and hard to come by. This author found a load of them and put them together in a single post.

The first issue is a problem with a load balancer. While checking for gathered emails, the author noticed a JavaScript file that contained an email that was not theirs - but had no idea why. After some testing, they noticed this only happened when a particular cookie was removed. It's like the load balancer was caching the file per user but sent back the most recent one if the request didn't have the cookie. This issue was used to salvage a large list of emails from the site.

Another load balancer issue was the result of a shallow copy vs. a deep copy. It turned out that once per hour that a caching bug occurred that led to an email leakage. Weird!

The final bug started off as hunting for XSSI issues. One of the JavaScript files was constantly changing information in it. This file contained authorization information for each user. What could go wrong with this?

The author deleted all of their cookies of the request still went through! But how? The URL had several other parameters, such as the location and other things, but they weren't random. It turned out that the CDN was caching these JS files! By brute forcing the loc parameter, it became possible for an attacker to steal auth information. Pretty neat!

A few things to look out from this:

• Are emails or IDs what you expect them to be?
• Test out how the caching is being done. Remove parameters, cookies and other things.
• Is the JavaScript dynamic? Seems to cause lots of problems if it is.