Hi, this is my first post here. I've read through a number of threads around here searching for my answer, but I just couldn't find it. So I'm hoping you smart folks here can help!

I want to make a bit-for-bit copy of the internal memory of my Blackberry. Any suggestions on how I would do that?

I have javaloader.exe and I have been playing around with the "recoverflash" command. Unfortunately it appears that this command requires that an OS be installed. Currently I have the BB wiped. I would like to look at a bit-for-bit copy of the memory while the BB is in its wiped state. I am trying to confirm that there really is nothing but zeroes.

Thanks in advance for any advice!

GuyFaux

Don't think anything like that exists.. But wait for others to chime in.

Two guys in black helicopters just dropped off this software at my house.
That and a tin foil hat.

Why would you want to do that unless you think you can hack the OS. I would think other have tried.

Give me a break. You assume to much.

I am doing this because my employer wants independent confirmation that the wiping utilities commonly used (javaloader.exe) and the wipe function built into the OS are doing the job as described. The easiest and surest way of doing this is taking a bit-for-bit image of the memory after a wipe and then looking at everything to see that it is in fact zeroed out or filled with uniform or pseudo-random data.

I am also curious if slack space is wiped during the wipe initiated on the handheld. RIM documentation says nothing about it from what I have read.

So....

Can anybody out there help?? Does anybody know more about the "recoverflash" command in javaloader.exe? I haven't been able to get it to work.

A very similar question was asked not to long ago, but can't seem to find the thread.

EDIT:
Found it. >>> How secure is the System Wipe?

And this was within the above thread.
http://docs.blackberry.com/en/admin/..._842412_11.jsp

Ok I will give you a break, a wipe will delete all sensitive data placed on the unit. The only remaining data will be the OS.

MY employer has tested this due to the data we send and receive.

Thanks. I read through that thread, but my problem is slightly different. My employer wants to see proof that every single bit is securely overwritten and I can't just take someone's word for it.

I appreciate the info you did provide though. I have saved it and it will go in the report I'm writing.

(I removed the hyperlinks from your quotes because I need to have 10 posts before I am allowed to link. )

Thanks. But I need more than just someone's word from the internet.

Any ideas on how to prove the wipe?

Wow, your boss can't take the word of RIM and the DOD?

http://docs.blackberry.com/en/admin/...l_Overview.pdf

I think you will have a hard time trying to prove those bits are flipped without getting RIM involved... Good Luck

Actually, that is just the word of RIM (not the DOD, the DOD just made the standard), which unfortunately is someone I am not allowed to take the word of. I am required to independently confirm the wipe.

This actually doesn't seem like something that would be terribly difficult to prove. What I need is a tool that can interact with the memory of the module without going through the OS. I was hoping there was a developer tool already out there that filled this role. Ah well..

Post your exact needs in the Developer section. Be specific and maybe you can get an answer.

Make sure you reference that a Mod asked that you post it there so you won't get flamed for a double post.

Thanks for the advice. I started a new thread in the Developer section. We'll see if it pans out.

Hey folks,

Well, after some work I've made a little progress on this front. I found a tool called "RIM Wireless Command-Line Programmer" version 3.9.0.49.

There is a switch called csavefs that seems to make an image of the file system for "secure" phones.

BTW, secure phones appears to be pretty much all the modern ones. The file dump starts with an unencrypted header "REDFEDMP" and towards then end of the file in plaintext you can find EKEY. My guess is the data after this point consists of the encryption key and perhaps the encryption key length.

Fascinating stuff really. Anyway...back to my project:

My first problem is that when I "imaged" a BB Storm with 1GB of internal memory my image only consisted of 103MB. Obviously there is data missing! Second, when I added several plain text files (adding about 48 more MB of data) the resulting image was still only 103MB!

As far as conclusions...well...I can tell you this so far: It doesn't appear that javaloader.exe does any sort of wipe at all. After "wiping" with javaloader and then imaging the BB I still got an image with the plaintext file header and tons of encrypted data. Obviously those bits haven't been overwritten with 1's, 0's or even psuedo-random data.

If anybody has played around with the Command-Line programmer and knows more about it let me know...for me it has been way more useful than javaloader.