Modelo ng Seguridad

Paano pinoprotektahan ng WindowsHelper ang iyong PC + ang iyong telepono, anong cryptography ang ginagamit namin, at kung ano ang tahasang hindi namin ipinagtatanggol. Huling na-update: 2026-04-25.

Ikot ng buhay ng pagpapares-code

Ang code ng pagpapares ay ang nakabahaging lihim bawat iba pang operasyon ng crypto ay nagmula sa. Ang buong ikot ng buhay:

[ Phone GENERATES random 8-char code ]
   ↓
[ Phone WRITES code + sessionId to Firestore in pc_connections doc ]
   ↓
[ Phone DISPLAYS code to user on screen ]
   ↓
[ User READS code, types it into companion's input field ]
   ↓
[ Companion QUERIES Firestore for waiting session matching the code ]
   ↓
[ Both sides DERIVE crypto keys from SHA-256(code, sessionId) ]
   ↓
[ Code STAYS in memory on both sides; never written to Firestore by either ]
   ↓
[ Disconnect / re-pair WIPES the code from both sides ]

• Random: mga code na nabuo sa pamamagitan ng cryptographically secure na mga RNG.
• 32-char na alpabeto × 8 posisyon ≈ 1.1 trilyong kumbinasyon. Ibinubukod ang I/O/0/1 upang maiwasan ang visual ambiguity, hindi ang kahalagahan ng seguridad — ang codespace ay sapat na siksik na ang 5 minutong brute-force na window na may mga limitasyon sa rate ng Firestore ay hindi magagawa.
• Hindi kailanman sumulat sa Firestore sa magkabilang panig. Tanging ang WAITING session doc lang ang nagdadala pairingCode; sa sandaling ipares, ang code ay mananatili sa memorya ng eksklusibo.
• In-memory wipe kapag idiskonekta, muling ipares, o isara ang app.

Cryptography

AES-256-GCM (command confidentiality + integrity)

Ang bawat command na ipinadala sa pamamagitan ng wire ay naka-encrypt gamit ang AES-256-GCM, isang authenticated-encryption mode.

• Susi: 256 bits, hinango bilang SHA-256("WH_SECURE_{code}_{sessionId}_CMD_KEY").
• Nonce: 96 bits (12 bytes), na nabuo sa bawat mensahe sa pamamagitan ng Random.secure() sa telepono o RandomNumberGenerator sa kasama.
• Auth tag: 128 bits (16 bytes), idinagdag sa ciphertext.
• Format ng wire: AESGCM:<nonce_b64>:<ciphertext_b64>:<tag_b64>
• Kaligtasan sa hindi muling paggamit: Ang 96-bit nonces mula sa isang CSPRNG ay nagbibigay ng birthday-paradox collision probability na ~2⁻³² pagkatapos ng 2⁴⁸ na mensahe — astronomically out of reach para sa anumang kapani-paniwalang dami ng command.

HMAC-SHA256 (command authenticity)

Ang bawat command ay mayroon ding HMAC signature kaya ang teleponong hindi alam ang pairing code ay hindi makakapag-inject ng mga command kahit na maaari itong sumulat sa Firestore.

• Susi: 256 bits, derived as SHA-256("WH_SECURE_{code}_{sessionId}_HMAC_KEY"). Hiwalay sa encryption key.
• Saklaw ng field: HMAC-SHA256(hmacKey, commandId | ciphertext | sentAtMillis). Ang mga tubo ay literal na mga character ng pipe, hindi mga delimiter - tatlong pinagsama-samang mga string.
• Order ng pagpapatunay: Na-verify ang HMAC dati decryption. Ang mga pekeng mensahe ay nag-aaksaya ng zero na mga cycle ng CPU sa mga cryptographic primitive.

Modelo ng pananakot

pananakot	Katayuan	Mga Tala
Eavesdropper sa lokal na network	Pinagaan	Ang AES-GCM ciphertext ay opaque sa mga tagamasid ng MITM.
Eavesdropper sa mga server ng Firestore	Pinagaan	Google sees AESGCM:... blobs, not commands.
Attacker na maaaring sumulat sa Firestore ngunit hindi alam ang code	Pinagaan	Nabigo ang pag-verify ng HMAC; itinatala ng kasama ang pagtanggi + tumanggi sa pagpapatupad.
Attacker na nag-crack / nag-phished ng code ng pagpapares	Nalalabi	Maaari silang mag-isyu ng mga utos na parang sila ang gumagamit. Pagbawas: i-rotate ang code mula sa tray menu.
I-replay ang isang naitala na utos	Nalalabi	sentAtMillis is HMAC-bound; companion doesn't yet enforce a freshness window. Future fix adds a TTL.
Hindi na-authenticate na attacker ang LAN-mode	Pinagaan	Ang WebSocket pair handshake ay nagpapatunay sa code; HMAC + AES gate sa bawat kasunod na utos.
Nakompromiso ang teleponong may ninakaw na key ng pagpapares	Nalalabi	Hindi makilala sa "ang gumagamit mismo." Pagbawas: limitasyon sa rate (10 cmd/min) + mapanirang-utos na kumpirmasyon ay nangangailangan ng pag-click sa gilid ng PC.
Maling na-type na command mula sa phone app	Pinagaan	Bina-block ng allowlist sa gilid ng telepono ang mga hindi nakikilalang prefix; mga command sa companion-side pre-flight blocks na nagta-target sa mga hindi umiiral na serbisyo.
Ang mapanirang utos ay tumakbo nang hindi sinasadya	Pinagaan	Companion-side modal requires user click to approve Remove-Item, Format-Volume, reg delete, shutdown /r, etc.
Hung / runaway na proseso ng PowerShell	Pinagaan	Ang mahirap na 5 minutong pag-timeout ay pumapatay sa buong puno ng proseso.
Companion .exe na pakikialam sa pagitan ng pag-download at pagtakbo	Pinagaan	SHA-256 published in companion-version.json; users can verify. Authenticode signing landing soon.
Ang pag-crash ng kasamang tumutulo sa sensitibong estado	Pinagaan	Ang mga ulat ng pag-crash + Ang mga writeback ng error sa Firestore ay nag-sanitize %USERPROFILE% / %MACHINE% / %USER%.
Ninakaw na device, nagpatuloy sa pagpapares ng Registry key	Nalalabi	Maaaring basahin ng isang attacker na may disk + access sa pag-log in ang patuloy na code. Binabalot ito ng pag-aayos sa hinaharap ng Windows DPAPI.

Wala sa saklaw

Mga bagay na tahasang ginagawa ni WindowsHelper. hindi ipagtanggol laban sa:

• Nakompromiso ang Windows account tumatakbo ang kasama. Ipinapalagay namin na sa kanila ang PC ng user. Nanalo na ang isang attacker na may admin sa PC ng user.
• Binary ng app ng telepono na nakompromiso. Hindi kami pumipirma sa mga build ng Android/iOS laban sa pakikialam na higit pa sa ibinibigay ng app store ng platform.
• Mga kalaban sa antas ng estado na may mga mapagkukunan upang ibagsak ang Google's Firestore o DigiCert's PKI. Ang produktong ito ay nagta-target ng mga banta sa antas ng consumer — script kiddies, casual snooper, hindi nasisiyahang miyembro ng sambahayan — hindi mga gobyerno.
• Mga pag-atake sa side-channel sa AES-GCM sa pamamagitan ng power / EM analysis. Ang kasama ay hindi isang smartcard.

Pagbubunyag

• Email support@windowshelper.app may paksa [security].
• Pakisama ang mga numero ng bersyon, mga hakbang sa repro, epekto, at perpektong pag-aayos.
• Unang tugon sa loob ng 48 oras. Sinubukan ang kalubhaan sa loob ng isang linggo. Ang mga isyu na may mataas na kalubhaan ay nakakakuha ng out-of-cycle na release.
• Palugit ng pagbubunyag: 90 araw mula sa paunang ulat, o mas maaga sa pamamagitan ng magkaparehong kasunduan.
• Walang bayad na bug bounty sa kasalukuyan — nag-credit kami ng mga reporter sa mga tala ng paglabas (nang may pahintulot).