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!

Superfluid.sol was the host contract of this whole infrastructure. Superfluid “agreements” are the rules that Super Tokens operate under. In order to have a trusted and shared state across agreements, a ctx for context was used. This contains all of the context for the agreement function, such as the sender of the call.

The usage of the ctx was not done securely though. Because it was user provided input that was being deseralized, it was likely this could be abused. Although they tried setting this up correctly, an attacker could inject their own malicious ctx when using multiple agreements at once. There is a hash check for the ctx, but this was forgotten about on the Host contract.

Since this context is trusted, an attacker could inject malicious calls and add other users as the pseudo msg.sender. By doing this, the attacker was able to steal money from the contract and all of its users. Overall, a obvious but interesting attack.

Armour DeFi has a insurance coverage-like functionality. A user with coverage can make a claim after suffering some event covered under the policy.

An ETH is worth 10^18 WEI. When dealing with money in Solidity, for functions such as msg.sender.transfer, the amount to specify should be in WEI.

When making a payout, the amount specified was in WEI. However, the developer thought that it was in ETH. Hence, they multiplied by 10^18, even though it was already in WEI. This results in a crazy large payout that should be possible.

This vulnerability was discovered a few hours after the bug bounty program amount increased, which means the program is working as intended! This bug had not been sent to production yet but would have resulted in a major hack if it would have been.

How was this not found in testing? This is basic functionality testing that should have test cases for it. Sometimes, all of these products just feel like scams.

Before the internet, the Super Nintendo (SNES) had an online gaming community via the XBAND Video Game Modem. The goal of the author was to create complete emulation support for XBAND.

XBAND networks was designed to send controller inputs between connected clients with the network and the mode. The XBAND OS would patch the ROM of the game to add its own instructions to inject controller inputs. The engineers who built the implants for the games had to reverse engineer the games in order to write custom patches, which is pretty neat.

To accurately emulate this, the most important thing is getting it to boot. This required setting up the memory mappings correctly. Additionally, the Rockwell Modem, used to send the wireless packets, was communicated with via MMIO. So, to accurately emulate this, the read and write had to be properly implemented. From reading specifications and old school docs, they were able to get this working in a few months.

The protocol used for the XBAND network was the Apple Data Streaming Protocol (ADSP). This was used because it provided basic sessions between two hosts. The XBAND would consume these packets via the modem, which would de-frame and push the information to the XBAND OS for consumption. To test out this functionality, the author created a way to injection arbitrary ADSP packets into the network layer.

The XBAND network has two types of calls: ServerTalk and GameTalk. ServerTalk was the server to client communication while the GameTalk was for client to client communication. The XBAND OS used the message dispatch pattern in order to execute OS function calls for ServerTalk packets. Each one of the message id corresponded to a piece of functionality.

While reverse engineering the dispatch codes, the author found one called msExecuteCode. What does this function do? It runs arbitrary code specified by the modem! To test this, the author used the packet injection feature and hit the corresponding location in the code on the game.

From there, the author wrote a short snippet of self-contained assembler that would reset the state of important registers and change the color of the screen to green. The author even got this to run on real hardware by setting up the modem and the SNES game locally.

From there, the author found a few other bugs. One allowed for a re-write of a char 244 OOB. Additionally, they found an unbounded write to SRAM for X-mail messages. Overall, this was an awesome post on emulation, games in the 80s and hacking. Thanks for writing this!

Before the internet, the Super Nintendo (SNES) had an online gaming community via the XBAND Video Game Modem. The goal of the author was to create complete emulation support for XBAND.

XBAND networks was designed to send controller inputs between connected clients with the network and the mode. The XBAND OS would patch the ROM of the game to add its own instructions to inject controller inputs. The engineers who built the implants for the games had to reverse engineer the games in order to write custom patches, which is pretty neat.

To accurately emulate this, the most important thing is getting it to boot. This required setting up the memory mappings correctly. Additionally, the Rockwell Modem, used to send the wireless packets, was communicated with via MMIO. So, to accurately emulate this, the read and write had to be properly implemented. From reading specifications and old school docs, they were able to get this working in a few months.

The protocol used for the XBAND network was the Apple Data Streaming Protocol (ADSP). This was used because it provided basic sessions between two hosts. The XBAND would consume these packets via the modem, which would de-frame and push the information to the XBAND OS for consumption. To test out this functionality, the author created a way to injection arbitrary ADSP packets into the network layer.

The XBAND network has two types of calls: ServerTalk and GameTalk. ServerTalk was the server to client communication while the GameTalk was for client to client communication. The XBAND OS used the message dispatch pattern in order to execute OS function calls for ServerTalk packets. Each one of the message id corresponded to a piece of functionality.

