While reverse-engineering the firmware on the Digoo DG-HOSA device which I have a couple of posts on already. I ran across some memory addresses that did not directly map to peripherals. I found the address ranges are called the Bit-band range and had special functionality allowing direct access to individual bits on peripherals. This post will give a quick summary of what these addresses are and how to unmap them to the normal peripheral addresses.
What is Bit Banding?
The Bit Banding is a feature of the ARM Cortex-M3/M4 allowing you to directly access specific bits within the Peripheral and SRAM regions. Normally you need to write a whole register at a time even if you want to change a single bit. There are memory regions allocated for this purpose they are named “Bit band alias” in this snip of the Processor memory map table.
To calculate the Bit band address for a specific bit on a port you use the following formula. This formula is also found in the Cortex-M3 Technical reference.
bit_word_offset – position of the target bit in the bit-band memory region. bit_word_addr – address of the word in the alias memory region that maps to the targeted bit. bit_band_base – starting address of the alias region. byte_offset – number of the byte in the bit-band region that contains the targeted bit. bit_number – bit position (0-7) of the targeted bit.
This was a quick introduction to bit banding if you are looking for more information check out his post which goes into great detail on this feature.
Now that we how to forward map an address I wrote up some python code that takes in the address, unmaps it, and lists the original port and register information.
Recently I found a Ghidra plugin that did not have a build for the current version for Ghidra I was using, and this motivated me to figure out how to build a plugin from its source. After looking around, I did not find many writeups on building existing plugins. This writeup covers both building out the development environment that could be used for writing plugins and extending Ghidra itself and then how to compile the plugin.
Create Build Environment
The first thing you will need to do is create a development environment for compiling the plugin. I found this fantastic article from Void Start Security describing creating a Ghidra development environment using the ghidra-builder Docker container and helper scripts. I made a fork for the repo, integrating the article’s changes and other enhancements. This makes it pretty to create an image used moving forward. Here are the commands I used.
# Clone the repository
$ git clone https://github.com/suidroot/ghidra-builder.git
$ cd ghidra-builder
# Build the Docker image
$ docker-tpl/build
After the Docker image build completed, you will have two options building the plugin; you can build against the Dev source tree or the Public release. First, I will cover the Public build preparation steps.
Prepare for a Public Build
Building a plugin against the current Public build is pretty straightforward. First, you will download the current archive from the NSA Github and extract it to a folder you will create named out in the ghidra-builder folder structure. In my example, I saved the file to the ‘Downloads‘ folder in my home directory. The example commands I ran are:
# Starting in the root of the ghidra-builder folder
$ mkdir out && cd out
# Downloaded the current Public release to Downloads
$ cp ~/Downloads/ghidra_10.1.1_PUBLIC_20211221.zip .
$ unzip ghidra_10.1.1_PUBLIC_20211221.zip
Archive: ghidra_10.1.1_PUBLIC_20211221.zip
.... snip...
The following section covers creating a development archive of Ghidra.
Prepare for a Dev Build
To make a Dev build of a plugin, you will first need to make a development build of Ghidra. The script build_ghidra.sh (part of this container) automatically clones from the GitHub repository, builds the source and places an archive in the out folder.
$ cd workdir
$ ../docker-tpl/run ./build_ghidra.sh
After the build of Ghidra has been completed successfully, you will need to expand the archive created by the build into the out folder.
$ cd out/
$ ls
ghidra_10.1.1_DEV_20220103_linux_x86_64.zip
$ unzip ghidra_10.1.1_DEV_20220103_linux_x86_64.zip
Archive: ghidra_10.1.1_DEV_20220103_linux_x86_64.zip
creating: ghidra_10.1.1_DEV/
... snip ...
inflating: ghidra_10.1.1_DEV/Extensions/Ghidra/ghidra_10.1.1_DEV_20220103_SleighDevTools.zip
creating: ghidra_10.1.1_DEV/Ghidra/Extensions/
$ cd ..
Now that we have the environment setup, we can build the plugin from its source.
Build the plugin
I initially found these instructions in wrongbaud’s posts about plugin development. In the out directory, you will need to clone or download the source of the plugin you are building. The connect to a shell in the Docker container and navigate into the source directory for the plugin. Then set the location of the Ghidra build’s directory you prepared earlier in a shell environment variable. Finally, execute the gradle command to build the plugin.
Now you have built the plugin for the version of Ghidra! You can install the zip archive in the version of Ghidra you are running that you built for or are using.
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
Starting off the 5 series of challenges we have a very simple password challenge, when extracting the archive you have one file extracted.
MinesweeperChampionshipRegistration.jar: Java archive data (JAR)
When running the file, you are prompted for an invitation code. I unzipped the jar file finding the metadata and a class file. I ran strings on the class file and was able to see the flag in plain text in the file.
After entering the flag shown in strings into the prompt it is validated!
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
The archive for this challenge included 2 files.
BusinessPapers.doc: data DudeLocker.exe: PE32 executable (console) Intel 80386, for MS Windows
I first took a look at the .doc file and it looks to be random data.
BusinessPapers.doc
After doing some initial analysis on the executable file, I found many references to encryption routines in the imports. This program looks to act like ransomware. Diving into the functionality, the program first looks for a directory named “Briefcase.”
If it can not open the directory, it jumps to an error accusing the person of being a reverse engineer!
After it validates, it can open the directory properly; a routine is called checking the drive’s serial number looking for a specific value. If the value doesn’t match, the program errors out. If the hard drive’s serial number matches, it jumps to the routine to decode the encryption key. The drive’s serial number and a pointer, the encoded data stored in the .data section, are passed into the mw_decode_key function.
The mw_decode_key function does what I have named it, it decodes the key used in the data encryption. It uses a simple xor loop to decode the key.
Now that we have the key decoded it is time for the program to set up and execute the encryption routines. As a way to summarize the overall process, I have created the following diagram showing the connections between all of the functions. The boxes colored in blue are handles to data structures and the boxes in green are variables containing a value. The first step in the entire process to set up the Provider which acts as a glue between the key generation functions. From here let us go through each box in numbered order.
Section 1 is used first to create a Hash of the key based on the SHA1 algorithm. Next, it takes this Hash and derives an AES256 key from the Hash and stores it the Key Handle. The key finally has its mode set a CBC cipher.
Section 2 is used to create the IV portion of the key. This is derived from an MD5 hash of the name of the file. This section writes the data to a Hash Handle then copies it out of the handle into the KP_IV parameter of the Key Handle created in section 1.
Finally, in section 3, where files are encrypted, the original file is opened and read into a File Buffer which is then read by the CryptEncrypt function that reads the Key Handle and executes the encryption writing it back to the buffer. The buffer is then written back to the original File Handler, overwriting the data on disk.
After looking over all of this crypto routine and using a debugger to extract both the main AES key and the IV key values, I created a decryption script in python to extract what I had assumed is encrypted data in the BusinessFiles.doc file. The following script uses the wincrypto and cryptodome packages to more or less follow the process I just outlined instead, decrypting the data.
# need wincrypto and cryptodome packages
from Crypto.Cipher import AES
from Crypto.Hash import MD5
from wincrypto import CryptCreateHash, CryptHashData, CryptDeriveKey
from wincrypto.constants import CALG_SHA1, CALG_AES_256
import magic
encryted = 'BusinessPapers.doc'
encypted_data = open(encryted, 'rb').read()
key = b'thosefilesreallytiedthefoldertogether'
md5_clear = bytes(encryted.lower(),"UTF-8")
# Derive Key
sha1_hasher = CryptCreateHash(CALG_SHA1)
CryptHashData(sha1_hasher, key)
d_key = CryptDeriveKey(sha1_hasher, CALG_AES_256)
# Create IV data
iv = MD5.new()
iv.update(md5_clear)
aes = AES.new(d_key.key, AES.MODE_CBC, iv=bytes.fromhex(iv.hexdigest()))
decd = aes.decrypt(encypted_data)
print (decd[:20])
print(magic.from_buffer(decd))
hFireWrite = open("test.bin", 'wb')
hFireWrite.write(decd)
hFireWrite.close()
The output of this script writes the data to disk and provides a preview of the first 20 bytes and the magic block info from the data.
A funny feature of this challenge is that it leaves a ransom note. The note is an image in the resources section of the file. This image is extracted and written to the disk. Then it set the wallpaper using the SystemParametersInfoW API call.
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
This challenge is like a lot of the first levels is a password challenge decoding challenges. In the next screenshot, you can see what happens when you run the executable.
I opened the binary up in IDA and found the main function. The Main function starts off setting up handles to read input and loading a string from the .rdata section to a local variable.
Taking a look at the string that is loaded, it looks like to be some encoded text. I guess that it is more than likely the password.
Back to the main function, after collecting the inputted password guess from the command line, it takes the inputted string and runs a function to encode it.
Looking at the encoder function I found what looks like a non-standard Base64 character set.
I took the custom Base64, the encoded string I found earlier, and entered them into CyberChef to decode the string. It returns what looks to be the flag.
To be sure I re-ran the challenge and enter the output and bingo it validates the flag!
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
This challenge includes two files, a packet capture formatted in PCAP format and a Windows binary.
Opening up the PCAP in Wireshark, I found multiple HTTP streams submitting POST requests. I looked at each of these POST requests and saw they all have a few bytes of content.
I copied the data from each of these HTTP POST requests and found what looked like a Base64 encoded string.
UDYs1D7bNmdE1o3g5ms1V6RrYCVvODJF1DqxKTxAJ9xuZW=
When I attempted to decode it using standard Base64 character sets I did not find any recognizable data. I knew that it wouldn’t be that easy.
Looking at the strings in the binary, I found two interesting strings, “flarebearstare” which could be a password, and another string that looks like a Base64 alphabet with the uppercase and lower case sections swapped in order.
I following the cross-reference for the “flarebearstare” string, finding a function with a data decoder loop. This function is passed data and loops through each byte, subtracting each character in order of “flarebearstare” from the current byte.
Decoder function
Looking over this functionality, I started to write up some code to decode the flag. I grabbed a Base64 library that needed a small modification to use a custom character set. My fork of the code can be found at this repo.
In the screenshot below, you can see my final script in a Jupyter notebook. As an aside, I have been using it for many challenges and other projects to test out decoder and other functionality. They have been instrumental in quick prototyping and experimentation.
Success there mostly is the flag. You can see there is some weirdness in the decoding of the flag, but this script decodes the main part of it needed in my mind to call it a solution.
Full Code
b64encoded = "UDYs1D7bNmdE1o3g5ms1V6RrYCVvODJF1DqxKTxAJ9xuZW=="
b64_alphabet = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/'
b = b64()
b64decoded = b.decode(b64encoded, alttable=b64_alphabet)
for i in b64decoded:
print (hex(ord(i)) + " ", end="")
print ()
count = 1
key = "flarebearstare"
key_len = len(key)
output = ""
counter = 0
for i in b64decoded:
temp = ord(i) - ord(key[counter])
print (chr(temp),end="")
#print (i, hex(temp), key[counter], chr(temp))
output += chr(temp)
if counter+1 < key_len:
counter+=1
else:
counter = 0
This is the second in a series looking at part of the Revil malware. The first post covered a triage and unpacking of the first stage. The post will look at the high-level flow and look in-depth at the configuration embedded in the sample and some options.
Looking at the flow diagram (pictured on the left), there is a pretty straightforward flow to the sample. It initially sets itself up by resolving the import table, reading the embedded configuration data, and command-line arguments. After the initial configuration is loaded and processed, the sample starts to execute the encryption and beaconing activities. Finally, it cleans up after itself clearing itself from memory, deleting itself from disk, and exiting. Now that we have an overview of this stage, we will look at how strings are obscured and how the configuration is loaded and processed.
String Encryption
When you run a string identification tool on this binary, you find there are not many readable strings. This sample obscures the vast majority of its strings. When analyzing it, you see many calls similar to this example.
This function located at 0x0040575B uses RC4 to decrypt the strings from a data block located at either 0x0040F270 or 004101B0. These blocks contain both the key and the encrypted data itself. The function is passed a pointer to the data block, offsets of the key and encrypted data, key size, and data size. It returns the clear string as the last parameter of the function call.
In the function that I labeled “mw_run_rc4_decrypt” (0x0040646A), you find a fairly standard RC4 decryption set of routines. I have recreated this functionally in python, which I used heavily when analyzing this sample to label the string variables.
!pip3 install arc4
from arc4 import ARC4
import pefile
import binascii
secondstage = "file1.bin"
pe = pefile.PE(secondstage)
section_offest = 0xf000
for section in pe.sections:
if b".data" in section.Name:
hex_data_1 = section.get_data()[(0x101b0-section_offest):]
hex_data_2 = section.get_data()[(0xf270-section_offest):(0xf17)]
def decrypt(data, position, keylen, datasize):
key = data[position:position+keylen]
cipher = ARC4(key)
rc4_data = cipher.decrypt(data[position+keylen:position+keylen+datasize])
# Convert to string
string_data = ""
for byte in rc4_data:
string_data += chr(byte)
return string_data
Revil Configuration
The encrypted configuration is stored in the .7tdlvx section of the binary. The data is RC4 encrypted like string data was. It also includes some tamper protection; there is a CRC32 value stored with the data. Below is the structure of the configuration section. I have labeled the data segments with numbers.
Decryption Key
crc32 Checksum
Configuration Size
Start of Encrypted configuration
The function shown in the image below is used to decrypt the data from the 7tdlvx section. When executed, the CRC32 value of the data is checked, and if it matches, the function is called to run the RC4 decryption. Pointers to the key, key length, address of the encrypted data, and size of the encrypted data are passed into the function to decrypt the data.
After the RC4 decryption, it returns a block of JSON data to a variable for further processing. Below is an abbreviated version of the configuration for readability. I put a full copy of it at the end of this post.
To assist in processing and analysis of the configuration I created the following python script to extract and parse the configuration file from the sample.
!pip3 install arc4
from arc4 import ARC4
import pefile
import binascii
import json
import pprint as pp
secondstage = "file1.bin"
try:
pe
except NameError:
pe = pefile.PE(secondstage)
key_len = 0x20
section_name = ".7tdlvx"
# located in the .7tdlvx section
for section in pe.sections:
if bytes(section_name, 'utf-8') in section.Name:
section_data = section.get_data()
key = section_data[:key_len]
crc = section_data[key_len:key_len+0x4]
config_len = int.from_bytes(section_data[key_len+0x4:key_len+0x8], "little")
print(hex(config_len))
data_3_hex = section_data[key_len+0x8:config_len+key_len+0x8]
print (len(data_3_hex))
cipher = ARC4(key)
dump = cipher.decrypt(data_3_hex)
# Store JSON to file
f = open("config_decoded.txt", "wb")
f.write(bytearray(dump))
f.close()
cfg = json.loads(dump[:-1])
pp.pprint(cfg)
As shown in the configuration example, the configuration is in a JSON-like format that needs to be parsed further to be used by the malware. In the first part of the parsing process, an array is built out, defining the elements and how to process them. The three elements in the example below are and string for the JSON key, an integer for the data type, and a function pointer to the function to parse the data.
// String with configuration Name
configuration_structure[0] = (int)&str_pk;
// Data Type
configuration_structure[1] = 5;
// Funcation to handle the data and write it to a Global Variable
configuration_structure[2] = (int)mw_cfg_pk_decoder;
The parser array along and decrypted configuration are passed into a function the walks through the JSON configuration. The function searches for the keys in the JSON configuration, and the parser function is called to process the configuration content.
Some examples of configuration values that take further processing are ‘pk’, ‘img’, and ‘nbody’. These are all base64 encoded strings that are decoded before being stored in memory. Using the following python code we can see the values stored in these keys.
pk: b'4abc40389f119032086fb8eeac6bb790919cba2f504738262f245eddd5313522'
img: All of your files are encrypted!
Find {EXT}-README.txt and follow instuctions
nbody: ---=== Welcome. Again. ===---
[+] What's Happened? [+]
Your files have been encrypted and currently unavailable. You can check it. All files in your system have {EXT} extension. By the way, everything is possible to recover (restore) but you should follow our instructions. Otherwise you can NEVER return your data.
[+] What are our guarantees? [+]
It's just a business and we care only about getting benefits. If we don't meet our obligations, nobody will deal with us. It doesn't hold our interest. So you can check the ability to restore your files. For this purpose you should visit our website where you can decrypt one file for free. That is our guarantee.
It doesn't metter for us whether you cooperate with us or not. But if you don't, you'll lose your time and data cause only we have the private key to decrypt your files. In practice - time is much more valuable than money.
[+] How to get access to our website? [+]
Use TOR browser:
1. Download and install TOR browser from this site: https://torproject.org/
2. Visit our website: http://4to43yp4mng2gdc3jgnep5bt7lkhqvjqiritbv4x2ebj3qun7wz4y2id.onion
When you visit our website, put the following data into the input form:
Key:
{KEY}
!!! DANGER !!!
DON'T try to change files by yourself, DON'T use any third party software or antivirus solutions to restore your data - it may entail the private key damage and as a result all your data loss!
!!! !!! !!!
ONE MORE TIME: It's in your best interests to get your files back. From our side we (the best specialists in this sphere) ready to make everything for restoring but please do not interfere.
!!! !!! !!
Conclusion
We covered a couple of the obfuscation functions in this stage of the malware, the use of RC4 in many places to hide plain text data making various functions harder to detect and reverse engineer. The configuration section allows for a lot of flexibility. I can imagine allowing for a fair amount of automation in the build system, simplifying the building and deploy time. The next post will cover the file encryption function section of the code.
Configuration Keys
The key below is a select list of some of the configuration options that affect the flow or functionality of the sample. There are many more keys shown in the full configuration.
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 third challenge, you are greeted with a nice goat named Elfie that when you are typing characters show up on the screen. As always I start off by checking out what kind of binary I am looking at
λ file elfie
elfie: PE32 executable (console) Intel 80386, for MS Windows
As I said we are greeted by thie goat that eats magic keys
After doing some initial analysis in Ghidra found some strings that indicate that this file might be a python executable.
Additionally, the icon embedded in the binary should have been a giveaway. I guessed it was probably a pyInstaller executable. I ran it through pyinstextractor.py to expand it out and get a copy of the python source to analyze.
C:\Users\IEUser\Desktop
λ pyinstxtractor.py elfie.exe
C:\Tools\pyinstxtractor\pyinstxtractor.py:86: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
import imp
[*] Processing elfie.exe
[*] Pyinstaller version: 2.1+
[*] Python version: 27
[*] Length of package: 12034944 bytes
[*] Found 26 files in CArchive
[*] Beginning extraction...please standby
[!] Warning: The script is running in a different python version than the one used to build the executable
Run this script in Python27 to prevent extraction errors(if any) during unmarshalling
[*] Found 244 files in PYZ archive
[+] Possible entry point: _pyi_bootstrap
[+] Possible entry point: pyi_carchive
[+] Possible entry point: elfie
[*] Successfully extracted pyinstaller archive: elfie.exe
You can now use a python decompiler on the pyc files within the extracted directory
C:\Users\IEUser\Desktop
I found the file elfie and opened it in VSCode to look at the contents.
it looks to be full of Base64 strings that are concatenated together, decoded, and executed.
Strings
I changed the final operation to print the encoded python code for further analysis.
The next layer down looked more like normal python code with obfuscated variable names.
Even looking at the obfuscated code the is pretty obvious but I wanted to clean up some of the variable names to make sure I was not missing anything else.
This is the first in a series looking at part of the REvil malware. I will start off by showing a brief triage overview of the sample and then dive into the initial details of the stage 1 unpacker. Let us get into it!
Initial Triage
The Revil (aka Sodinokibi) malware is ransomware that encrypts files on a victim’s disk and leaves a note to head to a Tor link to send payment to decrypt your files. The sample I am analyzing has the following has the hash.
I ran the sample using the sandbox Any.Run, and during the run, you can see it encrypt the files and change the background to instruct the user to look at the ransom note.
After the quick triage showing what this sample does to the victim’s computer, we will start to dive deeper into various aspects of how this sample operates, starting with the initial unpacking.
Unpacking
The Revil malware has two stages, the first stage contains an RC4 encrypted second-stage payload that is unpacked into memory. The second stage payload executes the ransomware functions encrypting files on disk. This executable follows a few steps where the second stage data is decrypted, placed into memory, and then executed.
The main function reflects this flow, looking at the marked-up IDA de-compiler screenshot. You can see the RC4 key copied into a memory buffer used to set up the RC4 KSA.
The resulting S array is passed into the decryption payload function.
The decryption loop pulls data from a pointer I named PAYLOAD_DATA that points to the start of the .enc section of the binary file. The data is decrypted and written back into the .enc section.
To simplify second stage extraction for further analysis, I have written a simple python script to extract the payload, decrypting it, and writing the second stage content to disk.
import pefile
import ARC4
pe = pefile.PE(firststage)
key = "kZlXjn3o373483wb6ne1LIBNWD3KWBEK"
section_name = "enc"
for section in pe.sections:
if bytes(section_name, 'utf-8') in section.Name:
section_data = section.get_data()
cipher = ARC4(key)
dump = cipher.decrypt(section_data)
print (dump[:20])
f = open("stage2.bin", "wb")
f.write(bytearray(dump))
f.close()
After this data is decrypted, it is loaded into memory using Windows Native API calls. First, it allocates a memory space using NtAllocateVirtualMemory and then writes the decrypted data to the newly allocated memory location.
It then dynamically resolves some Imports and executes the second stage code by calling into ecx, which points to the new memory region.
Close out
Now the second stage is unpacked and running! In the next post in this series, we will cover how to extract the configuration and parse the configuration data.
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
The second challenge from this season built on the first challenge. It was another password entry challenge but with a more complicated password encoding scheme.
First things first I validated what kind of file I was looking at.
λ file very_succes
very_succes: PE32 executable (console) Intel 80386, for MS Windows
When running the file I entered some test data to see how it looked to a user.
I switched back to Ghidra to do some static analysis on this binary and found the area of code that looked to handle the password comparison. The first check that jumped out to me was the length check that checked to see if the password was 37 characters long.
Then I found the encoding and matching bulk of the code which I have commented below. This block of code uses a combination of XOR and Bit-wise shifting of the characters to encode each character of the input to match it against the encoded password.
It took me a little bit to see that the SCASB instruction at 0x4010c8 is used to set the zero flag to 1 if the encoded value does not match and jump to a failure condition. Otherwise is set to 0 for success and continues the loop.
I ran the binary using x64dbg to walk through and monitor execution manually setting the Zero Flag to check how the algorithm operated. I also identified the location of the encoded key stored in EDI and copied out that data in hex.
As with the first challenge in this season I crudely implemented the encoder in python and using brute force was able to successfully generate the key.
