# Scanned_20260730-1659 > [!privacy] Privacy-redacted working copy > Private-person names approved by the vault owner are replaced with `[PERSON REDACTED]`. The private source PDF and pre-redaction backup preserve the original wording. This notice governs over any general statement below describing transcription as exact or unchanged. ## Archival scope and method This note reconstructs **all 69 physical PDF pages** of `Scanned_20260730-1659.pdf`, including the front and rear covers, blank pages, sideways duplication, bleed-through, crossed-out strings, account pages, domain lists, people fragments, diagrams, and device identifiers. The canonical notebook identity is the exact filename stem; **“Quick” is retained only as a source alias**. Each page was inspected visually from a rendered image rather than inferred from OCR. Except for explicit privacy redactions, quoted transcription preserves source spelling, capitalization, line grouping, uncertainty markers, and meaningful strike-throughs. Wiki-links occur only outside quoted transcription. Telephone numbers and credential-equivalent material are redacted with exact PDF/page locators and are not repeated in indexes, people notes, or overlays. The research layer uses official documentation, standards bodies, first-party product history, and primary technical sources wherever possible. Every interpretation is separated into **visible evidence**, **verified fact**, **strong inference**, and **unresolved ambiguity**. The notebook’s apparent date range is reconstructed from explicit internal dates rather than the 2026 scanning timestamp. ## Knowledge-graph navigation [[Index - Master Chronology|Master Chronology]] · [[Index - People|People]] · [[Index - Company and Institution|Companies and Institutions]] · [[Index - Acronym Dictionary|Acronym Dictionary]] · [[Index - Technology and Product Lineage|Technology and Product Lineage]] · [[Index - Domain and URL Index|Domain and URL Index]] · [[Index - Device Inventory|Device Inventory]] · [[Index - Project and Concept|Projects and Concepts]] · [[Index - Pattern Ledger|Pattern Ledger]] · [[Index - Unresolved Names and Identifiers|Unresolved Names and Identifiers]] · [[Index - Notebook Sources|Notebook Sources]] ## Notebook-level orientation The notebook is not a single-project log. It is a **rapid systems-reconnaissance ledger** whose dominant subjects are mobile firmware, alternate Android distributions, Apple internal services, network attribution, cloud/domain governance, account continuity, accessibility controls, embedded Java, and astronomical Unix software. Its pages repeatedly move across layers—human contact, brand identity, account credential, domain, ASN, IP address, firmware component, bus controller, operating-system service, application package, and physical device—suggesting that the author was trying to understand how identity and control persist as information crosses technical substrates. --- ## PDF page 1 — Front cover marked “Quick” **Source.** `Scanned_20260730-1659.pdf`, PDF page 1. **Visible page.** Red/pink textured paper cover, rounded corners, black marker word centered upper-middle. **Faithful transcription.** > "Quick" **Normalized linked entities.** [[Scanned_20260730-1659|Scanned_20260730-1659]]; [[Quick Capture Notebook|Quick capture notebook]]. **Entity and technical context.** `Quick` is treated as a physical alias and workflow label, not as the notebook's canonical title. The canonical source note remains [[Scanned_20260730-1659|Scanned_20260730-1659]]. **Whole-page reconstruction.** The cover’s single word is a functional title rather than a descriptive notebook identity: this was a **rapid-capture field notebook**, optimized for fragments that would later be decoded, normalized, or acted upon. The canonical note nevertheless remains the source filename. The physical wear and sparse cover inscription support repeated pocket use rather than ceremonial journaling. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Determine whether “Quick” was the author’s own notebook label, a brand/model marking, or a later archival annotation. ## PDF page 2 — Federal fraud-reporting contacts and IC3 **Source.** `Scanned_20260730-1659.pdf`, PDF page 2. **Visible page.** Inside red/pink cover, black marker notes in upper half; two federal fraud-reporting phone numbers, underlined separator, IC3 website, DOJ fraud number. **Faithful transcription.** > "Fbi > xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 2) > xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 2) > — > ic3.gov > > DOJ - Fraud > xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 2)" **Normalized linked entities.** [[Federal Bureau of Investigation|FBI]]; [[Internet Crime Complaint Center|IC3]]; [[United States Department of Justice|DOJ]]; [[Fraud Reporting|fraud reporting]]. **Entity and technical context.** [[Federal Bureau of Investigation|FBI]] is the U.S. federal investigative agency; [[Internet Crime Complaint Center|IC3]] is its online intake mechanism for internet-enabled crime complaints; [[United States Department of Justice|DOJ]] is the cabinet department that routes federal fraud reporting and prosecution resources. The telephone channels are intentionally not reproduced. **Whole-page reconstruction.** This page establishes an **incident-response front door**. `ic3.gov` is the FBI’s Internet Crime Complaint Center, the federal intake portal for suspected internet-enabled crime; the DOJ separately routes fraud reports by category. The copied telephone channels show the author building redundant escalation paths rather than relying on one website.[^ic3][^doj-fraud] The page likely predates or accompanies a specific fraud concern, but no victim, transaction, or allegation is identified here. **Evidentiary status.** **Visible evidence:** the quoted labels, layout, crossings, and privacy-preserving redactions. **Verified fact:** only externally documented service/technology identities. **Strong inference:** the page served operational access, recovery, migration, or support work. **Unresolved:** whether every recorded account was current, legacy, or test-only. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Recover the precipitating incident, complaint number, or adjacent correspondence; preserve the distinction between IC3 intake and DOJ category routing. ## PDF page 3 — Account and router credential ledger **Source.** `Scanned_20260730-1659.pdf`, PDF page 3. **Visible page.** Ruled white page with account/service labels and credentials in five grouped blocks; final line is a personal telephone number. **Faithful transcription.** > "mycommerce.com > bbc / [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 3] > > setapp > bbc / [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 3] > > [email protected] > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 3] > > MI Router login.net > admin / [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 3] > > MI OLD > admin / [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 3] > xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 3)" **Normalized linked entities.** [[MyCommerce|myCommerce]]; [[Setapp|Setapp]]; [[Xiaomi Mi Router|MI Router]]; [[Credential Ledger|credential ledger]]; [[Index - People#Bryant McGill|Bryant McGill]]. **Entity and technical context.** [[MyCommerce|myCommerce]] is a software-commerce/account label; [[Setapp|Setapp]] is a Mac application-subscription service; [[Xiaomi Mi Router|MI Router]] denotes Xiaomi router administration. `bbc` is not expanded because the page does not establish whether it is a username, organization, or mnemonic. The Apple-domain email is source evidence of an account identity, not a public-person identifier to duplicate elsewhere. **Whole-page reconstruction.** The page is an operational credential ledger spanning software licensing/subscription commerce, a Mac application service, an Apple-address identity, and two Xiaomi-router contexts. Its significance is architectural: **commercial identity, device administration, and network control were being held in one cognitive workspace**. The source materially contains passwords and a personal telephone number; they are preserved only by location-aware redaction. No attempt was made to test any account. **Evidentiary status.** **Visible evidence:** the quoted labels, layout, crossings, and privacy-preserving redactions. **Verified fact:** only externally documented service/technology identities. **Strong inference:** the page served operational access, recovery, migration, or support work. **Unresolved:** whether every recorded account was current, legacy, or test-only. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Identify whether “bbc” was an alias, organization, or reused username; map the two Mi Router contexts without attempting login. ## PDF page 4 — Galaxy Tab S7 firmware, UDisks2, and cellular identifiers **Source.** `Scanned_20260730-1659.pdf`, PDF page 4. **Visible page.** Ruled page dated at top; Samsung firmware component strings, one crossed out; D-Bus/UDisks filesystem interface; a boxed maximum unsigned integer with MCC/MNC annotations; final note linking the Cell ID value to an [PERSON REDACTED], Michigan router. **Faithful transcription.** > "1/25/2021 > ~~AP_T870XXU1BUAC~~ > BL_T870XXU1BUAC > AP- 11 > CSC_OMC_OXM_T870OXM1BUAC > HOME_CSC_OMC_OXM_T870OXM1BUAC > > org.freedesktop.UDisks2.Filesystem > > 429 496 7295 > MCC 310 MNC 410 > > \"Cell ID\" on [PERSON REDACTED] MI > Router" **Normalized linked entities.** [[Samsung Galaxy Tab S7|Galaxy Tab S7]]; [[Samsung Odin Firmware Package|Samsung firmware package]]; [[UDisks2|UDisks2]]; [[D-Bus|D-Bus]]; [[Mobile Country Code|MCC]]; [[Mobile Network Code|MNC]]; [[Unsigned 32-bit Integer|uint32]]. **Entity and technical context.** `AP`, `BL`, `CSC`, and `HOME_CSC` are Samsung firmware-package components; `SM-T870` is the Galaxy Tab S7 Wi-Fi family. [[UDisks2|UDisks2]] exposes storage objects and filesystem operations through [[D-Bus|D-Bus]]. `4294967295` equals $2^{32}-1$, the maximum unsigned 32-bit integer. [[Mobile Country Code|MCC]] and [[Mobile Network Code|MNC]] identify a public land mobile network; `Cell ID` identifies a radio cell within carrier/location-area context. **Whole-page reconstruction.** The `T870` strings identify Samsung’s Wi-Fi Galaxy Tab S7 model family; Samsung’s official update history confirms SM‑T870 as Galaxy Tab S7 and places `T870XXU1BUAC` in the Android 11-era build lineage.[^samsung-t870] `AP`, `BL`, `CSC`, and `HOME_CSC` are the familiar component slots used by Samsung/Odin firmware packages: application processor/system image, bootloader, regional/customer software configuration, and a user-data-preserving CSC variant. `org.freedesktop.UDisks2.Filesystem` is a D-Bus object interface associated with filesystem operations, tying mobile firmware investigation to Linux storage control. `4294967295` is the maximum unsigned 32-bit value; MCC 310 and MNC 410 encode a U.S. mobile network identity. The page therefore joins **firmware provenance, Linux storage middleware, and cellular identity** in one debugging trace. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Resolve the exact carrier represented by MCC 310/MNC 410 in the notebook’s time frame and the meaning of “[PERSON REDACTED] MI Router”; compare with device logs if archived. ## PDF page 5 — GoMcGill valuation, Telegram, and macOS service fragments **Source.** `Scanned_20260730-1659.pdf`, PDF page 5. **Visible page.** Ruled page of domain valuation/ranking notes, a dated Telegram event, Android/macOS application references, and an uncertain underlined final name/question. **Faithful transcription.** > "Domain. > GoMcGill worth? > 11 million dolls aS of > Dec 2022 > > 40k Global Rank > > Nov 8th 2020 4:22PM > Bryant/Mg Telegram > > MRT.app > > Readability Bundle > > Launch daemon inside RAC host > > [uncertain: MuskRyke?]" **Normalized linked entities.** [[GoMcGill|GoMcGill]]; [[Telegram|Telegram]]; [[Malware Removal Tool|MRT.app]]; [[macOS Launch Daemon|launch daemon]]; [[Domain Valuation|domain valuation]]. **Entity and technical context.** [[GoMcGill|GoMcGill]] is a brand/domain identity; the valuation and rank are notebook claims. [[Telegram|Telegram]] is a messaging platform. `MRT.app` most plausibly denotes Apple's Malware Removal Tool application bundle; a [[macOS Launch Daemon|launch daemon]] is a background service launched by `launchd`. `Readability Bundle`, `RAC host`, and the final uncertain name require the originating process list or screenshot. **Whole-page reconstruction.** The page combines an unverifiable domain-value claim with a global-rank note, a timestamped Telegram event, and macOS service terminology. `MRT.app` is most plausibly Apple’s Malware Removal Tool component, while “readability bundle” and “launch daemon inside RAC host” look like copied process/bundle observations rather than a coherent installation recipe. The domain figures are source assertions, not independently verified valuations. The repeated later appearance of these Apple terms indicates an unresolved effort to distinguish ordinary background services from anomalous persistence. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Verify the date and basis of the GoMcGill valuation/rank; identify “RAC host” and the uncertain final name from adjacent Apple diagnostics. ## PDF page 6 — Account-domain migration and [PERSON REDACTED] contact record **Source.** `Scanned_20260730-1659.pdf`, PDF page 6. **Visible page.** Ruled page charting an account/domain migration with downward arrows; lower half contains a person’s first name, a Coral Gables address, company name, and international phone number. **Faithful transcription.** > "Clubhouse.site > join SuccessMaker.cc > ↓ > converted to > windows10.yahoo.account > ↓ > firebase > > [PERSON REDACTED] > 2330 Ponce De Leon Blvd > Coral Gables Fl > Amadil, Inc. > xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 6)" **Normalized linked entities.** [[Clubhouse.site|Clubhouse.site]]; [[SuccessMaker.cc|SuccessMaker.cc]]; [[Firebase|Firebase]]; [PERSON REDACTED]; [[Amadil Inc.|Amadil, Inc.]]; [[Account Migration|account migration]]. **Entity and technical context.** `Clubhouse.site`, `SuccessMaker.cc`, and `windows10.yahoo.account` are retained as written account/domain labels rather than merged into known products. [[Firebase|Firebase]] is Google's application-backend platform. [PERSON REDACTED] is a minimally identified private contact; [[Amadil Inc.|Amadil, Inc.]] is a written company name whose relationship to the domains is unverified. **Whole-page reconstruction.** The arrows document a **service-identity migration**: a domain or account called `Clubhouse.site`/`SuccessMaker.cc` is said to have become a Yahoo/Windows-labeled account and then Firebase-backed. Nothing on the page proves that these labels denote the same corporate product; the safest reading is the author’s own account-consolidation map. The lower contact block anchors the abstract migration to a real-world property/business contact in Coral Gables. `Clubhouse.site` must not be merged with the social-audio service or the former Clubhouse project-management platform without corroboration. **Evidentiary status.** **Visible evidence:** the quoted labels, layout, crossings, and privacy-preserving redactions. **Verified fact:** only externally documented service/technology identities. **Strong inference:** the page served operational access, recovery, migration, or support work. **Unresolved:** whether every recorded account was current, legacy, or test-only. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Disambiguate Clubhouse.site from social audio and project-management products; identify Amadil, Inc. and [PERSON REDACTED] only from corroborating source records. ## PDF page 7 — F-Droid, Tutu, and 3C Android tools **Source.** `Scanned_20260730-1659.pdf`, PDF page 7. **Visible page.** Sparse ruled page with three Android application/tool names at upper left. **Faithful transcription.** > "F-Droid.apk > Tutu > 3c All in one Toolbar" **Normalized linked entities.** [[F-Droid|F-Droid]]; [[TutuApp|Tutu]]; [[3C All-in-One Toolbox|3C All-in-One Toolbox]]; [[Android Application Package|APK]]. **Entity and technical context.** [[F-Droid|F-Droid]] is an open-source Android repository/client; [[TutuApp|Tutu]] is an alternative mobile-app distribution service; [[3C All-in-One Toolbox|3C All-in-One Toolbox]] is a device-management utility. `F-Droid.apk` uses the [[Android Application Package|APK]] package format; the source word `Toolbar` is normalized only outside the quotation to the known product spelling `Toolbox`. **Whole-page reconstruction.** F-Droid is an installable catalog and repository ecosystem for free/open-source Android applications, while TutuApp represents a third-party distribution channel and 3C All-in-One Toolbox a device-management utility. F-Droid’s official documentation emphasizes reproducible repository metadata and user-controlled sources.[^fdroid] The list reads as a **comparative acquisition surface**: trusted open-source repository, less-governed alternate store, and deep system utility. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Correct “Toolbar” versus “Toolbox” only in normalized analysis; locate package IDs and installation dates. ## PDF page 8 — Sideways duplicate of Android-tool list **Source.** `Scanned_20260730-1659.pdf`, PDF page 8. **Visible page.** The physical page is scanned sideways in landscape orientation. The same three application/tool names as page 7 run vertically along the right edge; the rest is blank. **Faithful transcription.** > "F-Droid.apk > Tutu > 3c All in one Toolbar" **Normalized linked entities.** [[F-Droid|F-Droid]]; [[TutuApp|Tutu]]; [[3C All-in-One Toolbox|3C All-in-One Toolbox]]; [[Notebook Duplication|duplicate note]]. **Entity and technical context.** The entities are identical to page 7. The second physical occurrence is indexed as evidence of repetition, not as a separate product version or installation event. **Whole-page reconstruction.** This is a physical duplication of page 7, not a new conceptual entry. Its sideways orientation suggests either a scanning-order artifact or deliberate reuse of the page margin. Archival retention matters because duplicated fragments reveal which tool triads were important enough to be recopied or re-photographed. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Determine why the list was duplicated sideways and whether a missing neighboring page contained the intended comparison. ## PDF page 9 — Old MacBook Pro startup security and firmware commands **Source.** `Scanned_20260730-1659.pdf`, PDF page 9. **Visible page.** Dense ruled troubleshooting page for an older MacBook Pro. Several key-like strings at top are crossed out; below are credential notes, Startup Security Utility references, password-reset and command-line terms. **Faithful transcription.** > "~~[REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 9]~~ > ~~[REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 9]~~ > ~~[REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 9]~~ > ~~[REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 9]~~ > @macbook Pro Old [PERSON REDACTED] > (cloud ours) > PW admin / [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 9] > Startup Security PW: [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 9] > cmds [uncertain: carel i336] > safe mode term > > reset password > fi > firmwarepasswd > kextunload > kextutil, unload, find, stat; > Libs > Security > \"\" -i interactive mode > unlock-keychain" **Normalized linked entities.** [[MacBook Pro|MacBook Pro]]; [[macOS Startup Security Utility|Startup Security Utility]]; [[macOS Firmware Password|firmware password]]; [[Kernel Extension|kernel extension]]; [[macOS Keychain|Keychain]]; [[Safe Mode|Safe Mode]]. **Entity and technical context.** [[macOS Startup Security Utility|Startup Security Utility]] controls startup-disk and boot-security policy on supported Macs; a firmware password restricts alternate startup paths on older Intel Macs. `kextutil` and `kextunload` manage legacy kernel extensions; `find` and `stat` inspect filesystem objects; `unlock-keychain` opens a macOS Keychain. The uncertain command fragments are not promoted into executable instructions. **Whole-page reconstruction.** This page records recovery and security-control points on an older Intel-era MacBook Pro: firmware password, Startup Security Utility, Safe Mode, password reset, kernel-extension utilities, and Keychain unlocking. `kextutil` and `kextunload` belong to the pre-System-Extensions model of macOS kernel extension management; their presence helps date the troubleshooting vocabulary. The page is not a validated command sequence—several verbs are fragments, and credentials dominate the top—so it should be read as a **recovery scratchpad**, not executable instructions. **Evidentiary status.** **Visible evidence:** the quoted labels, layout, crossings, and privacy-preserving redactions. **Verified fact:** only externally documented service/technology identities. **Strong inference:** the page served operational access, recovery, migration, or support work. **Unresolved:** whether every recorded account was current, legacy, or test-only. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Recover the Mac model/year and macOS version; separate valid historical commands from copied or obsolete fragments. ## PDF page 10 — Western Digital My Cloud credentials and UDF **Source.** `Scanned_20260730-1659.pdf`, PDF page 10. **Visible page.** Ruled page of Western Digital/My Cloud NAS account notes, followed by an Apple filesystem acronym expansion. **Faithful transcription.** > "192 MCWD > > WD EX4/02 > > admin > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 10] > > bryantmcgill > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 10] > > jenimcgill > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 10] > > apple UDF > Universal Disk > Format" **Normalized linked entities.** [[Western Digital My Cloud EX4|WD My Cloud EX4]]; [[Network-attached Storage|NAS]]; [[Universal Disk Format|UDF]]; [[Optical Disc Filesystem|optical-disc filesystem]]. **Entity and technical context.** [[Western Digital My Cloud EX4|My Cloud EX4]] is a multi-bay NAS appliance. Multiple usernames indicate local/share identities. [[Universal Disk Format|Universal Disk Format]] is the standardized filesystem family used on optical media, including DVD and Blu-ray variants; it is not an Apple-proprietary filesystem despite the source prefix `apple UDF`. **Whole-page reconstruction.** The Western Digital My Cloud EX4 was a network-attached storage appliance, and the page records multiple local identities against it. The appended UDF expansion is technically separate: Universal Disk Format is the optical-media filesystem standardized for DVDs and Blu-ray; Blu-ray ROM2 explicitly adopted UDF 2.5.[^bd-rom2] The juxtaposition may reflect storage-format research migrating from NAS recovery into optical/archive compatibility. **Evidentiary status.** **Visible evidence:** the quoted labels, layout, crossings, and privacy-preserving redactions. **Verified fact:** only externally documented service/technology identities. **Strong inference:** the page served operational access, recovery, migration, or support work. **Unresolved:** whether every recorded account was current, legacy, or test-only. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Determine whether `192 MCWD` refers to a local IP suffix, device label, or network segment; inventory the exact My Cloud EX4 hardware. ## PDF page 11 — TPM 2.0 and cloud identity directories **Source.** `Scanned_20260730-1659.pdf`, PDF page 11. **Visible page.** Unruled white page with faint marker. A Microsoft search instruction and TPM console command lead into a vertical list of cloud identity and directory services. **Faithful transcription.** > "microsoft.com > > search bar tpm 2.0 update > > tpm.msc > Azure AD > Active Directory > Okta > Google Directory > One Login" **Normalized linked entities.** [[Trusted Platform Module|TPM 2.0]]; [[Active Directory|Active Directory]]; [[Microsoft Entra ID|Azure AD]]; [[Okta|Okta]]; [[Google Cloud Directory Sync|Google Directory]]; [[OneLogin|One Login]]. **Entity and technical context.** [[Trusted Platform Module|TPM 2.0]] supplies protected cryptographic operations and measured-boot state; `tpm.msc` is a Windows management console. [[Active Directory|Active Directory]] is Microsoft's on-premises directory; `Azure AD` is normalized to [[Microsoft Entra ID|Microsoft Entra ID]]. [[Okta|Okta]], [[OneLogin|OneLogin]], and Google directory tooling are cloud/federated identity alternatives. **Whole-page reconstruction.** The page maps hardware trust to cloud identity. TPM 2.0 is the platform trust hardware/firmware standard used for protected key operations and measured boot; `tpm.msc` is Windows’ TPM management console.[^tpm] Azure Active Directory was renamed **Microsoft Entra ID** in 2023, while on-premises Active Directory retained its name.[^entra-rename] Okta, Google directory services, and OneLogin are federated identity/directory alternatives. The notebook was approaching the modern idea that a device’s trust state and a user’s directory identity form a single access-control plane. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Identify whether the page was planning Windows 11 readiness, enterprise federation, or directory migration. ## PDF page 12 — D-Bus, QEMU, SPICE, qcow2, and virt-manager **Source.** `Scanned_20260730-1659.pdf`, PDF page 12. **Visible page.** Ruled page of Linux/QEMU configuration terms. Large “IPC” and “DBUS” labels sit above file-manager, VM, graphics, storage, CPU, keyboard-grab, and virt-manager notes. **Faithful transcription.** > "Rus > IPC connector name > DBUS > pcmanfm is file manager > > Qemu VM > Graphics spice > add spice usb redirection yes > Storage format qcow2 > Cpu default hypervisor host > Grab keys Ctrl-L + Alt-L > virt-manager.org" **Normalized linked entities.** [[D-Bus|D-Bus]]; [[Inter-process Communication|IPC]]; [[PCMan File Manager|PCManFM]]; [[QEMU|QEMU]]; [[SPICE Protocol|SPICE]]; [[QCOW2|qcow2]]; [[Virtual Machine Manager|virt-manager]]. **Entity and technical context.** [[Inter-process Communication|IPC]] is the general process-to-process communication category; [[D-Bus|D-Bus]] is a specific message-bus implementation. [[PCMan File Manager|PCManFM]] is a Linux file manager. [[QEMU|QEMU]] provides emulation/virtualization; [[SPICE Protocol|SPICE]] provides remote display and device redirection; [[QCOW2|qcow2]] is QEMU's copy-on-write disk format; [[Virtual Machine Manager|virt-manager]] is a graphical libvirt/QEMU manager. **Whole-page reconstruction.** D-Bus is a message bus for local inter-process communication; PCManFM is a lightweight Linux file manager. QEMU supplies machine virtualization/emulation, SPICE supplies remote-display and USB-redirection facilities, qcow2 supplies copy-on-write virtual disks, and virt-manager supplies a management GUI. QEMU’s documentation describes qcow2’s metadata and snapshot-oriented design, while the project’s support page points users toward virt-manager for a graphical workflow.[^dbus][^qcow2][^virt-manager] This is a compact **desktop virtualization recipe** rather than an abstract glossary. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Recover the intended guest OS, QEMU version, USB-redirection target, and the ambiguous grab-key notation. ## PDF page 13 — iOS jailbreak sources and FQDN/IP notes **Source.** `Scanned_20260730-1659.pdf`, PDF page 13. **Visible page.** Ruled page of iOS-jailbreak sources/tools, an FQDN-to-server-IP example, a copied date, and one unresolved final compound name. **Faithful transcription.** > "Jailbreakfree365.info > Jailbreak Central > > PwnMy > UncOver > > IP of FQDN > server > Ex: 192.168.122.254 > > ~~[illegible]~~ Dec 11 2012 > > [uncertain: fpyNeighborhood]" **Normalized linked entities.** [[iOS Jailbreaking|iOS jailbreaking]]; [[unc0ver|unc0ver]]; [[Fully Qualified Domain Name|FQDN]]; [[Internet Protocol Address|IP address]]. **Entity and technical context.** [[iOS Jailbreaking|Jailbreaking]] alters the normal iOS trust/installation boundary. [[unc0ver|unc0ver]] is a named jailbreak project; `PwnMy` and the two source domains require historical verification. A [[Fully Qualified Domain Name|FQDN]] is a complete DNS hostname, while the example address is an RFC 1918 private IPv4 address rather than a public server location. **Whole-page reconstruction.** The page catalogs iOS jailbreak sources and names `unc0ver`, a jailbreak project that historically supported multiple iOS versions and devices.[^unc0ver] The FQDN/IP example is ordinary DNS notation, but its presence beside jailbreak tools suggests the author was tracing download infrastructure or server endpoints. The final compound name remains unresolved and should not be normalized into a known product without visual or corpus corroboration. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Identify PwnMy and the unresolved final name; determine whether the 2012 date belongs to a jailbreak release, server, or copied certificate. ## PDF page 14 — Proxy exclusions, Lucky Patcher, and alternative Android stores **Source.** `Scanned_20260730-1659.pdf`, PDF page 14. **Visible page.** Ruled Android/proxy note page. Top gives proxy ignored-host values; middle lists Lucky Patcher and uncertain identifiers; bottom circles “Catapult” and connects it to third-party Android stores and PUBG. **Faithful transcription.** > "ignored hosts in proxy > > [uncertain: RVP]: localhost, 127.0.0.0; > ::1 > > Lucky Patcher 5 > > [uncertain: Codelane S] > [uncertain: vID APP3V] > [uncertain: pixel Luna 2021] > 10 > OS > > Catapult Uptodown > store > Aptoide Store > pubg" **Normalized linked entities.** [[Proxy Server|proxy]]; [[Loopback Address|loopback address]]; [[Lucky Patcher|Lucky Patcher]]; [[Uptodown|Uptodown]]; [[Aptoide|Aptoide]]; [[PUBG|PUBG]]. **Entity and technical context.** `localhost`, IPv4 loopback, and IPv6 `::1` are local-only destinations commonly excluded from proxies. [[Lucky Patcher|Lucky Patcher]] is associated with app modification/patching. [[Uptodown|Uptodown]] and [[Aptoide|Aptoide]] are alternative Android distribution channels; [[PUBG|PUBG]] is the game title. `Catapult` and the uncertain identifiers remain unassigned. **Whole-page reconstruction.** The loopback addresses belong in proxy-bypass lists so local services are not sent through an external proxy. Lucky Patcher, Uptodown, Aptoide, and PUBG form an alternate-distribution/modification cluster: patching or permission manipulation, third-party app stores, and a high-value target application. The page is evidence of **ecosystem mapping**, not proof that any app was modified. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Resolve “Catapult,” “Codelane,” and the uncertain IDs; determine whether the list was a malware/permission audit or software-acquisition plan. ## PDF page 15 — SELinux, App Ops, and Android permission utilities **Source.** `Scanned_20260730-1659.pdf`, PDF page 15. **Visible page.** Ruled page listing Android permission-management, application-management, and security utilities. A vertical divider separates a small AppOps note at right. **Faithful transcription.** > "SELinux Mode Changer > App Ops > Apps Organizer > Batch Uninstaller > List My Apps > Permission friendly apps > Android Permissions > Antivirus > AppLocker > Apps Bot > App Mover > > AppPost > appops > [uncertain: see more]" **Normalized linked entities.** [[Security-Enhanced Linux|SELinux]]; [[App Ops|App Ops]]; [[Android Permissions|Android permissions]]; [[Application Locker|AppLocker]]; [[Android Security Utilities|Android security utilities]]. **Entity and technical context.** [[Security-Enhanced Linux|SELinux]] is kernel-enforced mandatory access control; [[App Ops|App Ops]] is Android's framework-level operation/permission control. The remaining entries are user-facing package organizers, uninstallers, permission viewers, antivirus, lockers, movers, and app-list exporters. Similar names do not guarantee a single developer or trustworthy provenance. **Whole-page reconstruction.** Android’s SELinux deployment enforces mandatory access-control policy over processes and files; Android runs SELinux in enforcing mode in production builds.[^android-selinux] App Ops and the surrounding utilities expose or organize app permissions, package lists, uninstall operations, and movement between storage locations. The page shows the author differentiating **kernel-level policy, framework-level app operations, and user-level utility wrappers**—three layers often conflated in casual Android security discussions. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Identify exact package IDs and Android versions; determine whether SELinux was permissive or enforcing during testing. ## PDF page 16 — OxygenOS OTA and Jitterbug/Lively transition **Source.** `Scanned_20260730-1659.pdf`, PDF page 16. **Visible page.** Sparse ruled page connecting OxygenOS firmware language with the Jitterbug/Lively consumer-phone brand transition and domains. **Faithful transcription.** > "Oxygen OS > full OTA > > Jitterbug > ↑ > ~~Lively.com~~ > Lively.com > Wear Lively.com > [uncertain: bra]" **Normalized linked entities.** [[OxygenOS|OxygenOS]]; [[Over-the-Air Update|full OTA]]; [[Jitterbug Phone|Jitterbug]]; [[Lively|Lively]]. **Entity and technical context.** [[OxygenOS|OxygenOS]] is OnePlus's Android-derived operating system; a `full OTA` is a complete update payload. [[Jitterbug Phone|Jitterbug]] and [[Lively|Lively]] belong to an accessibility/senior-oriented phone-service lineage. The rewritten domain likely records brand normalization, not two independent services. **Whole-page reconstruction.** OxygenOS is OnePlus’s Android distribution, and “full OTA” denotes a complete over-the-air update package rather than a small incremental patch. Jitterbug’s consumer-phone service was rebranded under Lively; the repeated/corrected domain notes look like brand-transition normalization. The page’s deeper pattern is vendor firmware on one side and accessibility-oriented telecom branding on the other. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Date the Jitterbug-to-Lively rebrand note and identify the unresolved final fragment. ## PDF page 17 — ISP programming, NordVPN, and ENOVAP fragments **Source.** `Scanned_20260730-1659.pdf`, PDF page 17. **Visible page.** Ruled page mixing an ISP programming-tool reference, IVPS labels, NordVPN/App Store search notes, and an electronic-cigarette company/domain. **Faithful transcription.** > "NoMicro ISP Programming > tool > > IVPS > > IVPS Tour > > Nord VPN > search in apple > Store for ISP > > Pipeline electronic > cigarette > > lca-distribution.com > ENOVAP" **Normalized linked entities.** [[In-system Programming|ISP programming]]; [[NordVPN|NordVPN]]; [[Virtual Private Network|VPN]]; [[ENOVAP|ENOVAP]]; [[Electronic Cigarette|electronic cigarette]]. **Entity and technical context.** [[In-system Programming|In-system programming]] flashes embedded devices without removing the chip; [[Internet Service Provider|internet service provider]] is the competing `ISP` expansion suggested by the VPN/App Store context. [[NordVPN|NordVPN]] is a commercial VPN service. [[ENOVAP|ENOVAP]] and the written distribution domain concern electronic-vaping technology; `NoMicro` and `IVPS` remain unresolved. **Whole-page reconstruction.** `ISP programming` most plausibly means in-system programming of embedded hardware, although the adjacent NordVPN/App Store note also uses ISP in the internet-service-provider sense. That dual use is unresolved and should remain split in the acronym dictionary. ENOVAP is an electronic-vaping company/product context linked to the written distribution domain. The page is a reminder that identical abbreviations can bridge unrelated technical domains and must be disambiguated by local syntax. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Disambiguate both meanings of ISP; identify NoMicro/IVPS and the relationship between ENOVAP and the written distribution domain. ## PDF page 18 — [PERSON REDACTED] property contact and TikTok account ledger **Source.** `Scanned_20260730-1659.pdf`, PDF page 18. **Visible page.** Upper section records a [PERSON REDACTED]/Irving-property contact and domain. Lower section contains TikTok usernames, multiple passwords/account strings, email addresses, and a telephone number; all credential-equivalent strings and phone numbers are redacted. **Faithful transcription.** > "[PERSON REDACTED] (Irving property) > xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 18) > > [PRIVATE DOMAIN REDACTED] > > BM TikTok > User: bryantmcgill 336c > PW: [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 18] > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 18] > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 18] > > User: GoMcGill 9994 > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 18] > [email protected] > info@sr # > xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 18)" **Normalized linked entities.** [PERSON REDACTED]; [[Private Property Contact|private property contact]]; [[TikTok|TikTok]]; [[GoMcGill|GoMcGill]]; [[Account Recovery|account recovery]]. **Entity and technical context.** [PERSON REDACTED] is a private first-name contact linked by the source to an Irving property and a domain. [[TikTok|TikTok]] accounts for Bryant/GoMcGill occupy the lower block. The domain-derived phrase is not used to infer [PERSON REDACTED]'s surname. Usernames and emails are retained in the quotation; credentials and telephone numbers are not propagated. **Whole-page reconstruction.** The upper block is a property/contact record; the lower block is a TikTok identity and recovery ledger for Bryant/GoMcGill accounts. It documents a recurring notebook function: **binding public brands, private contact routes, and account credentials in one place**. Only the names, service labels, email addresses, and source locations are retained; passwords and telephone numbers are not propagated into people or account indexes. **Evidentiary status.** **Visible evidence:** the quoted labels, layout, crossings, and privacy-preserving redactions. **Verified fact:** only externally documented service/technology identities. **Strong inference:** the page served operational access, recovery, migration, or support work. **Unresolved:** whether every recorded account was current, legacy, or test-only. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Corroborate [PERSON REDACTED]’s business/domain identity without inferring a surname beyond the written domain; identify which TikTok handles were active. ## PDF page 19 — Webull login record **Source.** `Scanned_20260730-1659.pdf`, PDF page 19. **Visible page.** Sparse ruled page with Webull label, a telephone-number login identifier, and a password-like phrase. **Faithful transcription.** > "Webull > xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 19) > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 19]" **Normalized linked entities.** [[Webull|Webull]]; [[Telephone-number Login|telephone-number login]]; [[Credential Ledger|credential ledger]]. **Entity and technical context.** [[Webull|Webull]] is a brokerage/trading platform label. The page contains only a login identifier and secret; it does not establish account ownership status, securities activity, balances, or dates. **Whole-page reconstruction.** A telephone number appears to have served as the Webull login identifier, followed by a password-like string. This is a minimal account-access record. Because no transaction or balance is present, it cannot support any financial-history inference. **Evidentiary status.** **Visible evidence:** the quoted labels, layout, crossings, and privacy-preserving redactions. **Verified fact:** only externally documented service/technology identities. **Strong inference:** the page served operational access, recovery, migration, or support work. **Unresolved:** whether every recorded account was current, legacy, or test-only. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Determine whether Webull access was active, abandoned, or recovery-only; no financial inference is presently supported. ## PDF page 20 — Blank ruled page with bleed-through **Source.** `Scanned_20260730-1659.pdf`, PDF page 20. **Visible page.** Blank ruled page with faint bleed-through from adjacent writing and light edge staining. **Faithful transcription.** > "[blank]" **Normalized linked entities.** [[Blank Notebook Page|blank page]]; [[Bleed-through|bleed-through]]. **Entity and technical context.** No entity is intentionally written. `Bleed-through` describes transferred visibility from an adjacent physical page and is not transcribed as content. **Whole-page reconstruction.** The page is intentionally preserved as blank evidence. Faint transfer from neighboring pages confirms physical adjacency but does not support transcription. Blank pages can mark topic breaks, hesitation, or unused capacity; here it separates financial/account material from a renewed Apple/network investigation. **Evidentiary status.** **Visible evidence:** a physically blank or bleed-through page. **Verified fact:** none beyond material condition. **Inference:** it marks a pause or boundary. **Unresolved:** whether adjacent pages were once removed or reordered. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** No hidden signal should be manufactured; only physical adjacency may clarify the page’s archival role. ## PDF page 21 — Encrypted identifier, link-local proxy bypass, and Apple restore terms **Source.** `Scanned_20260730-1659.pdf`, PDF page 21. **Visible page.** Ruled page of identity/alias fragments, an “Encrypted/Id,” link-local bypass-proxy addresses, repeated MRT/readability/launch-daemon notes, and Apple restore/network parameters. **Faithful transcription.** > "[uncertain: Bij Latg] > > mcgill / mcgill~ x5 > Encrypted/Id: j192177 > > bypass proxies 169.254/16 > 169.254.141:170 > 255.255.0.0. > > MRT.app [uncertain: MRS] > readability bundle > launch daemon inside RAC host > > Duet Thermal booster > wlan.vo (CVO) > b.com. wow magic > wan, voice > wwan > APNonce" **Normalized linked entities.** [[Link-local Address|169.254/16]]; [[Proxy Bypass|proxy bypass]]; [[Malware Removal Tool|MRT.app]]; [[Duet Thermal Management|Duet Thermal]]; [[Apple Personalized Restore|APNonce]]; [[Wireless Wide Area Network|WWAN]]. **Entity and technical context.** `169.254/16` is the IPv4 link-local block; a proxy bypass prevents those local connections from leaving through the configured proxy. `MRT.app`, readability/launch-daemon fragments, [[Duet Thermal Management|Duet Thermal]], WLAN/WWAN/voice labels, and [[Apple Personalized Restore|APNonce]] are Apple diagnostic/recovery vocabulary. `Encrypted/Id` and `j192177` remain source identifiers without assumed function. **Whole-page reconstruction.** The 169.254/16 block is IPv4 link-local addressing, often used when DHCP fails or for directly connected services. The page pairs proxy-bypass syntax with repeated Apple service fragments, thermal management, WWAN, and APNonce. APNonce participates in Apple’s personalized-restore authorization process; in jailbreak/recovery communities it is tracked because restore eligibility depends on signed, device-specific values. This page is best read as a **device-state and restore-state correlation sheet**, not evidence of malicious persistence. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Identify `j192177`, “RAC/RPC host,” and Duet Thermal components from device logs; distinguish WLAN, WWAN, voice, and nonce fields. ## PDF page 22 — Blank ruled page **Source.** `Scanned_20260730-1659.pdf`, PDF page 22. **Visible page.** Blank ruled page with light discoloration at the upper-left corner. **Faithful transcription.** > "[blank]" **Normalized linked entities.** [[Blank Notebook Page|blank page]]. **Entity and technical context.** No written entity is present. **Whole-page reconstruction.** This blank page is a material pause. No intentional marks are visible, so no hidden content is inferred from paper discoloration. **Evidentiary status.** **Visible evidence:** a physically blank or bleed-through page. **Verified fact:** none beyond material condition. **Inference:** it marks a pause or boundary. **Unresolved:** whether adjacent pages were once removed or reordered. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** No textual lead; compare paper damage and page order only. ## PDF page 23 — Blank ruled page with reverse-side bleed-through **Source.** `Scanned_20260730-1659.pdf`, PDF page 23. **Visible page.** Blank ruled page with faint blue bleed-through from reverse-side writing, strongest along the right half and bottom edge. **Faithful transcription.** > "[blank]" **Normalized linked entities.** [[Blank Notebook Page|blank page]]; [[Bleed-through|bleed-through]]. **Entity and technical context.** No written entity is present; reverse-side ghosting is excluded from the transcription. **Whole-page reconstruction.** Only bleed-through is visible. The archive records the physical condition but does not treat reverse-side ghosting as an independent transcription. **Evidentiary status.** **Visible evidence:** a physically blank or bleed-through page. **Verified fact:** none beyond material condition. **Inference:** it marks a pause or boundary. **Unresolved:** whether adjacent pages were once removed or reordered. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Inspect reverse side and binding order, not the ghost image, for any recoverable sequence information. ## PDF page 24 — BOSSA flashing, scrobbling, QFIL, and firmware update **Source.** `Scanned_20260730-1659.pdf`, PDF page 24. **Visible page.** Ruled page linking BOSSA/Atmel SAM flashing, scrobbling, [PERSON REDACTED]’s insistence that an application run as a screenshot-related app, QFIL, FunCube, and firmware updating. “Scrob / Scrobbler!” is enclosed in a large oval. **Faithful transcription.** > "Bossa Atmel Sam > devices Flash program > > Scrob > Scrobbler! > > [PERSON REDACTED] > insisted > on running > as \"[uncertain: screenshot]\" > app... > > Qfil > Fun cube > firmware > update" **Normalized linked entities.** [[BOSSA|BOSSA]]; [[Atmel SAM Microcontroller|Atmel SAM]]; [[Scrobbling|scrobbling]]; [PERSON REDACTED]; [[Qualcomm Flash Image Loader|QFIL]]; [[FUNcube|FUNcube]]. **Entity and technical context.** [[BOSSA|BOSSA]] programs Atmel/Microchip SAM devices through SAM-BA; [[Qualcomm Flash Image Loader|QFIL]] is Qualcomm-oriented firmware flashing software; [[FUNcube|FUNcube]] is associated with amateur-radio/educational satellite hardware. [[Scrobbling|Scrobbling]] usually means logging media playback. [PERSON REDACTED] is preserved as the exact first-name spelling. **Whole-page reconstruction.** BOSSA is a host utility for programming Atmel/Microchip SAM microcontrollers through the SAM-BA bootloader; QFIL is Qualcomm’s flash-image loader used with supported chipsets. Their co-occurrence with firmware update and FUNcube suggests broad **device-recovery tooling**, spanning microcontrollers, Qualcomm devices, and radio/space-education hardware. “Scrobbling” normally means logging media-play events, but its role here is unclear. [PERSON REDACTED]’s screenshot-related insistence may describe an app behavior, not a product name. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Resolve the screenshot-app wording and “Scrob” meaning; identify the target hardware for BOSSA, QFIL, and FUNcube. ## PDF page 25 — Storage Access Framework and open mobile infrastructure map **Source.** `Scanned_20260730-1659.pdf`, PDF page 25. **Visible page.** Ruled page headed “SAF,” expanding Android’s Storage Access Framework and mapping an open/mobile-software stack from app repositories through AOSP, Ubuntu Touch, Linux phones, Firebase, Wi-Fi scanning, Tor/OpenVPN, and FreedomBox. **Faithful transcription.** > "SAF > Storage Access Frameworks > > F-Droid / APKPure? / APKMirror? > Android AOSP - > Nexus 5 Ubuntu Touch > Linux Phone > Pine / Librem5 > > Google firebase Server > > Disable wifi Scanning > > Tor / Open VPN > Freedom Box" **Normalized linked entities.** [[Storage Access Framework|SAF]]; [[F-Droid|F-Droid]]; [[APKPure|APKPure]]; [[APKMirror|APKMirror]]; [[Android Open Source Project|AOSP]]; [[Ubuntu Touch|Ubuntu Touch]]; [[PinePhone|PinePhone]]; [[Librem 5|Librem 5]]; [[Firebase|Firebase]]; [[Tor|Tor]]; [[OpenVPN|OpenVPN]]; [[FreedomBox|FreedomBox]]. **Entity and technical context.** [[Storage Access Framework|SAF]] is Android's user-mediated document/storage access layer. F-Droid, APKPure, and APKMirror are distribution sources with different governance models. [[Android Open Source Project|AOSP]] is the Android base; Ubuntu Touch, PinePhone, and Librem 5 represent alternate mobile OS/hardware paths. Firebase is centralized backend infrastructure; Tor, OpenVPN, and FreedomBox provide privacy, secure transport, and self-hosting. **Whole-page reconstruction.** The page sketches an unusually coherent **sovereign-mobile stack**. Android’s Storage Access Framework mediates user-approved document access; Android documentation requires third-party apps to use it for portable storage.[^android-storage] F-Droid/APKPure/APKMirror supply software, AOSP supplies the base operating system, Ubuntu Touch/PinePhone/Librem 5 represent alternative mobile platforms and hardware, Firebase supplies backend services, and Tor/OpenVPN/FreedomBox supply privacy and self-hosting. The unresolved tension is visible: Firebase centralizes identity/data while FreedomBox and Tor decentralize it. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Determine whether this was a deployable architecture or a survey; identify the intended self-hosted alternative to Firebase. ## PDF page 26 — ADB over TCP, LineageOS, SELinux, and ownCloud **Source.** `Scanned_20260730-1659.pdf`, PDF page 26. **Visible page.** Ruled page on Android debugging and alternative Android infrastructure. The upper block expands ADB and specifies TCP port 5555; lower lines list LineageOS, SELinux, adb, a person named [PERSON REDACTED], and several domains/host strings of uncertain spelling. **Faithful transcription.** > "ADB Android debug > bridge over > tcp 5555 > > Lineage OS > > SELinux > > Adb > > [PERSON REDACTED] > android.owncloud.com > [uncertain: files.nbu.apps.android.google.com] > [uncertain: vendily.android.com] > [uncertain: free.qt, ccc71]" **Normalized linked entities.** [[Android Debug Bridge|ADB]]; [[Transmission Control Protocol|TCP]]; [[Port 5555|port 5555]]; [[LineageOS|LineageOS]]; [[Security-Enhanced Linux|SELinux]]; [[ownCloud|ownCloud]]; [PERSON REDACTED]. **Entity and technical context.** [[Android Debug Bridge|ADB]] is Android's device-debugging protocol/tool; TCP port 5555 is the classic network-daemon port. [[LineageOS|LineageOS]] is the community successor to CyanogenMod; [[Security-Enhanced Linux|SELinux]] supplies mandatory policy enforcement; [[ownCloud|ownCloud]] is a self-hosted file-sync platform. The uncertain hostnames are not silently corrected. **Whole-page reconstruction.** ADB can place its daemon in TCP mode on port 5555, although modern Android strongly prefers authenticated wireless-debugging workflows and warns that network exposure must be controlled.[^adb] LineageOS is the community successor to CyanogenMod; SELinux remains the mandatory-access-control substrate. `android.owncloud.com` points toward self-hosted file synchronization. The page was integrating **debug transport, alternate firmware, policy enforcement, and private cloud** into one mobile-control architecture. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Resolve all host strings and [PERSON REDACTED]’s role; confirm whether port 5555 was exposed only on a trusted network. ## PDF page 27 — Android package names, Dr. Ketan ROM, and Tasker security tools **Source.** `Scanned_20260730-1659.pdf`, PDF page 27. **Visible page.** Ruled page beginning with Android package names, then a Dr. Ketan One UI ROM note for Samsung N986B, Samsara/Dr.Web references, Tasker Secure Settings, car-mode software, and an uncertain premium-app label. **Faithful transcription.** > "in > > com.google.android.apps.personalization > com.android.systemui > com.intangibleobject.securesettings.plugin > > Dr. Ketan Rom OneUI > N986B Samsung > > Samsara > Dr. Web > > Tasker Secure settings > Car Home Ultra > 4.2 Car mode pattern > \"[uncertain: Cloud Premium]\"" **Normalized linked entities.** [[Android Package Name|Android package name]]; [[Dr. Ketan ROM|Dr. Ketan ROM]]; [[Samsung Galaxy Note20 Ultra|Samsung N986B]]; [[One UI|One UI]]; [[Tasker|Tasker]]; [[Secure Settings Plugin|Secure Settings]]; [[Car Home Ultra|Car Home Ultra]]. **Entity and technical context.** `com.google.android.apps.personalization`, `com.android.systemui`, and `com.intangibleobject.securesettings.plugin` are package namespaces. [[Dr. Ketan ROM|Dr. Ketan ROM]] and `N986B` point to a Samsung custom-ROM/device context; [[Tasker|Tasker]] plus Secure Settings enables automation of privileged settings. Dr.Web is antivirus; Car Home Ultra is an automotive launcher/interface. `Samsara` and `Cloud Premium` require exact-package corroboration. **Whole-page reconstruction.** The three package names identify Android personalization/System UI and the Secure Settings plug-in used by automation tools such as Tasker. `N986B` corresponds to the international Samsung Galaxy Note20 Ultra family, and Dr. Ketan is associated with custom Samsung ROM work. Samsara, Dr.Web, and Car Home Ultra broaden the page into fleet/telemetry, antivirus, and automotive interfaces. The source supports a customization/security test environment, not a claim that all packages coexisted on one device. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Recover package versions and ROM build; determine whether Samsara means the fleet platform, a namesake app, or another project. ## PDF page 28 — Pebble, Appium, XDA, Settings+, and realme UI **Source.** `Scanned_20260730-1659.pdf`, PDF page 28. **Visible page.** Ruled page of Android/Pebble development and customization references: an uncertain apps domain, Auto App for Pebble, Appium server GUI for Linux, XDA, a Settings+ author/identifier note, and realme UI 3.0. **Faithful transcription.** > "[uncertain: Jcaapps.com] > > Auto App for Pebble > Pebble or [uncertain: UMI DIGI] > > appium-server-GUI-Linux > > XDA > > Settings+ by LauCass > (Batman/cricket) > > real-me (realme) UI 3.0" **Normalized linked entities.** [[Pebble Smartwatch|Pebble]]; [[Appium|Appium]]; [[XDA Developers|XDA]]; [[Settings Plus|Settings+]]; [[Index - People#Rushikesh Kamewar|Rushikesh Kamewar]]; [[realme UI|realme UI]]. **Entity and technical context.** [[Pebble Smartwatch|Pebble]] is a smartwatch platform; `Auto App for Pebble` suggests automation. [[Appium|Appium]] automates mobile applications for testing. [[XDA Developers|XDA]] is a device-modification/developer community. `Settings+ by LauCass` and [[Index - People#Rushikesh Kamewar|Rushikesh Kamewar]] appear in separate source lines and must not be merged without package evidence. [[realme UI|realme UI 3.0]] is realme's Android interface generation. **Whole-page reconstruction.** Pebble automation, Appium’s desktop server GUI, XDA, Settings+, and realme UI place this page in **cross-device interface testing**. Appium is an automation framework for mobile application testing; XDA is a developer community around Android modification. The parenthetical “Batman/cricket” cannot safely be mapped to Rushikesh Kamewar or a package without more evidence. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Identify the uncertain apps domain, device after “Pebble or,” and the Batman/cricket note; locate exact Settings+ package. ## PDF page 29 — Browser interception and FOSS download tools **Source.** `Scanned_20260730-1659.pdf`, PDF page 29. **Visible page.** Sparse ruled page listing phone-side browser/share interception and several download/browser applications, followed by “One UI.” **Faithful transcription.** > "On my phone > Browser Intercept Share > > Download Navi > FossBrowser > jQuarks > Jthor > > One UI" **Normalized linked entities.** [[Browser Interception|Browser Intercept Share]]; [[Download Navi|Download Navi]]; [[FOSS Browser|FOSS Browser]]; [[jQuarks|jQuarks]]; [[One UI|One UI]]. **Entity and technical context.** Browser Intercept Share describes Android intent/share interception; Download Navi, FOSS Browser, and jQuarks are lightweight/open-source-oriented download/browser tools. `Jthor` is unresolved. [[One UI|One UI]] indicates a Samsung operating context. **Whole-page reconstruction.** The page lists applications for intercepting share intents, downloading, and browsing through open-source or lightweight clients, then records One UI as the operating context. This is a user-level complement to the lower-level ADB/SELinux pages: instead of modifying the platform, it maps how content enters and leaves applications. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Identify `Jthor` and verify each package’s provenance/version. ## PDF page 30 — Ingenium unlock-word sequence and Dr. Ketan reference **Source.** `Scanned_20260730-1659.pdf`, PDF page 30. **Visible page.** Ruled page headed “Powered by Ingenium.” Eight numbered words or command names are scattered vertically, several evoking unlocking/opening; the page ends with an Android package-like identifier and “Dr. Ketan KYAS.” **Faithful transcription.** > "Powered by Ingenium > > 8 - Colloporus > 4 - Alberto > 1 - Alohomora > 5 - Liberare > 2 - Dunamis > 3 - Alohomora > 6 - Open Sesame > 7 - Portaberto > > [illegible] > [uncertain: com.mobit.ingenium.tca.3] > Dr. Ketan KYAS" **Normalized linked entities.** [[Ingenium|Ingenium]]; [[Alohomora|Alohomora]]; [[Open Sesame|Open Sesame]]; [[Dr. Ketan ROM|Dr. Ketan]]; [[Unlock Vocabulary Sequence|unlock-word sequence]]. **Entity and technical context.** `Alohomora`, `Open Sesame`, `Liberare`, `Dunamis`, `Portaberto`, and neighboring terms share opening/liberation/power semantics. [[Ingenium|Ingenium]] may be an application/developer label. The numbered order and repeated word are preserved because they may encode workflow sequence. [[Dr. Ketan ROM|Dr. Ketan]] supplies a possible Android-ROM context, not a confirmed relation. **Whole-page reconstruction.** The numbered words are structured like passphrases, activation words, game clues, or command vocabulary—many mean opening, freedom, or power. Because the sequence includes repeated `Alohomora` and a package-like identifier, the strongest interpretation is an **unlock/activation codebook** associated with an app or ROM workflow. It is not treated as a credential because the page does not label the words as a password, but the sequence remains security-sensitive contextually and is not generalized beyond the source. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Determine the source system for the numbered words; treat as a possible codebook until contextual evidence resolves it. ## PDF page 31 — Android launcher sizes, Gboard, and graphics-driver preferences **Source.** `Scanned_20260730-1659.pdf`, PDF page 31. **Visible page.** Ruled page comparing Android launchers and apparent download sizes, then Gboard and an uncertain developer-options note about graphics-driver preferences. **Faithful transcription.** > "Nexus Launcher > > Total Launcher 1m > Blackberry 1m > > iOS 15 50m > > Linux CLI Launcher > > GBoard > > * Dev No! > [uncertain: Graphic driver pref] > [uncertain: mod graphic driver sum]" **Normalized linked entities.** [[Android Launcher|Android launcher]]; [[Nexus Launcher|Nexus Launcher]]; [[Total Launcher|Total Launcher]]; [[BlackBerry Launcher|BlackBerry Launcher]]; [[Linux CLI Launcher|Linux CLI Launcher]]; [[Gboard|Gboard]]; [[Android Graphics Driver Preferences|graphics-driver preference]]. **Entity and technical context.** Nexus Launcher, Total Launcher, BlackBerry Launcher, Linux CLI Launcher, and an iOS-like launcher represent different interface emulation models. [[Gboard|Gboard]] is Google's keyboard. Android's per-app graphics-driver preference is a developer option controlling rendering-driver selection; the notebook's warning suggests caution around changing it. **Whole-page reconstruction.** Launcher names and rough sizes are being compared as interface substrates, while Gboard and graphics-driver preference extend the comparison from home screen to input and rendering. The `Dev No!` notation may indicate a warning not to change a developer option. The page captures a practical concern with **how much of the visible Android experience can be replaced without destabilizing graphics**. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Recover actual package sizes and device model; identify which graphics-driver setting was being protected from change. ## PDF page 32 — Android launcher survey headed APUS **Source.** `Scanned_20260730-1659.pdf`, PDF page 32. **Visible page.** Ruled page headed “Launchers” with a broad Android-launcher survey. “APUS” is written at top right; AIO has “500k” beside it; subsequent launchers are grouped by conventional, pixel-like, tablet, and minimalist forms. **Faithful transcription.** > "Launchers APUS > AIO 500k > Evie > Action > > CPL Custom Pixel Launcher > Pixel UI > Lawnchair > Arc Pro > Apex > Poco > Microsoft > Nova? > ADW Launcher > > ASAP (tablets) > Lean > Big > Smart 6 > Niagara Clean" **Normalized linked entities.** [[APUS Launcher|APUS]]; [[AIO Launcher|AIO Launcher]]; [[Evie Launcher|Evie]]; [[Action Launcher|Action Launcher]]; [[Custom Pixel Launcher|CPL]]; [[Lawnchair|Lawnchair]]; [[Nova Launcher|Nova]]; [[Niagara Launcher|Niagara]]. **Entity and technical context.** APUS, AIO, Evie, Action, CPL, Pixel UI, Lawnchair, Arc, Apex, Poco, Microsoft, Nova, ADW, ASAP, Lean, BIG, Smart Launcher, and Niagara are launcher/interface candidates. They range from commercial recommendation ecosystems to open Pixel-like replacements and accessibility/minimalist interfaces. The handwritten `500k` is a source metric of unclear type/date. **Whole-page reconstruction.** This is a broader launcher taxonomy: feature-dense dashboards, Pixel emulations, tablet launchers, accessibility-oriented large interfaces, and minimalist designs. APUS is singled out at the top, anticipating the APUS corporate notes on pages 68–69. The page supports a sustained inquiry into the launcher as a **governance layer over Android**—controlling search, recommendations, app discovery, telemetry, and visual identity rather than merely icons. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Reconstruct selection criteria—privacy, size, telemetry, accessibility, or visual control—and compare against APUS research on pages 68–69. ## PDF page 33 — Cloudflare firewall and autonomous-system numbers **Source.** `Scanned_20260730-1659.pdf`, PDF page 33. **Visible page.** Ruled page headed “Cloudflare,” then “GoMcGill firewall.” It records five major network autonomous-system numbers and providers, ending with “User Agents.” **Faithful transcription.** > "Cloudflare > > GoMcGill firewall > > ASNs > 15169 Google > 32934 Facebook > 8075 microsoft > 16276 OVH > 14618 Amazon, AES > > User Agents" **Normalized linked entities.** [[Cloudflare|Cloudflare]]; [[Autonomous System Number|ASN]]; [[Google|Google]]; [[Meta Platforms|Facebook]]; [[Microsoft|Microsoft]]; [[OVHcloud|OVH]]; [[Amazon Web Services|Amazon]]; [[User Agent|User Agent]]. **Entity and technical context.** An [[Autonomous System Number|ASN]] identifies an independently routed network. AS15169, AS32934, AS8075, AS16276, and AS14618 map to Google, Meta, Microsoft, OVHcloud, and Amazon network domains. [[Cloudflare|Cloudflare]] can proxy customer DNS through its anycast edge. A [[User Agent|User Agent]] identifies client software in application protocols and is distinct from ASN ownership. **Whole-page reconstruction.** The listed ASNs correctly identify major network operators: Google AS15169, Meta/Facebook AS32934, Microsoft AS8075, OVH AS16276, and Amazon AS14618. An ASN identifies a routing domain, not an individual server or application. Cloudflare’s proxied DNS uses its anycast network to answer for customer hostnames and can obscure the origin address from ordinary DNS lookups.[^cloudflare-proxy] The page was building a firewall/attribution table that connected traffic to infrastructure owners. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Recover firewall rules and timestamps; distinguish ASN-level ownership from hostname-, certificate-, and process-level attribution. ## PDF page 34 — Network geolocation, AT&T ASN, OID, SMI, and IANA **Source.** `Scanned_20260730-1659.pdf`, PDF page 34. **Visible page.** Dense ruled network-geolocation investigation dated May 26, 2021. It traces two IP addresses, AT&T ASN 7018, inconsistent Texas geolocation labels, Nokia-store/geodetic-lab hypotheses, a WoodSprings Suites address claim, and standards identifiers OID/SMI/ASN. “DDD” is written very large in the lower-left margin. **Faithful transcription.** > "Intel Mac OSX 10.10.5 > May 26, 2021 > 45.19.177.146 > AS7018 (ASN) AT&T > Did say San Antonio but now says > Kenedy in Karnes County (small airport) > near [uncertain: Kard] Airfield in Karnes city > near Yorktown btw San Antonio > + 'Chorpis Christi' > Nokia store 31100 from 1 of 3 places > ~~AS7018~~ 1) Finland > 2) [uncertain: GEOdetic Lab] in Nevada > station: FUEL > 3) > > Alleged address WoodSprings Suites > 174.249.40.223 > > ? OID Private Enterprise Number > 1.3.6.1.4.1 for use in ASN1 > iso.org found on [PERSON REDACTED] Phone > which is an SMI Network > prefix according to ~~IANA.org~~ > IANA.org > > DDD" **Normalized linked entities.** [[Intel Corporation|Intel]]; [[AT&T|AT&T]]; [[Autonomous System Number|ASN]]; [[IP Geolocation|IP geolocation]]; [[Object Identifier|OID]]; [[Private Enterprise Number|Private Enterprise Number]]; [[Abstract Syntax Notation One|ASN.1]]; [[Structure of Management Information|SMI]]; [[Internet Assigned Numbers Authority|IANA]]; [PERSON REDACTED]. **Entity and technical context.** AS7018 is AT&T's routing domain; IP geolocation is an inferred database mapping, not GPS. `OID` is an object identifier; `1.3.6.1.4.1` is the IANA private-enterprise branch; [[Abstract Syntax Notation One|ASN.1]] is a data-description notation; [[Structure of Management Information|SMI]] structures network-management objects. The geographic place names are hypotheses recorded during an investigation, not verified device locations. **Whole-page reconstruction.** This is a field investigation into why geolocation services disagreed. IP geolocation is probabilistic and commonly maps provider address space to registration, network, or inferred access locations rather than a precise device. AS7018 belongs to AT&T; the page tests San Antonio, Kenedy, Karnes County, Corpus Christi, and other hypotheses against two IPs. The OID arc `1.3.6.1.4.1` is the IANA Private Enterprise Number branch, used by organizations in SNMP/SMI and other ASN.1-based identifiers.[^iana-pen] The notebook was converging on a crucial distinction: **routing identity, registry identity, and physical location are separate ontologies**. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Re-run the historical IP/WHOIS/geolocation comparison using archived data; identify the Nokia/geodetic references and “station FUEL.” ## PDF page 35 — Firewall, port discovery, cloud, and iPhone identity checklist **Source.** `Scanned_20260730-1659.pdf`, PDF page 35. **Visible page.** Dense ruled checklist combining a speculative filesystem/partition observation, firewall and port-discovery tasks, license-manager/cloud/tool names, phone display/accessibility settings, Siri/Search identity/logo observations, and several uncertain app names. Boxed outlines emphasize several checklist items. **Faithful transcription.** > "? Files being converted into > images so what you would > think that partitions (so called) > could easily move things > in and out. > > ☐ Finish Firewall > Port discovery > ncube license manager > ☐ CALL CARMAX > ☐ Digital Ocean > ☐ JTool > ☐ Emergency Pump Phone > ☐ ZSC [uncertain: my Purton] > > Phone > Display ~~[illegible]~~ and text size > Accessibility - Auto-Brightness > ☐ Volt Bot > ☐ Cake > ☐ Zenkit > > In Siri and Search > sometimes show realname > + real logo not fake one." **Normalized linked entities.** [[Filesystem Partition|partition]]; [[Firewall|firewall]]; [[Port Scanning|port discovery]]; [[FLEXlm|license manager]]; [[DigitalOcean|DigitalOcean]]; [[CarMax|CarMax]]; [[iOS Accessibility|Accessibility]]; [[Siri and Search|Siri and Search]]. **Entity and technical context.** A [[Filesystem Partition|partition]] is a logical disk region; a disk image is a file representation of storage and can contain partitions. [[Port Scanning|port discovery]] identifies listening services; `nCube license manager` may refer to a FLEXlm-like license service but is unresolved. DigitalOcean is cloud infrastructure; the lower entries concern iPhone display/accessibility and Siri/Search identity presentation. **Whole-page reconstruction.** This checklist spans conceptual filesystem questions, firewall completion, port discovery, licensing software, cloud hosting, device repair, and iPhone interface settings. The opening idea—that files can be represented as images and move between partitions—appears to be an intuition about abstraction layers or disk-image containers, but it is not technically articulated enough to validate. The Siri/Search note shows attention to **identity leakage through logos and real names**, linking UI forensics to network forensics. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Resolve nCube/JTool/ZSC/Volt Bot and the opening partition model; locate screenshots showing the “real name + real logo” behavior. ## PDF page 36 — Application and iOS accessibility inventory **Source.** `Scanned_20260730-1659.pdf`, PDF page 36. **Visible page.** Full-page checkbox inventory of applications and iOS accessibility/audio settings. “Office” is circled. The bottom note says headphone notifications are always off and associates the setting with Accessibility Audio/Visual. **Faithful transcription.** > "☐ PulseWay > ☐ Microsoft Lens > ☐ MS Portal > ☐ Cash App > ☐ Pinstachio > ☐ Remote Buddy > ☐ Shopify > ☐ Buffer > ☐ IP Scanner > ☐ Moleskin Actions > ☐ Signal > ☐ Office > ☐ One Note > ☐ T-Mobile App > ☐ Braille Settings > ☐ Assisted Touch Devices > ☐ Voice Over Audio > ☐ Switches [uncertain: C1] > ☐ Headphone Safety > ☐ Call Audio Routing > ☐ Headphone Notifications > always off (Accessibility > Audio/Visual)" **Normalized linked entities.** [[Pulseway|Pulseway]]; [[Microsoft Lens|Microsoft Lens]]; [[Microsoft Intune Company Portal|MS Portal]]; [[Signal|Signal]]; [[Microsoft Office|Office]]; [[Microsoft OneNote|OneNote]]; [[AssistiveTouch|AssistiveTouch]]; [[VoiceOver|VoiceOver]]; [[iOS Accessibility|iOS accessibility]]. **Entity and technical context.** Pulseway is remote monitoring/management; Microsoft Lens is document capture; Microsoft Portal likely means Intune Company Portal; Cash App is payments; Shopify is commerce; Buffer is social publishing; IP Scanner is network discovery; Signal is secure messaging; Office/OneNote are Microsoft productivity tools; T-Mobile is carrier software. Braille, AssistiveTouch, VoiceOver, Switch Control, call routing, and headphone safety are iOS accessibility/audio subsystems. **Whole-page reconstruction.** The list combines enterprise remote management, scanning, finance, productivity, commerce, secure messaging, carrier software, and accessibility controls. The emphasis on VoiceOver, switches, AssistiveTouch, Braille, headphone safety, and call routing suggests an audit of iOS’s alternate interaction pathways. These pathways are not merely accommodations: they are privileged input/output surfaces that can reshape device control and automation. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Determine whether the checklist describes installed apps, permission audit targets, or accessibility test cases. ## PDF page 37 — iPhone Camera configuration checklist **Source.** `Scanned_20260730-1659.pdf`, PDF page 37. **Visible page.** Ruled checklist of iPhone Camera settings. Square checkboxes precede each setting; “always-ON” and each “OFF” state are written emphatically. **Faithful transcription.** > "☐ Camera Capture > change to most compatible > not high efficiency > ☐ Preserve Settings always-ON > ☐ Scene Detection - OFF > ☐ SMART HDR - OFF > ☐ LENS CORRECTION - OFF > ☐ VIEW OUTSIDE FRAME - OFF" **Normalized linked entities.** [[iPhone Camera|iPhone Camera]]; [[High Efficiency Image Format|High Efficiency]]; [[Camera Preserve Settings|Preserve Settings]]; [[Smart HDR|Smart HDR]]; [[Lens Correction|Lens Correction]]; [[View Outside the Frame|View Outside the Frame]]. **Entity and technical context.** `Most Compatible` generally selects JPEG/H.264-style capture rather than newer high-efficiency formats on supported iPhones. Preserve Settings retains selected modes; Scene Detection, Smart HDR, Lens Correction, and View Outside the Frame are computational-camera controls. The checkbox states are source-prescribed configuration, not universal recommendations. **Whole-page reconstruction.** Apple documents these as advanced Camera controls: format compatibility, preserved modes/settings, Scene Detection, Smart HDR on supported models, Lens Correction, and viewing outside the frame.[^iphone-camera][^iphone-preserve] The chosen configuration privileges **predictability and minimally transformed capture** over computational enhancement. That is consistent with later forensic concerns: stable encoding and fewer automatic scene changes make images easier to compare across time. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Identify the exact iPhone model/iOS build; compare EXIF and image output before and after the configuration. ## PDF page 38 — Cloud, analytics, and router-domain blocklist **Source.** `Scanned_20260730-1659.pdf`, PDF page 38. **Visible page.** Dense checkbox list of cleanup tasks, cloud/CDN/analytics domains, and a router-login reminder. “ditt” is struck through; “M2Static.com” is annotated with the quoted fragment “MOS”; a curved underline separates the list from the final router note. **Faithful transcription.** > "☐ Clean Out Surge > ☐ Finish Digital Ocean > ☐ Block Flash in Browser > ☐ s3.DualStack.us > ☐ iCloud-content.com > ~~ditt~~ > ☐ DigitalOceanSpaces.com > ☐ Office 365.com > ☐ me.com > ☐ Prismic.io > ☐ Pendo.io > ☐ M2Static.com \"MOS\" > ☐ Whistia.com > ☐ DriftT.com > ☐ Typekit.net > ☐ Wi-Portal.de > remind block town Germany > ☐ WIMSERV.net > ☐ WI-Static.net > ☐ Drift.com > ☐ Router-Network.com > use router IP login just > found" **Normalized linked entities.** [[DigitalOcean Spaces|DigitalOcean Spaces]]; [[Amazon S3 Dual-stack Endpoint|S3 dual-stack]]; [[iCloud|iCloud]]; [[Microsoft 365|Office 365]]; [[Prismic|Prismic]]; [[Pendo|Pendo]]; [[Wistia|Wistia]]; [[Adobe Typekit|Typekit]]; [[Router Administration|router login]]. **Entity and technical context.** S3 dual-stack and DigitalOcean Spaces are object-storage endpoints; iCloud/me.com and Microsoft 365 are account/productivity infrastructure; Prismic is a headless CMS; Pendo is product analytics; Wistia is video hosting; Typekit is Adobe Fonts; Drift is conversational marketing. `M2Static`, Wi-Portal, WIMSERV, WI-Static, Router-Network, and misspelled strings require exact DNS/process evidence. **Whole-page reconstruction.** This is a manually curated network-deny list mixing cloud storage, CDNs, analytics/customer-experience platforms, email/productivity infrastructure, font delivery, and router-administration domains. Several strings are misspelled or may be app-specific subdomains; they must not be treated as confirmed ownership mappings. Apple’s privacy-manifest model now explicitly distinguishes domains contacted for tracking, illustrating the later institutionalization of the notebook’s manual domain-attribution practice.[^apple-tracking-domains] **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Validate every domain spelling and owning service before blocking; recover the source app/process that contacted each endpoint. ## PDF page 39 — Telemetry, advertising, payment, and analytics domains **Source.** `Scanned_20260730-1659.pdf`, PDF page 39. **Visible page.** Full-page checkbox inventory of domains associated with applications, telemetry, advertising, payments, content delivery, and analytics. The final item is split over two lines and appears to pair the name “matthew” with a software domain. **Faithful transcription.** > "☐ mangacoin.net > ☐ nr-data.net > ☐ litix.io > ☐ appcenter.ms > ☐ whatsapp.net > ☐ flashjoin.net > ☐ criteo.com > ☐ stripe.com > ☐ revenuecat.com > ☐ pub.network > ☐ msedge.net > ☐ hexagon-analytics.com > ☐ crazyegg.com > ☐ sharethrough.com > ☐ xteko.com > ☐ bidswitch.net > ☐ digitige.com > ☐ casalemedia.com > ☐ openX.net > ☐ matthew > digitalnomads.software" **Normalized linked entities.** [[New Relic|nr-data.net]]; [[Microsoft App Center|appcenter.ms]]; [[WhatsApp|whatsapp.net]]; [[Criteo|Criteo]]; [[Stripe|Stripe]]; [[RevenueCat|RevenueCat]]; [[Microsoft Edge|msedge.net]]; [[Crazy Egg|Crazy Egg]]; [[BidSwitch|BidSwitch]]; [[OpenX|OpenX]]; [[Domain Blocklist|domain blocklist]]. **Entity and technical context.** `nr-data.net` is associated with New Relic telemetry; `appcenter.ms` with Microsoft App Center; WhatsApp's domain supports messaging infrastructure; Criteo, Sharethrough, BidSwitch, Casale Media, and OpenX belong to advertising/exchange ecosystems; Stripe handles payments; RevenueCat manages subscriptions; Crazy Egg is behavior analytics. `mangacoin`, `litix`, `flashjoin`, `digitige`, `xteko`, `hexagon-analytics`, and the final software domain need per-process attribution. **Whole-page reconstruction.** The list moves deeper into mobile telemetry and advertising supply chains: crash/analytics endpoints, communications infrastructure, payment/subscription services, ad exchanges, bidders, and behavioral analytics. Blocking all entries indiscriminately could break core functionality; the page is better understood as **attribution before policy**. The inclusion of Stripe and RevenueCat alongside Criteo, BidSwitch, and OpenX shows the author recognizing that revenue telemetry, payments, and advertising form adjacent but distinct data flows. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Map each domain to process, timestamp, certificate, and function; separate essential payment/subscription traffic from advertising. ## PDF page 40 — Apple IOKit-style bus and accessory-controller inventory **Source.** `Scanned_20260730-1659.pdf`, PDF page 40. **Visible page.** Hardware/IOKit-style inventory of Apple bus, port, accessory, and controller names. The list moves from SPI and I²C buses through the “tristar” Lightning-port controller and several IOAccessory classes, then to “Apple CBTL1614,” “AIM Bus,” and repeated “parrot” labels. **Faithful transcription.** > "spi1 > spi2 > > smc-i2c1 > type i2c > apple S5L8940XI2C controller > tristar > name = tristar > port-Lightning > usb2 > IOClass = AppleTristarBuiltin > IOAccessoryUSBPowerSourceDetect > IOAccessoryUSBConnectShim > IOAccessoryTRM > IOAccessoryManagerUserClient > > Apple CBTL1614 > AIM Bus > parrot > parrot > Apple parrot" **Normalized linked entities.** [[Serial Peripheral Interface|SPI]]; [[Inter-Integrated Circuit|I²C]]; [[System Management Controller|SMC]]; [[Apple Tristar|Tristar]]; [[Lightning Connector|Lightning]]; [[IOKit|IOKit]]; [[Apple Accessory Protocol|Apple accessory management]]. **Entity and technical context.** SPI and I²C are serial buses. Apple's Tristar/Lightning and `IOAccessory...` class names describe accessory detection, power, USB connection, and manager clients within IOKit-style registries. `CBTL1614` appears chip/controller-like; `AIM Bus` and `parrot` remain unresolved private labels. Public product names are not invented for private Apple class strings. **Whole-page reconstruction.** The strings resemble Apple IOKit registry class/property names captured from a device tree or diagnostic dump. SPI and I²C are low-level serial buses; Tristar is commonly associated with Lightning/USB accessory and charging negotiation; `IOAccessory…` names imply accessory-power and connection management. The precise roles of `CBTL1614`, `AIM Bus`, and `parrot` are not established by public documentation here. The page evidences a move from application-level telemetry to **hardware bus topology and embedded controller services**. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Correlate each registry string with an IORegistry dump and hardware model; resolve `parrot`, `AIM Bus`, and CBTL1614. ## PDF page 41 — Apple SMC/RTBuddy services, WildPackets, and Kismet **Source.** `Scanned_20260730-1659.pdf`, PDF page 41. **Visible page.** Apple low-level service/component notes arranged in two clusters. The upper cluster lists an AC-back/fan entry, SMC, ASC wrapper, IOP/SMC nub, and RTBuddy services; the lower cluster, separated by a long curved line, lists WildPackets and Kismet and points to “Certifi page 1.” **Faithful transcription.** > "ACback > apple [uncertain: Fan] FAN ANS3740 > Apple > > SMC > Apple ASC WrapperV4 > iop-smc-nub > RTBuddyV2 > SmcEndpoint1 > RTBuddyService > > wild Packets > Kismet > Kismet-server-[uncertain: 70].com > See Certifi > page 1" **Normalized linked entities.** [[System Management Controller|SMC]]; [[Apple System Coprocessor|ASC]]; [[RTBuddy|RTBuddy]]; [[WildPackets|WildPackets]]; [[Kismet|Kismet]]; [[Wireless Network Discovery|wireless discovery]]. **Entity and technical context.** [[System Management Controller|SMC]] coordinates low-level power/thermal functions; [[Apple System Coprocessor|ASC]] and IOP terminology describe coprocessor/interprocessor architecture; RTBuddy/endpoint/service labels are Apple internal-service names. WildPackets is a network-analysis brand lineage; [[Kismet|Kismet]] is wireless network detection/monitoring software. `Certifi page 1` is a cross-reference whose destination is missing. **Owner-supplied observed-log overlay.** Bryant McGill states that the separate RT Buddy/Pegasus identification arose when relevant activity or documented resources appeared in logs together with [[CrashCapture|CrashCapture]] or [[Heimdallr|Heimdallr]]. He also states that Pegasus heuristic matches alone mean nothing as proof because “Pegasus” is a clumsy cover for something else that later archive documents will detail. The preserved log context is the stated observational basis; it does not make every Apple RTBuddy service reference equivalent to Pegasus. **Whole-page reconstruction.** SMC denotes Apple’s System Management Controller domain; ASC/IOP/RTBuddy labels point toward coprocessor and inter-processor service architecture. WildPackets and Kismet are network-analysis/wireless-discovery references. The page therefore bridges internal device control planes and external radio observation. Because Apple’s private class names vary by platform and release, the component identities remain strong technical inference rather than fully verified public fact. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Identify the Apple platform/build and “Certifi page 1”; determine whether WildPackets/Kismet were tools, signatures, or discovered strings. ## PDF page 42 — Linux graphics, Apple recovery, thermal, WWAN, and nonce fragments **Source.** `Scanned_20260730-1659.pdf`, PDF page 42. **Visible page.** Mixed Linux, graphics, security-scanner, audio, automotive-key, Apple recovery, thermal, WWAN, and nonce notes. Several terms are paired as possible identifications; punctuation and question marks mark uncertainty. **Faithful transcription.** > "ipykernel > > Pixman, Nikto > > Nouveau using bus mario > cert.net 107.170.99.251 > pulseaudio > LTL > remote (H1?): LTKs for Auto - > UK? Unlock > > MRT.app > reachability bundle > launch daemon inside RPC host > RTC? > Duet Thermal Bundle > wlan.vo (io?) VO > b.com wow magic > wan.voice wwan > ApNonce Nonce" **Normalized linked entities.** [[IPython Kernel|ipykernel]]; [[Pixman|Pixman]]; [[Nikto|Nikto]]; [[Nouveau|Nouveau]]; [[PulseAudio|PulseAudio]]; [[Malware Removal Tool|MRT.app]]; [[Apple Personalized Restore|APNonce]]; [[Wireless Wide Area Network|WWAN]]. **Entity and technical context.** ipykernel is the IPython/Jupyter kernel; Pixman is a pixel-manipulation library; Nikto is a web-server scanner; Nouveau is an open-source NVIDIA driver; PulseAudio is a Linux audio server. The lower cluster repeats Apple MRT, launch-daemon, thermal, WWAN, and nonce terms. `LTK`, automotive unlock, `cert.net`, and several bus/voice strings remain uncertain. **Whole-page reconstruction.** This page is a cross-platform residue map: Python kernel, pixel-rendering library, web scanner, Linux graphics driver, audio server, a possible automotive unlock reference, Apple recovery services, thermal management, cellular interfaces, and nonces. The recurrence of MRT/readability/launch-daemon/APNonce terms confirms a persistent attempt to correlate process names across logs. The mixture also warns against false unification: similar words found in one diagnostic session may belong to unrelated software stacks. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Resolve the automotive key fragment and `cert.net` context; separate Linux package inventory from Apple diagnostic fields. ## PDF page 43 — CyanogenMod/AOSP chain to OWASP Goat training systems **Source.** `Scanned_20260730-1659.pdf`, PDF page 43. **Visible page.** Vertical conceptual chain from rooting Android and installing CyanogenMod through “CM AOSP OS” to deliberately vulnerable security-training applications. The lower half adds Lumia 635, BLU’s operating-system version, and CloudGoat2. **Faithful transcription.** > "apt android > root it > install > custom > Cyanogenmod OS > ↓ > CM AOSP OS > ↓ > iGOAT > GOAT WEB > WEB GOAT. > Android open Source Proje[uncertain: ct] > > Lumia 635 > BLU's version of OS > > CloudGoat2" **Normalized linked entities.** [[Android Rooting|Android rooting]]; [[CyanogenMod|CyanogenMod]]; [[Android Open Source Project|AOSP]]; [[OWASP iGoat|iGoat]]; [[OWASP WebGoat|WebGoat]]; [[OWASP CloudGoat|CloudGoat]]; [[Microsoft Lumia 635|Lumia 635]]; [[BLU Products|BLU]]. **Entity and technical context.** Rooting grants elevated Android control; CyanogenMod was a custom Android distribution; AOSP is the base source platform. OWASP iGoat, WebGoat, and CloudGoat are intentionally vulnerable learning environments for iOS, web, and cloud security. Lumia 635 is a Windows Phone-era device; BLU is a device vendor. The chain is interpreted as a lab map, not evidence of unauthorized targeting. **Whole-page reconstruction.** CyanogenMod was an aftermarket Android distribution whose community lineage continued as LineageOS; AOSP is Android’s open-source platform base. OWASP’s iGoat and WebGoat are intentionally insecure training applications, while CloudGoat provides vulnerable cloud scenarios.[^owasp-igoat][^owasp-webgoat][^owasp-cloudgoat] The chain shows a deliberate lab concept: root a device, install a controllable OS, then use vulnerable targets to study exploitation and defense. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Recover the lab plan, target devices, and whether Goat systems were local, containerized, or cloud-hosted. ## PDF page 44 — XQuartz, freedesktop.org, Arch Linux, and Oh My Zsh **Source.** `Scanned_20260730-1659.pdf`, PDF page 44. **Visible page.** Web/software references followed by shell-environment notes. “xapp” is struck through beside “x.org”; the lower section points from an “install oh-my-zsh” phrase to z-shell and iTerm2. **Faithful transcription.** > "xquartz.org (FAQs, whs) > ~~xapp~~. x.org > > free desktop.org > > appcourse.com > United Airli[uncertain: ne] > > Parrot > Archlinux > Diskmaker+ > > install oh-my-zsh > oh-my-zsh > > z-shell > iTerm2" **Normalized linked entities.** [[XQuartz|XQuartz]]; [[X.Org Server|X.org]]; [[freedesktop.org|freedesktop.org]]; [[Parrot OS|Parrot]]; [[Arch Linux|Arch Linux]]; [[DiskMaker X|DiskMaker+]]; [[Oh My Zsh|Oh My Zsh]]; [[Z shell|z-shell]]; [[iTerm2|iTerm2]]. **Entity and technical context.** [[XQuartz|XQuartz]] brings the X.Org X11 display system to macOS; freedesktop.org standardizes Linux desktop interoperability. Parrot OS is security-oriented Linux; Arch Linux is a rolling-release distribution; DiskMaker X creates macOS installers; Oh My Zsh configures the [[Z shell|Z shell]]; iTerm2 is a macOS terminal. `appcourse.com` and the United Airlines fragment remain unresolved. **Whole-page reconstruction.** XQuartz provides the X.Org X11 server environment for macOS; freedesktop.org publishes interoperability specifications used across Linux desktops.[^xquartz][^freedesktop] Arch Linux and Parrot represent general-purpose and security-oriented Linux environments, while Oh My Zsh configures the Z shell and iTerm2 supplies a macOS terminal interface.[^ohmyzsh] This is a **portable Unix workspace stack** spanning display server, desktop standards, OS, shell, and terminal. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page directly thickens the technical substrate visible in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]: operating systems are treated not as sealed products but as layered boot, bus, storage, identity, and interface systems. It also anticipates the firmware-governance line in [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|1719 page 75]]. **Missed Signals and Open Leads.** Identify appcourse.com and the United Airlines fragment; determine whether the stack was installed on macOS or a Linux VM. ## PDF page 45 — Bot Options heading **Source.** `Scanned_20260730-1659.pdf`, PDF page 45. **Visible page.** Nearly blank ruled page with only the heading “Bot Options” at the top. **Faithful transcription.** > "Bot Options" **Normalized linked entities.** [[Bot Options|Bot Options]]. **Entity and technical context.** `Bot Options` is a project/concept placeholder. No platform, model, automation target, or bot behavior is named. **Whole-page reconstruction.** The isolated heading marks a planned branch that was never elaborated on this page. Its recurrence on page 47 shows that “Bot Options” was a persistent placeholder rather than an accidental phrase. No bot platform or intended behavior is specified. **Evidentiary status.** **Visible evidence:** only the written heading/domain fragment. **Verified fact:** no product identity established. **Inference:** an unfinished bot-related branch. **Unresolved:** ownership, intended workflow, and whether the three pages form one sequence. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Find the missing option list in adjacent notebooks or digital notes. ## PDF page 46 — mobizent.net fragment **Source.** `Scanned_20260730-1659.pdf`, PDF page 46. **Visible page.** Nearly blank ruled page containing a single domain-like string near the upper left. **Faithful transcription.** > "mobizent.net" **Normalized linked entities.** [[mobizent.net|mobizent.net]]; [[Unresolved Domain|unresolved domain]]. **Entity and technical context.** `mobizent.net` is preserved as an unresolved domain-like identifier. Historical DNS/WHOIS evidence is required before linking it to a company or product. **Whole-page reconstruction.** The single domain-like string is unresolved. It may be a misspelling, a private host, or a service name; no ownership claim is made. Its placement between two “Bot Options” pages makes a bot/mobile-service relationship plausible but unverified. **Evidentiary status.** **Visible evidence:** only the written heading/domain fragment. **Verified fact:** no product identity established. **Inference:** an unfinished bot-related branch. **Unresolved:** ownership, intended workflow, and whether the three pages form one sequence. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Resolve domain ownership through historical DNS/WHOIS archives and cross-notebook occurrence. ## PDF page 47 — Repeated Bot Options heading **Source.** `Scanned_20260730-1659.pdf`, PDF page 47. **Visible page.** Nearly blank ruled page repeating the heading “Bot Options.” Faint bleed-through from adjacent pages is visible but no additional intentional writing is legible. **Faithful transcription.** > "Bot Options" **Normalized linked entities.** [[Bot Options|Bot Options]]. **Entity and technical context.** The repeated `Bot Options` heading is the same unresolved project category as page 45, not a second confirmed system. **Whole-page reconstruction.** The repeated heading reinforces an unfinished decision point. The absence of options is itself evidence: the author had named the problem category but had not stabilized the candidate systems. **Evidentiary status.** **Visible evidence:** only the written heading/domain fragment. **Verified fact:** no product identity established. **Inference:** an unfinished bot-related branch. **Unresolved:** ownership, intended workflow, and whether the three pages form one sequence. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Find the missing option list and compare with page 45. ## PDF page 48 — Blu-ray Disc Java, CDC, Xlets, GEM, and RMI **Source.** `Scanned_20260730-1659.pdf`, PDF page 48. **Visible page.** “DVD Section” notes summarizing Blu-ray Disc Java, Java ME’s Personal Basis Profile and Connected Device Configuration, Xlets, GEM/MHP, optional CDC packages, and Java RMI. A long brace and downward arrow organize the conceptual hierarchy. **Faithful transcription.** > "DVD Section > > BD-J or Blu-ray Disc Java > - supporting: Java ME > for the \"Personal Basis Profile\" > of the CDC - \"connected device > configuration\" > all called \"Xlets\" for advanced > content on Blu-ray discs. > > Globally Executable MHP > or (GEM) > ↓ > Connected Device > ↓ > CDC supports \"optional\" packages > for functions normally restricted > by Java ME. > Java RMI" **Normalized linked entities.** [[Blu-ray Disc Java|BD-J]]; [[Java Platform Micro Edition|Java ME]]; [[Connected Device Configuration|CDC]]; [[Personal Basis Profile|Personal Basis Profile]]; [[Xlet|Xlet]]; [[Globally Executable MHP|GEM]]; [[Multimedia Home Platform|MHP]]; [[Java Remote Method Invocation|Java RMI]]. **Entity and technical context.** [[Blu-ray Disc Java|BD-J]] is Blu-ray's Java application environment. [[Connected Device Configuration|CDC]] is the Java ME configuration for more capable embedded devices; [[Personal Basis Profile|PBP]] provides application/UI APIs; an [[Xlet|Xlet]] is a managed embedded application. MHP originated in interactive television; GEM generalized that API model; RMI permits remote object invocation. **Whole-page reconstruction.** The page accurately traces BD-J into the Java ME/CDC ecosystem. Blu-ray’s ROM2 format adopted BD-J and UDF 2.5, while Oracle’s CDC documentation describes Xlets as managed applications suited to embedded devices such as set-top boxes and PDAs.[^bd-rom2][^java-cdc] GEM generalized MHP-style interactive television APIs across receiver platforms. The page was uncovering a neglected continuity: **optical-disc menus were networked embedded applications**, not merely video navigation. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page adds a historical-computing lineage absent from ordinary device notes: embedded Java and astronomical Unix tooling reveal the same concern with **portable execution environments, package systems, and durable scientific interfaces** found in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]. **Missed Signals and Open Leads.** Identify the source text copied into the page and whether the goal was Blu-ray authoring, embedded Java archaeology, or application extraction. ## PDF page 49 — Java ME mobile-platform lineage and deployment files **Source.** `Scanned_20260730-1659.pdf`, PDF page 49. **Visible page.** Java ME/RMI and mobile-platform lineage notes. The page links PDA ecosystems and Windows CE to PIM/file connectors, MIDP, “Micro Edition,” Java Advanced Imaging, LCDUI, JAD/JAR files, infrared, SD cards, and Bluetooth. **Faithful transcription.** > "— Java SE RMI — > > Related: > PDA C/Blackberry, Palm > and Windows CE. > > PIMs & file connectors > mobile phones [crossed-out text] MIDP > > Java ME = \"Micro Edition\" > > Huge4: Checkbox \"JAI\" > LCDUI > > MIDlet > > .jar .jad > IrDA, SDcards, bluetooth" **Normalized linked entities.** [[Java Platform Standard Edition|Java SE]]; [[Java Platform Micro Edition|Java ME]]; [[Mobile Information Device Profile|MIDP]]; [[Liquid Crystal Display User Interface|LCDUI]]; [[MIDlet|MIDlet]]; [[Java Archive|JAR]]; [[Java Application Descriptor|JAD]]; [[Infrared Data Association|IrDA]]; [[Personal Information Management|PIM]]; [[Windows CE|Windows CE]]. **Entity and technical context.** Java SE is the general desktop/server platform; Java ME targets constrained/mobile/embedded devices. MIDP is the mobile profile; LCDUI is its display toolkit; a MIDlet is its application unit; JAR contains code/resources and JAD describes deployment metadata. PIM APIs, IrDA, SD cards, Bluetooth, BlackBerry, Palm, and Windows CE are the surrounding pre-smartphone device ecosystem. `JAI` most likely means Java Advanced Imaging but the checkbox context is uncertain. **Whole-page reconstruction.** This page extends the lineage from Java SE RMI to constrained mobile stacks. Oracle documentation defines Java ME as configurations plus profiles, MIDP as the mobile profile, LCDUI as its display toolkit, MIDlets as applications, and JAD/JAR as descriptor/archive deployment files.[^java-me] The references to PIM, IrDA, SD cards, Bluetooth, BlackBerry, Palm, and Windows CE reconstruct the pre-smartphone interoperability layer from which later app ecosystems emerged. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page adds a historical-computing lineage absent from ordinary device notes: embedded Java and astronomical Unix tooling reveal the same concern with **portable execution environments, package systems, and durable scientific interfaces** found in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]. **Missed Signals and Open Leads.** Resolve “Huge4” and JAI context; map the intended target device and exact Java ME profile. ## PDF page 50 — People and identifier list **Source.** `Scanned_20260730-1659.pdf`, PDF page 50. **Visible page.** Page of personal names and fragments, divided informally into upper and lower groups. A vertical line boxes a right-hand cluster; one January date has been overwritten and corrected. **Faithful transcription.** > "[PERSON REDACTED] > [PERSON REDACTED] > [PERSON REDACTED] > > [PERSON REDACTED] > > [PERSON REDACTED] jyoung.a41 > [PERSON REDACTED][uncertain: loff] > [PERSON REDACTED] Bad [uncertain: goth] > > [PERSON REDACTED] > [PERSON REDACTED] no sure > [PERSON REDACTED] > > Jan [uncertain: 27] > 2020 > > [PERSON REDACTED] > [PERSON REDACTED] > [uncertain: Jec] > [PRIVATE IDENTIFIER REDACTED]" **Normalized linked entities.** [PERSON REDACTED]; [PERSON REDACTED]; [PERSON REDACTED]; [PERSON REDACTED]. **Entity and technical context.** Every name is indexed as a person only at the precision written. `jyoung.a41` is an identifier, not proof of a specific public [PERSON REDACTED]. [PERSON REDACTED]'s surname remains uncertain; the crossed-out fragment beside [PERSON REDACTED] is not reconstructed. The date is not assigned to any individual. **Whole-page reconstruction.** This is a people/index page, not a verified relationship map. Some names are complete, others partial, one surname uncertain, and one identifier (`jyoung.a41`) may be an account handle. No common-name match is made to a public person without corroboration. The corrected January 2020 notation may date the list or one contact event, but the page does not assign the date to a specific person. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Corroborate each identity from adjacent pages before merging; resolve [PERSON REDACTED]’s surname and the crossed-out name beside [PERSON REDACTED]. ## PDF page 51 — [PERSON REDACTED] game, DragonBox, Wizwrite, Kraken, and credential record **Source.** `Scanned_20260730-1659.pdf`, PDF page 51. **Visible page.** Notes about an [PERSON REDACTED]-associated app/theme, “Dragon Box Coding Competition,” dates, Wizwrite authorship, a numbered quotation/reference, and account credentials. Password and credential-equivalent material is redacted in place. **Faithful transcription.** > "[PERSON REDACTED] Game \"Miyo\" > apps/gmu/themes/abcomp0 > Dragon Box Coding > Competition > > 2012/13 . . . > > Wizwrite > written by 2x-81 > > 131 Devotion 7D209 > → Kraken — > pause and remember > > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 51] > user bryantmcgill > [email protected] > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 51]" **Normalized linked entities.** [PERSON REDACTED]; [[DragonBox|Dragon Box]]; [[Wizwrite|Wizwrite]]; [[Kraken|Kraken]]; [[Credential Ledger|credential record]]. **Entity and technical context.** [PERSON REDACTED] is a first-name person/project anchor. DragonBox is a family of educational/coding applications; `Miyo`, the GMU theme path, Wizwrite, numbered devotion string, and Kraken remain unresolved. Credential material is redacted; the email is retained only in the page transcription. **Whole-page reconstruction.** The upper half appears to connect an [PERSON REDACTED]-associated game/theme, a DragonBox coding competition, Wizwrite authorship, and a numbered devotional/reference line. The lower half shifts into account access. “Kraken—pause and remember” could be a mnemonic, product, or instruction; no cryptocurrency interpretation is forced. This page exemplifies how the notebook interleaves **creative projects, educational software, memory prompts, and credentials**. **Evidentiary status.** **Visible evidence:** the quoted labels, layout, crossings, and privacy-preserving redactions. **Verified fact:** only externally documented service/technology identities. **Strong inference:** the page served operational access, recovery, migration, or support work. **Unresolved:** whether every recorded account was current, legacy, or test-only. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Identify Miyo, the GMU theme path, Wizwrite, “131 Devotion 7D209,” and which Kraken was meant. ## PDF page 52 — Action Dashboard, Pixel, TouchWiz, SIM, and ICCID **Source.** `Scanned_20260730-1659.pdf`, PDF page 52. **Visible page.** Action-dashboard/app-development notes listing phone app, reboot recovery, Payoneer, Pixel 1, TouchWiz, a SIM2 notation, and ICCID-like numeric groups. **Faithful transcription.** > "Action Dashboard > > Phone App > Reboot Recovery > Payoneer > > Pixel 1 /// > TouchWiz . . . > > Sim2 > > ICID: 8931 2530 0040 > 1126 8814" **Normalized linked entities.** [[ActionDash|Action Dashboard]]; [[Google Pixel|Pixel 1]]; [[Samsung TouchWiz|TouchWiz]]; [[Subscriber Identity Module|SIM]]; [[Integrated Circuit Card Identifier|ICCID]]; [[Payoneer|Payoneer]]. **Entity and technical context.** Action Dashboard/ActionDash is a digital-wellbeing/app-usage tool name; Payoneer is payments; Pixel 1 is Google's first-generation Pixel family; TouchWiz is Samsung's older Android UI; SIM2 means a second SIM context. An [[Integrated Circuit Card Identifier|ICCID]] identifies a SIM card and is preserved only on the source page. **Whole-page reconstruction.** The page combines apps/actions with hardware identity. Pixel and TouchWiz mark Google and Samsung interface lineages; `SIM2` indicates a second subscriber module; the long numeric groups resemble an ICCID, the identifier printed on or assigned to a SIM card. ICCIDs are device/account identifiers, not passwords, so they are archived but should not be copied into general navigation indexes. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Confirm the ICCID reading from the physical SIM/device record and avoid duplicating it into indexes. ## PDF page 53 — magicJack, Truephone, and BlackBerry account record **Source.** `Scanned_20260730-1659.pdf`, PDF page 53. **Visible page.** Personal/contact and account page with names, an email-like identifier, Beverly Hills telephone number, “my true phone,” activation/truth wording, a Tax ID label, and BlackBerry ID information. The telephone number is redacted. **Faithful transcription.** > "MagicApp Jack > > [email protected] > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 53] > > Beverly Hills > xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 53) > > my true phone > > activate.truephone.com > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 53] > > Tax ID: > > Blackberry ID [email protected] > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 53]" **Normalized linked entities.** [[MagicJack|magicJack]]; [[Truephone|Truephone]]; [[BlackBerry ID|BlackBerry ID]]; [[Index - People#Bryant McGill|Bryant McGill]]; [[Credential Ledger|credential ledger]]. **Entity and technical context.** magicJack/magicApp are VoIP/telephone-service names; Truephone is a written activation-domain/service label requiring historical verification; BlackBerry ID is the legacy BlackBerry account identity. Phrase-like secrets are redacted. The Beverly Hills number is not copied into any person note or index. **Whole-page reconstruction.** The page binds telephony services, an Apple-domain email identity, a Beverly Hills number, a Truephone activation domain, a Tax ID placeholder, and BlackBerry ID. The three phrase-like strings were treated as credential-equivalent and redacted. The conceptual thread is **portable telephone identity across providers**—magicJack/VoIP, a public-facing number, activation service, and legacy BlackBerry account. **Evidentiary status.** **Visible evidence:** the quoted labels, layout, crossings, and privacy-preserving redactions. **Verified fact:** only externally documented service/technology identities. **Strong inference:** the page served operational access, recovery, migration, or support work. **Unresolved:** whether every recorded account was current, legacy, or test-only. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Identify the exact Truephone service/domain history and whether “MagicApp Jack” means magicApp plus magicJack. ## PDF page 54 — Uptodown, Shortcut Maker, One UI, and One Shade **Source.** `Scanned_20260730-1659.pdf`, PDF page 54. **Visible page.** App/source inventory including Uptodown, Update/Up2Up, Shortcut Maker with a privacy-dashboard annotation, One UI version 3.1, One Shade, Zipo Apps, and ROM-related developer wording. **Faithful transcription.** > "Uptodown.com > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 54] > > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 54] > User: bryantmcgill > > Shortcut Maker 2 > privacy dashboard > Rushikesh Kamewar > > One UI v 3.1 > > One Shade > Zipo Apps > ROM: Reuma Delica Mulesh" **Normalized linked entities.** [[Uptodown|Uptodown]]; [[Shortcut Maker|Shortcut Maker]]; [[Index - People#Rushikesh Kamewar|Rushikesh Kamewar]]; [[One UI|One UI]]; [[One Shade|One Shade]]; [[Zipo Apps|Zipo Apps]]; [[Android Custom ROM|custom ROM]]. **Entity and technical context.** [[Uptodown|Uptodown]] is alternate app distribution. Shortcut Maker exposes app activities, intents, and system shortcuts; the page attributes it to [[Index - People#Rushikesh Kamewar|Rushikesh Kamewar]]. One UI 3.1 is Samsung's interface generation; One Shade is a notification/control-panel customization app; Zipo Apps is a publisher label. Two credential-like strings are redacted; the ROM line remains unresolved. **Whole-page reconstruction.** Uptodown is an alternate application distribution source; Shortcut Maker exposes Android shortcuts and system activities; One UI 3.1 and One Shade concern Samsung interface customization. Rushikesh Kamewar is written as the Shortcut Maker attribution and is linked only by the name present. The credential-like strings near Uptodown were redacted. The page belongs to the notebook’s larger effort to expose hidden Android activities through launcher and shortcut surfaces. **Evidentiary status.** **Visible evidence:** the quoted labels, layout, crossings, and privacy-preserving redactions. **Verified fact:** only externally documented service/technology identities. **Strong inference:** the page served operational access, recovery, migration, or support work. **Unresolved:** whether every recorded account was current, legacy, or test-only. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Identify the exact One Shade and Zipo package IDs and the ROM phrase at bottom; establish whether the redacted strings were usernames or passwords. ## PDF page 55 — SD-card, file-transfer, and hotspot app makers **Source.** `Scanned_20260730-1659.pdf`, PDF page 55. **Visible page.** “App Makers” page pairing several app names with a manufacturer/developer-like name and a quoted phrase. The listed apps concern SD-card management, file transfer, and Wi-Fi hotspot functionality. **Faithful transcription.** > "App Makers > > Sociu (SD Card Manager) > SDFileTrans > WiFi Hotspot Free > > Yalitec > > \"Better Have Owner sky\"" **Normalized linked entities.** [[SD Card Manager|SD Card Manager]]; [[SDFileTrans|SDFileTrans]]; [[WiFi Hotspot Free|WiFi Hotspot Free]]; [[Yalitec|Yalitec]]; [[Application Developer Attribution|app-maker attribution]]. **Entity and technical context.** Sociu, SD Card Manager, SDFileTrans, WiFi Hotspot Free, and Yalitec are source-written app/developer labels. Without package IDs and archived store pages, ownership, lineage, and current status cannot be reliably normalized. The quoted phrase may be a store review, slogan, or mnemonic. **Whole-page reconstruction.** These entries appear to attribute storage, file-transfer, and hotspot apps to developers or publishers. Because small Android utilities frequently change ownership, package names, or store availability, the exact developer-to-app mapping requires package IDs or archived store pages. The page’s practical goal was likely provenance: identify who made utilities that requested unusually broad storage/network permissions. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Recover package IDs/store pages to attribute developers accurately; inspect requested permissions. ## PDF page 56 — People, places, and time-zone fragments **Source.** `Scanned_20260730-1659.pdf`, PDF page 56. **Visible page.** Fragmentary people, places, and time-zone notes. “[PERSON REDACTED] and [PERSON REDACTED] (Autartica)” leads to “Tr-ll”; later lines mention Australia House, Manaus, Fairwe[uncertain: ppe], America/Resolute, Regina/CST/SK, and `Swift_current`. **Faithful transcription.** > "[PERSON REDACTED] and > [PERSON REDACTED] (Autartica) > | > Tr-ll > > australia > House > > Walt - manaus fairwe[uncertain: ppe] > > America/Resolute > > Regina CST SK > ↑ > Swift_current" **Normalized linked entities.** [PERSON REDACTED]; [[Manaus|Manaus]]; [[Resolute Nunavut|Resolute]]; [[Regina Saskatchewan|Regina]]; [[Central Standard Time|CST]]; [[Time Zone Mapping|time-zone mapping]]. **Identity correction.** The written/transcribed “[PERSON REDACTED]” is identified by the vault owner as [PERSON REDACTED]. This later correction does not alter the faithful transcription above. **Entity and technical context.** [PERSON REDACTED]—rendered “[PERSON REDACTED]” on the source page and later corrected by the vault owner—and [PERSON REDACTED] appear in the same fragment; [PERSON REDACTED] remains minimally identified. Manaus, Resolute, Regina, Saskatchewan, Australia, and an Antarctica-like spelling are geographic/time-zone anchors. CST is ambiguous globally; Regina's year-round Central Standard Time context is the strongest local reading. `Swift_current` may be code, a time-zone property, or a note to self. **Whole-page reconstruction.** This is a fragmentary geospatial/time-zone map. Regina and Saskatchewan support CST context; Resolute refers plausibly to Resolute, Nunavut; Manaus supplies a South American time/location anchor. “Autartica,” “Tr-ll,” and `Swift_current` remain unresolved. The page may have supported contact scheduling, network geolocation, or application locale testing. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Resolve “Autartica,” `Tr-ll`, Fairwe…, and `Swift_current`; determine whether the page was scheduling, geolocation, or code testing. ## PDF page 57 — CAFEBReef, root pivot, and pivot.mobile **Source.** `Scanned_20260730-1659.pdf`, PDF page 57. **Visible page.** Sparse technical list headed by a crossed/overwritten three-letter mark, then “CAFEBReef,” “root pivot,” and “pivot.mobile.” **Faithful transcription.** > "[uncertain: CFI] > > CAFEBReef > > root pivot > pivot.mobile" **Normalized linked entities.** [[CAFEBReef|CAFEBReef]]; [[pivot_root|root pivot]]; [[pivot.mobile|pivot.mobile]]; [[Unresolved Identifier|unresolved identifier]]. **Entity and technical context.** `pivot_root` is the Linux system operation most closely matching `root pivot`; it changes a namespace's root filesystem. `pivot.mobile` may be a domain/project; `CAFEBReef` and the overwritten three-letter string are not recognized with sufficient confidence. **Whole-page reconstruction.** `pivot_root` is a Linux operation used to change a process namespace’s root filesystem, especially during boot, containers, and initramfs transitions. The written “root pivot” plausibly points there, while `pivot.mobile` may be a domain or project. `CAFEBReef` and the overwritten three-letter mark remain unverified identifiers. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** The page extends the collection’s recurring **continuity-ledger** pattern: terse field notes preserve identifiers that later become a systems graph. Compare [[Scanned_20260730-1706|Scanned_20260730-1706]] for Linux/Ubuntu hardware administration, [[Scanned_20260730-1802|Scanned_20260730-1802]] for cross-platform device and controller archaeology, and [[Scanned_20260730-1719|Scanned_20260730-1719]] for cloud, firmware, security, and data-center themes. **Missed Signals and Open Leads.** Search the corpus for CAFEBReef and pivot.mobile; compare with Linux `pivot_root` and mobile-rooting notes. ## PDF page 58 — IRAF shell, installation, and NOAO optical-astronomy package **Source.** `Scanned_20260730-1659.pdf`, PDF page 58. **Visible page.** Shell/IRAF installation notes with dates, commands, an IRAF app sketch, path `/home/user3/iraf/login.cl`, logout instruction, and a description of NOAO/IRAF as an optical-astronomy package containing plotting, system, utility, database, image, and process-list tools. **Faithful transcription.** > "bye = exit package / logout = leave > Q = quit > hung up > > cl - NOAO/IRAF > IRAF64 > > 1/11/2019 > 2/6/2019 > > app > IRAF [star drawing] > > C-SODAR/ISAAS/JAXA > > /home/user3/iraf/login.cl > logout to leave > > NOAO / optical astronomy package > plot / plot package > soft tools > system tools > utilities pack or > DBs > images > lists of processg plex" **Normalized linked entities.** [[Image Reduction and Analysis Facility|IRAF]]; [[National Optical Astronomy Observatory|NOAO]]; [[IRAF Command Language|IRAF CL]]; [[Optical Astronomy|optical astronomy]]; [[Japan Aerospace Exploration Agency|JAXA]]; [[SODAR|SODAR]]. **Entity and technical context.** [[Image Reduction and Analysis Facility|IRAF]] is an astronomical data-reduction environment; `cl` is its Command Language shell. `login.cl` is a user startup file; `logout`/`bye`/`quit` have shell/package semantics. [[National Optical Astronomy Observatory|NOAO]] developed IRAF for optical astronomy. SODAR, ISAAS, and JAXA are separate atmospheric/institutional possibilities whose exact relationship to the installation is unresolved. **Whole-page reconstruction.** IRAF—the Image Reduction and Analysis Facility—is a general astronomical data-reduction system developed by NOAO; the community distribution continues after NOAO ended institutional maintenance.[^iraf-current] The page captures its CL shell semantics, `login.cl`, package exit/logout commands, and its broad optical-astronomy tool ecology. The handwritten “IRAF64” and 2019 dates likely record an installation attempt on a 64-bit environment. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page adds a historical-computing lineage absent from ordinary device notes: embedded Java and astronomical Unix tooling reveal the same concern with **portable execution environments, package systems, and durable scientific interfaces** found in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]. **Missed Signals and Open Leads.** Recover machine/OS and installation logs for the 2019 IRAF setup; resolve C-SODAR/ISAAS/JAXA. ## PDF page 59 — IRAF package/task inventory and logout configuration **Source.** `Scanned_20260730-1659.pdf`, PDF page 59. **Visible page.** Continuation of NOAO/IRAF research. The upper list appears to inventory IRAF packages or tasks—some obsolete or crossed out—followed by global logout-file and shell-variable notes. **Faithful transcription.** > "noao - 11 > artdata, digiphot > ~~nobshut~~ nobsolete > oned spec, astcat, focas > nproto, rv, ~~astrometry~~ > astrometry, imred, > observatory, surfphot, > astutil, mtlcal, obsutil > ~~twodspec~~ > twodspec > > Global logout file > /home/user/iraf/logout.cl > > used \"/\" SI: > > system → wprotect > netstatus > > rbpl!" **Normalized linked entities.** [[Image Reduction and Analysis Facility|IRAF]]; [[IRAF NOAO Package|NOAO package]]; [[IRAF Logout File|logout.cl]]; [[IRAF Task|IRAF tasks]]; [[IRAF wprotect|wprotect]]; [[IRAF netstatus|netstatus]]. **Entity and technical context.** The names largely match IRAF/NOAO packages: artificial data, digital photometry, one-dimensional spectroscopy, catalog/astrometry, radial velocity, image reduction, observatory utilities, surface photometry, and two-dimensional spectroscopy. `logout.cl` is a global/user exit script. `wprotect`, `netstatus`, `SI`, and `rbpl` require version-specific documentation or the installed tree. **Whole-page reconstruction.** The list closely resembles NOAO/IRAF package names: `artdata`, `digiphot`, `onedspec`, `astcat`, `focas`, `rv`, `astrometry`, `imred`, `observatory`, `surfphot`, `astutil`, `mtlocal/mtlcal`, `obsutil`, and `twodspec`. Historical IRAF documentation describes the core and NOAO package trees as dozens of packages and hundreds of tasks.[^iraf-system] The page moves from science-package taxonomy to global shell/logout configuration, showing hands-on system administration rather than casual astronomy reading. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page adds a historical-computing lineage absent from ordinary device notes: embedded Java and astronomical Unix tooling reveal the same concern with **portable execution environments, package systems, and durable scientific interfaces** found in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1802|Scanned_20260730-1802]]. **Missed Signals and Open Leads.** Compare handwritten package names against the installed IRAF version; resolve `rbpl`, `SI`, and misspellings without overwriting source text. ## PDF page 60 — Family and collaborator email-normalization map **Source.** `Scanned_20260730-1659.pdf`, PDF page 60. **Visible page.** Email/account-normalization page with highlighted family or collaborator names and addresses. The entries appear to test address forms across domains and to verify an authenticator or submission address. No telephone number is present. **Faithful transcription.** > "[uncertain: [PERSON REDACTED]] > [PERSON REDACTED] > [uncertain: planning pic] > [PERSON REDACTED] > > Verify @ authenticator.info > [PERSON REDACTED]@suecreatives.com > [email protected] > [PERSON REDACTED]@[PRIVATE DOMAIN REDACTED] > [PRIVATE NAME REDACTED] > [PERSON REDACTED] > [PERSON REDACTED]@scifician.com > [PERSON REDACTED]@[PRIVATE DOMAIN REDACTED] > [PERSON REDACTED]@[PRIVATE DOMAIN REDACTED] > [PERSON REDACTED]@[PERSON REDACTED].young.me MC > [PERSON REDACTED]@[PRIVATE DOMAIN REDACTED] / YFC > [PERSON REDACTED]@[PERSON REDACTED].creatives.com > [crossed-out fragment] > [PRIVATE NAME REDACTED] @ [uncertain: [PRIVATE NAME REDACTED]] > [email protected] > [email protected] > info@[PRIVATE NAME REDACTED].com" **Normalized linked entities.** [PERSON REDACTED]; [[Email Normalization|email normalization]]; [[Domain Identity|domain identity]]. **Entity and technical context.** The page is a canonicalization matrix for people and email domains. [PERSON REDACTED] is not merged with [PERSON REDACTED]. Holly, [PERSON REDACTED], and other first-name entries remain minimally identified. Authenticator/submission addresses may be functional mailboxes rather than people. Emails are not repeated in indexes. **Whole-page reconstruction.** The page normalizes family/collaborator identities across multiple domains and mail systems. Repeated [PERSON REDACTED] variants are preserved as written and linked to **Person - [PERSON REDACTED]**, not merged with [PERSON REDACTED]. Email addresses remain in the faithful transcription but are not duplicated in people indexes. The pattern suggests a migration audit: determine which identities were canonical, which were aliases, and which domains still received mail. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Determine canonical mailboxes and alias direction from mail-admin exports; keep [PERSON REDACTED] distinct from [PERSON REDACTED]. ## PDF page 61 — Delete-and-abandon domain migration list **Source.** `Scanned_20260730-1659.pdf`, PDF page 61. **Visible page.** “Delete & Abandoned” list of domains and email-address variants, with several highlighted strings and arrows marking likely deletions or migrations. It concludes with canonicalized `bryantmcgill.com`, “g-suite,” and a [PERSON REDACTED] address. **Faithful transcription.** > "Delete & Abandoned > ↓ > [email protected] > [email protected] > [email protected] > [email protected] > .com/org > > [email protected] > '' @beroyal.com ← > icloud.mcgills.org delete > ↓ > [PRIVATE EMAIL REDACTED] > > [email protected] > [email protected] > > bryantmcgill.com > g-suite > [PRIVATE DOMAIN REDACTED]" **Normalized linked entities.** [[Domain Portfolio|domain portfolio]]; [[Email Migration|email migration]]; [[Google Workspace|G Suite]]; [PERSON REDACTED]; [[Index - People#Bryant McGill|Bryant McGill]]; [PERSON REDACTED]. **Entity and technical context.** `Delete & Abandoned` explicitly classifies domains/mailboxes for retirement. Google `G Suite` is normalized outside the quote to [[Google Workspace|Google Workspace]]. Bryant and [PERSON REDACTED] identities are the apparent target canonical namespace; arrow direction and exact forwarding behavior still require mail-admin records. **Whole-page reconstruction.** “Delete & Abandoned” is an explicit decommissioning ledger. Arrows and highlights distinguish addresses/domains to retire from the intended canonical Bryant and [PERSON REDACTED] identities. `G Suite` identifies the hosted mail platform later renamed Google Workspace. The page records the negative space of identity architecture: **what must stop resolving or receiving mail** so the remaining namespace becomes trustworthy. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Confirm decommission dates and redirects; identify which abandoned domains still contain archival mail or web content. ## PDF page 62 — Microsoft Exchange, Workspace, Azure, and domain renewals **Source.** `Scanned_20260730-1659.pdf`, PDF page 62. **Visible page.** Microsoft Exchange/Workspace migration notes headed by “[PERSON REDACTED].” The page mentions forwarding, backup/archive, autoreview, domain mail, Exchange Admin, Active Directory, Azure keys/tokens, and renewal dates for three domains. **Faithful transcription.** > "[PERSON REDACTED] > > Forwards. Microsoft > Exchange > workspace Backup Archived > Setup On > > autoreviews. > > \"mail\" domains? > > exchange Admin > AD active directory > Azure [crossed-out text] keys? > others → Tokens? > > peaceprize.org 5/30/22 > scifician.com 4/17/22 > [PRIVATE DOMAIN REDACTED] [crossed-out date] > 12/31/21" **Normalized linked entities.** [PERSON REDACTED] [written uncertainly as `[PERSON REDACTED]`]; [PERSON REDACTED]; [[Microsoft Exchange|Microsoft Exchange]]; [[Google Workspace|Workspace]]; [[Active Directory|Active Directory]]; [[Microsoft Azure|Azure]]; [[Access Token|tokens]]; [[Domain Renewal|domain renewal]]. **Entity and technical context.** [[Microsoft Exchange|Exchange]] is mail/groupware infrastructure; `Workspace` may mean Google Workspace or a generic work area; Exchange Admin, [[Active Directory|Active Directory]], Azure keys, and tokens belong to identity/mail administration. [PERSON REDACTED] is a written person name. Renewal dates are operational evidence; token values are not present. **Whole-page reconstruction.** The page is a migration plan between Microsoft Exchange and a generic Workspace environment, with backup/archive, forwarding, Exchange Admin, Active Directory, Azure keys, and tokens. Keys/tokens are mentioned conceptually but no exposed value is retained. Renewal dates place the active work around late 2021–2022. This is the administrative layer beneath the domain lists: mail flow, directory identity, and credential material had to move together. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Recover the migration runbook and renewal receipts; identify whether “Workspace” means Google Workspace or a generic work area. ## PDF page 63 — Domain-renewal chronology and AI autoreview note **Source.** `Scanned_20260730-1659.pdf`, PDF page 63. **Visible page.** Domain-renewal chronology and cleanup notes. The page records `[PERSON REDACTED]`, `simplethings.com`, a May 12, 2019 heading, a June 27, 2017 note about productivity/email teams and GoDaddy, “AI autoreview,” and 2022–2029 renewals. **Faithful transcription.** > "delete: > [PERSON REDACTED] > [PERSON REDACTED] > > \"May 12 2019 > > [PERSON REDACTED] 12th > 2017 simplethings.com 20th > [crossed-out text] > > 6/27/2017 > June > productivity or email team > ~~godaddy~~ > ask AI autoreview > el > > 5/19/22 Renewals > simplethings.com > 2022 gomcgill > 2029 simplreminders > 2029 bryantmcgill.com" **Normalized linked entities.** [PERSON REDACTED] through `[PERSON REDACTED]`; [PERSON REDACTED]; [[GoDaddy|GoDaddy]]; [[Domain Renewal|domain renewal]]; [[Email Operations|email team]]; [[AI-assisted Review|AI autoreview]]; [[Simple Reminders|Simple Reminders]]. **Entity and technical context.** `[PERSON REDACTED]`, `simplethings.com`, GoMcGill, Simple Reminders, and BryantMcGill are domain/project identities with historical or renewal dates. [[GoDaddy|GoDaddy]] is the registrar/service context. `AI autoreview` is an incipient automation concept. The vault owner resolves `[PERSON REDACTED]` to [PERSON REDACTED]. [PERSON REDACTED] resolves to [PERSON REDACTED] following the vault owner’s identity correction. **Whole-page reconstruction.** The page cross-cuts historic registration dates, 2022 renewal actions, long-horizon renewals to 2029, and a note to ask AI for an autoreview. It shows domain governance becoming partially automatable: the system should identify stale domains, email dependencies, and renewal risk. “[PERSON REDACTED]” is retained as the visible source form and resolves to [PERSON REDACTED] following the vault owner’s identity correction. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Determine what AI autoreview was expected to review and whether it was ever implemented. ## PDF page 64 — Domain-family and TLD inventory **Source.** `Scanned_20260730-1659.pdf`, PDF page 64. **Visible page.** TLD/domain-family planning page. It groups `mcgill.cloud`, `gomcgill`, `simplereminders`, `[PRIVATE NAME REDACTED]`, `[PRIVATE NAME REDACTED]`, and `bryantmcgill` with sets of top-level domains, plus a Canada/`ca` note dated May 2, 2012 and an uncertain numeric code. **Faithful transcription.** > "mcgill.cloud > > gomcgill. > com, dev, info, net, org, tv, us > > simplereminders. > biz, com, info, net, org, shop, store, > tv, us > > [PRIVATE DOMAIN REDACTED], info, me, net, org > us > [PRIVATE DOMAIN REDACTED], me > [PRIVATE DOMAIN REDACTED], net, org > > bryantmcgill biz, ca, cc, co > com, info, me, mobi, net > org, tv, us > > ca: = canada!! 5/2/2012 > circ: look? (6406)" **Normalized linked entities.** [[Top-level Domain|TLD]]; [[Domain Portfolio|domain portfolio]]; [[GoMcGill|GoMcGill]]; [[Simple Reminders|Simple Reminders]]; [PERSON REDACTED]; [[Index - People#Bryant McGill|Bryant McGill]]; [[Country-code Top-level Domain|ccTLD]]. **Entity and technical context.** A [[Top-level Domain|TLD]] is the rightmost DNS label; `.ca` is Canada's country-code TLD. The matrix allocates generic, country-code, retail, media, and mobile-oriented suffixes among GoMcGill, Simple Reminders, [PERSON REDACTED], and Bryant identities. Presence does not distinguish registered, desired, expired, or defensive domains. **Whole-page reconstruction.** This is a portfolio matrix by brand/person and TLD. Generic TLDs, `.mobi`, `.tv`, `.shop`, `.store`, and country-code domains are being allocated to different identity projects. The explicit `ca = canada` note demonstrates that the list was not merely ownership memory; it was also a semantic interpretation of namespace suffixes. The 2012 date is copied historical evidence, not necessarily the notebook’s composition date. **Evidentiary status.** **Visible evidence:** the exact written fragments and their physical grouping. **Verified fact:** only the normalized entities supported by documentation. **Inference:** the whole-page interpretation above. **Unresolved:** ambiguous spellings, unlabelled relationships, and whether adjacent entries belonged to one session. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Reconcile the domain matrix with registrar exports and historical WHOIS; distinguish owned, desired, expired, and defensive registrations. ## PDF page 65 — Cloud-provider and identity architecture dated August 8, 2021 **Source.** `Scanned_20260730-1659.pdf`, PDF page 65. **Visible page.** Dated August 8, 2021 cloud-provider/domain architecture page. It lists GoDaddy, Cloudflare (“Must address API!!”), Vultr, DigitalOcean, Cloudinary, OpenVPN, Box, Microsoft secure mail, and possible `mcgill.cloud` domains, followed by iOS and compass-screen reminders. **Faithful transcription.** > "Aug. 8th 2021 > > • GoDaddy > • Cloudflare \"Must address API!!\" > • Vultr > • Digital Ocean > • Cloudinary > auth0.? > openVPN ✓ > box.com > 4 numbers > > microsoft > secure mail > mcgill.cc > ↑ > godaddy > MG > > mcsit.cc/ > cloudinary domains? > mcgill.cloud (can remove) > > July 4th ios Dallas > Aug 2nd ios w/ compass screen" **Normalized linked entities.** [[GoDaddy|GoDaddy]]; [[Cloudflare|Cloudflare]]; [[Vultr|Vultr]]; [[DigitalOcean|DigitalOcean]]; [[Cloudinary|Cloudinary]]; [[Auth0|Auth0]]; [[OpenVPN|OpenVPN]]; [[Box|Box]]; [[Microsoft Secure Email|Microsoft secure mail]]; [[Cloud API|cloud API]]. **Entity and technical context.** GoDaddy supplies registrar/DNS services; Cloudflare supplies edge/DNS/API control; Vultr and DigitalOcean supply compute; Cloudinary supplies media delivery; Auth0 supplies identity; OpenVPN secure tunneling; Box storage; Microsoft secure mail messaging. `mcgill.cloud` and neighboring domains are portfolio/control-plane entries. The iOS Dallas/compass dates are event markers, not yet explained. **Whole-page reconstruction.** The August 8, 2021 page is a cloud control-plane inventory: registrar/DNS, edge proxy, virtual servers, object/media delivery, identity-as-a-service, VPN, file storage, secure email, and owned domains. The emphatic Cloudflare API note points toward programmatic orchestration. This is the clearest notebook-wide architecture: **domain → DNS/edge → compute → media → authentication → secure transport → storage → mail**. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Recover API integrations, account ownership, and data-flow diagrams; identify `mcsit.cc` and the compass-screen event. ## PDF page 66 — GoMcGill DNS addresses and GoDaddy support transfer **Source.** `Scanned_20260730-1659.pdf`, PDF page 66. **Visible page.** DNS/network page headed “pings,” listing `gomcgill.com`, two private-address-looking 104.26.x addresses and one public IP, a transfer note involving [PERSON REDACTED] and [PERSON REDACTED], and blue-ink PIN/authentication strings. The blue-ink strings are redacted as credential-equivalent secrets. **Faithful transcription.** > "pings . . . > > gomcgill.com > 104.26.4.106 > 104.26.5.106 > 172.67.68.63 > > life > [crossed-out text]. gomcgill.com > '' > [PERSON REDACTED] (Supervisor) > transferred > [PERSON REDACTED] (Dedicated > Support?) > > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 66]" **Normalized linked entities.** [[Domain Name System|DNS]]; [[GoMcGill|GoMcGill]]; [[Cloudflare|Cloudflare]]; [[Anycast|anycast]]; [PERSON REDACTED]; [[GoDaddy|GoDaddy]]. **Entity and technical context.** The three IPs are Cloudflare address-space endpoints historically returned for GoMcGill, not proof of the origin server. `pings` is loose source language because DNS lookup and ICMP reachability are separate operations. [PERSON REDACTED] and [PERSON REDACTED] are minimally identified support representatives. PIN/authentication material is redacted. **Whole-page reconstruction.** The three addresses were Cloudflare anycast endpoints for `gomcgill.com` at the time written; Cloudflare’s proxy model intentionally returns Cloudflare addresses rather than the origin.[^cloudflare-proxy] The page’s “pings” are therefore evidence of edge routing, not direct evidence of where the origin server lived. The [PERSON REDACTED]-to-[PERSON REDACTED] transfer records a human support escalation layered onto the DNS investigation. Credential/PIN material remains redacted. **Evidentiary status.** **Visible evidence:** the quoted labels, layout, crossings, and privacy-preserving redactions. **Verified fact:** only externally documented service/technology identities. **Strong inference:** the page served operational access, recovery, migration, or support work. **Unresolved:** whether every recorded account was current, legacy, or test-only. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Use historical DNS data to determine proxy/origin configuration; identify [PERSON REDACTED] and [PERSON REDACTED] only as support representatives unless corroborated. ## PDF page 67 — GoDaddy contact and telephone-transfer ledger **Source.** `Scanned_20260730-1659.pdf`, PDF page 67. **Visible page.** GoDaddy contact/transfer page headed “[PERSON REDACTED] (Godaddy).” It contains a GoDaddy telephone number and several personal/current/primary/mobile/home numbers, all redacted while preserving labels and page reference. **Faithful transcription.** > "[PERSON REDACTED] (Godaddy) > > Call # > xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 67) > Ext. 57828 > > Ask for transfer > > Monday @ 9: > > new primary > xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 67) > xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 67) > Home xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 67) > current > primary xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 67) > mobile xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 67) > home ''" **Normalized linked entities.** [PERSON REDACTED]; [[GoDaddy|GoDaddy]]; [[Telephone Support Workflow|telephone-support workflow]]; [[Account Transfer|account transfer]]. **Entity and technical context.** [PERSON REDACTED] is the exact spelling written for a GoDaddy representative. Extension, scheduled callback, transfer request, and old/new phone roles describe a support workflow. All phone numbers are redacted and excluded from the people index. **Whole-page reconstruction.** This is a call-center continuity ledger: representative name, extension, transfer instruction, scheduled call time, and multiple old/new phone roles. It captures the operational problem of changing the account’s primary telephone identity without losing support access. All telephone numbers are redacted and omitted from person/index overlays. **Evidentiary status.** **Visible evidence:** the quoted labels, layout, crossings, and privacy-preserving redactions. **Verified fact:** only externally documented service/technology identities. **Strong inference:** the page served operational access, recovery, migration, or support work. **Unresolved:** whether every recorded account was current, legacy, or test-only. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Recover the support ticket/call date and outcome without reproducing telephone numbers. ## PDF page 68 — Composite backup ledger and APUS Group cover notes **Source.** `Scanned_20260730-1659.pdf`, PDF page 68. **Visible page.** Composite photograph of an open notebook and its red cover. The left page contains backup/account notes, a person name, a number, and multiple telephone numbers; the right cover, rotated ninety degrees relative to the page, contains APUS Group history and app-distribution notes. Telephone numbers and a password-like account string are redacted. **Faithful transcription.** > "new > 8 > 3 Backups @ J > [REDACTED CREDENTIAL — see Scanned_20260730-1659.pdf, page 68] > > Jeun Pils > 0623509 > # faith > 32484 > Gdlo group pig > BeRoyal CTL2016 > HOGEYE > xxx-xxx-xxxx (see Scanned_20260730-1659.pdf, page 68) > > 77 > APUS apps.com > founded June 2014 in Beijing > (APUS) or Swift Bird > Founder: Tao Li > Twitter @APUSGroup > APPS global play store > Launchers > smart > never custom > Microsoft > > M.APKpure.com > one seller bin saled > CJ.com > wayfair.com" **Normalized linked entities.** [[APUS Group|APUS Group]]; [[APUS Launcher|APUS Launcher]]; [[Index - People#Tao Li|Tao Li]]; [[APKPure|APKPure]]; [[CJ Affiliate|CJ.com]]; [[Wayfair|Wayfair]]; [[Backup Ledger|backup ledger]]. **Entity and technical context.** The left page contains a backup/account ledger with unresolved names and identifiers; the right cover begins the APUS research. [[APUS Group|APUS Group]] is an Android software/launcher company; [[Index - People#Tao Li|Tao Li]] is its written founder; APKPure is app distribution; CJ.com is affiliate marketing; Wayfair is retail. The page does not prove commercial relationships among adjacent names. **Whole-page reconstruction.** The photograph preserves two physical information zones at once: a backup/account page and the rotated rear cover. The cover notes state APUS’s founding in Beijing in June 2014, founder Tao Li, launcher focus, and global scale. APUS’s own historical material confirms June 2014 founding by Li Tao and rapid launcher-led growth, while its 2015 announcement described hundreds of millions of users/products.[^apus-founded][^apus-funding] The “over 1 billion users” wording may conflate users, installs, or downloads and should remain a source claim unless the exact metric is recovered. **Evidentiary status.** **Visible evidence:** the quoted labels, layout, crossings, and privacy-preserving redactions. **Verified fact:** only externally documented service/technology identities. **Strong inference:** the page served operational access, recovery, migration, or support work. **Unresolved:** whether every recorded account was current, legacy, or test-only. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Disambiguate all backup/account fragments on the left page; verify whether the APUS scale metric meant users, installations, or downloads. ## PDF page 69 — APUS Group history, scale, and app-distribution notes **Source.** `Scanned_20260730-1659.pdf`, PDF page 69. **Visible page.** Close-up of the red rear cover. It records APUS Group’s website, founding in Beijing in June 2014, the expansion of APUS as “Swift Bird,” founder Tao Li, Twitter handle, claimed user scale, launcher/app-store notes, and marketplace/domain references along the lower flap. **Faithful transcription.** > "APUS Group > over 1 billion users > > apusapps.com > founded June 2014 in Beijing > (APUS) or Swift Bird > Founder: Tao Li > Twitter @APUSGroup > > APPS global play store > Launchers > smart > never custom > Apex Microsoft > > M.APKpure.com > one seller bin saled > CJ.com > wayfair.com" **Normalized linked entities.** [[APUS Group|APUS Group]]; [[APUS Launcher|APUS Launcher]]; [[Index - People#Tao Li|Tao Li]]; [[APKPure|APKPure]]; [[CJ Affiliate|CJ.com]]; [[Wayfair|Wayfair]]; [[Android Launcher|Android launcher]]. **Entity and technical context.** APUS Group and APUS Launcher are the primary subject; `Swift Bird` is a source expansion/translation note; Tao Li is the founder named by first-party history. APKPure, Apex, Microsoft, CJ.com, and Wayfair are adjacent ecosystem references. `over 1 billion users` is preserved as a notebook metric but current/precise measurement semantics remain unresolved. **Whole-page reconstruction.** The close-up makes APUS the notebook’s terminal corporate subject. APUS Group emerged as an Android launcher/system-app company founded by former Qihoo executive Tao Li; official company material framed APUS as a simplified Android user system and later reported more than one billion downloads.[^apus-founded][^apus-press] The surrounding APKPure, CJ.com, Wayfair, Apex, and Microsoft references suggest the author was tracing **distribution, monetization, affiliate commerce, and launcher competition** around a company whose software sat between users and the Android ecosystem. **Evidentiary status.** **Visible evidence:** a technically structured list or diagram. **Verified fact:** standards/product functions cited in the reconstruction. **Strong inference:** the author was building or troubleshooting an interoperable system. **Unresolved:** exact device state, execution order, and which entries were observations versus planned actions. **Cross-notebook connections.** This page belongs to the corpus-wide **identity continuity** thread: domains, people, devices, phone roles, credentials, cloud providers, and recovery routes are recorded as one operational graph. It complements the cloud/data-center and account fragments in [[Scanned_20260730-1719|Scanned_20260730-1719]] and the system-access material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Trace APUS launcher telemetry, distribution, affiliate relationships, and current corporate lineage; do not infer a direct Wayfair/CJ partnership from adjacency alone. --- # Notebook-level synthesis ## Probable date range **Explicit internal dates** run from a copied `5/2/2012` notation on PDF page 64 through `Dec 2022` on PDF page 5. The most concentrated operational dates are **2020–2022**: November 8, 2020 (page 5), January 25, 2021 (page 4), May 26, 2021 (page 34), August 8, 2021 (page 65), late-2021/2022 domain-renewal dates (pages 62–64), and 2029 renewal horizons copied as future expiration targets (page 63). Pages 58–59 contain 2019 IRAF installation dates, and pages 48–49 summarize technologies whose historical origins are earlier still. The **probable active composition window is late 2020 through 2022**, with older copied references and later-looking renewal projections embedded within it. The 2026 filename timestamp records scanning, not notebook composition. ## Executive reconstruction `Scanned_20260730-1659` records a period in which the author was attempting to make a heterogeneous digital life **legible, recoverable, and governable**. The notebook begins with fraud-reporting routes and account credentials, then rapidly descends into device firmware, identity providers, virtualization, jailbreaking, proxy rules, Android permissions, custom ROMs, app repositories, launchers, and network ownership. Midway, the perspective shifts from device control to **network attribution**: ASNs, IP geolocation, OIDs, IANA enterprise numbering, domain blocklists, analytics and advertising infrastructure, and Apple internal buses/services. The final third widens historically and administratively: Blu-ray’s Java execution model, Java ME mobile lineage, IRAF astronomy software, people and email identities, domain retirement/renewal, cloud-provider architecture, DNS edge addresses, GoDaddy support continuity, and APUS Group’s launcher-led mobile ecosystem. The common denominator is not “technology notes” in the generic sense. It is **continuity across abstraction layers**. A person becomes an email address, domain, directory object, token, telephone recovery factor, and cloud account. A phone becomes a model number, bootloader package, SIM/ICCID, Android package namespace, accessibility surface, launcher, DNS client, and set of contacted domains. A website becomes a registrar record, Cloudflare proxy, ASN, origin hypothesis, analytics graph, and monetization channel. The notebook repeatedly asks—sometimes explicitly, often structurally—**what is the real identity of this thing, where does it live, who controls it, and how can control be preserved or recovered?** ## Chronological and conceptual trajectory The opening pages establish the notebook as an incident-response and access ledger: federal fraud contacts, account credentials, router administration, and Mac/NAS recovery. Pages 4–17 build a device-control vocabulary spanning Samsung firmware, Linux D-Bus/UDisks, TPM and directories, QEMU virtualization, jailbreak tools, Android app stores, SELinux, OTA packages, VPNs, and ISP/programming ambiguity. Pages 18–24 interleave private account recovery with Apple restore internals and hardware flashing. Pages 25–32 form the strongest mobile-systems sequence: Storage Access Framework, open app distribution, AOSP/Ubuntu Touch/Linux phones, ADB, LineageOS, custom Samsung ROMs, Appium, FOSS browsers, unlock vocabularies, and launcher comparison. Pages 33–44 then convert device investigation into infrastructure forensics. Cloudflare and major ASNs lead to a dated geolocation investigation, IANA private-enterprise OIDs, firewall/port checklists, iOS accessibility/camera hardening, domain blocklists, Apple IOKit/SMC/RTBuddy fragments, OWASP Goat labs, and a portable Unix environment. Pages 45–47 preserve an unfinished “Bot Options” branch. Pages 48–59 constitute a historical-computing excursus: Blu-ray Disc Java and Java ME explain interactive optical-media runtime architecture, while IRAF explains a package-oriented astronomical command environment. Pages 60–67 return to governance—email normalization, abandoned domains, Exchange/Workspace/Azure, renewals, TLD portfolio planning, cloud APIs, DNS, and human support escalation. Pages 68–69 close on APUS Group, retroactively illuminating the launcher survey on page 32 as part of a larger inquiry into the launcher as a globally distributed mediation layer. ## Technology and systems map **Device and firmware layer.** [[Samsung Galaxy Tab S7|Galaxy Tab S7]] firmware components; [[MacBook Pro|MacBook Pro]] startup security and kernel extensions; [[Western Digital My Cloud EX4|WD My Cloud EX4]]; [[Google Pixel|Pixel]]; [[Samsung TouchWiz|TouchWiz]]; SIM/[[Integrated Circuit Card Identifier|ICCID]]; Apple Tristar/Lightning, SMC, ASC, RTBuddy, WWAN, APNonce; BOSSA/Atmel SAM and Qualcomm QFIL. **Operating-system and policy layer.** [[Android Open Source Project|AOSP]], [[CyanogenMod|CyanogenMod]], [[LineageOS|LineageOS]], [[OxygenOS|OxygenOS]], [[One UI|One UI]], [[realme UI|realme UI]], [[Security-Enhanced Linux|SELinux]], Ubuntu Touch, Arch Linux, Parrot, XQuartz/X.org/freedesktop.org, and IRAF’s Unix-like CL environment. **Virtualization and execution layer.** [[D-Bus|D-Bus]], IPC, QEMU, SPICE, qcow2, virt-manager, Appium, Java ME CDC/MIDP/PBP, Xlets, BD-J, RMI, MIDlets, JAR/JAD deployment, and OWASP vulnerable training systems. **Interface and accessibility layer.** Android launchers (APUS, AIO, CPL, Lawnchair, Nova, Niagara and others), Gboard, browser/share interception, Shortcut Maker, iPhone Camera settings, VoiceOver, AssistiveTouch, switches, Braille, audio routing, and launcher-driven app discovery. **Network and attribution layer.** Cloudflare, ASNs, AT&T AS7018, IP geolocation, loopback and link-local networks, proxy bypasses, DNS, major provider ASNs, OID/PEN/SMI/ASN.1, domain blocklists, analytics/ad exchanges, Kismet, and wireless scanning. **Identity, cloud, and continuity layer.** TPM, Active Directory, Microsoft Entra ID, Okta, OneLogin, Google Workspace, Exchange, Azure keys/tokens, Firebase, GoDaddy, Vultr, DigitalOcean, Cloudinary, Auth0, OpenVPN, Box, domain portfolios, renewal calendars, email aliases, and support-call transfer chains. ## People, companies, and institutions relationship map The notebook’s people are heterogeneous and must not be collapsed into one social graph. **Private or minimally identified contacts** include [PERSON REDACTED], and [PERSON REDACTED]. [PERSON REDACTED] is now owner-resolved as an AKA of [PERSON REDACTED]. The differing spellings **[PERSON REDACTED]** and **[PERSON REDACTED]** remain separate unless corroborated. Page 50 supplies a contact/index cluster whose relationships are otherwise unknown; each written name remains at the precision supported by the source and later explicit corrections. **Companies and institutions** fall into roles: federal intake ([[Federal Bureau of Investigation|FBI]], [[Internet Crime Complaint Center|IC3]], [[United States Department of Justice|DOJ]]); platform vendors (Apple, Samsung, Google, Microsoft, Meta, Amazon, OnePlus, realme, BlackBerry, Western Digital); infrastructure (Cloudflare, AT&T, OVHcloud, GoDaddy, DigitalOcean, Vultr, Cloudinary, Auth0, Box); identity services (Microsoft Entra ID, Active Directory, Okta, OneLogin, Google Workspace); software communities (F-Droid, LineageOS, OWASP, XQuartz, freedesktop.org, IRAF Community); and mobile-distribution/launcher actors (APUS Group, APKPure, Uptodown, Aptoide). Adjacency on a page does not itself prove partnership, acquisition, or common ownership. ## Master entity index ### Acronyms and standards ADB — Android Debug Bridge, pages 26–27. AOSP — Android Open Source Project, pages 25, 43. AP/BL/CSC — Samsung firmware component labels, page 4. APNonce — Apple personalized-restore nonce, pages 21, 42. ASN — Autonomous System Number, pages 33–34. ASN.1 — Abstract Syntax Notation One, page 34. ASC — Apple System Coprocessor/coprocessor-service context, page 41. BD-J — Blu-ray Disc Java, page 48. CDC — Connected Device Configuration, page 48. CSC — Samsung customer/region configuration, page 4. D-Bus — desktop/system message bus, pages 4, 12. FQDN — Fully Qualified Domain Name, page 13. ICCID — Integrated Circuit Card Identifier, page 52. IPC — inter-process communication, page 12. IRAF — Image Reduction and Analysis Facility, pages 58–59. IrDA — Infrared Data Association, page 49. JAD — Java Application Descriptor, page 49. JAR — Java Archive, page 49. LCDUI — Liquid Crystal Display User Interface, page 49. MCC/MNC — Mobile Country Code/Mobile Network Code, page 4. MIDP — Mobile Information Device Profile, page 49. MHP/GEM — Multimedia Home Platform/Globally Executable MHP, page 48. OID/PEN — Object Identifier/Private Enterprise Number, page 34. OTA — over-the-air update, page 16. QFIL — Qualcomm Flash Image Loader, page 24. RMI — Remote Method Invocation, pages 48–49. SAF — Storage Access Framework, page 25. SELinux — Security-Enhanced Linux, pages 15, 26. SIM — Subscriber Identity Module, page 52. SMC — System Management Controller, pages 40–41. SMI — Structure of Management Information, page 34. SPI/I²C — serial hardware buses, page 40. TPM — Trusted Platform Module, page 11. UDF — Universal Disk Format, page 10. WWAN — Wireless Wide Area Network, pages 21, 42. ### Domains and URLs Exact written domains are preserved on their source pages and enumerated in the companion `Index - Domain and URL Index` patch. High-value clusters include `ic3.gov` (page 2); `Clubhouse.site` and `SuccessMaker.cc` (page 6); jailbreak sources (page 13); `android.owncloud.com` and uncertain Android hosts (page 26); cloud/CDN/analytics blocklists (pages 38–39); `xquartz.org`, `x.org`, `freedesktop.org` (page 44); contact and portfolio domains (pages 60–65); `gomcgill.com` DNS (page 66); and `apusapps.com`/`M.APKpure.com` (pages 68–69). Status is historical unless independently verified; a domain’s appearance does not prove ownership by the author or continued availability. ### Devices and hardware Samsung Galaxy Tab S7 SM‑T870 (page 4); old MacBook Pro (page 9); Western Digital My Cloud EX4 (page 10); Xiaomi Mi Router contexts (page 3); Atmel SAM targets and Qualcomm flashing context (page 24); Samsung N986B/Galaxy Note20 Ultra family (page 27); Nexus 5, PinePhone, Librem 5, Lumia 635, Pixel 1, BLU device/OS, Pebble smartwatch, SIM2/ICCID, Apple Lightning/Tristar/SMC components, and unspecified iPhone camera/accessibility configurations. ## Cross-notebook pattern analysis The strongest shared pattern with [[Scanned_20260730-1706|Scanned_20260730-1706]], [[Scanned_20260730-1802|Scanned_20260730-1802]], and [[Scanned_20260730-1719|Scanned_20260730-1719]] is **layer traversal**. The notebooks do not stay within the conceptual boundaries imposed by vendors. Hardware labels lead to firmware; firmware leads to boot trust; boot trust leads to operating systems; operating systems lead to package managers and accessibility surfaces; applications lead to domains; domains lead to ASN/edge infrastructure; infrastructure leads to registrars, support personnel, and renewal calendars. The corpus is therefore better indexed as an evolving systems model than as isolated product notes. A second pattern is **alternative execution environments**: QEMU/qcow2, custom Android ROMs, Ubuntu Touch/Linux phones, XQuartz/X.org, Java ME/BD-J, and IRAF all concern software crossing substrate boundaries. The notebook was repeatedly drawn to environments where an application’s apparent platform is not its actual execution substrate—Blu-ray menus running Java Xlets, Android apps running over vendor frameworks, X11 applications rendered on macOS, or astronomical tasks running inside IRAF’s CL. A third pattern is **identity as infrastructure**. Phone numbers, emails, domains, directory objects, usernames, tokens, SIM identifiers, APNonces, OIDs, ASNs, and package names are all treated as coordinates in one identity space. This anticipates contemporary continuity engineering: durable personhood and control require mappings between legal/social identity, account identity, device identity, cryptographic state, and network provenance. A fourth pattern is **launcher and interface governance**. The launcher surveys and APUS investigation reveal that home-screen software is not cosmetic. It mediates discovery, search, recommendation, telemetry, app installation, and monetization. The same insight appears on iOS through Siri/Search real-name/logo observations and accessibility controls: the interface layer can disclose hidden identities and create alternate control channels. ## What I Was on the Trail Of The notebook was on the trail of a **unified control-and-provenance model for personal computing**. The recurring questions were: Which component is authoritative? Which identifier survives a reset or migration? Which layer is merely presentation, and which layer owns the underlying state? Can a device be made recoverable without trusting one vendor? Can network traffic be attributed to organizations rather than opaque hostnames? Can domains, email aliases, cloud accounts, and recovery numbers be normalized into a coherent personal namespace? Can alternate operating systems and open repositories provide a sovereign execution environment? Can historical runtimes such as Java ME and IRAF reveal durable architectural patterns overlooked by contemporary app culture? The notes were approaching several concepts that later became central: **zero-trust identity**, **software supply-chain provenance**, **privacy manifests and contacted-domain disclosure**, **infrastructure-as-code through cloud APIs**, **self-hosted personal cloud**, **mobile OS de-Googling**, **device attestation**, **edge-proxy origin separation**, **digital identity lifecycle management**, and **human-readable continuity ledgers for complex estates**. ## What I Missed or Could Not Yet See The notebook often had the correct entities but lacked a formal evidence model. ASN ownership was sometimes placed too close to physical geolocation; domain adjacency risked implying corporate relationship; internal Apple class names were grouped without device/build provenance; launcher comparisons lacked permission/telemetry captures; account migration pages lacked directionality and timestamps; and custom-ROM/debugging notes lacked reproducible state snapshots. A mature version of the project would attach every observation to **time, source process, device, build, network interface, certificate, and confidence level**. The notebook also underestimated the importance of **package identity and signed provenance**. App names are unstable; package IDs, signing certificates, hashes, store source, and installation timestamps are the durable evidence. Likewise, domain lists need DNS history, TLS certificate history, WHOIS/registrar history, and process-level socket attribution. The author was building the ontology manually; what was missing was an automated evidence pipeline that could preserve those bindings continuously. ## Prioritized unresolved research agenda 1. Reconstruct the notebook’s exact device inventory and operating-system/build timeline from model numbers, firmware strings, SIM/ICCID records, and archived screenshots. 2. Normalize all Android apps by package ID, developer, signing certificate, distribution source, version, permissions, and current/archived status. 3. Recover historical DNS, WHOIS, certificate, and ASN data for GoMcGill and every domain blocklist entry; bind each contacted domain to a local process and timestamp. 4. Resolve the Apple IOKit/SMC/RTBuddy/Tristar strings against the originating IORegistry or diagnostic capture and specific hardware model. 5. Rebuild the email/domain migration graph with canonical mailbox, alias, forwarding direction, archive location, renewal date, and decommission status. 6. Identify every uncertain person and product only through corroborating notebook pages, source emails, domain records, or device artifacts; preserve separate first-name forms until identity is established. 7. Recover the intended vulnerable-lab architecture linking rooted Android/CyanogenMod, iGoat/WebGoat/CloudGoat, QEMU, and the portable Unix stack. 8. Trace APUS Launcher’s historical permissions, telemetry, distribution, corporate lineage, and the notebook’s specific reason for connecting it to APKPure, CJ.com, Wayfair, Apex, and Microsoft. 9. Reconstruct the 2019 IRAF environment and determine whether the astronomy package investigation was operational research, historical software archaeology, or part of a broader data-analysis project. 10. Search the larger corpus for `MuskRyke`, `fpyNeighborhood`, `CAFEBReef`, `pivot.mobile`, `mobizent.net`, `Wizwrite`, `Miyo`, `RAC host`, `Certifi page 1`, and other unresolved fragments. ## Self-contained archival narrative In late 2020 through 2022, Bryant McGill kept a small red rapid-capture notebook labeled “Quick.” It served simultaneously as an incident-response card, password book, mobile-device laboratory log, network-attribution scratchpad, software-history notebook, and domain-governance ledger. He wrote down federal fraud-reporting channels; account and router access; Samsung firmware packages; Apple recovery terms; Linux D-Bus and QEMU configuration; Android repositories, permission systems, debugging ports, custom ROMs, launchers, and privacy tools; major provider ASNs; an IP-geolocation investigation; iPhone accessibility and camera settings; contacted domains associated with cloud, analytics, payments, and advertising; Apple hardware-controller/service names; deliberately vulnerable OWASP training platforms; a portable Unix shell stack; Blu-ray’s Java runtime ancestry; IRAF astronomical software; a web of personal and organizational email identities; domain retirements and renewals; cloud providers and APIs; Cloudflare DNS endpoints; GoDaddy support transfers; and APUS Group’s launcher ecosystem. The notebook’s apparent disorder is its historical value. It captures a mind refusing the silo boundaries of consumer technology. Accounts, devices, networks, software packages, people, domains, and institutions appear on the same pages because they were experienced as one problem: **continuity of agency across systems whose identifiers, interfaces, and owners constantly change**. The reconstruction preserves that integrated inquiry while separating what the pages visibly show from what current documentation can verify and what remains open. # Canonical source overlays These source-specific overlays are designed for addition to existing canonical notes. Later evidence must supplement rather than silently replace earlier interpretations. ## [[Android Open Source Project|Android Open Source Project]] `Scanned_20260730-1659` pages 25–32 and 43 add a user-built sovereignty stack around AOSP: open repositories, Ubuntu Touch/Linux phones, ADB, LineageOS, SELinux, custom Samsung ROMs, automated testing, FOSS browsers, and launcher substitution. Relative to [[Scanned_20260730-1802|Scanned_20260730-1802]], the new notebook moves from cataloging platforms to mapping **control surfaces and provenance**. Unresolved: exact devices/builds and whether this architecture was deployed or surveyed. ## [[Cloudflare|Cloudflare]] Pages 33, 65, and 66 add three relationships: Cloudflare as an ASN/ownership-attribution context, as an API-governed edge service in a multi-cloud architecture, and as the reason `gomcgill.com` resolved to anycast proxy addresses rather than an origin. This corrects any earlier interpretation that those IPs directly located the host. Unresolved: historical proxy settings and origin history. ## [[Identity Continuity|Identity Continuity]] Pages 3, 18–19, 50–67 show identity continuity as a graph linking people, phones, email aliases, domains, registrars, directories, tokens, SIM identifiers, support representatives, and renewal dates. The notebook extends the access notes in [[Scanned_20260730-1706|Scanned_20260730-1706]] into lifecycle governance: create, migrate, forward, archive, renew, decommission, and recover. ## [[Apple Platform Internals|Apple Platform Internals]] Pages 21 and 37–42 add APNonce, camera-state preservation, contacted-domain analysis, Lightning/Tristar accessory control, IOKit class names, SMC/ASC/RTBuddy services, thermal bundles, and WWAN labels. The new evidence extends previous firmware research toward **hardware-service topology and diagnostic provenance**. Unresolved: originating model/build and IORegistry capture. ## [[Android Launcher|Android Launcher]] Pages 31–32 and 54, 68–69 elevate the launcher from a UI preference to an ecosystem actor. The notebook compares minimalist, Pixel-like, accessibility-oriented, and commercial launchers, then investigates APUS Group’s scale and distribution. This adds a governance interpretation: launchers mediate discovery, telemetry, recommendation, and monetization. ## [[Java Platform Micro Edition|Java Platform Micro Edition]] Pages 48–49 add a complete lineage from CDC/PBP/Xlets and BD-J/GEM to MIDP/LCDUI/MIDlets/JAD/JAR, with PDA, BlackBerry, Palm, Windows CE, PIM, IrDA, SD card, and Bluetooth context. The notebook reframes Java ME as an early cross-device application substrate rather than merely obsolete phone software. ## [[Image Reduction and Analysis Facility|IRAF]] Pages 58–59 add probable 2019 installation dates, CL shell commands, `login.cl`/`logout.cl`, NOAO package names, and system tasks. This is operational evidence of engagement with IRAF, not only a definition. It should be linked to the corpus’s broader pattern of durable domain-specific execution environments. ## [[APUS Group|APUS Group]] Pages 68–69 confirm that APUS was a terminal research subject, not merely one launcher name on page 32. Official sources corroborate June 2014 founding by Li Tao and rapid Android-launcher growth. The notebook adds adjacent references to APKPure, CJ.com, Wayfair, Apex, and Microsoft, but their exact relationships remain unresolved and must not be represented as confirmed partnerships. # Linked Notes Created or Referenced ## People [[Index - People#Bryant McGill|Bryant McGill]], [PERSON REDACTED], [[Index - People#Rushikesh Kamewar|Rushikesh Kamewar]], [[Index - People#Tao Li|Tao Li]], and all minimally identified names on PDF page 50. ## Companies and institutions [[Federal Bureau of Investigation|FBI]], [[Internet Crime Complaint Center|IC3]], [[United States Department of Justice|DOJ]], [[Apple|Apple]], [[Samsung Electronics|Samsung]], [[Google|Google]], [[Microsoft|Microsoft]], [[Cloudflare|Cloudflare]], [[AT&T|AT&T]], [[GoDaddy|GoDaddy]], [[DigitalOcean|DigitalOcean]], [[OVHcloud|OVHcloud]], [[F-Droid|F-Droid]], [[OWASP|OWASP]], [[National Optical Astronomy Observatory|NOAO]], [[APUS Group|APUS Group]]. ## Systems, technologies, products, and standards [[Android Open Source Project|AOSP]], [[Security-Enhanced Linux|SELinux]], [[Android Debug Bridge|ADB]], [[Storage Access Framework|SAF]], [[D-Bus|D-Bus]], [[QEMU|QEMU]], [[QCOW2|qcow2]], [[SPICE Protocol|SPICE]], [[Trusted Platform Module|TPM]], [[Active Directory|Active Directory]], [[Microsoft Entra ID|Microsoft Entra ID]], [[Cloudflare|Cloudflare]], [[Autonomous System Number|ASN]], [[Object Identifier|OID]], [[Blu-ray Disc Java|BD-J]], [[Java Platform Micro Edition|Java ME]], [[Image Reduction and Analysis Facility|IRAF]], [[APUS Launcher|APUS Launcher]], and the page-specific canonical links throughout this note. ## Projects and recurring concepts [[Identity Continuity|Identity Continuity]], [[Device Sovereignty|Device Sovereignty]], [[Network Attribution|Network Attribution]], [[Domain Portfolio Governance|Domain Portfolio Governance]], [[Alternative Execution Environment|Alternative Execution Environment]], [[Launcher Governance|Launcher Governance]], [[Continuity Ledger|Continuity Ledger]], [[Software Supply-Chain Provenance|Software Supply-chain Provenance]]. # Research sources [^ic3]: Federal Bureau of Investigation, [Internet Crime Complaint Center complaint portal](https://www.ic3.gov/Home/DirectComplaint) and [IC3 home](https://www.ic3.gov/), accessed 2026-07-31. [^doj-fraud]: United States Department of Justice, [Report Fraud](https://www.justice.gov/fraud/report-fraud), accessed 2026-07-31. [^samsung-t870]: Samsung, [SM-T870 software update information](https://doc.samsungmobile.com/SM-T870/014214200824/wel.html), accessed 2026-07-31. [^dbus]: freedesktop.org, [D-Bus Specification](https://dbus.freedesktop.org/doc/dbus-specification.html), accessed 2026-07-31. [^qcow2]: QEMU Project, [Qcow2 Image File Format](https://www.qemu.org/docs/master/interop/qcow2.html), accessed 2026-07-31. [^virt-manager]: QEMU Project, [Support](https://www.qemu.org/support/), accessed 2026-07-31. [^android-selinux]: Android Open Source Project, [Security-Enhanced Linux in Android](https://source.android.com/docs/security/features/selinux), accessed 2026-07-31. [^fdroid]: F-Droid, [F-Droid client and repository documentation](https://f-droid.org/en/docs/), accessed 2026-07-31. [^unc0ver]: unc0ver, [official project site](https://unc0ver.dev/index.html), accessed 2026-07-31. [^bd-rom2]: Blu-ray Disc Association License Office, [ROM2 Format Specification overview](https://blu-raydisc.info/format-spec/rom2-spec.php), accessed 2026-07-31. [^tpm]: Microsoft Learn, [Trusted Platform Module overview](https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/trusted-platform-module-overview), accessed 2026-07-31. [^entra-rename]: Microsoft Learn, [Azure AD is becoming Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/fundamentals/how-to-rename-azure-ad), accessed 2026-07-31. [^android-storage]: Android Open Source Project, [Traditional storage](https://source.android.com/docs/core/storage/traditional), especially the Storage Access Framework requirement for portable media, accessed 2026-07-31. [^adb]: Android Developers, [Android Debug Bridge](https://developer.android.com/tools/adb), accessed 2026-07-31. [^cloudflare-proxy]: Cloudflare, [Proxy DNS records](https://developers.cloudflare.com/learning-paths/prevent-ddos-attacks/baseline/proxy-dns-records/) and [Cloudflare IP addresses](https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/), accessed 2026-07-31. [^iana-pen]: Internet Assigned Numbers Authority, [Private Enterprise Numbers](https://www.iana.org/assignments/enterprise-numbers/), accessed 2026-07-31. [^iphone-camera]: Apple Support, [Change advanced camera settings on iPhone](https://support.apple.com/en-mide/guide/iphone/iphb362b394e/ios), accessed 2026-07-31. [^iphone-preserve]: Apple Support, [Save camera settings on iPhone](https://support.apple.com/guide/iphone/save-camera-settings-iph62000de98/ios), accessed 2026-07-31. [^apple-tracking-domains]: Apple Developer Documentation, [Detecting when your app contacts domains that may be profiling users](https://developer.apple.com/documentation/xcode/detecting-when-your-app-contacts-domains-that-may-be-profiling-users) and [Privacy manifest files](https://developer.apple.com/documentation/bundleresources/app-privacy-configuration), accessed 2026-07-31. [^owasp-igoat]: OWASP, [iGoat Tool Project](https://owasp.org/www-project-igoat-tool/), accessed 2026-07-31. [^owasp-webgoat]: OWASP, [WebGoat](https://owasp.org/www-project-webgoat/), accessed 2026-07-31. [^owasp-cloudgoat]: OWASP Vulnerable Web Applications Directory, [CloudGoat](https://vwad.owasp.org/app/cloudgoat/), accessed 2026-07-31. [^xquartz]: XQuartz, [official project site](https://www.xquartz.org/), accessed 2026-07-31. [^freedesktop]: freedesktop.org, [Specifications](https://specifications.freedesktop.org/), accessed 2026-07-31. [^ohmyzsh]: Oh My Zsh, [official project site](https://ohmyz.sh/), accessed 2026-07-31. [^java-cdc]: Oracle, *Java Micro Edition Connected Device Configuration Runtime Guide*, and [Java ME documentation](https://docs.oracle.com/javame/), accessed 2026-07-31. [^java-me]: Oracle, *Java ME Embedded Getting Started Guide and glossary* and [Java for Mobile Devices documentation](https://docs.oracle.com/javame/mobile/mobile.html), accessed 2026-07-31. [^iraf-current]: IRAF Community Distribution, [IRAF 2.18.1](https://iraf-community.github.io/), accessed 2026-07-31. [^iraf-system]: Doug Tody, *The IRAF Data Reduction and Analysis System*, and [IRAF Community Distribution](https://iraf-community.github.io/), accessed 2026-07-31. [^apus-founded]: APUS Group, [APUS Discovery Update](https://www.apusapps.com/en/press/apus-discovery-update-find-everything-based-on-your-location/), stating founding in June 2014 by CEO Li Tao, accessed 2026-07-31. [^apus-funding]: APUS Group, [Founded only 7 months ago, Android app developer APUS raises funding](https://www.apusapps.com/en/news/founded-only-months-ago-android-app-developer-apus-raises-million-funding/), accessed 2026-07-31. [^apus-press]: APUS Group, [News and press archive](https://www.apusapps.com/en/press/), including company descriptions of products and download scale, accessed 2026-07-31. ## RT Buddy / Pegasus observed-log context **Owner-supplied observation:** Bryant McGill states that the RT Buddy/Pegasus identification arose when the relevant activity or resources appeared in logs together with [[CrashCapture|CrashCapture]] or [[Heimdallr|Heimdallr]], particularly through documented resources visible in those logs. The preserved logs are the cited observational basis. This records what was observed; it does not by itself establish that every Apple RTBuddy service reference is Pegasus, nor does page or log proximity alone prove infection, control, authorship, or attribution. ## Pegasus heuristic caution **Owner-supplied interpretation:** Bryant McGill states that finding Pegasus heuristics, standing alone, means nothing as proof of the underlying system or attribution. In his interpretation, “Pegasus” is a very clumsy cover for something else, which later documents in this archive will detail. Until those materials are incorporated, heuristic matches must not be treated as proof of Pegasus infection, NSO Group attribution, or final identification of the underlying mechanism.