I would say that all three approaches above are either very problematic or very non-productive.
What is option #4? ?
Perhaps just what the OP actually did test, observe a problem and publish (informally or formally). That's what 'security researchers' do in closely related areas – test software, identify security problems, and publish. (Some of their discoveries even get patched … ) The difference seems to be that much of DF software is closed source and expensive, so not everyone can do the actual testing, and not everyone who has access can create the tests themselves.
Brian Carrier's initiative DFTT identified 'Testing in the public view' as important – it seems to be just what is being discussed here. While the tool being tested may be expensive, and so out of reach to some, the test design itself and any test data should be easier to get involved with.
So … are there any public test suites/test images for this particular area? If not, is it possible to build some? What would it require? What does it need to adapt to – different releases of Android or some other software? What questions should it answer? Etc.
Even if only a half-decent design/suite is produced, it's a platform that can be improved and extended. If everyone has to reinvent the wheel, we'll never get out of this particular ditch, unless the tool makers magically get their collective act together.
I'd like to thank everyone for comments.
To trewmte; I do not have the header/s for the original text message/s from the target SIM Card from UFED or XRY. But I have the following details from SIMcon extraction
TP-MTI SMS-DELIVER
TP-MMS MORE MESSAGES WAITING
TP-RP NO RP
TP-UDHI THERE IS NO INFO THAT GOES BY THIS NAME IN THE EXTRACTION
TP-SRI STATUS REPORT SHALL BE RETURNED
TP-OA 90…………(THE SENDER'S PHONE NUMBER)
TP-PID MOBILE-MOBILE
TP-DCS-CODING UCS2
TP-DCS-CLASSIMMEDIATE DISPLAY
TP-DCS-CLASS(EMPTY)
TP-SCTS 15 aug 12 190928 gmt+03.00
TP-UDL THERE IS NO INFO THAT GOES BY THIS NAME IN THE EXTRACTION
There are also other details in addition to the above ones. Maybe they include the above missing details under different name. The report is updated with more anonymization and SIMcon extraction message details is added. http//
I have used different readers on different computers. XRY and UFED has it their own readers. And with SIMcon, I have used and SIM card reader. And the card reader was attached to different computers at the time data was 'extracted' and 'harvested' from the target SIM card.
I do not know whether the original text message/s were saved directly to the target SIM card or saved in the handset and then later saved to the target SIM.
Regards,
Hi Yunus, thanks for checking and your replies. I will study the data you have given and offer some suggestions.
I was raising different observations in my post to see whether there would be other reasons other than the way each program extrapolates the data pointing to the conflicts you mention in your original post - e.g. are the programs you are using; can sometimes not reproduce the same output.
In part, you may have to accept that due to the way each programmer has written their SIM reading software that it may produce results the programmer personally thought was relevant as opposed to faithfully following the standard. By way of illustration you recorded
TP-UDL THERE IS NO INFO THAT GOES BY THIS NAME IN THE EXTRACTION
UDL is important when checking to see the length of the message sent actually matches the length of data in the production of a received message. As you know, this is where you 'might' see conflict between the actual message sent and potentially an altered message residing in the inbox.
I would like to look into your matter further and ask questions. However, this equally requires your time, if you are willing and able to give it?
Out of curiosity has XRY, UFED or SIMcon contacted you, yet, to offer an explanation?
Yes, I did (PM) and I am waiting for yunus reply.
There might be several reasons and we are checking this.
Hello trewmte,
Yes, you can ask further questions and I am willing and able to give it, however, if futher details requires the actual SIM card or generating a log file by re-examining it, I may not be able to provide details as the actual SIM was already sent to the requestor.
By the way, UFED and PARABEN (who purchased SIMcon)has contacted me.
UFED asked for generating a log file, however, the SIM was already sent to the requestor, so I can not generate it.
PARABEN said they purchased SIMcon, integrated the code into device seizure and asked if I would be willing the test the Device Seizure.
Regards,
Hi Yunus
I downloaded and read your report (english version), thanks.
For all three exam reports, you may consider require some clearer explanations from the respective SIM Card reading software producers as to exactly what they intended to be understood from their use of identification and terminology.
Whether they take these genuine observations to seek clarity as opposed to making criticism (which I hope not) I cannot say. Also, whilst hindsight is a wonderful thing and bestows knowledge on us all that needs to be weighed in the balance as to whether the terminology would mean the same interpretation when compared with the GSM/3GPP Standards?
Can I invite you to look at 3GPP TS 23.038 / TS 23.040 and consider indepth the absence of confirmation regarding
1. User Data Length (UDL) - why the software does not define this parameter for the actual length of the data?
2. Language Indicator (national, shift and locking shift mechanism) - whether all or part of a message would be discarded?
3. The impact of UCS2 and the number of characters per text message - for SIMcon the use of length 176 for every length field?
4. The variation in the timing issue for TP Service Centre Time Stamp (TP SCTS) - you have already noted the 90 minutes difference for UTC (XRY/UFED) suggests as the increments in the standard defines 15-minutes there is a misinterpretation by factor of 6 increments for the Time Zone?
5. The relevance of the SIMcon wording "TP-DCS-CLASSIMMEDIATE DISPLAY" - is it intended to communicate a Class 0 flash message?
Yunus, you work you have made available in this matter is evidentially important and thus impacts on examiners practices and procedures for examining SMS text mesaages. Have you received any answers to the issues you raised?
Trewmte,
The guys from Cellebrite have contacted me and said they have fixed the problem with the new update. That is good news. Thanks Cellebrite for quick response and fix.
Also, Paraben contacted me and said they acquired SIMcon and integrated the code into Device Seizure. Also, I was asked if I would you be willing to test Device Seizure on the SIM and share my results.
As the SIM used in the test was already examined and sent to the requesting agency, I can not re-test these software with the same SIM card again. However, I will continue the tests with new SIM cards to come to the lab for examination.
Regards,
Trewmte,
The guys from Cellebrite have contacted me and said they have fixed the problem with the new update. That is good news. Thanks Cellebrite for quick response and fix.
Also, Paraben contacted me and said they acquired SIMcon and integrated the code into Device Seizure. Also, I was asked if I would you be willing to test Device Seizure on the SIM and share my results.
As the SIM used in the test was already examined and sent to the requesting agency, I can not re-test these software with the same SIM card again. However, I will continue the tests with new SIM cards to come to the lab for examination.
Regards,
Hi yunus thanks for coming back and for the update.