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

Jaki ekwipunek jest potrzebny do polowania na duchy, jeżeli opętają one laptopa? Na pewno należą do niego: ocean cierpliwości, cache wyszukiwarki Google, kawa w nieprzyzwoicie dużych ilościach i kilka pendrive'ów, wśród których co najmniej jeden zawiera jakiegoś bootowalnego Linuksa. Z powyższego zestawu bezsprzecznie jednak najważniejsza jest cierpliwość. Jeżeli ktoś nie jest gotów poświęcić sześciu godzin na upolowanie diabła dźgającego Windows Update, nie nadaje się do wypędzania sił nieczystych z elektroniki.

Warto w tym miejscu nadmienić, że wola poświęcania absurdalnie dużych ilości czasu jest niezbędna w pewnych dziedzinach IT. W niektórych bardziej, niż w innych. Na przykład, naukę programowania można rozłożyć sobie na "lekcje" i podchodzić do niego metodycznie. Dzięki temu nie pochłonie to całego dostępnego czasu. Ale gdy rozpocznie się jakiś większy, własny projekt, a podczas prac nad nim wpadnie na odpowiednie tory koncentracji, trzeba zacząć sobie nastawiać budzik. Ale nie po to, by wstać, tylko żeby pamiętać, żeby położyć się spać.

Wysiłki te da się jednak ująć w pewne ramy oczekiwań czasowych. Projekty mają pewien, przynajmniej ogólnie określony, cel. Przystanek końcowy. Polowanie na awarie, szukanie dziur w oprogramowaniu i śledzenie incydentów sieciowych to literalnie praca bez końca. Gdy pociągnie się za jakiś nieszczęśliwy sznurek, można utknąć w jałowych analizach na tygodnie.

Z takiego binge'owania wychodzi się jednak zaopatrzonym w tajemną wiedzę, którą trudno wpisać do CV, ale która pozwala znaleźć swoje miejsce w firmowym zespole "Ghostbusters": ludzi wołanych do naprawy rzeczy zachowujących się w niemożliwy do okiełznania sposób. To cenne. Oczywiście, Sklep Windows 8.1 nie jest, być może, wzorcowo optymalną inwestycją czasu i sił, ale chodzi tu pewien sposób myślenia. Najłatwiej to zrozumieć tym ludziom spoza IT, którzy nie potrafią się położyć spać bez dokończenia krzyżówki lub doczytania rozdziału książki do końca.

Poza tym, trzymanie opętanej elektroniki w domu jest niezdrowe i może się prowadzić do krótkowzroczności, weganizmu i mańkuctwa.

Od czego zacząć? Od przejrzenia wnętrzności pobranych aplikacji. Rozmiar żadnej z nich nie przekracza 64 kilobajtów, a te nazywające się "vasetest101" nie dostarczają niczego poza bibliotekami uruchomieniowymi Visual C++ 2013 (podpisanymi przez Microsoft), aczkolwiek w wersji Preview. Ten Preview okaże się cenną wskazówką, ale na tym etapie jeszcze o tym nie wiedziałem. Czas zająć się pakietami, które dostarczyły jakiekolwiek mięso, poza bibliotekami.

Na początek najmniejszy. Pakiet "UniversalFmwkAppPackageBase" okazał się być naprawdę "Base": miał rozmiar 19 kilobajtów i to z symbolami debugowania! Zupełnie tak, jakby ktoś stworzył nowy projekt w Visual Studio, nacisnął od razu Build, a następnie wrzucił cokolwiek powstało od razu do Sklepu. Wewnątrz pliku EXE, ze względu na obecność symboli debugowania, znajdowała się ścieżka do pliku PDB. Zawierała ona cenną wskazówkę, brzmiała bowiem "c:\Users\v-mimeng\Documents".

V-mimeng! Gdybym miał strzelać, to obstawiałbym, że to nie maszyna jakiegoś programisty, a serwer buildowy, a mimeng to nazwa zespołu, do którego on należy. Co oznacza? "Eng" to niewątpliwie Engineering, a "mim"… Modern Immersive (wewnętrzna nazwa aplikacji WinRT)? Nie wiem, strzelam. Ale to nie szkodzi. Zawsze jest to jedna fraza więcej do późniejszego wyszukiwania podczas wykopalisk w Google'u.

