Files
isphere-ai-bridge/docs/source-discovery/2026-07-10-msglib-readability-precheck.md
2026-07-10 02:17:23 +08:00

86 lines
3.9 KiB
Markdown

# 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.