Opętany Sklep Windows. Walka z nawiedzonym systemem (Część II)

Każdy, kto przez dłuższy czas pracował na helpdesku IT wie, że regularnie pojawiają się urządzenia, które są po prostu nawiedzone przez diabła. Nie istnieje inne wytłumaczenie ich chorego zachowania, każda racjonalizacja takowego jest jedynie myśleniem życzeniowym, a objawy zazwyczaj znikają spontanicznie lub pod wpływem kompletnie niekoherentnych czynności diagnostycznych.

Wiadomo o czym mowa, prawda? O stacjach dokujących, które działają tylko z monitorami po lewej stronie biurka (niezależnie, jak podpiętymi). O blade'ach nieumiejących się uruchomić, zgłaszających błąd typu "413", podczas gdy podręcznik opisuje jedynie numery od 0 do 127. O publicznych udziałach udostępnionych, które i tak proszą o hasło, ale przyjmują każde… poza spacją. I przestają to robić, gdy zaczyna się badać ruch sieciowy WireSharkiem. O stacji roboczej, która nie potrafi przekierowywać folderów użytkownika, gdy jego domenowe konto ma nazwę zaczynającą się na "a". I tak dalej.

Wielu programistów zapomina o istnieniu opętanych urządzeń. Zwłaszcza pracując z daleka od wdrożeń, systemów i sprzętu. Choć, rzecz jasna, oprogramowanie również potrafi zachowywać się w nawiedzony sposób. Wydawałoby się, że w przypadku software'u łatwiej zdiagnozować przyczyny, ale to nie reguła. Dobrym przykładem będzie chociażby Windows 8.1, zainstalowany celem odkopania Media Center. Udało się obudzić nim siły nieczyste. Ale najpierw dygresja.

Jedną z zalet Windows 10 jest to, że aktualizacje kumulatywne nie wymagają już, w przypadku ich wstrzyknięcia w źródło instalacyjne, kroków niezbędnych do wykonania w fazie online. Co to znaczy? Pliki aktualizacji (CAB i MSU) zawierają "manifesty" oraz "payload". Payload to nowe pliki binarne, mające na celu zastąpić oryginalne, w których odnaleziono błędy. Manifesty, poza poświadczeniem oryginalności plików, opisują co z nimi zrobić. Czasem, poza zwykłą podmianą plików, potrzebne jest wykonanie pewnych operacji, jak zmiana ustawień albo migracja baz. Transakcja.

Gdy instalujemy aktualizacje na zainstalowanym systemie, nowe pliki są ładowane do bazy winsxs. Przez pewien czas dostępne są obie ich wersje, po ponownym uruchomieniu, system może zafundować aplikacjom od razu te nowe. Jeżeli coś potrzebuje starych, sięga do winsxs. Proces ponownego uruchomienia ("Trwa przygotowywanie aktualizacji…") realizuje zaległe transakcje.

Jak to wygląda w przypadku integrowania łatek z obrazem instalacyjnym? Nie można wykonać żadnych "operacji w systemie", ponieważ żadnego systemu jeszcze nie ma. W takiej sytuacji, oczekujące transakcje są zapisywane do pliku-ściągi (PENDING.XML). Zostaną one zrealizowane dopiero po pierwszym uruchomieniu zainstalowanego systemu. Obraz instalacyjny zawiera pliki oryginalne i zaktualizowane jednocześnie. Jeżeli aktualizacji jest np. 200, plik install.wim zaczyna ważyć kilkanaście gigabajtów.

Tak zainstalowany system, przez pierwsze godziny swojego działania, realizuje zaległe transakcje, a następnie sprząta opuchnięty katalog winsxs. Jest to pilna potrzeba, którą Windows realizuje w ramach harmonogramowanych zadań Automatycznej Konserwacji. W ich celu jest gotów nawet obudzić śpiący komputer, jeżeli jest podpięty do źródła zasilania.

Zatem opętany przez mszczące się za brak Kevina złe duchy laptop z Media Center niekoniecznie straszył mnie w nocy Poltergeistem, a zadokowany zmienił automatycznie plan zasilania (dlatego spał zamiast hibernować), po czym uruchomił zaległą konserwację. Instalując brakujące sterowniki, skonfigurował pilota do Media Center, a ten, widząc nowe urządzenie, włączył się. Ponieważ nie był jeszcze skonfigurowany, uruchomił się do ekranu startowego. To jego melodia obudziła mnie w środku nocy.