Przedrostek "v" nie jest mi obcy. Spotkałem się z określeniem "v-team" (vetting team) jako nazwą zespołu sprawdzającego, czy dostarczany składnik jest inżynieryjnie kompletny. Vetting team różni się od zwykłych testerów. Ci drudzy sprawdzają, czy dostarczane oprogramowanie nie jest przypadkiem przekombinowanym dziadostwem, które umieją obsługiwać tylko programiści. V-team sprawdza z kolei, czy dostarczane API pozwalają wyciągać za pomocą aplikacji obiecaną funkcjonalność.

Ale póki co, są to czyste spekulacje.

Aplikacje "TestFramework" dostarczają kolejnych wskazówek. Wewnętrzne nazwy plików w środku to "PurchasableIAPButtons". Łańcuchy tekstowe, wyłączając nazwy używanych API .NET 4.5.1, zawierają zwroty "Purchased", "Available" oraz "IAPs not available". IAP oznacza, jeżeli ktoś się nie domyślił, "in-app-purchase". Jest to API do umieszczania przycisków pozwalających na mikropłatności. Wspomniana aplikacja wydaje się nie robić nic poza próbą odpytania Sklepu o zaoferowanie jej takich przycisków. Robi to zarówno aplikacja autorstwa "KiddoTest", jaki "m1dfmmengesha". Obie mają w swoich ścieżkach PDB nazwę "v-mimeng", co wskazuje że wszystkie są ze sobą związane.

Udało się zebrać kilka haseł, które nadają się na frazy do namiętnego odpytywania Google'a. Może uda się odnaleźć ducha, który przejął systemowy Sklep (który wciąż, przypomnę, nie działał!), skoro wiemy być może, jak ma na imię?

Wpisanie w Google pełnych nazw wspomnianych aplikacji daje bardzo mało wyników. Jest ich poniżej dziesięciu i dzielą się na trzy kategorie:

logi z FRST i prośby o przeanalizowanie ich pod kątem wirusówpytania "co to jest, bo sysprep mi nie działa" zadawane (bez odpowiedzi) przez administratorówkod skryptu do oczyszczania systemu, leżący na GitHubie

Pierwszą kategorię można prędko skreślić jako zwykły szum informacyjny. Osoby potrzebujące "analizy logów" są zazwyczaj użytkownikami, którzy pobierają i instalują rzeczy niemalże z pogranicza rzeczywistości. Być może wyszukiwane aplikacje znajdują się w ich logach, ale towarzyszy im aktualizator Javy z 2003, Corel Media Folders Indexer 8, dwie wersje Worksa, najnowszy pakiet Adobe CC oraz kontroler obrotów do wiatraczka na USB z pozytywką.

Trudno nawet próbować wyobrazić sobie, jak przebiega użycie takich urządzeń, toteż wspomniane logi należy rozpatrywać w kategorii skamieniałości dinozaurów. Wszak wszyscy wiemy, że zostały one rozsypane prze Boga 4000 lat temu, aby testować naszą wiarę. Logi FRST także testują naszą wiarę. W ludzkość.

Pozostałe wyniki Google dostarczają więcej informacji. Skromna liczba rezultatów FRST dowodzi, że aplikacje te nie są dystrybuowane powszechnie. Wątki wskazujące na to, że przeszkadzają one głównie administratorom każą zakładać, że to głównie obrazy o dość niestandardowym procesie przygotowania okazują się być w nie zaopatrywane. Problemy z sysprepowaniem są z kolei poszlaką wskazującą na to, że u każdego owe aplikacje-śmieci pojawiły się w ten sam sposób: staging jako SYSTEM, bez możliwości łatwego usunięcia.

Mój obraz także został przygotowywany administracyjnie. Zawierał najnowsze aktualizacje LCU i SSU, a także .NET Framework 4.8, ale poza tym – około setki łatek wydanych od czasu Update 3. Dotyczyły one bardzo wielu składników, jak obsługa surface, Journal, Sklep, kodeki do kamerek itd. Nie byłoby w ogóle dostępne, gdyby Microsoft zdecydował się wydać kumulatywne Update 4, albo chociaż integrował łatki z oficjalnym ISO, dostępnym do pobrania. Niestety, od 2016 roku, a więc dwa lata przez zakończeniem głównego wsparcia technicznego, obraz nie jest aktualizowany.

