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!

.xbl or XML Binding Language is an XML-based markup language for altering the behavior of XUL widgets. Different file types get rendered on the web page while others do not.

When a client is using a denylist of file types (js, HTML, etc.), then using obscure file types, such as .xbl, are awesome for getting XSS. Interesting find that I will have to try out!

It should be noted that the Content-Type header makes a big difference on how items get rendered. So, trying this on Google Drive will likely not work. But, if only a denylist is used without setting this header properly, you may find XSS!

The Cloud is the way to go! Even on your Desktop, you can sync cloud based file storage with local storage. This post is about the Cloud Files API on the Windows OS.

Windows Cloud File API offers support for cloud sync engines and handles tasks such as creating and managing placeholder files and directories. This syncs between remote file system and the local client. With a large file, instead of taking up a massive amount of space on the computer, a placeholder is inserted instead.

When performing this operation for syncing the file system, there is a bug on changing the length of the packet. After the initial connection, the length of the point data can be set to 0. Clearly, the data we are written does not have a length of 0!

The problem is not the length being 0 though; there are bounds checks that happen. The vulnerability is that the length of the buffer used is subtracted by 12 when decompressing itself.

Because of the subtraction, this results in an integer underflow and a length of 0xFFFFFFF4 on the buffer. Whether this bug is exploitable is not mentioned in the article. The exploitability of this bug is dependent on whether the wildcopy can be stopped or not with controlled data.

Microsoft fixed this vulnerability by adding a check to make sure the retrieved length is not less than 4. This makes it impossible to trigger an integer underflow.

Historically, for DEF CON, you purchase everything in cash at the conference. This allows for people to remain anonymous if they would like to. Because of covid 19, you are supposed to buy the ticket online prior to the conference. With online data comes the potential for things to be leaked!

After Reznok purchased his ticket, there was a screen for reviewers the order with a click for the badge. The author noticed that he had no logged in and there was no token in the URL. Why not throw this into incognito?

When the author popped this into incognito mode, the payment information was still there! To make matters even worse, the ID was sequential, making these purchases easy to find. The author looked for a few other tickets then decided to report the finding to the Dark Tangent.

Reznok could have seen the name, ticket and email of all the people that had bought the tickets online. For a group of people that value anonymity, this is really bad! The issue was fixed quickly from the host company.

Web Assembly (WASM) is an assembly-like language intended to make the web fast. Applications can be compiled into WASM, such as Rust, in order to make a faster internet. This article is about breaking parts of WASM to get code execution within the browser.

The WASM execution pipeline has three stages of execution: parsing and two JITs. The Low Level Interpreter (LLInt) or parsing functionality is used for the bytecode generation process for the browser.

This parser is responsible for verifying function validity, including type checks and flow control. Wasm functions have a structured control flow in the form of blocks (which can be a generic block, a loop, or an if conditional). Each block has its own expression stack and can return multiple variables.

The m_maxStackSize field of a function is needed to get track of the amount of stack slots. This value is updated at multiple points, such as a push operation. When the parsing is done, is it rounded up for stack alignment purposes.

However, this alignment is not validated for an integer overflow! By setting the m_maxStackSize to UINT_MAX (0xffffffff) we can wrap around to 0. The variable m_numCalleeLocals, which determines the stack frame size during the prolog, will not allocate any data for the stack frame but write a bunch of data!

To trigger the operation the bug, the authors wrote a Wasm function that contains 2^32 push operations. With wildcopy bugs, we need to stop the write somehow. By using a quirk of the JS engine with it's handling of unreachable code, we can trigger the largest possible stack frame without crashing.

This exploit requires 16 vectors take on about 2GB of memory for a total of 32GB. On macOS, compression memory makes this doable! To run this, it takes about 2.5 minutes to allocate all of this memory.