While reverse engineering the dispatch codes, the author found one called msExecuteCode. What does this function do? It runs arbitrary code specified by the modem! To test this, the author used the packet injection feature and hit the corresponding location in the code on the game.

From there, the author wrote a short snippet of self-contained assembler that would reset the state of important registers and change the color of the screen to green. The author even got this to run on real hardware by setting up the modem and the SNES game locally.

From there, the author found a few other bugs. One allowed for a re-write of a char 244 OOB. Additionally, they found an unbounded write to SRAM for X-mail messages. Overall, this was an awesome post on emulation, games in the 80s and hacking. Thanks for writing this!

While playing around with the GreatFET One, the author found that Xorg would crash with format string payloads. After an advisory from Xorg that related to "input devices" the author decided to investigate to see if these bugs were the same thing.

A format string is commonly used in many programming languages. In C, it has the potential for horrible memory corruption bugs though. When a printf family function is called, it takes in a string with format specifiers (%x, for instance) and a variable amount of arguments depending on the format specifier. If an attacker can control the string, then they can trigger the format specifier functionality on unintended data.

In the case of Xorg, libinput is performing logging. While doing this logging, it is creating a format string dynamically by prepending a string with sprintf to be used later in another printf-like call. Because of this string concatenation for a format string with user controllable values, this created a fairly bad format string bug. This bug is explained at here.

Since the root causing had already been done, the author decided to write up a proof of concept for it; the goal was to leak the stack canary. Immediately, the author ran into two problems. First, there is a length limit of an individual field is 126 characters. Secondly, because the data was being prepended and there was a %s in the end of the string, almost everything caused a crash. Finally, FORTIFY_SOURCE=2 was set on the binary, disallowing the usage of the %N for writes.

To solve the %s crash problem, direct parameter access in the format string could be used. Since this doesn't increase the pointer being used for the stack, this was a good solution to the problem. Additionally, direct parameter access cannot skip any values because of FORTIFY_SOURCE=2 being set. Because of this and the length constraint, the furthest byte that can be accessed is 27.

Now, the format string is not too bad looking It ends up being %1$p%2$p...%27$p, which is parameterized access for all 27 bytes. Depending on the location of the field in the payload, this would leak the stack canary in the last few bytes. Damn, that's super awesome!

The author got this to work on Xubuntu 20.04.4. They tried this on Deban 11 systems but couldn't get it to work. Most distros have all binary protections, such as canaries, RELRO and things in place. They tried get code execution using this but the FORTIFY checks were just too much to overcome this.

Overall, I love the post from a practical side. First, this bug should have been caught by the compiler but wasn't because some flags were turned off. Second, the exploit is practical and shows the complexity with real world exploits and exploit mitigations. Great job!

The hacker has picked up a random IoT alarm from China. In parts 1 and 2, they dumped the firmware and figured out how it works. In this post, they decided to go through the reverse engineering of the radio wireless and how it communicates with the smart hub.

To start with, they identified the chip being used but couldn't find a datasheet (sad). To find the frequency of the device, mention the hackrf_sweep tool that comes from the HackRF SDR. Instead, they just looked at common frequency ranges in the graphical spectrogram GQRX. After doing this, they found the frequency of the alarm to be at 434MHz.

Once they had detected the frequency, they could do some further analysis. They chose to use Universal Radio Hacker (URH) to record the signal. The remote for the alarm has four buttons, where they take a recording of all of them. For each button, they repeat the capturing three times in order to analyze if the signal staus the same between runs.

When looking at the recording in URH, there are short blips of signals then breaks. Because of this, the data is likely encoded using Amplitude Modulation (AM). Zooming in on the signal shows no change in frequency or phase either. More specifically, On-Off-Keying (OOK). Simply but, if we want to send a 0, then don't off the transmitter (no signal). If we want to send a 1, then turn on the transmitter.

From analyzing the binary output of the signal with OOK, the authors determined a few things. First, all of the groups of captures are the same, such as unlock. Second, there are quite a few anomalous outputs. They determined this occurred because of the tool not understanding the difference between a break in transmission and zero, as well as the button being released part way through a transmission. After cleaning this up, there appears to be 97 bits of data. Interesting!

Figuring out the encoding can be tricky. Although OOK is used, a digital bit is commonly put into several bits of transmission. For instance, 4 bits may represent a single real digital bit being transmitted. In the case of the remote, they divided up the groups in several ways until something looked like a pattern. When dividing the data into groups of 4 and removing the first bit, they were left with only two patterns of 4 bit groups: 1110 and 1000.

