This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here Challenge 3 brings a PE executable file to take a look at. such_evil: PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows I loaded the file up in x64dbg and after navigating to the main function it looks to load a whole lot of data onto the stack then CALL into the loaded code.

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here In Challenge 2 the zip file extracts a html and png file. From the top of the HTML file to looks pretty normal until you see the PHP tag located near the bottom of the code including the PNG file in the img directory. The file looks to be a normal PNG file and displays image data when loaded.

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here In the very first challenge you are presented with a windows executable and when you run it you are presented with a Bob Ross painting a nice scene. But, when you click DECODE! You get a Bob Doge with an weird text string. Digging a little deeper to see what type of file we have we find we hace a .

Below are the slides my presentation at the Maine ISC(2) chapter meetup on June 10, 2020.

This post is a sequel to the post covering the sample “Bank Statement.bat.” I had received this message before the Bank Statement message, but I found the sample in the previous post was less obfuscated and easier to reverse engineer. In this post, I will cover the different ways that this sample hid the decoding routes and how I was able to gather the data to run the same decoding script I used before to extract the payload from the PNG data within this sample.

When looking through my Spam folder, I have run across a few messages with “.bat” files attached to them. Most messages have had different content in the message to entice a victim to open the attachment. I started to investigate each of the attachments and found they were Windows Binaries, and at least two had PNG files in the resources. After doing this initial triage, I wanted to see if the payload of these pieces of malware is encoded in this PNG data and how it was encoded.

Summary In this post, I will reverse and analyze a Ryuk malware sample. Ryuk is pretty well-known ransomware that encrypts the contents of a victim’s hard drive. The sample uses two executable stages, one that determines if the system is a 32bit or a 64bit system, then extracts out the appropriate second stage executable onto the file system and executes the second stage. The second stage then attempts to gain persistence through creating a registry key and then finally injects an encryption process into another process and starts to encrypt the file systems leaving behind a Ransom note for the user to find.

Below are the slides my presentation at the Maine OWASP chapter meetup on Janurary 23, 2020. Link to Slides

This is a continuation from a previous post: https://ben.the-collective.net/hugo/posts/2019-08-21-digoo-dg-hosa-part-1-teardown-and-hardware/ Finding the connections Now that I have the lay of the land for the device (which that I outlined in my previous part of the series) the first thing I looked for is the debugging connections for the main GigaDevices processor. This processor looks to be the primary processor for the device and has the most valuable firmware. Since the board was well labeled I didn’t need to use any tools like a JTAGulator or an Arduino board with the JTAGenum firmware to identify which test points are the debug interface.

This project started with the idea of purchasing a cheap security system off one of the Chinese stores. After a little hunting, I found Digoo DG HOSA 433MHz 2G&GSM&WIFI Smart Home Security Alarm System Protective Shell Alert with APP which looked interesting so picked one up to tear apart. I was curious about how various communication methods were implemented. This is the first part of this adventure the next part will be exploring the firmware of the device.

OpenSky is a proprietary trunking radio that is designed to carry both voice and data traffic. the protocol is marketed as to be secure and private. Opensky operates on the 700, 800, and 900 MHz bands. OpenSky was originally developed by M/A-Com as part of the Monarch wireless voice and data system for FedEx in the 90s. Later M/A Com was purchased by Tyco Electronics who was then purchased by Harris RF Communications.