Z kolei dorzucenie nazw aplikacji do skryptów oczyszczających oznacza, że można je uznawać za w jakiś sposób "fabryczne". Zbiór skryptów Tron próbuje je usuwać, choć wzbogacono go o tę możliwość dopiero niedawnym commitem. Postanowiłem zapytać autora skryptu, skąd wziął nazwy tych dziwacznych aplikacji. Skoro opracował metodę ich usunięcia, może wie coś więcej o ich pochodzeniu?

Googlowanie pozostałych słów kluczowych zaczęło przynosić lepsze wyniki. Okazało się, że Windows 8 dorobił się "nieoficjalnych" stron ze Sklepami tak samo jak Android. Na stronach tych można odkryć kopie usuniętych ze Sklepu aplikacji, a także przeczytać więcej szczegółów o samych pakietach. Strony te powoli przestają istnieć, ale wciąż pokazują się w wynikach wyszukiwania i są obecne w Google Cache. Udało się dzięki temu wyszukać kilka aplikacji, lekko zmieniając ich nazwy (kropki, podkreślenia, wersje…)

Wśród wyników znajdował się na przykład taki opis: "VmimengTestPurchasableIAPButtons: 6/9/2015 publish the app since new IAPs added. To be used by v-team to test IAP downloads."Świetnie. Zatem wiemy coraz więcej. Adresy kontaktowe to Microsoft oraz Bing. Wszystko wskazuje więc na to, że złowrogie aplikacje-śmieci pochodzą z Microsoftu i zostały pobrane przez Windowsa samodzielnie, bez ingerencji złośliwego oprogramowania. Autor "mmengesha" to prawdopodobnie nazwisko jednego z programistów, pracujących w Microsofcie w momencie opublikowania aplikacji. Tak mówi LinkedIn, ale to w zasadzie też spekulacja.

W międzyczasie odezwał się autor skryptu Tron. Wpisane nazwy to, jak się okazało, "member contributions", a więc nie wiadomo o nich nic więcej, poza tym że istniało kilka osób, u których aplikacje te pojawiły się spontanicznie. Trop więc urywa się, ale w kwestii pochodzenia aplikacji udało się już opracować całkiem spójną hipotezę roboczą.

Pozostało już tylko odkryć, co wywołuje ich pobranie. Przygotowałem więc kolejny obraz instalacyjny, integrując już tylko podstawowy zbiór aktualizacji: SSU, LCU, CU dla Internet Explorera, .NET 4.8, RSAT, Flash, Intel Microcode, Camera Codec Pack i PowerShell. Pozostawiłem sto-kilka aktualizacji oferowanych przez NTLite w spokoju. Założenie było takie, że Windows Update po instalacji zgłosi około sześćdziesięciu aktualizacji. Różnica względem NTLite'a oznaczałaby, że istnieje zbiór łatek "na specjalne okazje", które są oferowane bardzo niewielu użytkownikom i które dostarczają właśnie takich nieprzewidzianych przygód.

Istotnie, reinstalacja, a następnie podpięcie systemu do internetu, zakończyły się pobraniem 67 brakujących aktualizacji (dwukrotnie, bo dorzuciłem pakiet językowy). 48 godzin później nie pojawiły się żadne dziwne aplikacje, a w WindowsApps nie znajdowały się także "PlayReadyInternal_2.1" oraz "WinJS_Internal". Choć nie udało się znaleźć konkretnej aktualizacji, która za to odpowiada, inwazja sił nieczystych została okiełznana.

Czysta instalacja Windows 8.1 nie sprawiała już problemów, hipoteza o sterownikach okazała się… błędna, a nadający Kevina multiplekser nawet udało się ustawić przez WMC w tej podmiejskiej dziurze. No i Sklep zaczął działać! Rozsądek podpowiada, że po prostu go naprawiono, ale doświadczenie z cyfrowymi egzorcyzmami każe zakładać, że gdyby system dalej był opętany, Sklep pozostałby offline. Ponieważ komputery zasilane są magią, a ich zachowanie jest nieprzewidywalne, tajemnicze i złowrogie.

🎄