{ "id": "d474acfe-38d0-4bff-af3c-c5c9df244a63", "created_at": "2026-04-06T00:14:02.963217Z", "updated_at": "2026-04-10T03:23:51.07172Z", "deleted_at": null, "sha1_hash": "d7565d8e96ed23d43bb4eaa6e27a718b12aecc7d", "title": "Janus Vulnerability: Threats and Mitigation | Guardsquare", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 81784, "plain_text": "Janus Vulnerability: Threats and Mitigation | Guardsquare\r\nBy Guardsquare\r\nPublished: 2017-11-13 · Archived: 2026-04-05 18:32:49 UTC\r\nA serious vulnerability (CVE-2017-13156) in Android allows attackers to modify the code in applications without\r\naffecting their signatures. The root of the problem is that a file can be a valid APK file and a valid DEX file at the\r\nsame time. We have named CVE-2017-13156 the Janus vulnerability, after the Roman god of duality.\r\nJanus vulnerability\r\n The Janus vulnerability stems from the possibility to add extra bytes to APK files and to DEX files. On the one\r\nhand, an APK file is a zip archive, which can contain arbitrary bytes at the start, before its zip entries (actually\r\nmore generally, between its zip entries). The JAR signature scheme only takes into account the zip entries. It\r\nignores any extra bytes when computing or verifying the application’s signature. On the other hand, a DEX file\r\ncan contain arbitrary bytes at the end, after the regular sections of strings, classes, method definitions, etc. A file\r\ncan, therefore, be a valid APK file and a valid DEX file at the same time.\r\n \r\nAnother key element is a seemingly harmless feature of the Dalvik/ART virtual machine. In theory, the Android\r\nhttps://www.guardsquare.com/en/blog/new-android-vulnerability-allows-attackers-modify-apps-without-affecting-their-signatures\r\nPage 1 of 3\n\nruntime loads the APK file, extracts its DEX file and then runs its code. In practice, the virtual machine can load\r\nand execute both APK files and DEX files. When it gets an APK file, it still looks at the magic bytes in the header\r\nto decide which type of file it is. If it finds a DEX header, it loads the file as a DEX file. Otherwise, it loads the\r\nfile as an APK file containing a zip entry with a DEX file. It can thus misinterpret dual DEX/APK files.\r\nAn attacker can leverage this duality. He can prepend a malicious DEX file to an APK file, without affecting its\r\nsignature. The Android runtime then accepts the APK file as a valid update of a legitimate earlier version of the\r\napp. However, the Dalvik VM loads the code from the injected DEX file.\r\nThreats of the Janus Vulnerability\r\n Although Android applications are self-signed, signature verification is important when updating Android\r\napplications. When the user downloads an update of an application, the Android runtime compares its signature\r\nwith the signature of the original version. If the signatures match, the Android runtime proceeds to install the\r\nupdate. The updated application inherits the permissions of the original application. Attackers can, therefore, use\r\nthe Janus vulnerability to mislead the update process and get unverified code with powerful permissions installed\r\non the devices of unsuspecting users.\r\nOne can imagine a few severe scenarios. An attacker can replace a trusted application with high privileges (a\r\nsystem app, for instance) by a modified update to abuse its permissions. Depending on the targeted application,\r\nthis could enable the hacker to access sensitive information stored on the device or even take over the device\r\ncompletely. Alternatively, an attacker can pass a modified clone of a sensitive application as a legitimate update,\r\nfor instance in the context of banking or communications. The cloned application can look and behave like the\r\noriginal application but inject malicious behavior.\r\nThe zip file format is archaic and prone to problems like the Master Key vulnerability and this Janus vulnerability.\r\nAmbiguous zip files likely give rise to similar vulnerabilities in different contexts and on different systems. The\r\nroot cause is redundancy in the format. When designing data formats, protocols, data structures and code in\r\ngeneral, one should always strive to avoid redundancy. Any discrepancies lead to bugs or worse.\r\nJanus Vulnerability Mitigation and Scope \r\n We have created a simple internal tool to create Janus applications as a proof of concept. At this time, we have not\r\nseen any such applications in the wild.\r\nAny scenario still requires the user to install the malicious update from a source outside the Google Play store. It\r\nmay be relatively easy to trick some users because the application can still look exactly like the original\r\napplication and has the proper signature. For experts, the common reverse engineering tools do not show the\r\ninjected code. Users should always be vigilant when downloading applications and updates.\r\nThe Janus vulnerability affects recent Android devices (Android 5.0 and newer). Applications that have been\r\nsigned with APK signature scheme v2 and that are running on devices supporting the latest signature scheme\r\n(Android 7.0 and newer) are protected against the vulnerability. Unlike scheme v1, this scheme v2 considers all\r\nbytes in the APK file. Older versions of applications and newer applications running on older devices remain\r\nsusceptible. Developers should at least always apply signature scheme v2.\r\nhttps://www.guardsquare.com/en/blog/new-android-vulnerability-allows-attackers-modify-apps-without-affecting-their-signatures\r\nPage 2 of 3\n\nAndroid applications using DexGuard’s tamper detection mechanism are better hardened against cloning attacks.\r\nThe mechanism performs additional checks to make sure the protected applications have not been modified in any\r\nway. We recommend the use of tamper detection and DexGuard's other layers of protection against reverse\r\nengineering and cloning.\r\nDisclosure and resolution of CVE-2017-13156\r\nWe have reported this issue to Google on July 31, 2017, and received acknowledgment the same day. Google has\r\nreleased a patch to its partners in November. They have published the bug (CVE-2017-13156) in the Android\r\nSecurity Bulletin on December 4, 2017.\r\nSource: https://www.guardsquare.com/en/blog/new-android-vulnerability-allows-attackers-modify-apps-without-affecting-their-signatures\r\nhttps://www.guardsquare.com/en/blog/new-android-vulnerability-allows-attackers-modify-apps-without-affecting-their-signatures\r\nPage 3 of 3\n\nThe Janus vulnerability signed with affects APK signature recent Android scheme v2 and devices (Android that are running 5.0 and on devices supporting newer). Applications the that latest signature have been scheme\n(Android 7.0 and newer) are protected against the vulnerability. Unlike scheme v1, this scheme v2 considers all\nbytes in the APK file. Older versions of applications and newer applications running on older devices remain\nsusceptible. Developers should at least always apply signature scheme v2. \n Page 2 of 3", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://www.guardsquare.com/en/blog/new-android-vulnerability-allows-attackers-modify-apps-without-affecting-their-signatures" ], "report_names": [ "new-android-vulnerability-allows-attackers-modify-apps-without-affecting-their-signatures" ], "threat_actors": [ { "id": "d90307b6-14a9-4d0b-9156-89e453d6eb13", "created_at": "2022-10-25T16:07:23.773944Z", "updated_at": "2026-04-10T02:00:04.746188Z", "deleted_at": null, "main_name": "Lead", "aliases": [ "Casper", "TG-3279" ], "source_name": "ETDA:Lead", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "RbDoor", "RibDoor", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434442, "ts_updated_at": 1775791431, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/d7565d8e96ed23d43bb4eaa6e27a718b12aecc7d.pdf", "text": "https://archive.orkl.eu/d7565d8e96ed23d43bb4eaa6e27a718b12aecc7d.txt", "img": "https://archive.orkl.eu/d7565d8e96ed23d43bb4eaa6e27a718b12aecc7d.jpg" } }