KeepSafe for Androi...
 
Notifications
Clear all

KeepSafe for Android

twjolson
(@twjolson)
Active Member

I have a case in which the suspect used KeepSafe. I am finding images in \media\Main Folder\ and more in \media\Main Folder\.thumbs.

They are named with the following format <13 digit number>.<original file name?>.<original extension>.ksd. Some examples
1375729769368.2013080195185854-1.jpg.ksd
1375729877735.a100c5f4-40c8-447b-8ce5-381507a0d437.jpg.ksd
1378219904357.2013090395094012.jpg.ksd
1375730074092.VID_20120705_160718.3gp.ksd
1378219904357.2013090395094012.jpg.ksd
1375729846126.IMG_20130730_183003_634.jpg.ksd

However, when viewing the image, it shows a blue castle, similar to the one seen here

They all have different hash values. Testing on my phone, I found that the Keepsafe image is 3722 bytes larger than the original - everytime.

Looking at the hex, the images are definitely PNG files (not .jpg). Internally, no .jpg header is seen.

Is there a way to use PNG as a wrapper for .jpg (and other) files?

Comparing file names to the rest of the bookmarked files (thus far), I am not seeing a whole lot of overlap.

Looking at the keepsafeDatabase SQLite database, I have hashes, existing paths, and the new path.

I would not be surprised if this contains the smoking gun, so every bit of help would be appreciated.

Terry

Quote
Topic starter Posted : 05/12/2013 7:17 pm
jhup
 jhup
(@jhup)
Community Legend

Fire up an Android VM. I use AndroVM.

Load KeepSafe.

create baseline image.

Use KeepSafe on baseline image.

Compare and deduce how to reverse KeepSafe
OR
Load copy KeepSafe config from suspect to VM with data, and try to open through KeepSafe,
OR
find security fault in KeepSafe to break into it.

etc. mrgreen

ReplyQuote
Posted : 05/12/2013 7:39 pm
twjolson
(@twjolson)
Active Member

Thank you for the reply.

I have already done testing with a test phone. That revealed what was originally posted.

Copy over procedure is a good thought. I haven't played with Android VMs yet.

But, if this went to court, I'd like to be a bit more informed (and maybe find a more defensible procedure).

So, if anyone has any additional knowledge, I'd be grateful.

ReplyQuote
Topic starter Posted : 05/12/2013 9:46 pm
trevin.mowery
(@trevin-mowery)
New Member

Is it possible to share your test images? I'd be curious to see the difference in the original and the KeepSafe version.

ReplyQuote
Posted : 06/12/2013 12:02 am
jaclaz
(@jaclaz)
Community Legend

It *seems* like the encryption is not "specific".
I.e. by reinstalling the app (with a known PIN) and redeploying the previously backed up contents of the "Main Folder" inside the (hidden) .keepsafe folder they can be viewed, according to this
http//appcyla.wordpress.com/2013/05/29/bypassing-file-hiding-apps/

jaclaz

ReplyQuote
Posted : 06/12/2013 12:45 am
twjolson
(@twjolson)
Active Member

Is it possible to share your test images? I'd be curious to see the difference in the original and the KeepSafe version.

Regular
KeepSafe

I had to rename the KeepSafe version to PNG, to allow the upload. It was originally .ksd. I am unsure if Photobucket altered the data, however. I know the original had EXIF metadata in it.

It *seems* like the encryption is not "specific".
I.e. by reinstalling the app (with a known PIN) and redeploying the previously backed up contents of the "Main Folder" inside the (hidden) .keepsafe folder they can be viewed, according to this
appcyla.wordpress.com/...ding-apps/

jaclaz

The problem with using another phone is these images may contain contraband, and all we have for testing is a personal phone. The rest are either far off brand, or very old (Android 2.3ish).

I emailed you about the AndroVM/Genymotion. Absent reversing the encryption (I am seeing reference to libcrypto in the KeepSafe folder), that is my best option, I think.

