{
	"id": "acf18a8a-605c-4c19-b5cd-c580882b479d",
	"created_at": "2026-04-06T00:12:35.239897Z",
	"updated_at": "2026-04-10T03:21:08.471142Z",
	"deleted_at": null,
	"sha1_hash": "41c78ac6093d9bd173f751290c595ad02e2c4333",
	"title": "Attack on Zygote: a new twist in the evolution of mobile threats",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 528655,
	"plain_text": "Attack on Zygote: a new twist in the evolution of mobile threats\r\nBy Nikita Buchka\r\nPublished: 2016-03-03 · Archived: 2026-04-05 20:57:19 UTC\r\nThe main danger posed by apps that gain root access to a mobile device without the user’s knowledge is that they\r\ncan provide access to far more advanced and dangerous malware with highly innovative architecture. We feared\r\nthat Trojans obtaining unauthorized superuser privileges to install legitimate apps and display advertising would\r\neventually start installing malware. And our worst fears have been realized: rooting malware has begun spreading\r\nthe most sophisticated mobile Trojans we have ever seen.\r\nRooting malware\r\nIn our previous article we wrote about the increasing popularity of malware for Android that gains root access to a\r\ndevice and uses it to install apps and display aggressive advertising. Once this type of malicious program\r\npenetrates a device, it often becomes virtually impossible to use it due to the sheer number of annoying ads and\r\ninstalled apps.\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 1 of 17\n\nSince the first article (August 2015), things have changed for the worse – the number of malware families of this\r\ntype has increased from four to 11 and they are spreading more actively and becoming much better at “rooting”.\r\nAccording to our estimates, Trojans with superuser privileges attacked about 10% of Android-based mobile\r\ndevices in the second half of 2015. There were also cases of these programs being pre-installed on new mobile\r\ndevices coming from China.\r\nHowever, it’s worth noting that Android-based devices running versions higher than 4.4.4 have much fewer\r\nvulnerabilities that can be exploited to gain root access. So basically, the malware targets earlier versions of the\r\nOS that are still installed on the majority of devices. The chart below shows the distribution of our product users\r\nby Android version. As can be seen from the chart, about 60% use a device on which these Trojans can gain root\r\naccess.\r\nVersions of Android OS used by users of our products\r\nThe owners of the Trojans described above, such as Leech, Ztorg, Gorpo (as well as the new malware family\r\nTrojan.AndroidOS.Iop) are working together. Devices infected by these malicious programs usually form a kind\r\nof “advertising botnet” via which advertising Trojans distribute each other as well as the advertised apps. Within a\r\nfew minutes of installing one of these Trojans, all other active malware on the “network” is enabled on the\r\nvictim’s device. Cybercriminals are cashing in on advertising and installing legitimate applications.\r\nIn 2015, this “advertising botnet” was used to distribute malware posing a direct threat to the user. This is how one\r\nof the most sophisticated mobile Trojans we have ever analyzed was spread.\r\nUnique Trojan\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 2 of 17\n\nThe “advertising botnet” mentioned above was used to distribute a unique Trojan with the following features:\r\nModular functionality with active use of superuser privileges\r\nMain part of malicious functionality exists in device RAM only.\r\nTrojan modifies Zygote system process in the memory to achieve persistence.\r\nIndustrial approaches used in its development, suggesting its authors are highly qualified.\r\nThe Trojan is installed in the folder containing the system applications, under names that system applications are\r\nlikely to have (e.g. AndroidGuardianship.apk, GoogleServerInfo.apk, USBUsageInfo.apk etc.).\r\nBefore starting work, the malicious program collects the following information:\r\nName of the device\r\nVersion of the operating system\r\nSize of the SD card\r\nInformation about device memory (from the file /proc/mem)\r\nIMEI\r\nIMSI\r\nList of applications installed\r\nThe collected information is sent to the cybercriminals’ server whose address the Trojan receives from a list\r\nwritten in the code:\r\nbridgeph2.zgxuanhao.com:8088\r\nbridgeph2.zgxuanhao.com:8088\r\nbridgeph3.zgxuanhao.com:8088\r\nbridgeph3.zgxuanhao.com:8088\r\nbridgeph4.zgxuanhao.com:8088\r\nbridgeph2.viewvogue.com:8088\r\nbridgeph3.viewvogue.com:8088\r\nbridgeph3.viewvogue.com:8088\r\nbridgeph4.viewvogue.com:8088\r\nOr, if the above servers are unavailable, from a list of reserve command servers also written in the code:\r\nbridgecr1.tailebaby.com:8088\r\nbridgecr2.tailebaby.com:8088\r\nbridgecr3.tailebaby.com:8088\r\nbridgecr4.tailebaby.com:8088\r\nbridgecr1.hanltlaw.com:8088\r\nbridgecr2.hanltlaw.com:8088\r\nbridgecr3.hanltlaw.com:8088\r\nbridgecr4.hanltlaw.com:8088\r\nIn reply, an encrypted configuration file arrives and is stored as /system/app/com.sms.server.socialgraphop.db.\r\nThe configuration is regularly updated and contains the following fields:\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 3 of 17\n\nmSericode – malware identifier\r\nmDevicekey – the device identifier generated on the server (stored in /system/app/OPBKEY_\u003c\r\nmDevicekey \u003e);\r\nmServerdevicekey – the current server identifier\r\nmCD – information used by cybercriminals to adjust the behavior of the modules;\r\nmHeartbeat – execution interval for the “heartbeatRequest” interface\r\nmInterval – interval at which requests are sent to the command server\r\nmStartInterval – time after which the uploaded DEX files (modules) are run\r\nmServerDomains – list of main domains\r\nmCrashDomains – list of reserve domains\r\nmModuleUpdate – links required to download the DEX files (modules).\r\nIf the mModuleUpdate field is not filled, the DEX files are downloaded and saved. Then these files are\r\ndownloaded in the context of the malicious program using DexClassLoader.loadClass(). After that, the modules\r\nare removed from the disk, i.e. they only remain in device memory, which seriously hampers their detection and\r\nremoval by antivirus programs.\r\nThe downloaded modules should have the following interface methods for proper execution:\r\ninit(Context context) – used to initialize the modules\r\nexit(Context context) – used to complete the work of the modules\r\nboardcastOnReceive(Context context, Intent intent) – used to redirect broadcast messages to the module;\r\nheartbeatRequest(Context context) – used to initiate the module request to the command server. It is\r\nneeded in order to obtain the data module required by the server;\r\nheartbeatResponce(Context context, HashMap serverResponse) – used to deliver the command server\r\nresponse to the module.\r\nDepending on the version, the following set of interfaces may be used:\r\ninit(Context context) – used to initialize the modules\r\nexec() – used to execute the payload\r\nexit(Context context) – used to complete the work of the modules\r\nThis sort of mechanism allows the app downloader to execute modules implementing different functionality, as\r\nwell as coordinating and synchronizing them.\r\nThe apps and the loaded modules use the “android bin”, “conbb”, “configopb”, “feedback” and “systemcore” files\r\nstored in the folder /system/bin to perform various actions on the system using superuser privileges. It goes\r\nwithout saying that a clean system does contain these files.\r\nConsidering the aforementioned modular architecture and privileged access to the device, the malware can create\r\nliterally anything. The capabilities of the uploaded modules are limited only by the imagination and skills of the\r\nvirus writers. These malicious programs (the app loader and the modules that it downloads) belong to different\r\ntypes of Trojans, but all of them were all included in our antivirus databases under the name Triada.\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 4 of 17\n\nAt the time of analysis the app downloader (detected by us as Backdoor.AndroidOS.Triada) downloaded and\r\nactivated the following modules:\r\nOPBUpdate_3000/Calendar_1000 – two modules with duplicate functionality capable of downloading,\r\ninstalling and running an application (detected as Trojan-Downloader.AndroidOS.Triada.a).\r\nRegistered_1000 – module capable of sending an SMS upon the request of the command server. Detected\r\nas Trojan-SMS.AndroidOS.Triada.a.\r\nIdleinfo_1000 – module that targets applications that use SMS to make in-app purchases (intercepts\r\noutgoing text messages). Detected as Trojan-Banker.AndroidOS.Triada.a.\r\nUse of the Zygote process\r\nA distinctive feature of the malicious application is the use of the Zygote process to implement its code in the\r\ncontext of all the applications on the device. The Zygote process is the parent process for all Android applications.\r\nIt contains system libraries and frameworks used by almost all applications. This process is a template for each\r\nnew application, which means that once the Trojan enters the process, it becomes part of the template and will end\r\nup in each application run on the device. This is the first time we have come across this technique in the wild;\r\nZygote was only previously used in proof-of-concepts.\r\nThe chart below shows the architecture of the malicious program.\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 5 of 17\n\nLet us take a closer look at how the Zygote process is infected.\r\nPreparatory stage and testing\r\nAll the magic starts in the crackZygoteProcess() function from the Trojan-Banker module. Its code is displayed\r\nin the screenshot below.\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 6 of 17\n\nFirst, the Trojan loads the shared library libconfigpppm.so and invokes the configPPP() function exported by this\r\nlibrary (the first highlighted string on the screenshot). Second, if configPPP() succeeds in calling\r\nSystem.getProperty() from Android API with the unusual argument ‘pp.pp.pp’ (it will be explained later why\r\nthis action is performed) and the returned value is not null, the Trojan runs the ELF-executable configpppi with\r\nthe PID of the zygote process as an argument.\r\nLet’s go through the process in order. The first thing the Trojan does inside the configPPP() function from\r\nlibconfigpppm.so is to obtain the load address (in the address space of its process) of the file that implements the\r\nActivityThread.main() function from Android API. Next, using the load address and /proc/self/maps, the Trojan\r\ndiscovers the name and path to the file on the disk. In most cases, it will be\r\n/system/framework/framework.odex.\r\nThe Trojan reads this file from disk and compares it with the file that is already loaded in the address space. The\r\ncomparison is performed as follows:\r\n1. 1 The file is divided into 16 blocks;\r\n2. 2 The first 8 bytes of each block are read;\r\n3. 3 These 8-byte sequences are compared with the corresponding sequences from the file that loaded in\r\nmemory;\r\nIf the comparison fails, configPPP aborts its execution and returns a 103 error code. If the comparison succeeds,\r\nthe Trojan starts patching framework.odex in memory.\r\nThen, the malware obtains the Class structure of ActivityThread (which is defined in framework.odex) by using\r\ndexFindClass and dexGetClassData functions. The authors of the malware copied these functions from Dalvik\r\nVirtual Machine. The structure contains various information about a dex class and is defined in AOSP. Using the\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 7 of 17\n\nstructure, Triada iterates through a list of methods implemented in this class looking for a method named “main”.\r\nAfter the method has been found, the Trojan obtains its bytecode with the help of the dexGetCode function (also\r\ncopied from open sources). When the bytecode is obtained, it is compared with the corresponding bytecode from\r\nthe file on the disk, thereby checking if the framework has already been patched. If the method has already been\r\npatched, the malware aborts its execution and returns a 103 error code.\r\nAfter that, the Trojan starts looking for the first string in the DEX strings table that are between 32 and 64 symbols\r\nlong. After a string has been found, the Trojan replaces it with “/system/lib/libconfigpppl.so” and saves its ID.\r\nNext, Triada accesses the DEX methods table and tries to obtain a method with one of the following names –\r\n“loop“, “attach” or “setArgV0“. It takes the first one that occurs in the table, or, if there are no methods with\r\nthese names, the penultimate method from the DEX methods table, and replaces it with a standard System.load()\r\nmethod (one that loads shared libraries to process address space) and saves its ID. The pseudocode that performs\r\nthis manipulation is shown below.\r\nAfter these actions, the preparatory stage is complete, and the Trojan performs the actual patching. It modifies the\r\nmemory of the process, adding the following instructions to the bytecode of the “main” method of the\r\nActivityThread class:\r\n1A 00 [strID, 2 bytes]                    //const-string v0, “/system/lib/libconfigpppl.so”\r\n71 10 [methID, 2 bytes] 00 00      //invoke-static {v0}, Ljava/lang/System;-\u003eload(Ljava/lang/String;)V\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 8 of 17\n\n0E 00                                             //return-void\r\nwhere strID is thesaved ID of the replaced string, and methID is the saved ID of the replaced method.\r\nAfter these modifications, when ActivityThread.main() is called, it will automatically load the shared library\r\n“/system/lib/libconfigpppl.so” to the context of the caller process. But because framework.odex is only patched\r\nin the context of the Trojan process, the library will only be uploaded in the Trojan process. This seemingly\r\nmeaningless action is performed in order to test the ability of the malicious program to modify the Zygote process.\r\nIf the steps described above do not cause errors in the context of the application, they will not cause errors in the\r\ncontext of the system process. Such a complex operation as changing the Zygote address space has been\r\napproached very carefully by the attackers, since the slightest error in this process can result in immediate system\r\nfailure. That is why the “test run” is performed to check the efficiency of the methods on the user’s device.\r\nAt the end configPPP() writes the following data to “/data/configppp/cpppimpt.db“:\r\nID of replaced string (4 bytes);\r\nContent of replaced string (64 bytes);\r\nID of replaced method (4 bytes);\r\nPointer to the Method structure for replaced method (4 bytes);\r\nContent of the Method structure for ActivityThread.main() (52 bytes);\r\nLoad address of framework.odex (4 bytes);\r\nList of structures that contain (previously used for comparison, 192 bytes):\r\n1. 1 Pointer to the next block of framework.odex;\r\n2. 2 First 8 bytes of the block:\r\nSize of framework.odex in memory (before patching) (4 bytes);\r\nPointer to the DexFile structure for framework.odex (4 bytes);\r\nContent of the DexFile structure for framework.odex (44 bytes);\r\nPointer to the Method structure for System.load() (4 bytes);\r\nSize of ActivityThread.main() bytecode before patching (4 bytes);\r\nBytecode of ActivityThread.main() before patching (variable);\r\nFinally, the Trojan calls the patched ActivityThread.main(), thus loading /system/lib/libconfigpppl.so in its\r\naddress space. We will describe the purpose of this library after explaining the functionality of the configpppi\r\nELF-executable that performs the actual modification of Zygote’s address space.\r\nModification of the Zygote\r\nIn fact, configpppi also patches ActivityThread.main() from framework.odex, but unlike libconfigpppm.so, it\r\nreceives the PID of a process running on the system as an argument and performs patching in the context of this\r\nprocess. In this case, the Trojan patches the Zygote process. It uses information obtained at the previous stage (in\r\nlibconfigpppm.so) and stored in /data/configppp/cpppimpt.db to modify the Zygote process via ptrace system‐\r\ncalls.\r\nThe Zygote process is a daemon whose purpose is to launch Android applications. It receives requests to launch\r\nan application through /dev/socket/zygote. Every launch request triggers a fork() call. When fork() occurs the\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 9 of 17\n\nsystem creates a clone of the process – a child process that is a full copy of a parent. Zygote contains all the\r\nnecessary system libraries and frameworks, so every new Android application will receive everything it needs to\r\nexecute. This means every application is a child of the Zygote process and after patching, every new application\r\nwill receive framework.odex modified by the Trojan (with libconfigpppl.so injected). In other words,\r\nlibconfigpppl.so ends up in all new apps and can modify how they work. This opens up a wide range of\r\nopportunities for the cybercriminals.\r\nSubstitution of standard Android Framework features\r\nWhen the shared library /system/lib/libconfigpppl.so is loaded inside the Zygote by System.load(), the system\r\ninvokes its JNI_OnLoad() function. First, the Trojan restores the string and method replaced earlier by\r\n/system/lib/libconfigpppm.so or configpppi, using the information from /data/configppp/cpppimpt.db. Second,\r\nTriada loads the DEX file configpppl.jar. This is done with the help of a standard Android API via\r\ndalvik.system.DexClassLoader.\r\nTo ensure that DEX is successfully loaded, the Trojan calls its method pppMain from the PPPMain class. This\r\nmethod only outputs to logcat string “PPP main started”.\r\nThe next stage is to prepare hooks for some methods from Android Framework (framework.odex). The malware\r\nchecks if everything necessary for hook methods exist in configpppl.jar (it uses the internal\r\ncheckPackageMethodExits() method for this). The Trojan then prepares hooks for the following methods:\r\n1. 1 java.lang.System.getProperty()\r\n2. 2 android.app.Instrumentation.newApplication()\r\n3. 3 com.android.internal.telephony.SMSDispatcher.dispatchPdus()\r\n4. 4 android.app.ActivityManager.getRunningServices()\r\n5. 5 android.app.ActivityManager.getRunningAppProcesses()\r\n6. 6 android.app.ApplicationPackageManager.getInstalledPackages()\r\n7. 7 android.app.ApplicationPackageManager.getInstalledApplications()\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 10 of 17\n\nThe hooks are placed using the standard RegisterNatives() function. This function is designed to perform binding\r\nJava methods with their native implementation (i.e. written with C/C++). Thus, the Trojan substitutes standard\r\nmethods from Android Framework with methods implemented in libconfigpppl.so.\r\nVerifying the success of a Zygote modification\r\nThe function which substitutes the original getProperty() first checks its argument. If the argument is the\r\n“pp.pp.pp” string (which was mentioned earlier), then the function immediately returns “true”. Otherwise, it calls\r\nthe original getProperty() with its passed argument. Calling the hooked getProperty() with “pp.pp.pp” as an\r\nargument is used to check whether or not hooking of Android Framework functions was successful. If the hooked\r\ngetProperty() returned “true”, then the Trojan will start configpppi ELF with the PID of the Zygote process as an\r\nargument.\r\nAfter that, the the Trojan “kills” processes of the applications: “com.android.phone”, “com.android.settings”,\r\n“com.android.mms”. These are the standard “Phone”, “Settings” and “Messaging” – applications that are the\r\nTrojan’s primary targets. The system starts these apps automatically the next time the device is unblocked. After\r\nthey start they will contain framework.odex with all the hooks placed by libconfigpppl.so.\r\nModification of outgoing text messages\r\nThe function which substitutes newApplication(), first calls the original function, and then invokes two functions\r\nfrom configpppl.jar: onModuleCreate() and onModuleInit().\r\nThe function onModuleCreate() checks in the context of the application it is running and then sets the global\r\nvariable mMainAppType according to the results of checking:\r\nIf function is running within com.android.phone, then mMainAppType set to 1;\r\nIf function is running within com.android.settings or com.android.mms, then mMainAppType set to 2;\r\nIf function is running within one of these apps: com.android.system.google.server.info,\r\ncom.android.system.guardianship.info.server, com.android.sys.op, com.android.system.op.,\r\ncom.android.system.kylin., com.android.kylines, com.android.email, com.android.contacts,\r\nandroid.process.media, com.android.launcher, com.android.browser, then mMainAppType set to -1;\r\nIf function is running within any other application, then mMainAppType set to 0;\r\nDepending on the value of mMainAppType, the function onModuleInit() calls one of the initialization routines:\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 11 of 17\n\nThus, the Trojan tracks its host application and changes its behavior accordingly. For example, if mMainAppType\r\nis set to -1 (i.e. the host application is com.android.email, com.android.contacts etc.), the Trojan does nothing.\r\nIf the host application is com.android.phone, Triada registers broadcast receivers for the intents with actions\r\ncom.ops.sms.core.broadcast.request.status and com.ops.sms.core.broadcast.back.open.gprs.network. It first\r\nsets the global variable mLastSmsShieldStatusTime to the current date and time, then turns on mobile network\r\ndata (GPRS Internet).\r\nIf the host application is com.android.settings or com.android.mms, Triada registers broadcast receivers for the\r\nintents with the following actions:\r\ncom.ops.sms.core.broadcast.request.status;\r\ncom.ops.sms.core.broadcast.back.open.gprs.network;\r\ncom.ops.sms.core.broadcast.back.send.sms.address.\r\nThe first two are the same as in the previous case, and the third sends an SMS, which is passed off as extra intent\r\ndata.\r\nIf the host application is any other app (apart from apps that trigger mMainAppType = -1), then Triada first checks\r\nwhether or not the application uses the shared library libsmsiap.so:\r\nDepending on the result, it calls one of the following functions: PISmsCore.invokeMMMain() or\r\nPISmsCore.invokeOtherMain().\r\nBoth functions invoke the PISmsCore.initInstance() method which performs the following actions:\r\n1. 1 Initialization of the Trojan’s global variables with various information about the infected device (IMEI,\r\nIMSI etc.);\r\n2. 2 Substitution of the system binders “isms” and “isms2”, which are used by the parent application along\r\nwith its own ones;\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 12 of 17\n\n3. 3 Creation of multiple directories /sdcard/Android/com/register/, used for write log and configuration files;\r\n4. 4 Registration of broadcast receivers for intents with the actions\r\ncom.ops.sms.core.broadcast.responce.shield.status and\r\ncom.ops.sms.core.broadcast.responce.sms.send.status, which simply set the corresponding variables to\r\nrecord the time of an event;\r\n5. 5 If a function is invoked from PISmsCore.invokeMMMain(), then a new thread is created. This thread\r\nenters an endless loop and turns on mobile network data, and won’t let the user turn it off.\r\nThe most interesting action among the above is the substitution of the system binders “isms” and “isms2”.\r\nBinder is an Android-specific inter-process communication mechanism, and remote method invocation system. All\r\ncommunication between client and server applications within Binder pass through a special Linux device driver –\r\n/dev/binder. The scheme of inter-process communication via the Binder mechanism is presented below.\r\nFor example, when an application wants to send an SMS it calls the sendTextMessage (or\r\nsendMultipartTextMessage) function, which in fact leads to the transact() method of an “isms” (or “isms2”) binder\r\nobject being called.\r\nThe transact() method is redefined in the malicious “isms” binder realization, replacing the original. So, when the\r\nparent application of the Trojan sends an SMS it leads to the call of the malicious transact() method.\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 13 of 17\n\nIn this method, the Trojan obtains SMS data (destination number, message text, service center number) from raw\r\nPDU. Then, if a network connection is available, it sends this data to a random C\u0026C server from the following\r\nlist:\r\nbridgeph2.zgxuanhao.com:8088\r\nbridgeph3.zgxuanhao.com:8088\r\nbridgeph3.zgxuanhao.com:8088\r\nbridgeph4.zgxuanhao.com:8088\r\nbridgeph2.viewvogue.com:8088\r\nbridgeph3.viewvogue.com:8088\r\nbridgeph3.viewvogue.com:8088\r\nbridgeph4.viewvogue.com:8088\r\nThe C\u0026C server should respond with some data that, among other things, contains a new SMS destination address\r\n(number) and new SMS text.\r\nIf a network connection is not available, then the Trojan tries to find the appropriate data in the local configuration\r\nfiles that are stored in the /sdcard/Android/com/register/localuseinfo/ directory in encrypted form.\r\nThe Trojan then replaces the SMS destination address and the SMS text of the original message (obtained from\r\nC\u0026C or local configuration files), and tries to send it in three different ways (simultaneously):\r\n1. 1 Via the standard Android API function sendTextMessage. It will lead to the same malicious transact()\r\nmethod of the Trojan “isms” binder realization;\r\n2. 2 By sending an intent with the action “com.ops.sms.core.broadcast.back.send.sms.address”. It will be\r\nreceived and processed by the same Trojan module but inside the “Messaging” or “Settings” application;\r\n3. 3 By passing the new SMS destination address and new SMS text to the original “isms” binder transact()\r\nmethod.\r\nWhen the Trojan sends an SMS in one of these ways, it saves the new SMS destination address and new SMS text\r\nin a special variable. And, before sending the new SMS, it checks if it has not already been sent. This helps to\r\nprevent endless recursive calls of the transact() method, meaning only one SMS will be sent per originally sent\r\nmessage (by the parent application).\r\nBesides the PISmsCore.initInstance() function, PISmsCore.invokeMMMain() calls another function –\r\nPIMMCrack.initInstance(). This method tries to determine which version of mm.sms.purchasesdk the host\r\napplication is using (the Trojan knows for sure that the host application is using this SDK, because it has checked\r\nfor libsmsiap.so, which is part of this SDK). mm.sms.purchasesdk is the SDK of Chinese origin – it is used by\r\napp developers for enabling In-App purchasing via SMS.\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 14 of 17\n\nThus, the mechanism described in this chapter allows the Trojan to modify outgoing SMS messages that are sent\r\nby other applications. We presume that the Trojan authors use this opportunity to secretly steal users’ money. For\r\nexample, when a user buys something in some Android game shop, and if this game uses SDK for in-app\r\npurchases via SMS (such as mm.sms.purchasesdk), the Trojan’s authors are likely to modify the outgoing SMS so\r\nas to receive the user’s money instead of the game developers. The user doesn’t notice that his money has been\r\nstolen; instead he presumes he hasn’t received the appropriate content and will then complain to the game\r\ndevelopers.\r\nFiltration of incoming text messages\r\nThe original dispatchPdus() is used (as shown in the diagram below) to dispatch PDUs (Protocol Data Unit, low-level data entity used in many communication protocols) of incoming SMS messages to the corresponding\r\nbroadcast intent. Then, all applications that subscribed for the intent are able to receive and process, according to\r\ntheir needs, the text message that is contained in the form of PDUs inside of this intent.\r\nThe function which substitutes dispatchPdus() invokes the moduleDispatchPdus() method from configpppl.jar. It\r\nchecks the host application and if the application is not com.android.phone, it informs and broadcasts to all apps\r\nin the system intent with the action android.provider.Telephony.SMS_RECEIVED (along with the received\r\nPDUs). This standard intent informs all other applications (e.g. “Messaging” or “Hangouts” of the incoming\r\nSMS).\r\nIf the host for the malware is com.android.phone, then Triada checks the originating address and message body\r\nof the incoming SMS. The information that the Trojan needs to check is contained within two directories:\r\n/sdcard/Android/com/register/infowaitreceive/ and /sdcard/Android/com/register/historyInfo/. The names of\r\nthe files that are stored in these directories contain postfix, which signifies the date and time of the last response\r\nfrom the C\u0026C. If these files were updated earlier than the last response was received, the Trojan deletes these files\r\nand aborts the checking of the incoming SMS. Otherwise, the malware decrypts all the files from the directories\r\nmentioned above and extracts phone numbers and keywords from them to perform filtering. If the SMS was\r\nreceived from one of these numbers or the message contains at least one keyword, the Trojan broadcasts an intent\r\nwith the action android.provider.Telephony.SMS_RECEIVEDcom.android.sms.core along with the message. This\r\nis an intent with a custom action and only those applications that explicitly subscribe to this intent, will receive it.\r\nThere are no such applications on “clean” Android devices. In addition, this method could be used to organize\r\n“exclusive” message distribution for Triada modules. If some of the new modules subscribe to the intent with the\r\naction android.provider.Telephony.SMS_RECEIVEDcom.android.sms.core, they will receive the filtered message\r\nexclusively, without any other applications on the system knowing about it.\r\nConcealing Trojan modules from the list of running services\r\nThis function is used to obtain a list of all running services. The Trojan substitutes the function to hide its modules\r\nfrom this list. The following modules will be excluded from the list received from the original\r\ngetRunningServices():\r\ncom.android.system.google.server.info\r\ncom.android.system.guardianship.info.server\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 15 of 17\n\ncom.android.sys.op\r\ncom.android.system.op.\r\ncom.android.system.kylin.\r\ncom.android.kylines.\r\nConcealing Trojan modules from the list of running applications\r\nThis function is used to obtain a list of all running applications. The Trojan substitutes the function to hide its\r\nmodules from this list. The following modules will be excluded from the list received from the original\r\ngetRunningAppProcesses():\r\ncom.android.system.google.server.info\r\ncom.android.system.guardianship.info.server\r\ncom.android.sys.op\r\ncom.android.system.op.\r\ncom.android.system.kylin.\r\ncom.android.kylines.\r\nConcealing Trojan modules from the list of installed packages\r\nThis function is used to obtain a list of all installed packages for applications. The Trojan substitutes the function\r\nto hide its modules from this list. The following modules will be excluded from the list received from the original\r\ngetInstalledPackages():\r\ncom.android.system.google.server.info\r\ncom.android.system.guardianship.info.server\r\ncom.android.sys.op\r\ncom.android.system.op.\r\ncom.android.system.kylin.\r\ncom.android.kylines.\r\nConcealing Trojan modules from the list of installed applications\r\nThis function is used to obtain a list of all installed packages for applications. The Trojan substitutes the function\r\nto hide its modules from this list. The following modules will be excluded from the list received from the original\r\ngetInstalledPackages():\r\ncom.android.system.google.server.info\r\ncom.android.system.guardianship.info.server\r\ncom.android.sys.op\r\ncom.android.system.op.\r\ncom.android.system.kylin.\r\ncom.android.kylines.\r\nConclusion\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 16 of 17\n\nApplications that gain root access to a mobile device without the user’s knowledge can provide access to much\r\nmore advanced and dangerous malware, in particular, to Triada, the most sophisticated mobile Trojans we know.\r\nOnce Triada is on a device, it penetrates almost all the running processes, and continues to exist in the memory\r\nonly. In addition, all separately running Trojan processes are hidden from the user and other applications. As a\r\nresult, it is extremely difficult for both the user and antivirus solutions to detect and remove the Trojan.\r\nThe main function of the Trojan is to redirect financial SMS transactions when the user makes online payments to\r\nbuy additional content in legitimate apps. The money goes to the attackers rather than to the software developer.\r\nDepending on whether or not the user gets the content he pays for, the Trojan either steals the money from the user\r\n(if the user does not receive the content) or from the legitimate software developers (if the user receives the\r\ncontent).\r\nTriada has clearly been designed by cybercriminals who know the targeted mobile platform very well. The range\r\nof techniques used by the Trojan is not found in any other known mobile malware. The methods of concealing and\r\nachieving persistence used by Triada can effectively avoid detection and removal of all malware components after\r\ninstallation on the infected device; the modular architecture allows attackers to extend and alter the functionality\r\nso they are limited only by the capabilities of the operating system and applications installed on the device. Since\r\nthe malware penetrates all applications installed on the system, the cybercriminals can potentially modify their\r\nlogic to implement new attack vectors against users and maximize their profits.\r\nTriada is as complex as any malware for Windows, which marks a kind of Rubicon in the evolution of threats\r\ntargeting Android. Whereas previously, the majority of Trojans for the platform were relatively primitive, new\r\nthreats with a high level of technical complexity have now come to the fore.\r\nSource: https://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nhttps://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/\r\nPage 17 of 17\n\nmemory of the ActivityThread process, adding class: the following instructions to the bytecode of the “main” method of the\n1A 00 [strID, 2 bytes] //const-string v0, “/system/lib/libconfigpppl.so”\n71 10 [methID, 2 bytes] 00 00 //invoke-static {v0}, Ljava/lang/System;-\u003eload(Ljava/lang/String;)V\n   Page 8 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/"
	],
	"report_names": [
		"74032"
	],
	"threat_actors": [],
	"ts_created_at": 1775434355,
	"ts_updated_at": 1775791268,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/41c78ac6093d9bd173f751290c595ad02e2c4333.pdf",
		"text": "https://archive.orkl.eu/41c78ac6093d9bd173f751290c595ad02e2c4333.txt",
		"img": "https://archive.orkl.eu/41c78ac6093d9bd173f751290c595ad02e2c4333.jpg"
	}
}