With the stack frame in a weird state, we can now get a memory leak. To make this happen, the authors write a function that has 2 arguments. When processing Wasm, there are what are called slow-paths, which will call C++ functionality natively. By calling the slow path in a particular way, we can get the C++ functions to overwrite our parameters for an information leak. One of the paths gave the address of JavaScriptCore dylib and a stack address.

The offsets for writing will only go DOWN the stack. As a result, nothing useful can be overwritten within the context of our current thread. So, in order to make this exploit work, we are going to hop from our current thread into something else. By using quirks of the engine, we can write to arbitrary offsets in the positive direction.

With the arbitrary write from a particular offset, the authors can overwrite values on the victim stack. Using this, it is trivial to overwrite the RIP on the other threads stack. For leaks, we can simply read from an offset of the stack.

To read from the location on the stack, the following Wasm works:

local.get 0 ;; JavaScriptCore dylib address
i64.const <offset to gadget>
i64.add ;; the addition will write the gadget to the stack

For writing, the same primitive works but using a local.get 1 instead.

To get arbitrary code execution with our own shellcode, we need to bypass SIP, which only allows sections of code to be RWX if mapped with MAP_JIT. So, we must map our own section to wrote our own shellcode.

This vulnerability was patched by utilizing checked arithmetic within the generator for the various stack operations. Besides using unsigned values, it also has code to ensure that no overflows occur.

A file system is an organization of data and metadata on a storage device. It controls how the data is stored and retrieved, and its most important function is to manage user data. Finding a vulnerability in this is catastrophic!

The Linux kernel's seq_file interface produces virtual files. Each record must fit into the buffer size. When the node grows too big, the size is doubled. This size value is of type of size_t, which is a 64-bit unsigned integer.

This size value is passed to multiple functions that use an int, which is a signed 32-bit. This results in an insecure truncation and a insecure signed issue. This can lead to memory corrupt bugs when allocated the right buffer size for the information for the file node.

In order to trigger this, an attacker needs to create, mount and delete a directory structure whose path is larger than 1GB. Then, when looking at /proc/self/mountinfo, the code path deals with the insecure integer truncation.

The actual issue is that the function dentry_path expects a 32 bit signed integer. However, the truncation results in a negative value for the length of the buffer. When this buffer offset gets used, it writes the string //deleted to a specific offset.

When an attacker controls the system as well as they do on Linux, this primitive is enough to get things started to get deeper primitives. In order to exploit this, the authors created a small eBPF program that has been validated within the kernel. Once this has been validated, the vulnerability is triggered that overwrites instructions of the eBPF code, breaking the security guarantee. This is done multiple times.

This overwritten instruction transforms into an out of bounds information disclosure and a limited write. Using the out of bounds write, they turn the exploit into a full on arbitrary read/arbitrary write by using ntf and map_push_elem.

It's truly amazing how such a simple bug (integer truncation) turns into a full Linux kernel privilege escalation. To me, this integer truncation issue is more likely in many more spots. Most of the time, compilers do not call this out. Great find and great research!

Animal Crossing is a social simulation video game series developed and published by Nintendo. It has many iterations including GameCube, Wii and Switch versions. The focus of this article is on the GameCube version of the game.

While exploring Animal Crossing in on the Dolphin emulator, the author wanted to know how the NES emulator in the game works. From a tiny bit of reversing, the game has small NES ROM image within the game. This means that the game itself contains a custom NES emulator. But, how does the emulator load the game and how does it know which game to load?

The author used the Dolphin GameCube emulator to force jump to the section that would load the ROM. The game itself it stored on a memory card when it tries to load the ROM, which can be seen in the crash logs. Now, we know that the game itself it stored on a memory card when it tries to load the ROM.

After some more reversing, the author found the location where the game was being loaded from the memory card: offset 0x642. After adding a ROM to this memory card location with the proper magic file headers, most NES games booted up. At this point, the author has a Save Game attack vector: what can we do with this?

