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:.


This post is written for aspiring reverse engineers and will talk about a technique called _API hashing_. The technique is used by malware authors to hinder reverse engineering. We will first discuss the reasons a malware author may even consider using API hashing. Then we will cover the necessary technical details around resolving dynamic imports at load-time and at runtime and finally, will described API hashing and show a Python script that emulates the hashing method used in Sodinokibi/REvil ransomware. Read on


Earlier this year, I was thrilled to hear that my submission for a talk at this year's [FrOSCon](https://www.froscon.de/) (Free and Open Source Software Conference) was accepted. [The talk](https://programm.froscon.de/2019/events/2350.html) is about Ghidra, the reverse engineering tool which was recently release into open source by the NSA. Since I expected a very heterogeneous audience with people from all kinds of industries with all kinds of backgrounds, I decided to give a long introduction with a lot of motivation for reverse engineering and only use the last quarter or so of the talk to actually show Ghidra's capabilities. You can find the [slides here](https://blag.nullteilerfrei.de/wp-content/uploads/2019/08/FrOSConTalk2019-Ghidra.pdf), the source [of the slides on github](https://github.com/larsborn/FrOSCon2019-Ghidra-Talk) and a recording at [media.ccc](https://media.ccc.de/v/froscon2019-2350-ghidra_-_an_open_source_reverse_engineering_tool). Based on feedback after and during the talk, I added a bullet point under Motivation: a lot of people at FrOSCon seemed to be in the position where a wild binary blob appeared and they had to deal with it. Some because they found an old service running with source code not available (or readable) anymore and some because they want to re-implement a protocol that is not documented.


A while back [I blawgd about how to get the MSDN library for offline use](https://blag.nullteilerfrei.de/2017/12/21/get-the-msdn-library-for-offline-use/). However, the Help Viewer has its problems. I won't list all of its problems, but it was certainly a bad candidate to integrate Win32 API documentation support to Ghidra. There is [a pretty neat project by Laurence Jackson](http://laurencejackson.com/win32/), but I think I just found something a little better even: Microsoft provides [a download of the MSDN Library for Visual Studio 2008 SP1, stand-alone, offline, as an ISO](https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=20955) - smell this, Help Viewer: So this is nice, but the main point of this exercise was to integrate this into Ghidra. If that's something you care about, read on.


After a system crash, Ghidra greeted me with the message
Unsupported file system schema: idata
when I tried to open the project. Click here to see what happened next!