Threat Research

Dogspectus Ransomware Analysis

By Homing Tay | May 19, 2016

On April 25, 2016, Blue Coat published an article on a new Android Ransomware, called "Dogspectus.” On May 12, 2016, Dell SonicWALL published a separate report on the Android Lockscreen malware campaign with similar characteristics to Dogspectus. These similarities are not a coincidence. We began our own extensive investigation into this ransomware some time ago, and will share additional technical details of this malware here that have not been previously discussed.

Technical Details

The main Android Application Package (APK) of this malware is simply a shell that hides the actual APK that contains the malicious codes. It does not employ many of the more advanced obfuscations that are used by most malware in the wild – such as method name obfuscation, packing, or native code libraries. It does, however, use a string obfuscation via a custom encoder. In the sample analyzed (sha256 197588be3e8ba5c779696d864121aff188901720dcda796759906c17473d46fe ), the decoding scheme is in Obstetric.class. See Figure 1. The result of the decoding yields the following strings:


 ( Figure 1: Obstetric class with decoding methods. )


a[0] =

a[1] = :

a[2] = read

a[3] = LoganberryApplication

a[4] = dexElements

a[5] = mDexs

a[6] = setAccessible

a[7] = path

a[8] = close

a[9] = mZips

a[10] = .dex

a[11] = pathList

a[12] = makeDexElements

a[13] = write

a[14] = dex

a[15] = form.html

a[16] = loadDex

a[17] = mFiles

a[18] = isAccessible

a[19] = mPaths

a[20] = dex2

a[21] = open

a[22] = getAssets

a[23] = test.apk

a[24] = .SupervisedActivity

a[25] = getDeclaredField

a[26] = flush


These strings are used by the methods found in LoganberryApplication.class for various operations resulting in the decryption of the file "form.html," and the subsequent loading of the decrypted file as "test.apk." The file "form.html" in the assets folder is decrypted with a simple XOR operation with byte 0x88.


( Figure 2: Assets folder. )


When decrypted, the new classes.dex file contains the appropriate class names that match the AndroidManifest.xml file below.

***Full text removed for easier readability***

( Figure 3: Decrypted form.html. )


The servers that the APK tries to contact are the following:

- hxxp://

- hxxp://

- hxxp://

- hxxp://

- hxxp://

- hxxp://


 ( Figure 4: autumns.html. )


The application displays an HTML page on the home screen - in the sample analyzed, it is named empty.html in the assets folder. It then attempts to get a new HTML file from one of the C&C (command and control) servers. If successful, the file is saved as "autumns.html" and loaded instead of the default "empty.html" page. The page is displayed with the flag SYSTEM_UI_FLAG_FULLSCREEN with the setSystemUiVisibility method. While the "Back" button does not work, the "Home" button is capable of taking the user out of the page.


Figure 5: Setting setSystemUiVisibility to the value 4 which is SYSTEM_UI_FLAG_FULLSCREEN. )

In Figure 7, The application sends a POST request to a server containing information on all the packages installed in the mobile device. The data is encrypted with a hardcoded AES key and then base64 encoded with URL and Filename Safe Alphabet, - replacing + and / with - and _. In the image below, calling encodetoString with a flag value of 10 sets the URL_SAFE flag, which then enables the URL and Filename Safe Alphabet implementation. See Figure 6. Decrypting the data value in the POST request yields:


( Figure 6: Method to AES encrypt and base64 encode the plaintext. )

( Figure 7: HTTP POST request. )


{"10":-1,"17":"","15":"72596a633239726f6c63754c706f57595a4a2b5a7049667a","62":{},"16":1463507611,"13":0,"60":{"17":"null","15":"null","16":"null","13":19,"14":"4.4.3","11":"mako","12":"aosp_mako","3":"<removed - Android ID>","2":"e5a5d48e-d680-4a33-8298-968c38831dee","10":"mako","1":"3.20402","0":"17","7":"LGE","6":"AOSP on Mako","5":"<removed - IMEI>","4":"null <no SIM card - IMSI>","9":"Android","8":"MAKO"},"14":{},"61":{"3":["","","","","","","",










Some of the information on the JSON objects is shown below:


( Figure 8: JSON object methods. )



One interesting action that can be performed by this malware is turning on the front camera, taking a picture, and then saving it to the local directory.


( Figure 9: Checks for front facing camera. )


In the image above, the method checks that the mobile device has a front camera feature. A CameraInfo().facing value of 1 indicates that the direction the camera is facing is the same as the screen.


( Figure 10: Starts camera preview. )


The method shown above sets the parameters of the camera and then starts the preview with startPreview().


( Figure 11: Saves image to “crate.jpg”. )

Finally, in the method onPictureTaken(), it writes the image to the file "crate.jpg," which the application then sends to the C&C server.


This malware is also capable of calling the LocationManager to request GPS and network information, and updating the Handler's thread with sendMessage if the location changes.


( Figure 12: Request for GPS and network information. )


This ransomware does not yet encrypt any files with a public-private key pair, due to the Android's permission model that restricts an application from accessing another application's files directory. However, for a rooted user, if the code to encrypt files is ever added to the malware, the application would be able to access another application's directory and encrypt it with the key. On its own, this malware is not currently very harmful. However, combined with other malwares/rooting tools, this could be a nasty bit of malware. 

Fortinet blocks the Android Lockscreen malware with the signature Android/Locker.HR!tr. 













Join the Discussion