The author was interesting in spotting a Save Game exploit that would cause enough memory corruption to take over the GameCube. From messing around with special tag functionality, the author noticed complex memory manipulation for loading metadata with dubious calls to memcpy. Because of this, they started bug hunting in this area.

The NES is a 16-bit system. So, most of the offsets for values were only 16 bits long away. However, the QDS parsing area loads a 24-bit offset. One issue has a maximum value of 0xFFFFFF, which is much larger than the boundary of the ROM. But, because this write zeros everything out first then later does the write, this did not look like a good option to pursue. There were many other deadends that would simply cause crashes but nothing exploitable.

Eventually the author found the PAT tag, which was by far the most complicated of all of the tags. A PAT tag has a 8-bit type, 8-bit patch size and a 16-bit offset value, followed by the patch data. Using this patch code, it would be possible to edit the NES game being loaded on the current platform.

The patch address validation is flawed! Because of the poor validation, it allows us to overwrite arbitrary data on the heap from 0x80000000 - 0x807FFFFF with the format described above. Because Animal Crossing loads in this space, we can use the patching functionality to overwrite arbitrary locations inside of Animal Crossings game on the GameCube. This is a complete emulator escape!

Patching data is trivial. But, what if we want to patch the game? Because of the Instruction Cache on the CPU, overwriting the instructions does not do anything to start with. To get around this issue, the author overwrite a function pointer within malloc to divert the flow of execution. Because the pointer was now changed, we could point it to our own code to do whatever we wanted within Animal Crossing.

To wrap this up, there are few interesting reversing tips that should be pointed out:

• Error messages go a long ways when debugging.
• Files and parsers LOVE magic values, such as AA55 for bootloaders.
• Dynamic debugging is the way to go in order to hit normally unreachable code paths. This will help you see if something is worth your time or not.

This is an awesome post on a 20 year old game console that I grew up on as well. Emulation is tricky to do, which is why this exploit works in the first place.

Clients that run on machines have an interesting problem: we control the client. How do we know that the device is not being tampered with? How do we know that the application is not being reversed? Because developers do not want their IP stolen, there is a constant arms race on exploitation and protection.

Pokemon Go is mobile phone game meant to bring Pokemon to real life. The authors of the game, understandably, do not want people cheating at this game. People can cheat by spawning arbitrary Pokemon at will or teleports to foreign countries without actually traveling.

To make cheating harder, they have added anti-cheat protections. To start with, whenever the app is loaded when a Jailbroken phone, the game simply crashes. But why? The crashes are intentional!

The main Pokemon Go application is just a stub around the Unity implementation, which has the main logic. Among the things loaded is the NianticLabsPlugin plugin. This contains the myriad of protections put into the game to stop reversing, cheating and other things. This library is where the crash happens at.

Analyzing constructors gets us a long ways. On iOS and Android, we can hook the function call_array from the ELF loader. Within this, all constructor addresses are checked beforehand, making this a wonderful place to debug the code.

By hooking at this location, we can get control before the execution of constructors. This allows for the ability to trace them, replace/disable them and detect to hook other constructors as well. From this, NianticLabsPlugin has 120 constructors with various detection methods.

First, it checks for debuggers by seeing if PTrace is attached to the binary. If so, it kills itself. Straight syscalls are used instead of the normal wrapper function around PTrace.

In the same area, this is a kill to the PID of the binary with a signal of 0. According to the man page "[…] A value of 0, however, will cause error checking to be performed (with no signal being sent). This can be used to check the validity of pid." If the PID is not valid, we crash the program.

Pokemon Go opens a socket on the same port that Frida uses and tests the Frida handshake. If this is the case, then simply crash the program.

There is also simply Jailbreak detection that is done by checks if specific files exist. If so, the device is likely jailbroken and should crash. At some point, signature validation is done as well.

The ant-debugging techniques on this are pretty serious! The author goes into how to decode obfuscated strings in the binary as well. The new feature of the post (for Frida) is undo all relocations of symbols with an ELF. Overall, interesting post on anti-debugging techniques!

