I'm known for my Ghidra stand-up comedy routines. In order to make them enjoyable for everyone in the room, the font size better be not as tiny as it normally is when you do your day-to-day reverse engineering. There are two places to consider: 1. menus, dialogs, etc. 2. specialized components like the assembly listing view and the decompiler # Font Size Override The first can be adjusted by editing the launch.properties file, which is normally located in the support directory within your Ghidra directory (C:\Users\born\Programs\ghidra_11.0.1_PUBLIC\support\launch.properties on my machine). Just add the following somewhere in the file to adjust the font size to 23:
VMARGS=-Dfont.size.override=23
# Components In order to adjust the font size in dialogs, I recommend searching the settings dialog ("Edit" -> "Tool Options") for "font". By the time of writing this involved the following entries (I use 12 for small and 18 for presentations): * Byte Viewer * Console * Decompiler -> Display * Graph -> Program Graph Display Options -> Miscellaneous * Listing Display


This blag post covers scanning the Ghidra virtual memory with YARA. Do you want to know more?


**Disclaimer:** If you are not running Windows on your host, you might not get anything out of this post. Sorry Tux. I am convinced that the Windows Sandbox is one of the best virtualization solutions to do dynamic malware analysis (for Windows malware, at least). The reason is quite simple: Distinguishing a Windows 10 Sandbox instance from the actual underlying Windows 10 install should be very difficult for malware. Specifically if the host is running on HyperV with Guarded Host enabled, my current understanding is that there are little to no differences between the two, but they are neatly isolated from one another. The configuration options are limited, but you can easily cook up a config that launches a WindowsSandbox instance that has all the tools you need for some basic unpacking & dynamic analysis. This is what my malware analysis sandbox looks like at launch: New Windows Sandbox I have successfully executed a number of samples that evade execution in other virtualized environments. That's a far cry from rigorous testing, so take my praise with a grain of salt. Still, it might be worth a try, the setup is really easy. Do you want to see my config?


The Zlob malware contains lots of bogus API calls to hinder analysis. This blag post describes how to use a script in Ghidra to automate the process of patching out those calls with NOP instructions. Is that even hard?!


Directing your attention as a reverse engineer is key for not wasting your life looking at irrelevant code. This blag post will use an anti-analysis technique used in the Zloader malware as an example to practice this art. We will also take a short detour into code-level obfuscation and are going to re-implement the API hashing function from Zloader in Python. This post is aimed towards reverse engineering beginners that have already heard about API hashing. If you don't know, what Ghidra is or how to use it, you will need to brush over some parts of this post. Tell me everything!


In this blog post, we will follow one of herrcore's awesome videos and re-implement the automation as a Ghidra script in Java. The video in question is part of a series about a legacy malware family called Hamweq. CERT Polska published an extensive analysis of Hamweq: The malware implements a IRC-based botnet with worm-like capabilities. In this post we will solely focus on the string deobfuscation functionality in the malware. Show me what you got!


This blag post describes my though-process during identification of the string deobfuscation method in a sample belonging to the Zloader malware family. Specifically, I wanted to identify the function or functions responsible for string deobfuscation only using static analysis and Ghidra, understand the algorithm, emulate it in Java and implement a Ghidra script to deobfuscate all strings in a binary of this family. The target audience of this post are people that have some experience with static reverse engineering and Ghidra but who always asked themselves how the f those reversing wizards identify specific functionality within a binary without wasting hours, days and weeks. Show me what you got!


This post will explain, how to identify a function responsible for string deobfuscation in a native-PE malware sample. We will use a KpotStealer sample as a concrete example. KpotStealer (aka Khalesi or just Kpot) is a commodity malware family probably circulated in the shadowy parts of the internet since 2018. It got its name from a string publicly present on the Admin-Panel. After we found the function we will understand the data structure it uses and emulate the decryption of a string with CyberChef and Binary Refinery. An interesting detail here is that Ghidra currently does not guess the function signature correctly. Finally, we will develop a Java script (hehe) for Ghidra to automatically deobfuscate all strings given the corresponding obfuscation function. Show me what you got!


This post describes the memory layout as well as the method used by the Sodinokibi (or REvil) ransomware to protect its strings. It will then list a few Java snippets to interact with the Ghidra scripting API and finally explain a working script to deobfuscate all strings within a REvil sample. If you don't care about the explaination, you can find the most recent version of the script you can simply import into Ghidra on github. I want it all.


Since the temperature of scripting in Ghidra is so high at the current point in time, I want to tell you that scripting it in Java is so much better than scripting it in Python. After that I'll randomly motivate why one wants to get the "original bytes" from a sample and how to do it. Show me what you got!


Found another rabbit hole! While reading my daily digest of tubes [an article about the Mozi bot](https://blog.netlab.360.com/mozi-another-botnet-using-dht/) sparked my interest. Peer-to-peer (P2P) botnets are always cool and this one has some worm-like capabilities and seems to hide its traffic within bittorrent communications. Naturally I wanted to take a look at the sample. But you will not believe, what happened next!


I have spent some time reverse engineering Delphi binaries with IDA & HexRays at work, but IDA tends to make a few mistakes and I wrote a few scripts to fix them. Then [Ghidra](https://ghidra-sre.org/) came along and I was very curious to know how it would fare against some of the Delphi malware that I know and ~~loathe~~ love. I'd say it does about as bad as IDA, and so I went on a journey to rewrite my scripts from work as Ghidra scripts. TL/DR; [The scripts are on GitHub](https://github.com/huettenhain/dhrake/). But would you like to know **more**?


While understanding existing code during software development or reverse engineering, it is quite useful to be able to quickly see other instances of the same variable or function in the current code view. To enable this feature in Ghidra, I suggest you perform the following two configuration changes: Under "Edit" → "Tool Options..." 1. select "Listing Fields" → "Cursor Text Highlight" in the tree view on the left and change "Mouse Button To Activate" to "LEFT" 2. select "Key Bindings" in the tree view on the left and assign a key you can easily press to "Highlight Defined Use" ("SPACE" for example) Happy understanding! Update (2019-11-22): Actually "Highlight Defined Use" refered to in item 2. of the above list is not the same as the highlighted parts from item 1 :sadkeanu:.