Password found but doesn't work

[altayhunter]

When I ran python2 crack_enmicromsg_db_\(C_version\).py it completed successfully and wrote the password to pass.txt. However, when I run tools/decrypt_db_with_password.py with this password and EnMicroMsg.db it tells me file is not a database.

I also tried using sqlcipher directly with the same results:

$ sqlcipher EnMicroMsg.db 
SQLCipher version 3.28.0 2019-04-16 19:49:53
Enter ".help" for usage hints.
sqlite> PRAGMA key = '1234567';
sqlite> PRAGMA cipher_use_hmac = OFF;
sqlite> PRAGMA cipher_page_size = 1024;
sqlite> PRAGMA kdf_iter = 4000;
sqlite> SELECT name FROM sqlite_master WHERE type='table';
Error: file is not a database

I tried setting more details, but it still fails with the same error:

sqlite> PRAGMA key = '1234567';
sqlite> PRAGMA cipher_page_size = 1024;
sqlite> PRAGMA kdf_iter = 4000;
sqlite> PRAGMA cipher_use_hmac = OFF;
sqlite> PRAGMA cipher_plaintext_header_size = 16;
sqlite> PRAGMA cipher_hmac_algorithm = HMAC_SHA1;
sqlite> PRAGMA cipher_kdf_algorithm = PBKDF2_HMAC_SHA1;
sqlite> ATTACH DATABASE 'plaintext.db' AS plaintext KEY '';
Error: file is not a database

Any idea why this isn't working? Note: I replaced my actual key with 1234567 in this comment.

[chg-hou]

@altayhunter Please refer #11 and post the outbuffer.

[altayhunter]

outbuffer:
de 3b ba 39 16 40 20 20 83 67
2a 66 52 f0 6c e9 6a 63 2a e6
41 25 f1 af 5c fa 06 d7 4e be
bc cb 04 9e 0b 38 f8 b9 e8 43
fd 11 ad 40 88 06 ad a5 24 7e
e2 37 c7 15 31 ac 44 ca 1f 2e
ec 94 3a 70 c6 29 ff 65 6d 58
f8 ba 98 ee 33 e1 ff 0b 94 63
a0 2d b7 ea 33 6e 55 ca cb 91
c1 19 c4 47 80 48 a7 13 f6 9e

[chg-hou]

Correct outbuffer should look like:

04 00 01 01 10 40 20 20 00 00 00 01 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 2d e2 26 0d 03 ec 00 02 03 62 00 03 62 03 b7 00 00 00 00, where bold letters indicate the hex for header checking used in password_cracker.c. Meanwhile lots of null bytes (0x00) should exist.

So the key you got is not correct. Please edit checkpoint = '995' # first three chars to start from and continue the cracking.

[altayhunter]

I'm using crack_enmicromsg_db_\(C_version\).py, so I edited pass_start to keep cracking. It found 22 passwords altogether, but only one of them had a correct looking output buffer:

outbuffer:
04 00 02 02 10 40 20 20 22 f2 
10 77 00 00 49 b3 00 00 02 9c 
00 00 00 3c 00 00 01 4f 00 00 
00 04 00 00 00 00 00 00 00 00 
00 00 00 01 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 22 f2 10 77 
00 2e 30 3a 05 00 00 00 58 01 
fe 00 00 00 02 37 03 eb 03 e6

However, when I tried this password I still got the same file is not a database error. Is this not a valid outbuffer?

[chg-hou]

@altayhunter Have no idea. The header seems correct. The only doubt is that: the file change counter (22 f2 10 77 = Dec 586289271) is quite large. I am not sure whether this is normal or not. A workaround is to transfer the database into another android phone using the backup function (Settings > Chat > Backup & Migration). As different phones use different password, it might be possible to crack the database from the new phone in the case of database corruption.

[amakuramio]

same problem here, my wechat is permanently blocked for ''fraud'' and im trying to backup and restore to new phone / account but no pass is working edit: funny, i found pass myself, i was always using capital letter when decrypting, it was imei of phone i registered with, plus uim, md5 first 7 without capitals

[wzyboy]

It seems WeChat cannot obtain IMEI on Android 10 devices, so the md5(imei + wxuin)[:7] trick does not work for me. So I went for brute-force tracking.

I tried all combinations from 0x0000000 to 0xfffffff in a few days. I have the exact same results as @altayhunter's: There are about 20 matches that have 40 20 20 in the outbuffer, but only one of them has lots of 00s in it:

Pass: 07a8537
outbuffer:
04 00 02 02 10 40 20 20 de ba
04 9c 00 00 9c aa 00 00 00 00
00 00 00 00 00 00 01 84 00 00
00 04 00 00 00 00 00 00 00 00
00 00 00 01 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 de ba 04 9c
00 2e 30 3a 05 00 00 00 64 01
b6 00 00 00 9c a4 03 eb 03 e6

But I tried to decrypt with key=07a8537 and got file is not a database error.

[wzyboy]

@chg-hou I looked up "file change counter" in SQLite doc:

The file change counter is a 4-byte big-endian integer at offset 24 that is incremented whenever the database file is unlocked after having been modified. When two or more processes are reading the same database file, each process can detect database changes from other processes by monitoring the change counter. A process will normally want to flush its database page cache when another process modified the database, since the cache has become stale. The file change counter facilitates this.

In WAL mode, changes to the database are detected using the wal-index and so the change counter is not needed. Hence, the change counter might not be incremented on each transaction in WAL mode.

I can see that my file change counter (de ba 04 9c) is even larger than @altayhunter's. I migrated all my chat log from a non-rooted Google Pixel 4 to a rooted Google Pixel 2. The Pixel 2 has only WeChat installed right after a factory reset. Since the chat log is migrated anew, the file change counter should not be this large, should it?

Also, there are indeed wal files in the same directory alongside EnMicroMsg.db. Does this affect the integrity of the main database?

[wzyboy]

Great I solved it. It seems there's a bug in tools/decrypt_db_with_password.py. I tried the do_decrypt() function in ppwwyyxx/wechat-dump and it successfully decrypted the db.

I'll file up a PR to fix the bug: #14

---

07a8537 is actually the first password candidate that I encountered. Lucky for me, only 2.99% (0x07a8537 / 0xfffffff) of all possible combinations are tried when the correct password is found. Unlucky for me, I did not read this issue first so I wasted dozens of CPU hours on subsequent candidates :joy:

[altayhunter]

@wzyboy Thank you so much! Your fix worked for me, so after all this time I've finally been able to decrypt my database.

[wzyboy]

Okay according to this comment, on Android 10 devices where WeChat cannot get hold of the IMEI, it just uses a fixed string 1234567890ABCDEF as the IMEI. Combining this with the UID and the calculated MD5 matches the brute-forced password I got.

So for any Android 10 users that cannot decrypt their databases with md5(imei + uid) trick, use 1234567890ABCDEF for IMEI...