Join Us!

Sony Ericsson Sent ...
 
Notifications
Clear all

Sony Ericsson Sent SMS Date/Time  

  RSS
KVS379
(@kvs379)
New Member

Hi All,

A particular exhibit which I am working on is a Sony Ericsson and as with all Sony Ericssons the date and times of Sent SMS are never extracted.

This occurs on all the tools I have used; XRY, Paraben, Oxygen, Cellebrite.

Does anyone know why this is and does anyone know if there is a solution to this problem? Obviously, without having to manually transcribe each individual message.

Thanks,

Regards,

KVS

Quote
Posted : 12/06/2009 2:16 am
AlexC
(@alexc)
Active Member

Having spoken to Robert at MSAB about this in the past - it is apparently down to the protocol used to extract calls on Sony Ericssons (GSM0705 off the top of my head - but don't quote me on that!).

You'll get the same thing with most LGs which also use the same protocol. It's not a limitation of the software as such - just the protocol.

ReplyQuote
Posted : 15/06/2009 4:28 pm
trewmte
(@trewmte)
Community Legend

AlexC GSM0705 is one of a number of standards to look at for SMS text messages. The format for SMS text messages headers are pretty standard so I am puzzled why it is suggested to you that somehow the header of the text message has been truncated and removed from body of message or not supplied by the handset due to protocol?

I do not see how it is a protocol issue, unless you mean the protocol used within the handset software readers are not calling and fetching the data using a protocol that the handset itself understands. Which makes it a handset software reader ("XRY, Paraben, Oxygen, Cellebrite") problem and not a protocol problem of the handset itself per se, which I should add displays the date and time stamps quite adequately.

ReplyQuote
Posted : 15/06/2009 6:15 pm
AlexC
(@alexc)
Active Member

Is it possible to "spy" on the AT commands sent to, and the responses given by the handset?

I would be interested in investigating whether the handset replies with anything looking like a time-stamp for these messages.

Might it be possible to "talk a different language" to the handset in order to get these timestamps?

I'm fully aware that the handset displays the date stamp, and from what I remember from investigating test Sony Ericsson handsets' file system (a little forcefully!) the timestamps were present and correct - whether they were in the standard GSM-esque format I can't remember; probably though - as I don't recall having any great deal interpreting them.

ReplyQuote
Posted : 15/06/2009 7:12 pm
KVS379
(@kvs379)
New Member

Cheers for the replies guys.

From both your answers I suppose it is safe to assume that no solution is available yet.

However, how is it that these leading mobile forensic software suites are all lacking in this particular area? Does it come down to the actual mobile phone software?

ReplyQuote
Posted : 15/06/2009 7:25 pm
burratha
(@burratha)
Junior Member

Greg,

I appreciate what you're saying and I agree with your comments in the main, however I would suggest that the issues raised in this thread generally relate to outgoing SMS.

I do think, however, that how a handset sends the data over the network, and how it stores its own self-generated data (ie. SMS created on the device) are different. Incoming SMS information is generally taken from the SMS packet, therefore would "normally" be stored as a standard form.

Example

* Nokia S40 handsets generally store incoming SMS timestamps as YYMMDDHHMMSS (reverse nibbled) however outgoing messaged are stored in a different format, and only then when the internal clock is set.
* iPhone - all SMS data is stored in SQlite databases
* BlackBerry - again, stored in databases

However, all these devices comply with the standards when they send the data over the network - let's face it, they would have to or the message wouldn't be transmitted. Would it?

It seems the this Sony Ericsson is no different - with outgoing timestamps and their relationship to the respective message being stored in a proprietory format.

Food for thought/discussion?

ReplyQuote
Posted : 17/06/2009 3:40 pm
AlexC
(@alexc)
Active Member

I emailed Robert at MSAB again, for some clarification and he sent me a useful link that I think goes some way to explain the limitation.

http//www.developershome.com/sms/cmgrCommand.asp

If you scroll down to the section titled "26.2.2. Format of the Information Response of the +CMGR AT Command in SMS Text Mode"

and look at the response format for incoming

+CMGR message_status,address,[address_text],service_center_time_stamp[,address_type,TPDU_first_octet,protocol_identifier,data_coding_scheme,service_center_address,service_center_address_type,sms_message_body_length]sms_message_body

and outgoing

+CMGR message_status,address,[address_text][,address_type,TPDU_first_octet,protocol_identifier,data_coding_scheme,[validity_period],service_center_address,service_center_address_type,sms_message_body_length]sms_message_body

messages (the square brackets are optional fields) you'll notice that the SMSC Timestamp is omitted from the outgoing response. (The validity period doesn't appear in the Incoming response).

So it appears that by using this particular set of AT commands you can never get a timestamp for outgoing messages - the handset stores them, true enough, but you'd have to get at them another way.

It makes me wonder how SE's own software addresses the SMS (you can do a backup of all the SMS with it). Does it extract the dates for the (sent) messages? And if it does what "language" is it speaking to the handset?

(edited to remove the code tags that were needlessly stretching the screen!)

ReplyQuote
Posted : 17/06/2009 4:54 pm
trewmte
(@trewmte)
Community Legend

I have no arguments with any of the replies above, which I fully appreciate provide useful advice and guidance, save to say that if a handset software reader protocol is not understood by the handset itself to return the data to the handset software reader, that the software is seeking, then this shows the software is unable to communicate in a language that the handset understands, in this case return of date and time stamps for text messages.

My comments are intended to shift any ideas regarding the mobile telephone being at fault unless proven otherwise and align the issues associated with this puzzle where they belong and that is with the handset software reader. I take it at this stage of this particular handset software reader's development it is unable to retrieve certain types of data from the mobile telephone in question.

Additionally, there is no mandatory requirement for a mobile 'phone to use AT Command for certain types of data.

ReplyQuote
Posted : 18/06/2009 6:24 pm
Share: