admin/isphere-ai-bridge
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
8f526e9aa9be43b3065029f202f7174d8f221f0b
isphere-ai-bridge/docs/source-discovery/2026-07-09-n12-pre-zyl-schema-notes.md
zhaoyilun 3d68a18097 docs: confirm file receive metadata evidence
2026-07-10 00:40:02 +08:00

7.9 KiB
Raw Blame History

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.

C12 file-transfer evidence precheck

A temporary ignored scanner decrypted only the selected N12-pre log files and wrote count-only metadata to runs/offline-evidence-intake/zyl-qqfile-20260709/metadata/c12-file-evidence-counts.json. No raw decrypted message content is committed.

Count summary:

Source Decrypted File-transfer / file evidence Cache/download evidence
PacketReader.ProcessPacket 245/245 57 <subject> hits, 123 FILE_TRANSFER hits, 57 FILE_TRANSFER_CANCEL hits, 91 body file-extension hits, 107 parsed file-candidate messages 0 zyl\importal\<hash> hits, 0 download-keyword hits
Smark.SendReceive 1,078/1,078 5 FILE_TRANSFER hits, 4 body file-extension hits, 5 parsed file-candidate messages 0 zyl\importal\<hash> hits, 0 download-keyword hits
SaveToDB 14/14 9 generic file-extension hits and 2 attachment-keyword hits; no parseable XMPP message candidates 0 zyl\importal\<hash> hits, 0 download-keyword hits
archive-list.txt n/a 11 cached file entries under 11 zyl\importal\<hash> directories; extensions observed: .doc, .docx, .jpg, .pdf, .xlsx cache entries exist, but no confirmed link from message log to cache hash yet

Decision: file metadata listing can proceed from log-backed normalized messages. Real download_ref, saved_path, and cache hash resolution remain deferred until the message-to-cache mapping or a client-side download connector is validated.

Updated source decision

The previous matrix selected MsgLib.db as the first source subject to schema inspection. Stage B2 changes that decision:

  1. MsgLib.db remains a high-value candidate but is blocked by a non-SQLite wrapper/encryption layer.
  2. PacketReader.ProcessPacket decrypted XMPP XML is the first implementable source for isphere_receive_messages.
  3. Smark.SendReceive and SaveToDB are fallback/reconciliation sources.
  4. File receiving likely needs PacketReader file-transfer XML plus a later map to zyl\importal\<hash> document cache directories.

Next node

Open Stage C with a log-backed source abstraction first:

  1. Add a small decrypt/parser package for IMPP.Util.Log.LogSecurityPolicy style lines.
  2. Parse decrypted PacketReader.ProcessPacket XML into normalized message structs.
  3. Use redacted fixture strings in tests, not raw user message text.
  4. Keep MsgLib.db work as a separate follow-up node for DB wrapper/encryption analysis.
Reference in New Issue View Git Blame Copy Permalink