Implementation case study
NoMorePwn
Capture a successful login into a desktop vault while keeping origin checks and lock state explicit.
Components and tested boundaries
- Chromium login observation and exact origin checks
- Native delivery intercepted in browser fixtures
- Separate native host: framed input/output and Qt IPC
- Real controller and temporary encrypted vault
- Desktop unlock, save, lock and reopen
Decision: exact origins and locked-vault rejection
Scheme, host and port define the origin. Sharing the last two host labels does not make unrelated co.uk or github.io sites trustworthy. This conservative rule requires explicit handling for legitimate cross-origin login flows. A locked vault rejects capture rather than retaining a plaintext pending-password queue; the user must retry after unlock.
Bounded walkthrough
Six real Chromium fixtures exercised success, direct HTTP 401, cross-origin rejection a redirect ending in 401, and multi-hop redirects to a foreign destination or back to the login route. Native delivery was intercepted in those fixtures. A separate real native-host/Qt/controller chain saved into an encrypted temporary vault and exercised lock/reopen and errors. Full browser registration has not been exercised end to end.
Repairs and lessons
Capture now depends on the final successful HTTP result; a redirect alone cannot count as login success. Other repairs cover save-error acknowledgments, notification preferences, Windows launcher working directory and already-drained Unix output. Small process and HTTP boundaries can invalidate a convincing UI demonstration.
Proof and limits
261 Python tests and 78 extension assertions passed on the functional repair. Password and notes fields use authenticated encryption; service, username and group metadata remain plaintext. Autofill is absent. Firefox runtime, installed browser registration and independent security review remain unverified.
Review source and changes ยท Inspect detailed execution evidence