isphere-ai-bridge/docs/source-discovery/2026-07-10-msglib-readability-precheck.md

MsgLib.db readability and wrapper-path precheck

Date: 2026-07-10

Question

Why are the copied MsgLib.db files not directly readable as SQLite, and what is the safest next path for extracting contact/group display names and richer message metadata?

Evidence checked

• Existing ignored metadata:
  • runs/offline-evidence-intake/zyl-qqfile-20260709/metadata/schema-inspection-summary.json
  • runs/offline-evidence-intake/zyl-qqfile-20260709/metadata/archive-list.txt
• New ignored C24 metadata:
  • runs/offline-evidence-intake/zyl-qqfile-20260709/metadata/c24-msglib-format-precheck.json
  • runs/offline-evidence-intake/zyl-qqfile-20260709/metadata/c24-wrapper-string-precheck.json
• Read-only extracted wrapper candidates under ignored:
  • runs/offline-evidence-intake/zyl-qqfile-20260709/extracted/c24-wrapper-candidates/

No raw DB bytes, decrypted messages, or personal values are committed in this note.

Findings

1. The three inspected MsgLib.db copies do not start with SQLite magic and contain no SQLite header within the first 1 MiB sample.
2. The inspected DB samples have high entropy and the same non-SQLite prefix shape across iSphere and IMPP account copies. This strongly suggests a consistent encrypted/wrapped DB format rather than a random corrupt copy.
3. The archive contains standard SQLite libraries, DB abstraction libraries, and a repair tool next to MsgLib.db:
   • System.Data.SQLite.dll
   • Utilities.Lib.DBSQLite.dll
   • Utilities.Lib.SQLiteInteraction.dll
   • Utilities.Lib.SQLiteInteractionBase.dll
   • Utilities.Lib.DBBase.dll
   • Utilities.Lib.DBModel.dll
   • HYHC.IMPP.DAL.dll
   • RepairDatabase.exe
4. String-only static scanning of wrapper candidates shows that HYHC.IMPP.DAL.dll and RepairDatabase.exe reference message/group DB behavior and candidate table/method names, including:
   • tblMsgGroupPersonMsg
   • ImportOldDataBase
   • GetGroupMessaeByID
   • GetGroupRecentMsg
   • UpdateGroupName
   • SelectMsgGroupName
   • SelectRecentGroupName
   • SaveGroupInfomation
   • groupJid
   • set_MemberJid
   • set_MsgGroupName
   • set_MemberName
   • get_naturalname
5. Utilities.Lib.SQLiteInteraction.dll exposes SQLiteConnectionStringBuilder plus get_Password and set_Password.
6. Utilities.Lib.DBModel.dll exposes configuration concepts such as IConStrDecryption, PasswordPropertyName, and DecryptionPropertyName.
7. smcrypto-* and BouncyCastle.Crypto.dll are present, but C24 does not prove they are the actual MsgLib.db wrapper. They are supporting crypto candidates only.

Decision

Do not treat MsgLib.db as ordinary SQLite.

The best current hypothesis is:

MsgLib.db is an encrypted or wrapped SQLite database opened through the client DB abstraction layer, likely involving Utilities.Lib.SQLiteInteraction*, Utilities.Lib.DBModel, and HYHC.IMPP.DAL.

The next safe implementation path is not direct DB reads. It is static wrapper analysis first:

1. Inspect .NET metadata/IL for the DB wrapper assemblies.
2. Identify how connection strings/password/decryption are supplied.
3. Identify table names and model classes for message, contact, group, member, and display-name fields.
4. Only after that, attempt a read-only schema extraction on copied DB files under ignored paths.

Next slice

C25 should perform a read-only static .NET wrapper analysis over the extracted candidate assemblies. It should produce table/model/source mappings only, not execute the client and not write to the original DB.

Suggested C25 focus:

• HYHC.IMPP.DAL.dll
• Utilities.Lib.SQLiteInteraction.dll
• Utilities.Lib.DBModel.dll
• Utilities.Lib.DBSQLite.dll
• RepairDatabase.exe

Expected output:

• candidate table names;
• candidate model/property names for contact/group/message metadata;
• likely connection-string/password/decryption flow;
• decision whether C26 can attempt a copied-DB read-only schema extraction.