Since the groups of 1110 and 1000 were likely not a coincidence, this must be how the data is encoded. Compared to the unlock and lock codes, only the last 8 bits were ever different. While doing research on common encoding algorithms for wireless, they came across the EV1527 protocol which showed exactly what the analysis mentioned above. Neat!

In terms of security, this wireless device is a joke. It is trivially vulnerable to spoofing and replay attacks, since there is no authentication on the device. Additionally, jamming could be done to prevent the alarm from working.

The one tricky part is that the first 20 bits are a remote control identification number. Although an eavesdropper can learn this and use it, a first time walk up is hard. Theoretically, an attacker can attempt to brute force this but it is likely too large of a space to work.

The authors of the post really went hard on recreating this with URH. By setting up the protocol, it is possible for it to recreate arbitrary signals that you have not seen before. For instance, you could modify a lock code to be an unlock code. Additionally, they fuzzed the other commands (16 possible command bits) to no avail.

Overall, interesting post going into their methodology for wireless signal reverse engineering. The groups use of URH is awesome as well, as I usually recreate stuff in GNU radio instead of URH.

MicroTik recently added the ability to containerize application running on their routing. This is the functionality being targeted in this attack.

An interesting feature is allowing for mount points between the host and the container. For instance, if you wanted to allow the /etc folder on a disk into a container, the command would look like the following: /container/mounts/add name=<name> src=disk1/etc dst=<container_location> .

The author realized a few flaws in this. First, paths are resolved through symbolic links. This means that the directory was being resolved prior to the mounting process. Second, symbolic links are resolved from the hosts root instead of the container root for both the src and dst parameters.

Using this facts, many horrible things can be done. First, when performing the mounting of a drive in the container, we can mount arbitrary locations. For instance, we can mount into an arbitrary directory by using symlinks. This should be easy to exploit then, right?

The mounts are created with nosuid, nodev and noexec permissions. Practically, this means that even if a binary or shared library was overwritten, it wouldn't matter because of these permission. The executor would simply get "permission denied". Config files would be a good target because of this; but the author couldn't find anything helpful.

The author discovered that symlinking existing on the noexec file system but pointing to binaries outside of the filesystem would still be executed. The containers root file system does not have the noexec, which is helpful. So, they created a mount point over an existing binary, such as telnet to create a symbolic link. This link then pointed within the executable part of the container.

Now, the next time telnet was ran, it was executed to give the author a reverse shell. This gives arbitrary code execution on the device from within the context of the container. In order to fix this, I assume some patching with the symbolic links was done. Overall, awesome post with very useful explanations.

Cloudflare Email Routing was in a closed beta, with the author not being invited. A check in the UI was placed to allow access to the functionality or not; this could be bypassed via changing a boolean from true to false.

The actual bug has to do with the email routing itself. When setting up routing, you need to prove ownership of it. Changes, such as modifying the DNS records, should not be possible until ownership is verified of the domain. A domain can only be active in my account at a time; but, multiple accounts can be unverified/pending at the same time.

The author wanted to verify that the ownership check for a domain was validated prior to making changes. It turns out, that it wasn't! So, an attacker could have a domain in the pending state and still make changes to it. Obviously, this only worked for domains already using Cloudflare Email routing.

As an attacker, this allows for the hijacking of email routing entirely by specifying an additional location for it to be returned to. This completely breaks the price of email! Additionally, emails are commonly used for password resetting, making all users at major risk.

Overall, two great bug finds for a bug bounty payout.

Virtualization, especially with hypervisors in place, needs to ensure that no assets leak from one virtual machine to the other or from the hypervisor to the virtual machine. Failure to do so may result in vm escapes or cross-box contamination.

In the mainline Linux kernel for 5.18-rc1 to 5.19-rc6, statically allocated .bss (block starting symbol) were not being cleared upon moving between XenPV guests and hosts. Because of this, a virtual machine guest connecting to the Xen IOMMU could access restricted memory. This can be done by calling kexec() from the guest.

This appears to be a regression issue while attempting to add support for the hypervisor. The proof of concept has a simply NULL pointer dereference but could be much worse.

Overall, an interesting and impactful bug. But, I wish the explaination in the article was easier to understand. The proof of concept is just a crash log and doesn't say how this was triggered.

Charged Particles is a decentralized NFT marketplace. A ERC721 NFT is called a Proton, which is ready to be energized by adding interest-bearing assets to it.

A Charged Particle can have a royalties receiver contract set on it. When the NFT is sold, it does not reset upon being sold to a different user.

As a result, the contract can hold the NFT hostage, even after being sold. The malicious contract simply has a fallback that reverts if the random isn't paid.

Denial of Service (DoS) bugs can be impactful in this space, this millions of dollars at stake.