ReplyQuote
Topic starter Posted : 06/12/2013 2:51 am
AlexC
(@alexc)
Active Member

If you have the APK for the application, dump it and decompile the code - it sounds like they're using a static key (by the sound of the link posted above), so it should be defined in the code somewhere (unless, I suppose it's getting pulled down from a server each time, but that sounds risky) - it'll probably give you a better idea of the encryption scheme used as well.

They might have obfuscated the code, which would make the digging more "fun", but I've had success doing similar jobs this way.

Trimming off the PNG bodged at the top of the file (it has an empty IEND tag at the bottom, so you should be able to just go from that point down) would, I suspect, give you the encrypted data.

Good luck with this, sounds interesting! If I get a chance to play I might download the app and have a poke…

ReplyQuote
Posted : 09/12/2013 10:24 pm
twjolson
(@twjolson)
Active Member

If you have the APK for the application, dump it and decompile the code - it sounds like they're using a static key (by the sound of the link posted above), so it should be defined in the code somewhere (unless, I suppose it's getting pulled down from a server each time, but that sounds risky) - it'll probably give you a better idea of the encryption scheme used as well.

They might have obfuscated the code, which would make the digging more "fun", but I've had success doing similar jobs this way.

Trimming off the PNG bodged at the top of the file (it has an empty IEND tag at the bottom, so you should be able to just go from that point down) would, I suspect, give you the encrypted data.

Good luck with this, sounds interesting! If I get a chance to play I might download the app and have a poke…

Yea, that is WAY above my head.

But, you know, if you want to do so for me, feel free.

The current plan is to get a identical phone, load the .ksd files onto a mSD card, and enter the PIN on that test phone. Then, either restore them and dump the phone, or photograph the screen of each picture.

We also put in a request for assistance with the company, we'll see if we hear anything back.

Terry

ReplyQuote
Topic starter Posted : 10/12/2013 12:26 am
AlexC
(@alexc)
Active Member

It's actually (potentially) not as tricky as it sounds.

There are a number of decompilers which go back to (more or less) Java now. They used to decompile to Dalvik Op-Code instructions, which although more "interesting", were far harder to work with.

Once it's decompiled I'd just start grepping the files for
"key"
"crypt"
"AES"
and hex strings surrounded by quotes.

It might help if you have some experience reading code, or have some understanding of how a program is likely to have been structured, but in this case, simple text searches would be a good place to start.

ReplyQuote
Posted : 10/12/2013 2:22 pm
twjolson
(@twjolson)
Active Member

For those who may be interested (I would be surprised if no one else came across KeepSafe in their cases, especially child exploitation…)

I started by making an image of a test phone that had been wiped (which was a pain, as I had to bypass Android activation, since I didn't have a cell account to go with the phone), that way I could show that the unencrypted images weren't there to begin with.

I installed KeepSafe and set the passcode to the same as the suspect phone.

I then transferred the encrypted pictures by plugging in the phone. The Encrypted pictures are on the Internal pseudo-mSD Card (which I forgot about, and went through a bit of trouble to prep a physical mSD card. I then used Explorer to browse and take screenshots to show that there was no files in the Keepsafe folder prior to the copy over procedure. I then copied over the .keepsafe folder, and merged the source and destination. I then used Explorer to show that the encrypted files were now in place.

Next, I used ZRT to take pictures of the now unencrypted photos. I did this because I was unsure if I would retrieve unencrypted versions when I dumped the phone later.

After that bit of fun was done, I used Keepsafe to unlock (I think that is its term keepsafe uses.) the pictures. It does this by reading the database which has original file names and paths. I was concerned this wouldn't work, as the test phone didn't have this database with the original files and paths. It turns out that it sent them all to /data/data/media/DCIM/public/*.

Thanks to all who responded in forum and via email.

ReplyQuote
Topic starter Posted : 10/01/2014 1:15 am
Share:
Share to...