← Powrót do WindowsHelper

Model bezpieczeństwa

W jaki sposób WindowsHelper chroni Twój komputer i telefon, jakiej kryptografii używamy i przed czym wyraźnie się nie bronimy. Ostatnia aktualizacja: 25.04.2026.

zgłaszanie luki

E-mail support@windowshelper.app z tematem [security]. Nie otwieraj publicznych problemów w GitHubie — daj nam czas na przesłanie poprawki przed ujawnieniem.

Cykl życia kodu parowania

Kod parowania to wspólny sekret każda inna operacja kryptograficzna wywodzi się z. Pełny cykl życia:

[ 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 ]

Losowe: kody generowane za pośrednictwem kryptograficznie bezpiecznych RNG.
Alfabet 32 znaki × 8 pozycji ≈ 1,1 biliona kombinacji. Nie obejmuje operacji we/wy/0/1, aby uniknąć niejednoznaczności wizualnej, a nie znaczenia bezpieczeństwa — przestrzeń kodowa jest na tyle gęsta, że 5-minutowe okno brutalnej siły z limitami szybkości Firestore jest niewykonalne.
Nigdy nie pisano do Firestore przez żadną ze stron. Zawiera tylko dokument sesji WAITING pairingCode; po sparowaniu kod pozostaje wyłącznie w pamięci.
Czyszczenie pamięci po rozłączeniu, ponownym sparowaniu lub zamknięciu aplikacji.

Kryptografia

AES-256-GCM (poufność poleceń + integralność)

Każde polecenie wysyłane przewodem jest szyfrowane przy użyciu AES-256-GCM, trybu szyfrowania uwierzytelnionego.

Klucz: 256 bitów, wyprowadzone jako SHA-256("WH_SECURE_{code}_{sessionId}_CMD_KEY").
Nonce: 96 bitów (12 bajtów), generowanych świeżo dla każdej wiadomości przez Random.secure() na telefonie lub RandomNumberGenerator na towarzyszu.
Tag autoryzacji: 128 bitów (16 bajtów), dołączonych do tekstu zaszyfrowanego.
Format drutu: AESGCM:<nonce_b64>:<ciphertext_b64>:<tag_b64>
Bezpieczeństwo jednorazowego użytku: 96-bitowe nonces z CSPRNG dają prawdopodobieństwo kolizji z paradoksem urodzinowym wynoszące ~2⁻³² po 2⁴⁸ wiadomościach — astronomicznie poza zasięgiem jakiejkolwiek wiarygodnej głośności poleceń.

HMAC-SHA256 (autentyczność poleceń)

Każde polecenie zawiera również podpis HMAC, więc telefon, który nie zna kodu parowania, nie może wstrzykiwać poleceń, nawet jeśli może pisać do Firestore.

Klucz: 256 bits, derived as SHA-256("WH_SECURE_{code}_{sessionId}_HMAC_KEY"). Oddzielne od klucza szyfrowania.
Zakres pola: HMAC-SHA256(hmacKey, commandId | ciphertext | sentAtMillis). Potoki to dosłowne znaki potoku, a nie ograniczniki — trzy połączone ciągi.
Kolejność weryfikacji: Sprawdzone przez HMAC wcześniej odszyfrowanie. Sfałszowane wiadomości marnują zero cykli procesora na prymitywy kryptograficzne.

Model zagrożenia

Zagrożenie	Stan	Notatki
Podsłuchiwacz w sieci lokalnej	Złagodzony	Tekst zaszyfrowany AES-GCM jest nieprzezroczysty dla obserwatorów MITM.
Podsłuchiwacz na serwerach Firestore	Złagodzony	Google sees `AESGCM:...` blobs, not commands.
Atakujący, który może pisać do Firestore, ale nie zna kodu	Złagodzony	Weryfikacja HMAC kończy się niepowodzeniem; towarzysz rejestruje odrzucenie + odmawia wykonania.
Osoba atakująca, która złamała/wyłudziła kod parowania	Pozostały	Mogą wydawać polecenia tak, jakby byli użytkownikiem. Łagodzenie: obróć kod z menu zasobnika.
Powtórka nagranego polecenia	Pozostały	`sentAtMillis` is HMAC-bound; companion doesn't yet enforce a freshness window. Future fix adds a TTL.
Nieuwierzytelniony atakujący w trybie LAN	Złagodzony	Uzgadnianie pary protokołu WebSocket sprawdza poprawność kodu; Bramka HMAC + AES przy każdym kolejnym poleceniu.
Zhakowany telefon ze skradzionym kluczem do parowania	Pozostały	Nie do odróżnienia od „samego użytkownika”. Ograniczanie: limit szybkości (10 cmd/min) + potwierdzenie polecenia niszczącego wymaga kliknięcia po stronie komputera.
Błędnie wpisane polecenie z aplikacji na telefon	Złagodzony	Lista dozwolonych po stronie telefonu blokuje nierozpoznane prefiksy; Polecenia przed lotem po stronie towarzyszącej są skierowane do nieistniejących usług.
Destrukcyjne polecenie zostało uruchomione przypadkowo	Złagodzony	Companion-side modal requires user click to approve `Remove-Item`, `Format-Volume`, `reg delete`, `shutdown /r`, etc.
Zawieszony/niekontrolowany proces PowerShell	Złagodzony	Twardy 5-minutowy limit czasu zabija całe drzewo procesów.
Companion Manipulowanie plikiem .exe pomiędzy pobieraniem i uruchamianiem	Złagodzony	SHA-256 published in `companion-version.json`; users can verify. Authenticode signing landing soon.
Companion awaria, wyciek, stan wrażliwy	Złagodzony	Raporty o awariach + zapisywanie zwrotne błędów Firestore oczyszczają `%USERPROFILE%` / `%MACHINE%` / `%USER%`.
Skradzione urządzenie, zachowany klucz parowania rejestru	Złagodzony	Utrwalony kod parowania jest szyfrowany za pomocą Windows DPAPI (na konto), więc nie można go odczytać ze skopiowanego dysku ani innego konta Windows.

Poza zakresem

Rzeczy, które WindowsHelper wyraźnie robi nie bronić się przed:

Zhakowane konto Windows prowadzenie towarzysza. Zakładamy, że komputer użytkownika należy do niego. Osoba atakująca mająca uprawnienia administratora na komputerze użytkownika już wygrała.
Zhakowany plik binarny aplikacji telefonicznej. Nie zabezpieczamy kompilacji systemu Android/iOS przed ingerencją wykraczającą poza to, co zapewnia sklep z aplikacjami na platformie.
Przeciwnicy na szczeblu państwowym z zasobami umożliwiającymi obalenie infrastruktury PKI Firestore lub DigiCert firmy Google. Celem tego produktu są zagrożenia konsumenckie — dzieci piszące scenariusze, przypadkowi szpiegowie, niezadowoleni członkowie gospodarstw domowych — a nie rządy.
Ataki z kanału bocznego na AES-GCM poprzez analizę mocy/EM. Towarzysz nie jest kartą inteligentną.

Ujawnienie

E-mail support@windowshelper.app z tematem [security].
Podaj numery wersji, kroki odtwarzania, wpływ i idealną poprawkę.
Pierwsza odpowiedź w ciągu 48 godzin. Zdefiniowano stopień nasilenia w ciągu jednego tygodnia. Problemy o dużej ważności są wydawane poza cyklem.
Okno ujawnienia: 90 dni od pierwszego raportu lub wcześniej za obopólną zgodą.
Obecnie nie ma płatnej nagrody za błąd — w uwagach do wydania (za pozwoleniem) opisujemy reporterów.