6.4 KiB
N12-pre zyl Schema and Log Inspection Notes
Date: 2026-07-09
Evidence id: zyl-qqfile-20260709
Stage: B2 selected DB/log inspection
Files inspected under runs/
| Label | Extracted path | Result |
|---|---|---|
| iSphere latest DB | runs/offline-evidence-intake/zyl-qqfile-20260709/extracted/msgdb-isphere-90005981/MsgLib.db |
high-entropy binary; not direct SQLite |
| IMPP same-account DB | runs/offline-evidence-intake/zyl-qqfile-20260709/extracted/msgdb-impp-90005981/MsgLib.db |
high-entropy binary; not direct SQLite |
| IMPP large DB | runs/offline-evidence-intake/zyl-qqfile-20260709/extracted/msgdb-impp-27091282/MsgLib.db |
high-entropy binary; not direct SQLite |
Smark.SendReceive log |
runs/offline-evidence-intake/zyl-qqfile-20260709/extracted/log-smark-90005981-20260707/2026-07-07_1.log |
decryptable line-based log |
SaveToDB log |
runs/offline-evidence-intake/zyl-qqfile-20260709/extracted/log-savetodb-90005981-20260707/2026-07-07_1.log |
decryptable line-based log |
PacketReader.ProcessPacket log |
runs/offline-evidence-intake/zyl-qqfile-20260709/extracted/log-packetreader-90005981-20260707/2026-07-07_1.log |
decryptable line-based XMPP message log |
LoginInfo log |
runs/offline-evidence-intake/zyl-qqfile-20260709/extracted/log-logininfo-90005981-20260707/2026-07-07_1.log |
decryptable login metadata XML |
MsgLib.db inspection result
The three selected MsgLib.db files are not directly readable with Python sqlite3 read-only mode.
Observed result:
DatabaseError('file is not a database')
Observed binary traits:
| File | Size bytes | SHA256 | Header / format signal |
|---|---|---|---|
msgdb-isphere-90005981/MsgLib.db |
2,839,552 | 4f308a26e4d528175853dac8889b69f371b4cad779f75ce2e31d2f83043f86a2 |
high entropy, first bytes start 45 1b bd 2b; not SQLite format 3 |
msgdb-impp-90005981/MsgLib.db |
2,776,064 | 6707d06126e3cd9a535f6d3879123e31377f0cb7d350b7a6e0cdfe1b34656943 |
high entropy, first bytes start 45 1b bd 2b; not SQLite format 3 |
msgdb-impp-27091282/MsgLib.db |
12,198,912 | fe60ddcfbaa70523b21ec080f6d7e633298c9a9d710b7e9c36d91996bf4dc0f0 |
high entropy, first bytes start 45 1b bd 2b; not SQLite format 3 |
Tried the known IMPP.Util.Log.LogSecurityPolicy DES/CBC key against the first DB blocks. It did not reveal a SQLite header. Current conclusion: MsgLib.db remains an important source candidate, but it is not the first implementable Stage C source until the DB wrapper/encryption/loading path is identified.
Log decryption result
The selected logs are Base64 line-based ciphertext. The existing local iSphere log policy finding applies to these logs:
- policy owner:
IMPP.Util.Log.LogSecurityPolicy - cipher: DES
- mode: CBC
- padding: PKCS7
- key string:
hyhccdtm - IV bytes:
12 34 56 78 90 AB CD EF - plaintext encoding: UTF-8
Decryption succeeded for all selected log lines:
| Log | Lines | Decrypted | Useful structure |
|---|---|---|---|
SaveToDB |
14 | 14 | NLog-style records from IMPP.Client.control.MessageCenter.Chat_OnMessageArrived; message type com.vision.smack.packet.ReceiptMessage; includes from: and body: fields |
Smark.SendReceive |
1,078 | 1,078 | XMPP send/receive stanzas; includes IQ and message traffic |
PacketReader.ProcessPacket |
245 | 245 | XMPP <message> stanzas; includes id, from, to, type, <body>, <subject>, <isphere ... sendtime=...> |
LoginInfo |
1 | 1 | XML login metadata; contains account/user/dept/contact fields and should be treated as sensitive metadata |
Field mapping evidence
PacketReader.ProcessPacket is now the strongest immediate source for isphere_receive_messages because decrypted lines expose message-level XML shape.
Observed redacted shape:
<message id="..." from="<jid>/imp_pc_4.1.2.6842" to="<jid>" type="chat">
<body>...</body>
<received xmlns="urn:xmpp:receipts" id="..." type="1" stamp="" />
<subject>...</subject>
<isphere xmlns="isphere.im" type="1001" sendtime="..." version="...">
<alert type="0" />
</isphere>
</message>
Candidate mapping to isphere_receive_messages:
| MCP field | Candidate source |
|---|---|
message_id |
<message id="..."> |
conversation_id |
normalized from / to JID pair or group JID |
conversation_type |
`<message type="chat |
sender |
from JID, stripped of resource such as /imp_pc_4.1.2.6842 |
timestamp |
log timestamp line plus <isphere sendtime="..."> when present |
content_text |
<body>...</body> |
| attachment/file hint | <subject> plus body filename when file-transfer subject is present |
| receipt/status | <received>, <consumed>, <readed> elements when present |
SaveToDB is useful as a behavioral trace but not the first parser source. It records Chat_OnMessageArrived and ReceiptMessage entries with from: and body: fields, and indicates some messages meet a “not stored to small DB” condition. This explains why MsgLib.db may not contain every received message even after its wrapper is solved.
Smark.SendReceive is useful as a lower-level transport trace. It includes XMPP IQ/message traffic and can become a fallback source or reconciliation source after the PacketReader parser is stable.
LoginInfo can map the local logged-in account identity, but it contains sensitive user metadata. Use only field names and identifiers needed for normalization; do not include raw personal values in committed docs or test fixtures.
Updated source decision
The previous matrix selected MsgLib.db as the first source subject to schema inspection. Stage B2 changes that decision:
MsgLib.dbremains a high-value candidate but is blocked by a non-SQLite wrapper/encryption layer.PacketReader.ProcessPacketdecrypted XMPP XML is the first implementable source forisphere_receive_messages.Smark.SendReceiveandSaveToDBare fallback/reconciliation sources.- File receiving likely needs
PacketReaderfile-transfer XML plus a later map tozyl\importal\<hash>document cache directories.
Next node
Open Stage C with a log-backed source abstraction first:
- Add a small decrypt/parser package for
IMPP.Util.Log.LogSecurityPolicystyle lines. - Parse decrypted
PacketReader.ProcessPacketXML into normalized message structs. - Use redacted fixture strings in tests, not raw user message text.
- Keep
MsgLib.dbwork as a separate follow-up node for DB wrapper/encryption analysis.