A format string vulnerability was discovered within the WiFi daemon. However, it was determined to be unexploitable besides for a DoS. The authors of this article decided to dive a little further into this bug.

To me, format string vulnerabilities are incredibly serious because of the capabilities that format strings have. From arbitrary reads to arbitrary writes, it's an extremely serious bug!

Within WiFi daemon, while processing SSID names, is where the vulnerability was at. The same bug was found in a log file printer as well. This is where things hit the fan...

This new format string bug only required seeing the WiFi in the vicinity; it did not even have to be connected to! To make matters worse, iPhones automatically scan to every 3 seconds for different WiFi names when the phone is off! This is a 0-click attack, as long as the attacker is around.

%n in traditional format string exploitation is used to write to arbitrary locations. Apple did not implement this functionality for security reasons. But, the %@, in Objective-C, can be used to print the contents of an object.

By using the %@ format string, we may be able to use another object on the stack in the format string. This attack could be used as a use after free for something on the stack or many other objects on stack for a write.

By spraying a substantial amount of objects to be on the stack with a Beacon Flooding attack, they found potential values that were being put onto the stack that are controllable!

By deferencing these values, pointers and potentially function pointers, could be written in order to pop a shell. With control over the RIP, a ROP chain will do in order to compromise the device.

This exploit would likely require a memory leak of some kind in order to exploit. But itself, this bug is enough to get code execution but an attacker would have no idea where to jump to or where to reference pointers. Awesome and bug and research!

This article dives into the Schneider Electric Modicon Programmable Logic Controller (PLC).

Modbus is the standard for controlling PLCs in SCADA systems/ Modbus was designed in 1979, prior to people caring about security. The most widely used version of Modbus goes over IP (Modbus/TCP standard). Modicon chose to extend the Modbus implementation under a reserved Modbus function code with the UMAS.

UMAS reimplements the Modbus protocol but adds essential functionality for modern tech. In particular, binary data transfer, authentication, firmware updates and several other things were added. UMAS has several commands that require chains of proper commands; this is done with a reservation.

The reservation mechanism was created to synchronize modifications of the PLC’s program; this is a form of global locking over the entire system. Once a station had reserved something, a one-byte token was used to perform further modifications, but only if the PLC is modified.

The reservation had an issue though: this reservation used a hardcoded secret between software for the challenge-response method. As a result, enhanced reservation was created. The new version used an authentication method with a challenge-response way with a dynamically set password. Wow, that's a lot of background!

The first vulnerability is an authentication bypass. From reversing the firmware, they found a plethora of undocumented commands. One of these commands allowed for reading any address in physical memory with no auth. As a result, the hash of the application password could be stolen. This device can even be used to crash the device with bad address reads.

The authors of the article decided to understand the flow of the auth process. When an incorrect password was typed the software rejected the password without generating any traffic with the PLC. But how is this possible?

Prior to the reservations, a call to read the password hash from memory was done! Then, this hash is validated locally with the entered password. This is an obvious flaw with the authentication flow; an attacker can brute force the hash offline. So, this attack was successful TWICE.

The command WritePhysicalAddress allows for writing to any physical memory. Using this, they could get code execution by altering many different places in memory.

The command PrivateMessage allows for the calling of internal functions on the PLC by accessing C++ objects. This can be exploited by writing to somewhere in memory with the BlockWrite command. Then, referencing this object makes it easy to control the PC to pop a shell.

This article has nice pictures on what the modbus and UMAS protocols look like and great docs on the exploitation of this. The bugs for this were unique and worth the read. Great research!

A list of all things Linux kernel hacking. The list of items is pretty lit!

• Techniques and protection bypasses
• Vulnerabilities. They are divided into info leaks, local privilege escalation and RCE.
• Finding bugs in the Linux kernel.
• Defensive actions in the Linux kernel.
• Exploits
• Tooling
• CTF/workshops