![[FCO]FreeCoursesOnline](https://onehack.us/uploads/default/original/3X/b/4/b4d2fc8468becec1e9976784dba394e5a378ec81.jpg){kind=small}
Intro:
Malware authors have been abusing packers (or runtime based obfuscates [70]) to protect malicious apps from being analyzed [6]. We call the apps protected by packers as packed apps and their protection behaviors as packing behaviors, such as detecting the running environment, hiding the original Dex
data (i.e., the Dex file and the Dex items that constitute the Dex file) and then releasing them at runtime, to name a few.
Many unpacking tools (i.e., unpackers) for Android apps [3, 7,8, 36, 45, 56, 70, 72, 79, 86] have been developed to recover the packed app’s original Dex file. They retrieve the hidden Dex data that has been released to the memory through a customized Android system [56, 70, 79, 86], or a debugger [3], or a dynamic binary instrumentation (DBI) framework [36, 72], or a full Android system emulator [7, 8, 45].
Since arms race between packers and unpackers never ends, packers are evolving to render unpackers ineffective. In particular, they adopt various approaches to detect the presence of unpackers and impede the analysis as well as change the write-then-execute pattern to prevent unpackers from collecting
all the hidden Dex data [1, 2]. To deal with the ever-evolving packers, we argue that a long-lasting effective unpacker should first scrutinize the packing behaviors of the packed apps and then choose the proper unpacking strategies accordingly…
Happy learning!