{
	"id": "094ace0f-0b7d-4fde-a4c1-6e2e13e2543d",
	"created_at": "2026-04-06T00:18:45.93876Z",
	"updated_at": "2026-04-10T03:20:40.088142Z",
	"deleted_at": null,
	"sha1_hash": "8d1d62a7fcc7fe11b77fab471c50f9126b7f8802",
	"title": "Malware Analysis —Manual Unpacking of Redaman",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3380383,
	"plain_text": "Malware Analysis —Manual Unpacking of Redaman\r\nBy jon\r\nPublished: 2022-01-26 · Archived: 2026-04-05 13:19:11 UTC\r\nIn this post, we are looking to manually unpack the sample called Redaman, which is a banking trojan. Some of its\r\ncapabilities include:\r\nMonitor browser activity,\r\nDownloading files to the infected host\r\nKeylogging activity\r\nCapture screen shots and record video of the Windows desktop\r\nCollecting and exfiltrating financial data, specifically targeting Russian banks\r\nSmart card monitoring\r\nShutting down the infected host\r\nAltering DNS configuration through the Windows host file\r\nRetrieving clipboard data\r\nTerminating running processes\r\nAdding certificates to the Windows store\r\nInfo from Unit42 Analysis.\r\nWhat makes this sample unique and an excellent training sample to practice manual unpacking is because this\r\nsample performs a fairly simple packing process: PE overwrite and a secondary DLL Injection.\r\nSelf-Injection, or in this example the PE Overwrite occurs when the malware allocates a “stub” in itself, transfers\r\nto that stub address, allocates that stub area and write whatever malicious content it needs to in there, and then\r\nchanges the permissions, and then run from that overwritten area.\r\nA Better Explanation.\r\nPacked Sample\r\nWe can identify this file as packed based on a number of info:\r\nHigh level entropy on the main file with PEStudio:\r\nPress enter or click to view image in full size\r\nhttps://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb\r\nPage 1 of 14\n\nChecking in IDA, we see that first there is some obfuscation, barely any functions, and only a small amount of\r\nanalyzed code (blue bar at the top of screenshot)\r\nPress enter or click to view image in full size\r\nPE Overwrite\r\nhttps://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb\r\nPage 2 of 14\n\nTo start we look for where virtual allocation of memory takes place which in this case it is the function\r\nVirtualAlloc. The return value for VirtualAlloc is the base address of the allocated region. Which we can find in\r\nthe EAX register. We put a breakpoint at the return of the function:\r\nPress enter or click to view image in full size\r\nThis will help us to see how many times and where memory is being virtually allocated.\r\nWe also want to add a breakpoint at the entry of VirtualProtect, this is where the protections and access is\r\nchanged. The first argument to VirtualProtect will be the address to the memory section which protections will be\r\nchanged. It needs to change the protections to get the permission to write\r\nPress enter or click to view image in full size\r\nNow we run the debugger until we hit our second breakpoint (First one is always on the entry point of the file).\r\nPress enter or click to view image in full size\r\nhttps://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb\r\nPage 3 of 14\n\nFrom the screenshot we hit the breakpoint, we right click on the address in EAX and follow in dump. We can see\r\nthat at address 0003000 there is a large amount of zeros where VirtualAlloc has allocated space.\r\nContinuing on we hit the return of VirtualAlloc again at address 021B0000. So we know that VirtualAlloc is used\r\nat address 0003000 and 021B0000. Our next hit is the entry of VirtualProtect:\r\nPress enter or click to view image in full size\r\nChecking the first argument passed to VirtualProtect in the EAX register we can automatically see that instead of\r\nzeros we now have what looks to be an exe (the MZ or hex 4D 5A gives it away). At this point we now have\r\ngotten to the point in the malware where not only has the main payload been unpacked but now it is ready to have\r\nits permissions and access changed, we now right click on the dump and choose the “Follow in Memory Map”\r\nPress enter or click to view image in full size\r\nhttps://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb\r\nPage 4 of 14\n\nIn memory map we can see that at the address where the exe is loaded, (021B0000) that location has read and\r\nwrite protections. We now dump out that location and examine it.\r\nUnpacked File\r\nImmediately after opening the “unpacked” file we notice that is indeed packed again based on IDA.\r\nPress enter or click to view image in full size\r\nThere are not enough functions and small amount of analyzed code by IDA. Looking at the few functions that are\r\navailable we can start to see some interesting actions taking place.\r\nhttps://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb\r\nPage 5 of 14\n\nPress enter or click to view image in full size\r\nloc_4011AA looks to be a loop. The key is moved to EDX and XORed with a byte from unk_403000 then rotated\r\nleft. Then theres some decreasing and increasing happening and then there is a conditional jnz which moves the\r\ncode along only if not being equal to zero.\r\nGet jon’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nThis is most likely the encryption or encoding algorithm used.\r\nhttps://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb\r\nPage 6 of 14\n\nFollowing along we can see that it is loading DLLs into a buffer. LoadLibraryA is called which provides a return\r\nto a handle that can be used in GetProcAddress below:\r\nhttps://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb\r\nPage 7 of 14\n\nNext it pushes into a buffer RTLDecompressBuffer which decompresses the buffer which is in this case:\r\nNTDLL.DLL\r\nhttps://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb\r\nPage 8 of 14\n\nNext called up is DLLGetGlassObject of NTDLL.DLL and then a call to GetProcAddress.\r\nWe then see that EAX which holds RTLDecompressBuffer is moved to EDX and then called again. Looking at the\r\ndocumentation for RTLDecompressBuffer, the parameters are:\r\n[in] CompressionFormat which is 102h\r\n[Out] UncompressedBuffer Buffer which is [ebp+lpBuffer]\r\n[in] UncompressedBufferSize which is [ebp+dwSize]\r\n[in] CompressedBuffer buffer that contains the data in ECX which holds unk_403000 (encryption\r\nmethod)\r\n[in] CompressedBufferSize which is the length 29CD6h\r\n[out] FinalUncompressedSize which is the return stored at EAX\r\nThis result is then cmp with itself and if it meets the conditional it continues on.\r\nPress enter or click to view image in full size\r\nhttps://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb\r\nPage 9 of 14\n\nsub_40102A loads KERNEL32.DLL and calls RTLDecompressBuffer in the same way NTDLL.DLL is loaded in.\r\nThen we start to see the formation of a temp file\r\nhttps://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb\r\nPage 10 of 14\n\nThe malware uses GetTempFileNameW, creates the file with CreateFileW, writes to the file using WriteFile and\r\nthen loads the file as a DLL using LoadLibraryA. (Partially Pictured)\r\nAn finally a buffer with the string “host 00000000000” before the code ends. The zeros are probably changed to\r\nsome unique ID that the malware uses to send back to a C\u0026C server.\r\nhttps://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb\r\nPage 11 of 14\n\nThat’s all we can get out of IDA so now we move to the debugger and use the same methods to find the payload\r\nDLL\r\nUnpacking the “Unpacked” File\r\nSince we know the next step of this malware is to perform a DLL injection, we can put a breakpoint at\r\nLoadLibraryW (not LoadLibraryA)…\r\n'A' stands for ASCII and 'W' stands for byte string and the 'A' calls are just the wrappers around the\r\n'W' ones so placing the breakpoint at the LoadLibraryW will hit all the load DLL calls.\r\nSource\r\nand from there we can see the path where the DLL will be dropped.\r\nPress enter or click to view image in full size\r\nhttps://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb\r\nPage 12 of 14\n\nChecking that location we can find the file and checking in PEStudio we can see that it is a DLL (file maybe\r\nhidden).\r\nPress enter or click to view image in full size\r\nConclusion\r\nSo to wrap things up, we successfully unpacked the inital Redaman file using VirtalAlloc and VirtualProtect, we\r\nthen discovered the encryption algorithm it uses, and finally unpacked once again with LoadLibraryW to find the\r\npayload DLL.\r\nThanks for reading.\r\nResources:\r\nRussian Language Malspam Pushing Redaman Banking Malware\r\nUnpacking Redaman Malware \u0026 Basics of Self-Injection Packers — ft. OALabs\r\nhttps://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb\r\nPage 13 of 14\n\nUnpacking Redaman Malware \u0026 Basics of Self-Injection Packers — ft. OALabs (Video)\r\nSource: https://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb\r\nhttps://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://jonahacks.medium.com/malware-analysis-manual-unpacking-of-redaman-ec1782352cfb"
	],
	"report_names": [
		"malware-analysis-manual-unpacking-of-redaman-ec1782352cfb"
	],
	"threat_actors": [],
	"ts_created_at": 1775434725,
	"ts_updated_at": 1775791240,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8d1d62a7fcc7fe11b77fab471c50f9126b7f8802.pdf",
		"text": "https://archive.orkl.eu/8d1d62a7fcc7fe11b77fab471c50f9126b7f8802.txt",
		"img": "https://archive.orkl.eu/8d1d62a7fcc7fe11b77fab471c50f9126b7f8802.jpg"
	}
}