{ "id": "7090ad91-ffa7-40f3-af1c-ffce74bfc572", "created_at": "2026-04-06T00:13:15.473237Z", "updated_at": "2026-04-10T13:12:57.54994Z", "deleted_at": null, "sha1_hash": "8844959c14247f83c6a940e83c9eac9894c012d7", "title": "Android malware based on SMS encryption and with KitKat support", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 127521, "plain_text": "Android malware based on SMS encryption and with KitKat\r\nsupport\r\nBy Łukasz\r\nPublished: 2014-09-23 · Archived: 2026-04-05 22:49:09 UTC\r\nMost of the malware based on the SMS C\u0026C communication channel is not compatible with Android 4.4 KitKat.\r\nThis is due to the fact that KitKat introduced a concept of one messaging app, which all other apps had to go\r\ntrough before they send or handle a received text message. This prevented malware from hiding received short\r\nmessages or sending without saving them in the \"Sent\" folder.\r\nWell, it wasn't hard to predict that this state of affairs wouldn't last long and that malware authors would\r\neventually catch up. Malware described here not only supports KitKat, but also uses an open-source SMS\r\nencryption tool as a basis for its code. Let's have a look at the insides of the new sample (hash:\r\n84e2e9e8430792b583d02d3cc1bf8535) and let's call it SmsSecure, just for the sake of brevity.\r\nOpen-source encryption\r\nI have to say that I did lie a bit. Well, I didn't tell the whole truth. Commands sent trough the SMS channel are not\r\nencrypted per se. Only the code for secure messaging is used as a basis for this malware, presumably because it\r\nsupports Android 4.4 out-of-the-box and it is easier to encourage users to install \"Secure SMS\" application as a\r\nmain messaging app. It has the same package name, org.thoughtcrime.securesms and hides main portion of its\r\ncode in the x* (namely xlibs, xservices, xpack, xbroadcast) subpackages. These are responsible e.g. for sending\r\nreceived text messages to the C\u0026C server.\r\nThere are two channels of communication: one trough unencrypted text messages and the other one trough POST\r\nrequests, which body is encrypted using blowfish. So, all of this talk about \"encrypted SMS\" is just a scam.\r\nEmulator detection and other techniques\r\nWhat we are used to is that the Android malware increasingly has a code that detects whether it is run on the\r\nemulator or not. There are couple of usual checks (e.g. phone model) and a couple of unusual checks illustrated\r\nbelow.\r\nhttp://maldr0id.blogspot.ch/2014/09/android-malware-based-on-sms-encryption.html\r\nPage 1 of 5\n\nNot that frequent technique is checking for the Network Operator and SIM Operator name. These names are\r\nhardcoded in the emulator and are equal to Android. \r\nAnother interesting feature is the configuration. Configuration is stored as the Raw Resources, because it is\r\nencrypted. Encryption method is Blowfish/CBC (IV=\"12345678\") and the key is stored in the resource cleverly\r\ncalled blfs.key and the configuration is encrypted in two files named in the same cunning way: config.cfg and\r\nconfig1.cfg. However, if you try to just decode the configs using the key provided, you will fail. Key is somewhat\r\n\"obfuscated\" using a byte2hex function outlined below.\r\nIt takes every byte in the key file, renders it to a hexstring and then construct a new string of this hexstrings. The\r\nfunction that gets the key limits it size to 50 bytes. So instead of the key:\r\nNfvnkjlnvkjKCNXKDKLFHSKD:LJmdklsXKLNDS:\u003cXObcniuaebkjxbcz\r\nwe get:\r\n4e66766e6b6a6c6e766b6a4b434e584b444b4c4648534b443a\r\nReally clever obfuscation technique. After decrypting the configuration files we get two beautiful XMLs:\r\n\u003c?xml version=\"1.0\" encoding=\"utf-8\"?\u003e\r\n          \u003cconfig\u003e\r\n            \u003cdata rid=\"25\" \r\nhttp://maldr0id.blogspot.ch/2014/09/android-malware-based-on-sms-encryption.html\r\nPage 2 of 5\n\nshnum10=\"\" shtext10=\"\" shnum5=\"\" shtext5=\"\" shnum3=\"\" shtext3=\"\" shnum1=\"\" shtext1=\"\"\n del_dev=\"0\"\n url_main=\"\"\n url_data=\"\"\n url_sms=\"\"\n url_log=\"\"\n phone_number=\"+43676800505476\"\n download_domain=\"ttt\"\n ready_to_bind=\"0\" /\u003e ?xml version=\"1.0\" encoding=\"utf-8\"?\u003e See if you can spot the fake one. Anyhow, that's it for the text-based C\u0026C, but what about the HTTP-based\ndropzone? Well, there isn't any URL hard coded. The dropzone URL comes via the text command.\nSMS commands\nEach command is send in a following form (the originating number is completely ignored):\nhttp://maldr0id.blogspot.ch/2014/09/android-malware-based-on-sms-encryption.html\nPage 3 of 5\n\n\u003ccontrol_code\u003e \u003ccommand\u003e \u003cnumber\u003e \u003cservice_code\u003e\r\nTwo last values are optional. control_code should be one of the 6-digit predefined codes. service_code is a number\r\nto which the logs will be send (as a text messages) and will be updated no matter what the issued command\r\nis. What are the possible commands? Well, there are eleven of them, listed below.\r\nSTART - starts redirecting all text messages to the number (service_code is ignored) by setting the RTB\r\n(ready to bind) value to 2 and sending the \"Service Started\" SMS to the number.\r\nSTARTB - starts redirecting all text messages to the number URL (URLs are for some reason called\r\n\"buffers\") by setting the RTB value to 1 and sending the message as above (but via HTTP).\r\nSTOP - command complimentary to the START and STARTB commands. Sets the RTB value to 0 and\r\nsends \"Service stopped\" SMS/POST request to the number.\r\nDEL - removes the application. Just like that. But you still have to send the correct control_code. Sends\r\nback the \"Delete command received\" to the number.\r\nSETB - sets what the author calls \"Buffers\". These are all the URLs needed for the HTTP communications.\r\nURLs are set according to the following pattern: number/[1|2|3|4].php. First one is used for a ping-back,\r\nsecond one is a dropzone for the captured messages, third one is for the configuration update and the last\r\none is for the logs (e.g. that some action has started).\r\nCLEARB - clears the \"buffers\" i.e. the URLs mentioned above.\r\nSETP - sets the phone number that will overwrite any number that comes in the text message. Useful for\r\nusing the fake number values in the subsequent commands.\r\nCLEARP - reverts the above setting.\r\nCLEAR - does both the CLEARB and CLEARP.\r\nLOCK - set the password for the device to number and locks the device. I don't think this feature is enabled\r\nin the mentioned sample, as the sample does not require the Device Admin privileges.\r\nUNLOCK - clears the password and locks the device (which makes it unlockable after the lock above).\r\nThe application also supports blocking messages from some numbers. These numbers should be contained in the\r\n\"filters\" variable (separated by the semicolon) and can only be updated via the HTTP or in the starting configs.\r\nSummary\r\nThis is a fine example of the malware evolution - now completely compatible with KitKat. It even checks whether\r\nyou have set it as a main messaging app already and displays a pestering notification if not. It also tries to do some\r\ntargeting based on the SIM operator (as pictured below). However, this function is never used in the code, as it\r\nwas probably dropped at some point by the authors. Anyhow, the targeted countries were supposed to be Austria,\r\nRussia and Switzerland.\r\nHowever, my favorite part is how they extensively log everything and use \"setted\" instead of \"set\".\r\nhttp://maldr0id.blogspot.ch/2014/09/android-malware-based-on-sms-encryption.html\r\nPage 4 of 5\n\nUpdate\r\n@seckle_ch reports that the SmsSecure is used in conjunction with the retefe banking trojan, targeting Austria,\r\nSwitzerland and Sweden.\r\nSource: http://maldr0id.blogspot.ch/2014/09/android-malware-based-on-sms-encryption.html\r\nhttp://maldr0id.blogspot.ch/2014/09/android-malware-based-on-sms-encryption.html\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "ETDA" ], "origins": [ "web" ], "references": [ "http://maldr0id.blogspot.ch/2014/09/android-malware-based-on-sms-encryption.html" ], "report_names": [ "android-malware-based-on-sms-encryption.html" ], "threat_actors": [], "ts_created_at": 1775434395, "ts_updated_at": 1775826777, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/8844959c14247f83c6a940e83c9eac9894c012d7.pdf", "text": "https://archive.orkl.eu/8844959c14247f83c6a940e83c9eac9894c012d7.txt", "img": "https://archive.orkl.eu/8844959c14247f83c6a940e83c9eac9894c012d7.jpg" } }