Add KakaoTalk support for iOS

[abrignoni]

Adds KakaoTalk support for iOS. Five artifacts from the client's own stores:

• Messages (Message.sqlite): sender, chat, type and the sent, read and updated times, all in the clear. The message body and attachment are encrypted at rest and reported as stored. Published research describes the scheme (AES-CBC under a key derived from the account's user id, with a key and IV hardcoded in the client that it does not publish); no decryption is attempted, and the citation is in the notes.
• Chats (Talk.sqlite): rooms, member and unread counts, and the folder a chat is filed under.
• Users: friends, chat members and official accounts the client knows, with names and profile fields. Phone numbers are encrypted and reported as stored.
• Address Book Matches (ZCONTACT): device contacts the client synced, with the encrypted numbers as stored.
• Chat Media: files under the per chat media folders, attributed to a chat by the folder id the store records and rendered where the bytes are a type the report can show.

Message.sqlite and Talk.sqlite are generic file names, so each store is confirmed to carry the client's own layout before a row is reported. Two epochs appear in the Message table and are converted separately: sentAt and readAt are Cocoa seconds, updateAt is Unix seconds. The raw phone and contact id columns are absent from the older of the two schemas seen and are resolved per store.

Field mapping was done against private samples, so no sample_data is recorded.

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

🤖 Generated with Claude Code

[abrignoni]

Update: the message body, attachment and phone-number fields are now decrypted rather than reported as stored ciphertext.

The client encrypts these per record with AES-CBC, keyed on the owning user id through PBKDF2-HMAC-SHA1 with two iterations, and a key and IV hardcoded in the client. The derivation and the two constants were recovered from the client binary and validated against the stored ciphertext: two iterations decrypt every value, one and three decrypt none, and the wrong user id decrypts none. On the samples tested every message body, every attachment field and every populated user phone number decrypted (the phone numbers to phone-shaped strings). A value that does not decrypt is left as stored. The device address-book numbers in ZCONTACT use a different key that was not recovered and stay as stored.