Android Ransomware that Encrypts JPGs and Video

Don't Lose Your Data Forever!

DIY data recovery has risks. You could lose your data forever! Don't want to risk it? Talk to a professional now.


Staff member
So I've got a rather odd case here that showed up. I've never seen anything quite like it. It's a microSD card from an Android device. Suddenly the pictures all seemed corrupted to the user. The card and filesystem all seem normal, but the opening signature of all the jpgs and video files on the card look like this:

Android Ransomware.jpg

As you can see there is some variance in the opening signature, likely a checksum or key of sorts. But some elements such as the second line of 03 00 00 02 00 00 10 00 00 02 8C 2D 04 09 03 01 as well as the visible code "CONSOLE" are consistent. This is then followed by a few sectors of all zeros before random looking data begins (as you'd expect in a jpg or video).

Has anyone ever come across such an Android ransomware or have any idea which one this might actually be? There doesn't seem to be any ransom notes left behind anywhere.


I see these all the time. I think it is Android file based encryption. Entropy in such files also suggests encryption.

No one was able to point me anywhere, I asked several places, here's one: ... ncryption/

and here: ... ncryption/

In an Android developer forum suggested it was Android file based encryption. Without any further info to go on.

And it is my impression it was mostly Samsungs but that may simply be because it is a popular brand.


I only noticed now your post was from months ago. Curious: Did you ever find more info on this?


Staff member
No, I explained to the customer that it would end up being an expensive custom job to even attempt recovery and he decided it wasn't worth pursuing it further.

So, I never figuring it out.


New member
Have some tools been developed since then to remove that type of encryption, or is it still a serious threat to Android users?


Check: section 5.9, see the mention of the _CONSOLE string. I dropped this is a forensics reddit sub months ago, and today received an answer ..

5.9. Literal Data Packet (Tag 11)

A Literal Data packet contains the body of a message; data that is
not to be further interpreted.

The body of this packet consists of:

- A one-octet field that describes how the data is formatted.

If it is a 'b' (0x62), then the literal packet contains binary data.
If it is a 't' (0x74), then it contains text data, and thus may need
line ends converted to local form, or other text-mode changes. RFC
1991 also defined a value of 'l' as a 'local' mode for machine-local
conversions. This use is now deprecated.

- File name as a string (one-octet length, followed by file name),
if the encrypted data should be saved as a file.

If the special name "_CONSOLE" is used, the message is considered to
be "for your eyes only". This advises that the message data is
unusually sensitive, and the receiving program should process it more
carefully, perhaps avoiding storing the received data to disk, for

- A four-octet number that indicates the modification date of the
file, or the creation time of the packet, or a zero that
indicates the present time.

- The remainder of the packet is literal data.

Text data is stored with <CR><LF> text endings (i.e. network-normal
line endings). These should be converted to native line endings by
the receiving software.


FYI. Came across one of those again.

So user took SD card from phone and inserted in card reader on PC and cut/paste files to hard drive. He later found files were corrupt, however when viewed in hex editor we see the 'CONSOLE' header.

Since in between phone was not factory reset or anything we took card out of the phone again and copied the 'corrupt' files to card. Card was then put back in phone. We then told phone to decrypt. When card is now again read in card reader connected to PC all files are fine.