Cant open database anymore on latest whatsapp

[wjp79]

When opening a database I get a message that I am using an older version of the viewer. When opening the database with a sql viewer I saw they changed and hashed a lot of data like phone numbers etc.

I hope you get this working with the latest changes....

[andreas-mausch]

Uff. :( Thanks, I'll check out what they've changed.

[ghost]

I believe it is related to the legacy_available_messages_view view.

[GeorgFleig]

@andreas-mausch you can check out the necessary changes here: https://github.com/residentsummer/watoi/pull/47/files

[wjp79]

Hi, So I used the sql command (thanks venusjivani) to insert the legacy-avaiable_messages_view to be inserted into the msgstore.db. But when I open the msgstore.db file with whatsapp viewer, I still get the "you seem to open an older whatsapp database" message. Is there a debug switch or something to find out what is going on?

I get the msgstore directly from my rooted phone. (I dont decrypt the file)

Thank you

[wjp79]

So I manual added the missing tables and now I can open the database with whatsapp viewer. But now to figure out how to add the content of the new tables to the old tables so I can view them in whatsapp viewer. Piece of cake....:-( (I really need to learn how to code...)

[andreas-mausch]

I've taken a new backup on my test phone. Unfortunately, WhatsApp banned my phone number (most likely because I was using the Android Emulator with no real SIM). Luckily, they responded quickly to my support ticket and unbanned the number again.

So, I have a dump of a new database schema: A lot of things changed.

• The database names and count changed a lot
• There seems to be one database table for each type of message you can send, which looks quite clean
• The filename (they call it file_path) is now stored in a database field, and not in a serialized Java object anymore (see #22). That's a big improvement (or the solution before was quite hacky if you will)
• Thumbnails are now only stored in one place (before for example link thumbnails were stored differently than image thumbnails) :+1:
• There is a lot of stuff WhatsApp Viewer can't handle yet, like payments, status, calls, contacts etc.
• One thing which isn't clear to me yet is quoted messages: I can see the according database table, but I cannot see how the quoted message is referenced (at least in my test database the key_id points to messages which don't exist).
• Also, for the encryption part, I tried to look up how https://github.com/ElDavoo/WhatsApp-Crypt14-Crypt15-Decrypter does it. And it seems to be a bit more complicated than the fixed offset used before. Not sure how fast I can get some similar logic in.

I managed to update WhatsApp Viewer to get the basic functionality work again with the new database schema. However, only with the new one. I need to put more time in to make it compatible with the old version(s), too.

My plan is to make a release just for the new schema nevertheless, so WhatsApp Viewer at least works again for more recent backups.

[wjp79]

Hi, thank you for the update! Looking forward to this release.

[ElDavoo]

• Also, for the encryption part, I tried to look up how https://github.com/ElDavoo/WhatsApp-Crypt14-Crypt15-Decrypter does it. And it seems to be a bit more complicated than the fixed offset used before. Not sure how fast I can get some similar logic in.

That program does a lot of checks that were skipped before. The important problem is that we ignored the database header completely, so when its length changes, we can not decrypt anymore. It also does many more checks you don't need.

Correct and boring solution

The important stuff that you need to do is to:

1. Read the first byte of the db, which is the length of the upcoming protobuf message.
2. If the second byte is 0x01, you need to skip it (not sure why)
3. Read and parse the protobuf message. You can use .proto files in the linked repo to generate classes for this program. Of course you are only interested in the IV.
4. The rest of the file is the encrypted db to decrypt as usual

Quick and dirty solution

A much hackier, cheaper solution is to just use a list of hardcoded offsets instead of a single pair of offsets lol