{"id":4710,"date":"2024-01-09T10:35:42","date_gmt":"2024-01-09T18:35:42","guid":{"rendered":"https:\/\/www.pnfsoftware.com\/blog\/?p=4710"},"modified":"2024-01-12T10:05:24","modified_gmt":"2024-01-12T18:05:24","slug":"how-to-use-jeb-auto-decrypt-strings-in-protected-binary-code","status":"publish","type":"post","link":"https:\/\/www.pnfsoftware.com\/blog\/how-to-use-jeb-auto-decrypt-strings-in-protected-binary-code\/","title":{"rendered":"How To Use JEB – Auto-decrypt strings in protected binary code"},"content":{"rendered":"\n

This is the second entry in our series showing how to use JEB and its well-known and lesser-known features to reverse engineer malware more efficiently. Part 1 is here<\/a>.<\/em><\/p>\n\n\n\n

Today, we’re having a look at an interesting portion of a x86-64 Windows malware that carries encrypted strings. Those strings happen to be decrypted on the fly, the first time they’re required by some calling routine.<\/p>\n\n\n\n

SHA256: 056cba26f07ab6eebca61a7921163229a3469da32c81be93c7ee35ddec6260f1. The file is not packed, it was compiled for Intel x86 64-bit processors, using an unknown version of Visual Studio. The file is dropped by another malware and its purpose is reconnaissance and information gathering. Let’s load it in JEB 5.8 and do a standard analysis (default settings). <\/p>\n\n\n\n

\n

Table of Contents<\/p>\n