Posts

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.

Hello, we’re going to be trying something a little bit different today. A colleague recommended this whisper.cpp thing, which is a port of open.ai’s whisper model to C/C++. So rather than type out this blog, the way that it’s going to be formed is I read a question that’s curious to me. And I’m going to talk about it, edit it up, and slap some screenshots and links and see what kind of blog that turns out as. So this may not be the best blog, but really I’m just trying to figure out if this workflow kind of works in general. So we’re going to start off with a question that I found on Reddit on r/asknetsec. You can find it below.

The real motive of this series of blogs may take a few iterations to become clear to the reader, assuming of course I can actually pull it off. Let’s forget about the big picture for a moment and break things down into pieces I can wrap my head around. Mostly because I’ve already started, I’m already doing the things, and I don’t even know the right words to call 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:

The 3rd Annual Binary Golf Grand Prix (BGGP3) is to find the smallest file which will crash a specific program.

Where we last left off, I had done an initial reverse engineering pass of Windows Update Delivery Optimization see: DOing Harm. I got familiar with the protocol, how peer discovery works, etc… but mainly only looked at the first handshake as that was most interesting to me at the time.

There’s this thing called Windows Delivery Optimization which allows “you to get Windows updates and Microsoft Store apps from sources in addition to Microsoft, like other PCs on your local network, or PCs on the internet that are downloading the same files.”

Where last I left off in Adventures in Bluetooth: Part 1, I was originally attempting to flash custom firmware to a Fitbit Charge 2 smartwatch and ended up taking a quite large side-quest. Let’s see how far I can make it towards the objective this time!

Have you ever had an idea you couldn’t quite shake? Something that worms it’s way into your brain for one reason or another and just wont leave. Always on the backburner, thinking about it in the shower every day, in the bed as you go to sleep at night, zoning out in the living room, for as long as you can remember?

I was a Private Internet Access (PIA) customer for many, many years. Some recent changes spurred me to look for a new VPN provider and I ended up landing on ProtonVPN which I’ve been using for a few months now.

Symbian OS, Android, Radio Frequencies, BTSNOOZ, BTSNOOP, and getting kicked in the teeth. Below follows a chronicling of deciding to explore Bluetooth by hacking the firmware for a Fitbit Smartwatch and realizing I was in way over my head and slowly trying to regain any hope of understanding.

So far I’ve managed to have just enough reverse engineering skills as is useful to me at the time, but recently I’ve taken an interest in getting a bit more in depth.

Recently I stumbled across a thread on Reddit r/AskNetsec Now, without looking at the post: What do you think the answers looked like?

Last week a friend of mine asked me to debug/RE some phishing emails that had been sent to them. These phishing emails were visually very clever and looked identical to the real site! But as I looked at the javascript I frankly became embarassed for the developer. Sure, they’d run the code through an obfuscation engine and added some basic anti-debug tricks, but that’s nothing you can’t defeat with AST and proxying function calls.

It’s easy to set up an IDS or other infrastructure to drop packets that match rules. There are many tools for real-time inspection of connections that can handle higher level protocols like HTTP or TLS. This article aims to go a bit lower and address how to edit packets in flight. We’ll be looking at it through the lens of editing packets for a game using Golang.

This aims to explain and perform an example of how the Client-Puzzle-Protocol (CPP) may be implemented (almost) entirely in HTTP.

Let’s build the smallest WASM / GBA ROM / 7Zip polyglot in 584 bytes for the Binary Golf Grand Prix 2021.

In early 2017, @ericlaw wrote a blog post titled The Line of Death. The general premise is that there is some inherent user trust of any content that appears above the browser window and that considerations must be taken to ensure that browsers can not be manipulated to easily betray this trust.

Earlier this month, I came back around to seriously considering an attempt at bitsquatting. While the prior link goes into great depth on the topic, I will attempt to give a very high level overview here:

I’ve been doing weekly chaos engineering projects for a while now, so I decided to start a blog. A sort of dumping ground for all the things I do. If you’re interested in more projects like this, give me a follow on Twitter @_mattata. I’m always working on something fun.