{
	"id": "1a51cb10-19fc-4115-8221-a11a369264db",
	"created_at": "2026-04-06T00:14:56.798054Z",
	"updated_at": "2026-04-10T03:20:33.871924Z",
	"deleted_at": null,
	"sha1_hash": "6c2323f36ea8af20d7bd69dbf8c2f2455e7affef",
	"title": "Malicious Packer pkr_ce1a",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 9570749,
	"plain_text": "Malicious Packer pkr_ce1a\r\nBy Malwarology LLC\r\nPublished: 2022-11-21 · Archived: 2026-04-05 18:55:05 UTC\r\nThis packer has been observed delivering a wide variety of malware families including SmokeLoader and Vidar\r\namong many others. It has been observed in the wild going back a number of years potentially to 2017. The\r\nparticular variant of the packer analyzed here contains two sets of bytes with no apparent use which occur on\r\neither side of values that are integral to the decoding and unpacking process. These two byte strings are stable\r\nacross many months of observed samples of this packer. What follows is a detailed analysis of the first stage of\r\none sample of this packer which delivers a SmokeLoader payload. Until a widely recognized name or identifier\r\ncan be determined for this packer, it has the designation pkr_ce1a .\r\nThis sample has two known filenames. The first, 6523.exe , is observed in the wild in the path component of the\r\nURL used to distribute the file.1 The second, povgwaoci.iwe , is located in the RT_VERSION resource within the\r\nVS_VERSIONINFO structure in a field named InternationalName . This field along with others in the same\r\nStringTable structure are not parsed by Exiftool or Cerbero Suite. This indicates that the structure is malformed or\r\nnon-standard.\r\nAccording to AV detection results, the correct identification of the unpacked file, SmokeLoader, does appear.\r\nThere is also one detection based on dynamic analysis: Zenpack.\r\nThe import hash of this sample is shared by a group of other files.2 However, the large majority of imported\r\nfunctions are called in dead code located after opaque predicates. Therefore, the usefulness of this import hash is\r\nalmost nothing. Closer analysis of the opaque predicates in this sample can be found below.\r\nAccording to the File Header, the timestamp of compilation is 2022-02-16T10:14:32Z. The linker version found in\r\nthe PE32 Optional Header is 9.0.\r\nLinker Version 9.0\r\nThe compiler is identified as Visual Studio 2008 Release according to function signatures in Ghidra that match a\r\nnumber of library functions in the sample. One example of this detection for the ___security_init_cookie\r\nhttps://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nPage 1 of 15\n\nfunction is shown in the figure below.\r\nCompiler Detection: Visual Studio 2008 Release\r\nThe majority of the library functions found in the sample are from Microsoft Visual C++ 9.0.21022. This is\r\nidentified in the sample’s rich signature.\r\nRich Signature: VC++ 9.0.21022\r\nhttps://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nPage 2 of 15\n\nMain Function\r\nThe instructions highlighted in yellow in the figure above are examples of junk code insertion. These are dummy\r\ninstructions that are placed between relevant instructions with the goal of making signature development more\r\ndifficult. The instructions at the end of the function highlighted in white are not executed. These highlight\r\ncolorings are used throughout the screenshots of this analysis.\r\nThe first instructions in the main function calculate the size of the encoded data that contains the shellcode which\r\nis the next stage of the packer. The first part is read from a constant in the .data section at address 0x41cc3c .\r\nThe second part is hardcoded in the main function at address 0x406573 . The size is calculated in the next\r\ninstruction by adding the two parts together. The resulting size is written to a variable in the .data section.\r\nHighlighted in the figure below are the bytes before and after the first constant. These two sets of bytes are not\r\nread during the execution of the packer, and their purpose is unknown. However, they are stable across builds of\r\nthis packer going back for months at least.\r\nhttps://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nPage 3 of 15\n\nStable Surrounding Bytes\r\nThe address where the encoded data is located goes through a similar process. The first part is read from the\r\n.data section then written to a variable in the same section. The addition to the second part does not occur until\r\nlater in the unpack_shellcode function. The bytes surrounding this part are shown in the figure below.\r\nStable Surrounding Bytes\r\nThe next set of instructions handles loading kernel32.dll and resolving the address of LocalAlloc .3 These\r\ninstructions taken together are unique to this packer and shared across hundreds of variants. The stray instruction\r\nat address 0x406588 is part of the previous logical grouping of instructions. This is an example of interleaving\r\ncode that is meant to make signature development more difficult.\r\nResolve LocalAlloc\r\nThe call to LocalAlloc is obfuscated by calling it from the eax register. This is a type of function call\r\nobfuscation. The uBytes parameter to the function is 63072 bytes which is the result of the calculation described\r\nabove.\r\nObfuscated Call to LocalAlloc\r\nhttps://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nPage 4 of 15\n\nThe final instructions in the main function are calls to other malicious functions and finally a call to the entry\r\npoint of the decoded shellcode. The next stage of the packer starts after that call.\r\nChange Protection Function\r\nThis function is a wrapper around an obfuscated call to VirtualProtect . Starting at address 0x4058e3 and\r\ncontinuing until the call to GetProcAddress , the name of the function VirtualProtect is written character-by-character, out of order, to a variable in the .data section. Building the function name in this way is an example\r\nof variable recomposition. The address of this string is then used as the lpProcName parameter to\r\nGetProcAddress . Finally, a call is made to VirtualProtect to change the protection from PAGE_READWRITE\r\n( 0x4 ) to PAGE_EXECUTE_READWRITE ( 0x40 ) thus enabling execution in the newly allocated memory.\r\nhttps://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nPage 5 of 15\n\nThe flNewProtect parameter to the VirtualProtect function is also obfuscated by adding together 0x20 and\r\n0x20 . This hides the PAGE_EXECUTE_READWRITE flag of 0x40 from being located near the call to\r\nVirtualProtect . This is a form of argument obfuscation.\r\nObfuscated New Protect Value\r\nThis function performs three actions that are interspersed with anti-analysis code. The first action is moving the\r\nencoded data from its starting location in the .data section to the newly allocated memory.\r\nMove Encoded Data\r\nNote the instructions at addresses 0x405aa7 and 0x405acd . These are both opaque predicates. An opaque\r\npredicate appears to be a conditional jump, but the conditions can only be met in one way making the jump\r\neffectively unconditional. The one at the top is basically a fake: it never jumps. The one in the middle always\r\njumps. This one additionally encloses a block of dead code. This packer very frequently couples dead code\r\ninsertion with opaque predicates that always jump over the dead code. The function calls in the dead code are\r\nincluded in the import table making identification via import hash of little utility.\r\nhttps://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nPage 6 of 15\n\nLater on in this function is the call to the decode function. After that is a call to a function which shifts the\r\npointer to the decoded shellcode. The shift changes the offset from the start of this data to the location of the\r\nshellcode original execution point (OEP). Because the shellcode is position independent, this OEP is also offset\r\nzero of the shellcode. Both of these functions are analyzed in more detail below.\r\nThe shift_shellcode_oep function is additionally wrapped in an anti-emulator loop which has a very high\r\nnumber of iterations. This slows processing in an emulator which can potentially cause a timeout and an analysis\r\nfailure.\r\nDecode and Shift Shellcode OEP Functions\r\nNote the comparison instruction at address 0x406486 . During the anti-emulation loop, the call to\r\nshift_shellcode_oep is made once when the counter reaches 0x770e . This is a type of anti-emulation\r\ncircumvention countermeasure. A basic method for circumventing extremely long loops that target emulators is to\r\npatch out the loop. Another is to detect the loop in the emulator and then modify the counter to leave the loop.\r\nBecause the shift function is called once at a point in the loop, either of these circumventions could end up not\r\nexecuting this function and would leave the emulator unable to execute the shellcode correctly.\r\nThe unpack_shellcode function overall contains ten opaque predicates primarily of the same type shown above.\r\nOne of them is slightly different in that it creates a dead end filled with dead code. The last instruction in the dead\r\nend is a call to terminate . Therefore, this appears to be a location where the execution of the packer ends.\r\nhttps://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nPage 7 of 15\n\nOpaque Predicate with Dead End\r\nThere are a total of four anti-emulation loops similar to the one analyzed above. Two of these wrap opaque\r\npredicates which in turn wrap inserted dead code. One, however, in addition to wrapping two opaque predicates,\r\nalso contains two additional anti-emulator behaviors. Both of these are calls to unusual APIs: GetGeoInfoA and\r\nGetSystemDefaultLangID . During analysis, Qiling emulator halted with an exception because neither of these\r\nAPI calls have been implemented.\r\nAnti-Emulation: Unusual API Calls\r\nIn the very first code block of the unpack_shellcode function, a new and subsequently unused exception handler\r\nis registered. Chances are about even that this is an anti-emulation behavior or it is just junk code. If it is anti-emulation, it is targeting older emulators based on specific versions of Unicorn Engine which do not implement\r\naccess to the Windows Thread Information Block (TIB). Moving the contents of fs:0x0 as happens at address\r\n0x405983 would fail in that particular environment. This type of anti-emulation is an unimplemented opcode.\r\nhttps://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nPage 8 of 15\n\nRegister New SEH\r\nIn the last block of the unpack_shellcode function, before the return, the SEH is reset back to the previous\r\nhandler. This occurs right after a junk call to LoadLibraryW from which no functions are subsequently resolved.\r\nLast Block of unpack_shellcode\r\nhttps://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nPage 9 of 15\n\nDecode Function (Truncated)\r\nThe data is decoded in chunks. So this function has three basic purposes: convert the encoded shellcode size to a\r\nchunk count by dividing by 8, wrapping a loop around the call to the decode_chunk function, and then calling\r\nthat function. In the middle of this function is a very large insertion of dead code wrapped by an opaque predicate.\r\nThis is highlighted in white in the figure above. It has also been truncated for the screenshot. There are two\r\nlocations in this function with junk code insertion which impedes signature development: at addresses 0x4057c1\r\nand 0x4057cc .\r\nThe chunks are 8 bytes long, therefore at the end of the loop after the call to decode_chunk , 8 is added to the\r\nchunk pointer then the chunk count is decremented by one.\r\nhttps://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nPage 10 of 15\n\nChunk Decode Loop Control\r\nDecompiled Decode Chunk Function\r\nhttps://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nPage 11 of 15\n\nThe decode_chunk function has four opaque predicates that each wrap dead code, and there are two locations\r\nwith junk code insertion. In addition to these, the logic of the function is quite convoluted. However, after\r\npatching out all of the opaque predicates, dead code, and junk code, a cleaner decompilation graph can be\r\nanalyzed. The figure above is that graph, fully annotated and cleaned up.\r\nThere are three tiny functions called during the decoding algorithm: load_data_keyB , add_key4 , and,\r\nxor_mix . These simply isolate small pieces of the algorithm to impede analysis and make signature development\r\nmore difficult.\r\nAlgorithm Isolates\r\nShift Shellcode OEP Function\r\nThe shift_shellcode_oep function is very simple. It adds 0x3bf1 to the address of the start of the decoded\r\nshellcode in allocated memory. This shifts the pointer from the start of the decoded data to the offset of the OEP.\r\nhttps://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nPage 12 of 15\n\nThis is the address that is called in the main function.\r\nThis packer is polymorphic. Variants and builds share many of the same functionality, behavior, and code features.\r\nHowever, they are in different order with randomization of opaque predicates, junk code, and dead code. In spite\r\nof this, detection can be achieved by focusing on the two stretches of stable bytes which were identified above.\r\nThe following two YARA rules match these bytes.\r\nrule Packer_pkr_ce1a_ShellcodeSizePart\r\n{\r\n meta:\r\n author = \"Malwarology LLC\"\r\n date = \"2022-10-14\"\r\n description = \"Detects bytes surrounding the first part of the data size of the second stage shellcode i\r\n reference = \"https://malwarology.substack.com/p/malicious-packer-pkr_ce1a\"\r\n sharing = \"TLP:CLEAR\"\r\n exemplar = \"fc04e80d343f5929aea4aac77fb12485c7b07b3a3d2fc383d68912c9ad0666da\"\r\n address = \"0x41cc3c\"\r\n packer = \"pkr_ce1a\"\r\n strings:\r\n $a = { 00699AF974[4]96AACB4600 }\r\n condition:\r\n $a and\r\n uint16(0) == 0x5A4D and\r\n uint32(uint32(0x3C)) == 0x00004550\r\n}\r\nrule Packer_pkr_ce1a_ShellcodeAddrPart\r\n{\r\n meta:\r\n author = \"Malwarology LLC\"\r\n date = \"2022-10-17\"\r\n description = \"Detects bytes surrounding the first part of the address of the second stage shellcode in\r\n reference = \"https://malwarology.substack.com/p/malicious-packer-pkr_ce1a\"\r\n sharing = \"TLP:CLEAR\"\r\n exemplar = \"fc04e80d343f5929aea4aac77fb12485c7b07b3a3d2fc383d68912c9ad0666da\"\r\n address = \"0x41bc9c\"\r\n packer = \"pkr_ce1a\"\r\n strings:\r\n $a = { 0094488D6A[4]F2160B6800 }\r\n condition:\r\n $a and\r\n uint16(0) == 0x5A4D and\r\n uint32(uint32(0x3C)) == 0x00004550\r\n}\r\nhttps://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nPage 13 of 15\n\nFilename: 6523.exe\r\nFilename: povgwaoci.iwe\r\nMD5: 5663a767ac9d9b9efde3244125509cf3\r\nSHA1: 84f383a3ddb9f073655e1f6383b9c1d015e26524\r\nSHA25: fc04e80d343f5929aea4aac77fb12485c7b07b3a3d2fc383d68912c9ad0666da\r\nImphash: bc57832ec1fddf960b28fd6e06cc17ba\r\nTimestamp: 2022-02-16T10:14:32Z\r\nFile Type: Win32 EXE\r\nMagic: PE32 executable (GUI) Intel 80386, for MS Windows\r\nSize: 238080\r\nFirst Seen: 2022-10-14T18:37:13Z 4\r\nhxxp[://]guluiiiimnstrannaer[.]net/dl/6523.exe\r\nDEFENSE EVASION::Software Packing [F0001]\r\nANTI-BEHAVIORAL ANALYSIS::Emulator Evasion::Undocumented Opcodes [B0005.002]\r\nANTI-BEHAVIORAL ANALYSIS::Emulator Evasion::Unusual/Undocumented API Calls [B0005.003]\r\nANTI-BEHAVIORAL ANALYSIS::Emulator Evasion::Extra Loops/Time Locks [B0005.004]\r\nANTI-STATIC ANALYSIS::Disassembler Evasion::Argument Obfuscation [B0012.001]\r\nANTI-STATIC ANALYSIS::Disassembler Evasion::Variable Recomposition [B0012.004]\r\nANTI-STATIC ANALYSIS::Executable Code Obfuscation::Dead Code Insertion [B0032.003]\r\nANTI-STATIC ANALYSIS::Executable Code Obfuscation::Junk Code Insertion [B0032.007]\r\nANTI-STATIC ANALYSIS::Executable Code Obfuscation::Interleaving Code [B0032.014]\r\nANTI-BEHAVIORAL ANALYSIS::Emulator Evasion::Unimplemented Opcodes [B0005]\r\nANTI-STATIC ANALYSIS::Executable Code Obfuscation::Opaque Predicate [B0032]\r\nANTI-STATIC ANALYSIS::Executable Code Obfuscation::Function Call Obfuscation [B0032]\r\nIntezer\r\nUnpacMe\r\nhttps://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nPage 14 of 15\n\nSubscribe to Malwarology Research\r\nBy Malwarology LLC · Launched 3 years ago\r\nA newsletter about malware reverse engineering, malware analysis, and threat intelligence. This includes formal\r\ndeep dive reports on malware families, analysis tools and techniques tutorials, and as-it-happens research project\r\nprogress updates.\r\nSource: https://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nhttps://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://malwarology.substack.com/p/malicious-packer-pkr_ce1a?r=1lslzd"
	],
	"report_names": [
		"malicious-packer-pkr_ce1a?r=1lslzd"
	],
	"threat_actors": [],
	"ts_created_at": 1775434496,
	"ts_updated_at": 1775791233,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6c2323f36ea8af20d7bd69dbf8c2f2455e7affef.pdf",
		"text": "https://archive.orkl.eu/6c2323f36ea8af20d7bd69dbf8c2f2455e7affef.txt",
		"img": "https://archive.orkl.eu/6c2323f36ea8af20d7bd69dbf8c2f2455e7affef.jpg"
	}
}