Być może część z Was stwierdziła właśnie, że chcę tą wypowiedzią zmierzać do konkluzji, w której podważę zjawisko opętania sprzętu. Że stwierdzę, że każde takie zjawisko ma logiczne uzasadnienie. Nic podobnego. Z opisywanym laptopem stało się jeszcze wiele innych rzeczy, których śmiertelnicy nie są stanie objąć przyziemnym, racjonalnym rozumem.

Kolejne cuda zaczęły zachodzić po doinstalowaniu pakietów językowych. Zawsze instaluję system po angielsku, a następnie dodaję polski i francuski pakiet językowy. O powodach tego podejścia można przeczytać w naszych zeszłorocznych opracowaniach dotyczących Emoteta. Skutkiem ubocznym tej procedury jest to, że Windows Update ponownie chce instalować już obecne w systemie łatki, ponieważ nie zgadza się język kilku plików.

Dlatego ze zrozumieniem przyjąłem, że wiatraki laptopa wyją cierpiętniczym skowytem, wiedziałem bowiem, że procesor dławi się od bezsensownej pracy, zlecanej przez TrustedInstaller. Nieco trudniej było wytłumaczyć, dlaczego w systemie, z którego obrazu usunąłem wszystkie aplikacje Metro, samodzielnie pojawiło się szesnaście nowych. Nie wyglądały przyjaźnie. Ich nazwy był bowiem następujące:

24712m1dfmmengesha.mxtest2_2.0.0.0_neutral__x35ns48czryn024712m1dfmmengesha.TestFrameworkBackpublish050515_1.0.0.0_neutral__x35ns48czryn024712m1dfmmengesha.TestFrameworkBP052015_1.0.0.9_neutral__x35ns48czryn024712m1dfmmengesha.TestFrameworkwin81appxneutral06_4.0.0.7_neutral__x35ns48czryn040538vasetest101.25336FD6F8AF0_12.0.21005.1_x64__ssm1v0s3df7zc40538vasetest101.TESTFRAMEWORKABO2_12.0.21005.1_x64__ssm1v0s3df7zc48682KiddoTest.Frameworkuapbase_1.0.0.2_neutral__81ffpr532s7pc50856m1dfLL.TestFrameworkProd06221501_1.0.0.10_neutral__nwcxtg9ehxpvt24712m1dfmmengesha.mxtest224712m1dfmmengesha.TestFrameworkBackpublish05051524712m1dfmmengesha.TestFrameworkBP05201524712m1dfmmengesha.TestFrameworkwin81appxneutral0640538vasetest101.TESTFRAMEWORKABO248682KiddoTest.Frameworkuapbase50856m1dfLL.TestFrameworkProd0622150140538vasetest101.25336FD6F8AF0

Tak nie brzmią nazwy porządnych, bezpiecznych programów. Tak nazywają się trojany. Co gorsza, aplikacje nie pojawiały się w zbiorze zainstalowanych pakietów APPX dla żadnego użytkownika w systemie i nie było ich także na liście aplikacji w które "zaopatrzono" obraz. Nic dziwnego, wszystkie "zaopatrzone", czyli domyślne aplikacje Metro zostały usunięte, zresztą na pewno nie nazywały się w ten sposób!

Skąd wzięły się te programy? W systemie zainstalowany był jedynie 7-Zip i Office 365, nie pobierają one w ramach zależności tak dziwacznych pakietów. Zresztą, przypomnijmy, Sklep nie działa! Poza tym, czy Sklep naprawdę serwowałby aplikację "25336FD6F8AF0" wydawcy "40538vasetest101"? Jest w nim sporo śmieci, ale przecież nie aż takich…

Naturalnym krokiem w takich okolicznościach jest odpiąć komputer od sieci, zrobić kopię podejrzanych plików, a systemowi zafundować "kwarantannę". Rozpocząłem więc badanie dziwacznych okazów znikąd i podjąłem próby ich usunięcia. Prędko okazało się, że oprogramowanie zainstalowane przez moce piekielne jest niemożliwe do usunięcia.

[code]Windows cannot remove 24712m1dfmmengesha.TestFrameworkBackpublish050515_1.0.0.0_neutral__x35ns48czryn0 because the current user does not have that package installed. Use Get-AppxPackage to see the list of packages installed.[/code]

