Hello,

I’m currently working on an investigation that involves a Blackberry 8310 device. My specific question is the following; is there a legitimate situation where the “original date/time” field within the EXIF metadata of a photo taken by the Blackberry device would be off by many hours from when it was claimed that the photo was taken?

The Blackberry device in question is set to use “Blackberry” as the source to synchronize date and time with. Time zone is set correctly.

To paint a clearer scenario with specific details changed, I have a client who is stating that a photo was taken at 3:30am on 1/18. However, the EXIF data of the photo shows an original date/time of 9:18pm on 1/17. I want to know, with a high degree of confidence, that the EXIF data contained within the image with original date/time pulled from the Blackberry device is accurate. Else, are any of the following scenarios probable (or others)?

- RIMS time servers sending out incorrect time to Blackberry devices, thus writing incorrect time stamps in the EXIF metadata?
- other?

Thank you in advance.

If it was set to a different time zone and the date/time was set manually then yes it can write a different timestamp. Let me know if you have anymore questions and I'll do what I can to help you. I've had to do Forensic's on Blackberry's before and don't envy you.

When the time is set to Blackberry, does not mean a server from RIM will update the time, that means that you specify the time manually. So you can set that at any time you want no matter the time zone

Regards

I am out of my league here as far as the forensics aspect but my first approach in verifying my primary assumption would be to cross-reference any calls made prior to and after the photo was alleged to have been made and then reference those call times?

If the calls log times are accurate prior to and subsequent to the photograph being taken - the logical assumption would be that the photograph time is accurate.

This could be backed up by placing phone calls, logging them - taking a picture then placing more phone calls. Repeat this a few times under similar conditions as on the day in question and I would think you have a fairly solid piece of information to work on right there.


David

More than likely the EXIF is correct, but VIOLATOR has a good idea.

That is an amazing idea!

Thanks for all the input. I went down a similar path as Violator suggested. Initially I began by looking at the logs on the device. Next I imaged the device and used both ABC Amber Blackberry Converter and Blackberry Simulator to go through the data within the image. In parallel, after imaging the device, I compared EXIF data from photos taken prior to the incident and after the incident -- the original date/time was correct before and after the incident.

I want to make sure that I can trust the EXIF original date/time from the photo beyond a reasonable doubt.

Again, thanks for all of your feedback!

Update: I was finally able to recreate (and consistently) a situation on the device in question whereby the wrong creation date was being written into the EXIF field. I've written more about it here:

blog.zenone.org/2009/01/forensics-blackberry-curve-8310-and.html

Thanks again,
Steve

That's pretty odd it time stamps with a different time stamp without even needing to fiddle with the time zone. I get a slight time difference. Not hours, but I waited for the clock to roll to 14:43 and took a picture. It came through with EXIF time of 14:42:26, or almost 30 seconds too soon.

I'm thinking that's the time I started the camera since I did wait a while for the time to roll over. I took another series of shots one after the other and they came through with different times stamps. Maybe just the first one gets the wrong time stamp.

Not sure if I am helping or not.

I took 3 photos with my 8310. I uploaded them to my linux box and ran a program called "jhead" on them. This tool can read and display EXIF data on jpeg images. All 3 photos EXIF dates and times matched what my 8310 shows in image properties.

maybe I'm doing something wrong?


EDIT: forgot to mention that I'm running v4.5.0.110

MORPH - I appreciate you posting some follow-up to this as this was an extremely interesting thread - as was the post in your blog regarding this issue.

Please continue to post on this issue and any other findings or suspicions you may have.

Thanks


David

any chance of us getting to see this picture you speak of? sounds pretty scandalous!

Here's an update...

ADDITIONAL ENABLED SETTINGS WORTH NOTING:

* PASSWORD (options | security options | general settings | password)
* BACKLIGHT TIMEOUT value of 30 seconds (options | screen/keyboard | backlight timeout)
* SECURITY TIMEOUT value of 1 minute (options | security options | general settings | security timeout)

[update: 1/23/2009] - I can also reproduce this EXIF incorrect time stamp issue without deleting photos. This issue presents itself only with the first photo taken after the phone has automatically locked, requiring a password to unlock before the said photo with the incorrect EXIF time stamp can be taken by the device. Subsequent photos taken before the security timeout locks the device have the correct EXIF time stamps.

[update: 1/23/2009] - Could this be a residual artifact of the security lockout feature? (will need to test after disabling the security timeout)

devnull -- I'd be curious if you can recreate the problem I'm seeing by enabling the security timeout feature (if not already set for 30 sec w/ a password) and:

1. Take a photo [for this example, IMG00001]
2. Let the security timeout automatically lock the phone
3. Wait a bit
4. Unlock the phone and take two more photos before the phone automatically locks again [for this example, IMG00002 and IMG00003]

From there copy the pictures over to your Linux box and look at the EXIF data. If you're able to recreate the same problem I'm seeing, I suspect you'll see the following:

• IMG00001 may or may not have the correct EXIF time stamp
• IMG00002 will have an incorrect EXIF time stamp. It will probably show a date/time when IMG00001 was taken
• IMG00003 will have the correct EXIF time stamp

Thanks for everyone's help and input!

I just got finished reading another thread and just found it extremely interesting that the time difference indicate is 2 minutes:



Whether it is relevant or not I have no idea. But the fact that the time difference you were able to recreate and substantiate, and this issue stated above, is a very intriguing coincidence.

Could that difference be because there is a difference between Blackberry time and Network time? I am curious to know what the time setting was applied on the phone and what setting the imaging system uses to stamp the time?


David

Instructions followed with the exception of one. I don't have the ability to set a 30sec security timeout. The least I could set it was 1min. Below is the data as displayed from Linux jhead utility.

******** IMG00017.jpg ************
Exif header 300 bytes long
Exif section in Intel order
(dir has 9 entries)
Make = "Research In Motion"
Model = "BlackBerry 8310"
Orientation = 1
XResolution = 72/1
YResolution = 72/1
ResolutionUnit = 2
DateTime = "2009:01:24 10:47:05"
YCbCrPositioning = 2
ExifOffset = 194
Exif Dir:(dir has 6 entries)
ExifVersion = "0220"
DateTimeOriginal = "2009:01:24 10:47:05"
ColorSpace = 1
ComponentsConfiguration = "?"
ExifImageWidth = 1024
ExifImageLength = 768
Jpeg section marker 0xdb size 132
Jpeg section marker 0xdd size 4
JPEG image is 1024w * 768h, 3 color components, 8 bits per sample
Jpeg section marker 0xc4 size 418
File name : IMG00017.jpg
File size : 33682 bytes
File date : 2009:01:24 10:52:49
Camera make : Research In Motion
Camera model : BlackBerry 8310
Date/Time : 2009:01:24 10:47:05
Resolution : 1024 x 768

Wait for security timeout..............

******** IMG00018.jpg ************
Exif header 300 bytes long
Exif section in Intel order
(dir has 9 entries)
Make = "Research In Motion"
Model = "BlackBerry 8310"
Orientation = 1
XResolution = 72/1
YResolution = 72/1
ResolutionUnit = 2
DateTime = "2009:01:24 10:49:55"
YCbCrPositioning = 2
ExifOffset = 194
Exif Dir:(dir has 6 entries)
ExifVersion = "0220"
DateTimeOriginal = "2009:01:24 10:49:55"
ColorSpace = 1
ComponentsConfiguration = "?"
ExifImageWidth = 1024
ExifImageLength = 768
Jpeg section marker 0xdb size 132
Jpeg section marker 0xdd size 4
JPEG image is 1024w * 768h, 3 color components, 8 bits per sample
Jpeg section marker 0xc4 size 418
File name : IMG00018.jpg
File size : 24391 bytes
File date : 2009:01:24 10:52:49
Camera make : Research In Motion
Camera model : BlackBerry 8310
Date/Time : 2009:01:24 10:49:55
Resolution : 1024 x 768

******** IMG00019.jpg ************
Exif header 300 bytes long
Exif section in Intel order
(dir has 9 entries)
Make = "Research In Motion"
Model = "BlackBerry 8310"
Orientation = 1
XResolution = 72/1
YResolution = 72/1
ResolutionUnit = 2
DateTime = "2009:01:24 10:50:00"
YCbCrPositioning = 2
ExifOffset = 194
Exif Dir:(dir has 6 entries)
ExifVersion = "0220"
DateTimeOriginal = "2009:01:24 10:50:00"
ColorSpace = 1
ComponentsConfiguration = "?"
ExifImageWidth = 1024
ExifImageLength = 768
Jpeg section marker 0xdb size 132
Jpeg section marker 0xdd size 4
JPEG image is 1024w * 768h, 3 color components, 8 bits per sample
Jpeg section marker 0xc4 size 418
File name : IMG00019.jpg
File size : 22361 bytes
File date : 2009:01:24 10:52:49
Camera make : Research In Motion
Camera model : BlackBerry 8310
Date/Time : 2009:01:24 10:50:00
Resolution : 1024 x 768

Devnul -- did all of the DateTime and DateTimeOriginal values match up with the actual times the photos were taken?

Wirelessly posted

Morphic - yes they do. I wll do another batch and do a better job of reporting.



Just outa curiosity,what's the purpose of the security lock timeout value in these tests?

I'm not sure if the timeout value has anything to do with the issue I'm seeing. I listed the value for documentation if others were to setup a *somewhat* similar environment for testing.

Thanks again!

absolutely fascinating read

I agree! I think this might need it's own section. Maybe CSI BB? I couldn't stop reading it. I am setting this as a subscription with instant notification. I am waiting to see what is going to happen next.

this issue only happens when the bb locks with de camera app running, isn't?

This doesn't seem to be limited to the 8310. I have an 8330 and it also writes bad EXIF data. While I have not gone to the analysis extent that other folks in this thread have, I have seen similar - if not the same - behavior.

I file my photos by date taken so we can browse them later on the computer by logical "event" (e.g., "Las Vegas Vacation"). If I sort by EXIF date taken, the images are invariably out of order and I have to manually figure out what the sequence was so I can guess at what the proper EXIF data should be.

It's very frustrating. I thought it was just something I was doing wrong. I hope it'll be fixed, but I'm not holding my breath.

my bold also has problems with correct EXIF dates... the filedate is always correct, but the EXIF date is only occasionally correct... its really annoying.