Reverse Engineering

This article is a long time coming. z3, the constraint solver, is commonly used in crackmes and CTF challenges. Wherever possible, I just lift to angr for symbolic execution and bruteforce that way, since z3 is basically math bruteforce anyways. Regardless:

Recently I ran into a headache of Out-Of-Memory errors when using Binary Ninja. Specifically, this was in relation to dissassembling a Mach-O aarch64 binary from an iOS app grabbed from decrypt.day.

The popular social media app “TikTok” is likely facing an iminent ban in the United States in the coming days. This has resulted in a mass migration to the Chinese app 小红书 (meaning “little red book”), Xiaohongshu, or simply “REDnote”.

Recently I needed to get the data off of a LUKS encrypted partition on a Virtual Machine that “wasn’t mine” and I’d never done it before. As you might imagine, a huge headache ensued.

Recently Sift caught an interesting payload. As it turns out, the exploit was CVE-2024-0769, which is now tagged here: D-Link DIR-859 Information Disclosure Attempt .

For this last years Binary Golf Grand Prix the goal was to: Create the smallest self-replicating file. Requirements: Produce exactly 1 copy of itself Name the copy “4” Not execute the copied file Print, return, or display the number 4 I sat down with some beer, as one does, and resolved that my personal twist on the challenge would be to not just do a single filetype, but a chain of obscure filetypes. I scripted out enumeration of all of the default file handlers for Windows 7 in a blog I titled Obscure Windows File Type.

In order to see CVE-2023-50164 in the wild, I expect that in the coming weeks, we will see research into vendor and product specific implementations leveraging Apache Struts2 in order to determine exactly what path must be traversed to in order to drop a web shell so that it can be called remotely through a public interface over the defined routes.

At GreyNoise we work with network protocols. When a new vulnerability is published we are quick to jump into investigation mode and gather any and all resources we can find in order to write a tag and provide messaging to our customers and community. GreyNoise doesn’t have much common need to detailed firmware analysis. If it’s happening on the internet, we already see it. However, when we do need to investigate vulnerabilities in embedded devices things can get very complicated very quickly if no information is publicly available. It can be fun and insightful to learn these skills for the rare case we need them.

This blog is far overdue and unfortunately isn’t really a “Part 1”. The truth is, I’ve poked around with Wi-Fi Direct for several months now with mild success and many dead-ends that resulted in learning a lot. The purpose of this blog is to retrace my steps and document some resources before diving into some fun stuff for Part 2.

For this years Binary Golf Grand Prix I started off by learning to fuzz properly, use a debugger properly, and various tooling. The objective was originally to hit all of the bonus points: