crypt14 encryption

[ahmedtsadek]

Hexdump of your key file
file name: key
mime type:

0000-0010: ac ed 00 05-75 72 00 02-5b 42 ac f3-17 f8 06 08 ....ur.. [B......
0000-0020: 54 e0 02 00-00 78 70 00-00 00 83 00-01 02 0e 8f T....xp. ........
0000-0030: 7a 5c a9 27-eb c6 cd d0-c1 32 93 b1-78 52 ee 22 z.'.... .2..xR."
0000-0040: e2 f6 3e c4-2c c1 86 9c-19 55 45 d0-fb 64 7f fa ..>.,... .UE..d..
0000-0050: 6e ab 99 90-35 ba e0 12-54 37 a5 2f-17 c4 a0 33 n...5... T7./...3
0000-0060: ae 00 d8 4d-79 ac 5f 2e-55 a9 20 64-53 31 cd 84 ...My._. U..dS1..
0000-0070: 53 07 a3 78-1f 0a 7a 8b-f0 c3 5d 23-5f 71 00 00 S..x..z. ..]#_q..
0000-0080: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 40 20 ........ ......@.
0000-0090: 61 b4 f6 8f-52 08 c7 a2-ce c9 22 02-f0 b7 a3 de a...R... ..".....
0000-009e: 25 6a bd c3-63 68 5a ef-2a a4 03 d2-f2 77 %j..chZ. *....w

**Hexdump of the encrypted DB
file name: msgstore.db.crypt14
mime type:

0000-0010: bf 01 08 00-12 4d 0a 02-00 01 12 01-32 1a 20 0e .....M.. ....2...
0000-0020: 8f 7a 5c a9-27 eb c6 cd-d0 c1 32 93-b1 78 52 ee .z.'... ..2..xR.
0000-0030: 22 e2 f6 3e-c4 2c c1 86-9c 19 55 45-d0 fb 64 22 "..>.,.. ..UE..d"
0000-0040: 10 7f fa 6e-ab 99 90 35-ba e0 12 54-37 a5 2f 17 ...n...5 ...T7./.
0000-0050: c4 2a 10 cb-b4 7e 9c 0a-4e 25 06 d3-2c b0 11 3b .*...~.. N%..,..;
0000-0060: 6f c9 18 22-6c 0a 09 32-2e 32 34 2e-35 2e 37 36 o.."l..2 .24.5.76
0000-0070: 1a 02 39 35-20 01 28 01-30 01 38 01-40 01 48 01 ..95..(. 0.8.@.H.
0000-0080: 50 01 58 01-60 01 68 01-70 01 78 01-80 01 01 88 P.X.`.h. p.x.....
0000-0090: 01 01 90 01-01 98 01 01-a0 01 01 a8-01 01 b0 01 ........ ........
0000-00a0: 01 b8 01 01-c0 01 01 c8-01 01 d0 01-01 d8 01 01 ........ ........
0000-00b0: e0 01 01 e8-01 01 f0 01-01 f8 01 01-80 02 01 88 ........ ........
0000-00c0: 02 01 90 02-01 98 02 01-a0 02 01 a8-02 01 b8 02 ........ ........
0000-00d0: 01 c0 68 3e-72 90 f4 bf-44 3b 88 53-4d 16 82 01 ..h>r... D;.SM...
0000-00e0: 19 0e a5 93-e7 37 bb 8a-65 ae 04 e5-f5 8f f6 31 .....7.. e......1
0000-00f0: 35 b4 5a dd-6a d7 d2 e1-0d 6a bd f4-34 c0 b8 d9 5.Z.j... .j..4...
0000-0100: fa 7f 0b 1f-49 f6 6b 6c-b5 84 f0 a4-e8 3b d7 1c ....I.kl .....;..

Screenshots

Program output using -v and -f

Additional context
I decrypt the file it goes good but when I encrypt it again and move it to the device for restore it fails and says something wrong with the backup
Also I tried to replace the msgstore.db found in data/data/com.whatsapp/database folder with the new decrypted msgstore.db and same thing it fails and says something wrong with the database
if possible to chat let me know

[ElDavoo]

Hi, encryption still needs work

[ElDavoo]

Also I tried to replace the msgstore.db found in data/data/com.whatsapp/database folder with the new decrypted msgstore.db and same thing it fails and says something wrong with the database

It's strange, there are multiple checks to ensure everything is fine. Did you set the correct file permissions and SELinux context? Maybe the app does additional checks?
Unfortunately if WA doesn't tell what's exactly wrong I'm out of ideas.

[code-consensus]

Hi,

I have tried to run the same process in the latest version (v0.10.0), and I noticed something in the output that perhaps is related to the potential problem.

I follow the exact same command-line options as the original poster, but my output messages are different.

I run the following to make a crypt14 file:
waencrypt -v --reference msgstore_ref.db.crypt14 key_file msgstore_orig.db msgstore.db.crypt14

Then I run:
wadecrypt -v key_file msgstore.db.crypt14

However, instead of: mdbfactory.py:121 : [D] Header information in your crypt14 file: followed by Cipher version, key version, server salt, Google ID, etc, I have instead listed crypt15 info:
mdbfactory.py:121 : [D] Crypt15 info:
Header information in your crypt15 file:IV: xxxxxxxxxxx
Key type: 1
WhatsApp version: 2.24.09.80
...
i.e. no Cipher version, key version, server salt, Google ID

BUT, the IV number of what is listed as the "crypt15" header is actually the same IV as the original crypt14 header file, so some of the data is passing through at least.

Also my original crypt14 file had Key type 0, whereas the reencrypted one is Key type 1, so that info doesn't get picked up from the reference file. I do note though that the command-line options for waencrypt there is no "key type" input, so maybe that's why that doesn't get picked up as it is not process anywhere by the script.

N.B. if you try to instead to explicitly state crypt14 for the encryption via the "--type 14" argument, the program crashes:
waencrypt -v --type 14 --reference msgstore_ref.db.crypt14 key_file msgstore_orig.db msgstore.db.crypt14
--> props.py, line 42, in get_features
for i in range(5, self.max_feature + 1):
AttributeError: 'Props' object has no attribute 'max_feature'. Did you mean: 'get_feature'?

Perhaps the issue is that with using a crypt14 reference file, the program is mistaking it for a crypt15 file and encrypting as crypt15 or something like this?

[ElDavoo]

Hi, the encryption part is still hacky and I only did a few tests with crypt15 files, not with 14. I will try to make more tests and to fix these cases

[code-consensus]

Also my original crypt14 file had Key type 0, whereas the reencrypted one is Key type 1, so that info doesn't get picked up from the reference file. I do note though that the command-line options for waencrypt there is no "key type" input, so maybe that's why that doesn't get picked up as it is not process anywhere by the script.

I think I was mistaken in this aspect...
I think all crypt14 databases have key type 0 (I have seen from examining my own msgstore.db.crypt14 files), and in fact @ElDavoo code specifies that (in db14.py as "prefix.key_type = 0").
The reason my key type above was being set to 1 is because waencrypt, when using a reference file, assumes it is a crypt15 database -- and crypt15 databases seem to have a key type of 1 (according to my examination). For the record, with crypt15, it seems the program sets it in db15.py as "prefix.key_type = key_type.Key_Type.HSM_CONTROLLED" (which seems to result in "1")

[code-consensus]

Hi, encryption still needs work

Apart from not being able to use a crypt14 reference file, I would say the encryption is actually working pretty well!

I realize that I made a post to another thread that more appropriately would have belonged here, but in issue #140 I made a test of using encryption with crypt14 with various options, and it was able to recreate my encrypted databases with the exact same hashes as the WhatsApp-provided databases (see the post for exact steps).

Furthermore, I also tested re-encrypting crypt15 databases, using the same logic as my other post, and again coming out with the exact same hashes. (I did it using a reference crypt15 db, and also with instead specifying everything manually)

So I would say that encryption is definitely beyond beta! Great work @ElDavoo !!

edit: Above comments do not apply to crypt12, as I haven't tried anything related to that.