Wpisy z tagiem: konsola

Jak wyglądała historia zabezpieczeń konsoli Xbox?
• Pierwsza konsola posiadała tak zwany** ukryty ROM**. Był to bardzo mały kod, którego celem była inicjalizacja pamięci oraz odszyfrowanie i załadowanie kolejnego, drugiego bootloadera. Ten mały kod zawierał zatem klucze szyfrujące, które miały ochronić konsolę przed atakami. Bez ich znajomości nie można stworzyć nowego, alternatywnego oprogramowania, które zostałoby zaakceptowane przez konsolę.
• Te 512 bajtów znajdowało się w mostku południowym, który komunikował się z procesorem za pomocą szyny Hyper Transport. Jej podsłuchanie wydawało się skomplikowane i wymagało drogiego, zaawansowanego sprzętu. Ale pewien doktorant, Bunnie, który zajmował się tematem szybkiego przetwarzania danych, stworzył swój własny sniffer – czyli urządzenie pozwalające na pozyskanie i analizę informacji. Tak pozyskano klucze szyfrujące.
• Jednak nie wszyscy chcieli z nich korzystać. Nielegalne liczby to takie wartości, których teoretycznie, z prawnego punktu widzenia, nie można posiadać/używać. Zaczęto szukać innych rozwiązań. Gdy suma kontrolna odszyfrowanego bootloadera nie zgadzała się – konsola przerywała swoją pracę. To znaczy – miała przerywać, bo okazało się, że tak nie jest. Wynikało to z faktu, że pierwsze prototypy wykorzystywały procesory AMD. Chwilę przed premierą jednak zmieniono je na produkty Intela. Teoretycznie procesory były ze sobą kompatybilne, ale czasami występowały w nich drobne różnice. A nikomu nie przyszło do głowy sprawdzić, czy po zmianie wszystko działa prawidłowo.
• Później znaleziono błędy w obsłudze zapisów stanu gry różnych produkcji. Odpowiednio manipulując plikiem z „save'm” można było wykonać zdalny kod na konsoli. Było to jednak problematyczne. Po pierwsze, należało posiadać oryginalną kopię podatnej gry. A po drugie – z każdym uruchomieniem konsoli trzeba było uruchomić grę i wczytać odpowiedni plik. A to trwało.
• Gdy w napędzie nie było płyty – z dysku twardego uruchamiał się specjalny plik – dashboard. Nie można go było podmienić na inny – bo konsola sprawdzała, czy został on stworzony przez Microsoft. Tylko, że program ten ładował inne zasoby: grafiki, dźwięki i czcionki. Z czasem znaleziono błąd w obsłudze czcionek. Teraz wystarczyło tylko zapisać na dysku specjalny plik aby uruchomić zewnętrzny kod.
• Xbox 360 to lepiej zabezpieczona wersja konsoli. Wprowadzono nową technologię – eFuses. Były to specjalne „bezpieczniki”, które przy użyciu odpowiedniej komendy można było „przepalić”. Raz spalonych bezpieczników nie dało się przywrócić. W ten sposób konsola mogła na stałe zapisać różne informacje. Dzięki temu można było zapobiec instalacji starszej wersji oprogramowania.
• Najsłabszym elementem konstrukcji był napęd. To on decydował czy płyta jest oryginalna i przesyłał informację do procesora. Komunikacja ta była zabezpieczona. Konsola i napęd posiadały ten sam, unikalny, losowy klucz, który był generowany podczas procesu parowania. Właśnie przez to nie można było wyjąć napędu z jednego urządzenia i przenieść do drugiego.
• Zaczęto modyfikować oprogramowanie napędów. Xbox wykorzystywał kilka napędów różnych firm. Ataki różniły się drobnymi szczegółami. Generalnie należało odczytać unikalny klucz, a następnie przejść do specjalnego trybu serwisowego i zapisać nowy, zmieniony firmware. W każdej rewizji metody były coraz trudniejsze. W pewnym momencie należało „przeciąć” ścieżki na płytkach PCB.
• Najtrudniejszym, ekstremalnym pomysłem był „kamikaze hack”. Microsoft zablokował możliwość aktualizacji oprogramowania i ukrył pamięć w innym chipie a całość zalał żywicą (aby utrudnić do niego dostęp). Ktoś zauważył jednak, że wiercąc malutką dziurkę w układzie (oczywiście w odpowiednim miejscu) – można było usunąć blokadę zapisu. Możesz sobie wyobrazić jak wiele napędów uległo zepsuciu przez nieuważne korzystanie z wiertarki.
• Po drodze zmieniono format płyt. Zapisywano dużo więcej danych niż normalnie. Początkowo domowe nagrywarki nie chciały wypalać danych tak blisko końca płyty. Później, w zabezpieczeniu AP 25 konsola zadawała napędowi pytanie o topologię płyty. Pirackie kopie nie posiadały tych danych. Oryginalne płyty tłoczono w tłoczniach i można było na nich (oprócz danych gry) nanieść pewne dodatkowe informacje. Z czasem jednak znaleziono rozwiązanie i na ten problem.
• W tej konsoli również wykorzystywano problemy powiązane z grami. W grze King Kong używano specjalnego pliku - shadera. Można było przy jego pomocy uruchomić dowolny kod. Był tylko jeden problem – plik ten musiał znajdować się na płycie z grą. Aby więc móc korzystać z tej metody – trzeba było posiadać przerobiony napęd (bo przecież oryginalna konsola nie działała z podróbkami).
• Microsoft wysadził bezpieczniki aby uniemożliwić przywrócenie starego, podatnego oprogramowania. Konsola sprawdzała pewien hash literka po literce. Fakt ten wykorzystano w Timing Attack. Mierzono tam czas jaki zajęło konsoli zweryfikowanie ciągu znaków. Im więcej bajtów się zgadzało – tym dłużej trwało sprawdzanie. Mówimy tu o bardzo małych – ale możliwych do zmierzenia wartościach. Tak ominięto to zabezpieczenie.
• Z czasem powstał „reset glitck attack”. Procesor to zaawansowana konstrukcja. Ufamy, że za każdym razem zachowuje się tak samo. Nie chcemy przecież aby wyniki dodawania były różne. Istnieją jednak specjalne urządzenia, które pozwalają „glitchować” procesor. Wtedy zachowuje się on nieco inaczej. Na przykład pomija jakiś warunek i wykonuje inny kod niż zazwyczaj. Dzięki temu można było ominąć warunek sprawdzający oprogramowanie i wykonać zdalny kod.

Więcej o zabezpieczeniach opowiadam w filmie:

Od dłuższego czasu zbierałem się, żeby zrobić update mojego grammar checkera - w ten weekend się udało!

Wreszcie dodałem elementy, których mi brakowało:

• obsługa markdownu,
• lepsza integracja z Gitem (hooki),
• zmienne środowiskowe w configach,
• lepsza dokumentacja,
• lepsza obsługa błędów,
• milion drobnych usprawnień,
• logo ;)

Jak ktoś nie widział wcześniejszego posta (dawno to było) to w skrócie co to potrafi:

• zaawansowane sprawdzanie pisowni za pomocą LanguageTool,
• obsługa zdalnych API (domyślnie api.languagetool.org) i możliwość użycia lokalnego serwera (zautomatyzowana instalacja),
• wszystko interaktywnie w konsoli,
• dostępne jako pakiet NPM lub jako pojedyncze binarki (Windows, Linux, MacOS).

Używam na co dzień od dwóch lat (głównie do sprawdzania commitów, teraz także do README wszelakich).

Jak ktoś chce poczytać więcej to zapraszam na GitHub

Demko poniżej.