Forgery messages history in the Skype database

I am not aware of how the checksum in the skype database is calculated. Certainly it is straight forward to open the main.db file in an sqlite editor modify a message/save it and then open skype (rather than an investigation tool such as SkypeAlyzer) and see the changed message in the history for that contact.

What you won't get is the edited message in the recipienst history, or in an alternate database for your (the edited) account on a different machine.

Tnx for answer. And I want to clarify …
I have a conversation between two users using Skype (two files main.db).
Some of the chat-messages between them do not match the text.
I suspect that one of them changed their messages in its database using some SQLite-editor program.
How to identify which of them had falsified the history of their messages?

Looking for evidence that an SQL Browser was installed/uninstalled would suggest the user had the ability to achieve that

A traces of the use of SQlite-editors - registry, lnks, prefetch - investigated. No traces.
I thought that by the value of the field 'crc' in table 'messages' I can identify a fake text chat messages.

A traces of the use of SQlite-editors - registry, lnks, prefetch - investigated. No traces.

Can you clarify a couple of things?

First, which OS were you examining? I get from what you've said already that it's Windows, but I'm interested in which version.

Second, can you clarify which locates you checked, specifically? For instance, what did you check in the Registry, exactly, and what process did you use?

Ок!
1. I have to examine two HDD with ‘Windows XP Professional’ from two computers (HDD1 & HDD2).
2. I used Encase 6.19, Mitec’s WRR and RegRipper 8) and SQLite Database Browser 2.0 for viewing 'main.db'.
3. I checked in the registry
RecentDocs, Shellbags, UserAssist, LastVisitedMRU, ACMru, OpenSave MRU, RunMRU, AppCompatCache, apppath, uninstall – with WRR and RR.
4. Prefetch analysis - notable pref-files not found. I used Encase.
5. LNKs analysis - notable LNKs not found. I used EnCase.
6. Keyword search 'main.db', ‘sqlite’ (UTF8, ansi, unicode codepages)

Not found anything useful.

Now I suspect that the file ‘mian.db’ can be copied from HDD2 to another computer, then modified and copied back. This is indicated by the date of creating file ‘main.db’ on HDD2.

ctime – 04/14/2013 (attributes $STANDARD… and $FILENAME checked).
But the message history in that file for a period between 03/16/2011 and 06/12/2011.

But this is not enough… imho

Depends how far you can go with evidence collection but maybe get the GUID of a potential thumb drive that was connected around those dates, then request collection of that storage medium too. Then obviously run checks to see if the file still remains on that drive. That should be strong enough IMO, even though it doesn't directly point the finger but it does raise more questions.

However, if you're doing this for personal experimentation then I can't help you any further with technical advice. I'm only a final year student and I'm stumped out of ideas from what I've been taught.

I am computer forensic expert in the state department of law enforcement.
And it's not personal. The fraud case.
2Adampski - Thanks for idea of checking USB data devices

Sometimes, showing that there is discrepancy is evidence in itself.

But, here is what I would do if I had time to dig - find an open source code that reverse engineered the main.db.

Browser Artifact Recovery Forensic Framework (BARFF) for example, contains the information, including main.db structure. Check the code and see if there is something in there.

Maybe Skype Logs Reader by NirSoft will give you a different view.

Maybe digging through other references to the database structure could help.

Test. Install the same version of Skype, make a few chat lines of various type, then see if you can generate the same checksums (if they are checksums). This is of course could get quite cumbersome and complicated. (What fields to include for example.)

Good luck.