Files
isphere-ai-bridge/docs/source-discovery/2026-07-10-live-probe-recorder.md
2026-07-10 10:59:48 +08:00

107 lines
3.0 KiB
Markdown

# iSphere Live Probe Recorder
Date: 2026-07-10
Purpose: collect read-only runtime evidence from a machine where iSphere / IMPlatformClient can actually log in.
## Why this recorder exists
The current development machine cannot log in because the current network has no reachable server. Simulating login would only prove window rendering and would not prove the real logged-in runtime state required by the B-route sidecar connector.
Therefore the selected path is to carry a dedicated recorder executable to a working environment, run it after manual login, and bring the generated JSON evidence back.
## Built artifact
Package directory:
```text
runs/live-probe-recorder-package/
```
Executable:
```text
runs/live-probe-recorder-package/ISphereLiveProbeRecorder.exe
```
Zip package:
```text
runs/live-probe-recorder-package.zip
```
The package is generated by:
```powershell
powershell -NoProfile -ExecutionPolicy Bypass -File scripts\package-live-probe-recorder.ps1
```
## Operator steps
1. Copy `runs/live-probe-recorder-package.zip` to the machine/network where iSphere can connect to its server.
2. Extract the zip.
3. Manually open and log in to iSphere / `IMPlatformClient.exe`.
4. Manually open one direct-contact chat window and one group-chat window if possible. Keep the editor/send/attachment area visible, but do not send anything.
5. Keep the client window open.
6. Double-click `ISphereLiveProbeRecorder.exe`.
7. The program writes a folder under:
```text
probe-output/isphere-live-probe-<timestamp>/
```
8. Compress that generated folder and return it.
## What it records
The recorder writes:
```text
manifest.json
probe_client_runtime.json
process_details.json
network_inventory.json
filesystem_inventory.json
services_registry_shortcuts.json
scan_windows.json
uia_summary.json
uia/*.json
feasibility_summary.json
README.txt
NEXT_STEP.txt
```
The important evidence is:
- target process PID/name/title/path;
- process bitness;
- loaded module list;
- command-line metadata with basic secret redaction;
- key module presence, including `smack.dll`, `IMPP.Interface.dll`, `IMPP.ServiceBase.dll`, `IMPP.Service.dll`, `TcpFileTransfer.dll`;
- visible window metadata;
- UIA tree for target windows, useful if route A UI/RPA is needed later.
- install/cache/config/log/database candidate metadata;
- version and SHA256 for important binaries;
- redacted text samples for small config/log files;
- uninstall registry entries;
- related services and shortcuts;
- target-process TCP connections;
- related named pipes.
## What it does not do
The recorder does not:
- send messages;
- send or upload files;
- click UI;
- type text;
- inject hooks;
- attach instrumentation;
- modify client files or data.
## Decision after returned evidence
If `probe_client_runtime.json` proves the loaded modules and bitness match the static evidence, continue with B-route sidecar design.
If the running client cannot be inspected, or the expected modules are absent, switch to the A-route constrained UI/RPA fallback.