Krótka powtórka z serwisowania aplikacji Metro/UWP: apki instalowane przez każdego użytkownika lądują w tym samym katalogu: WindowsApps. Dzieki temu, że stosowany jest ścisły rozdział kodu, danych i stanu, wspólny katalog na kod nie jest żadnym problemem. Dane aplikacji leżą w ProgramData, a stan specyficzny dla każdego użytkownika - w jego katalogu domowym.

Aplikacja może się pojawić w katalogu WindowsApps na kilka sposobów. Po pierwsze, może tam być od początku: Mechanizm ten, zwany "provisioning", to metoda znana z telefonicznych Androidów: "zbundlowane" aplikacje, niemożliwe do odinstalowania bez zrootowania telefonu. Są dodawane do systemu w fazie offline.

Na szczęście, nie trzeba rootować Windowsa, żeby otrzymać w nim prawa administracyjne. Dzięki temu, wbudowane aplikacje (provisioned APPX packages) da się odinstalować, albo przez DISM w trybie offline, albo przez PowerShell, jako administrator, w trybie online. Nie dotyczy to aplikacji będących częścią systemu (InfusedApps i SystemApps), tych nie da się usunąć bez wyrządzania poważnych szkód.

Drugim sposobem, na jaki aplikacja może się pojawić w WindowsApps jest jego instalacja. W oryginalnym zamierzeniu miało to być możliwe wyłącznie przez Sklep, obecnie możliwe jest także instalowanie pakietów MSIX dwuklikiem, a także instalacja plików APPXBUNDLE za pomocą cmdletu "Add-AppPackage" środowiska PowerShell.

Jest jednak jeszcze jedna metoda instalacji pakietów APPX. Chodzi o staging, czyli przygotowanie do późniejszego użycia. Ten osobliwy tryb serwisowania polega na zainstalowaniu aplikacji w bazie, ale nie u któregokolwiek użytkownika. Żaden użytkownik, także administrator, nie może jej usunąć, ponieważ teoretycznie nie jest zainstalowana. Leży sobie tylko. Ale ponieważ mowa o Windowsach, gdzieś na peryferiach systemu plików znajduje się jakaś binarna baza, która "wie" o tej aplikacji. Przez co jej usunięcie uszkodzi Sklep.

Naturalnie, stage'owane pakiety to problem. Systemu, który je zawiera, nie da się poddać procedurze sysprepowania, czyli przygotowania obrazu uogólnionego, na potrzeby masowych wdrożeń. Niejasny stan aplikacji sprawia też, że jej obecność uniemożliwia przeprowadzenie przywracania systemu. Stage'owanie aplikacji to zatem przymusowe wrzucanie ich do komputerów o specjalnym przeznaczeniu, nie powinno zachodzić spontanicznie.

Laptop jest więc opętany przez Siły Zła. Nie ma lepszego wytłumaczenia. Co więcej, wspomniane Siły Zła zawiązały najwyraźniej sojusz z Siłami Ironii, ponieważ jeszcze kilka dni wcześniej mocno krytykowałem użycie narzędzi typu FRST. Co prawda miałem na myśli używanie ich do prób naprawy systemów, które powinno się zaorać (a ten system zdecydowanie należało zaorać), no ale wciąż.

Co pobrało owe paczki? Otóż… BITS.

[code]2020-12-13 23:39:01:811 416 f20 Report REPORT EVENT: {0B7F1013-3CF4-4931-A5A1-9BA36576F46F}2020-12-13 23:38:56:780+01001 189[AU_NONDEADLINE_INSTALL_READY]102 {00000000-0000-0000-0000-000000000000} 0 0AutomaticUpdates Success Content Install Installation Ready:The following updates are downloaded and ready for installation: - 24712m1dfmmengesha.TestFrameworkwin81appxneutral06 - microsoft.windowscommunicationsapps[/code]

Windows pobrał je sam. Żaden komponent nie skłonił systemu do zaciągnięcia podejrzanych plików znikąd. Windows 8.1 samodzielnie pobrał bardzo podejrzane paczki, twierdząc że są składnikiem systemu wymagającym aktualizacji. Ponadto, źródłem żądania był Windows Update, a pochodzeniem paczek istotnie był (niedziałający!) Sklep Windows.

A zatem Siły Zła robią zakupy w Sklepie-Widmo… Tak, to wszystko ma sens! Jakiś. Być może. Pozostało odkryć, skąd wzięły się owe Siły Zła i dokonując cyfrowych egzorcyzmów, odesłać je ponownie w otchłań piekieł. Nadszedł więc czas polowania na duchy (z rozszerzeniem .appx).

Ciąg dalszy już jutro