Zabrałem się za zabawy z firmwarem, którego celem jest dodanie wsparcia pamięci EEPROM adresowanych wordem a nie bajtem. Odkąd mogę testować swoje hacki bezpośrednio na urządzeniu, całą uwagę mogę poświecić na tych zadaniu, skupiając się na analizach i eksperymentach.
Moje urządzenie, jak i oryginalna wersja posiada pamięć EEPROM, która FX2 używa do różnych celów, między innymi do bootowania. Jest to pamięć szeregowa z serii AT24Cxx z komunikacją po magistrali I2C. A istotnymi różnicami między oryginałem a klonem (lub płytka developerską) jest wersja użytej kostki.
Kolejny odcinek z serii SaeLog odnośnie hackowania sprzętu i oprogramowania (głównie) analizatora logicznego. Od ostatniego wpisu minęło sporo czasu, dokładnie 4 miesiące. Jakoś tak się złożyło, że nawał obowiązków i innych spraw (wyjazdów, urlopów i przede wszystkim praca) nie pozwoliły mi szybciej wrócić do tego tematu. Ale udało się i mam nadzieję, że kilka kolejnych wpisów oznaczonych tagiem #SaeLog w miarę szybko się pojawi.
Korzystając z informacji zawartych w SaeLog#4 bez problemu udało mi się wyekstrahować kod firmware-u z aplikacji.
Wydobywając kod firmware z kodu procesu Sealogic (SaeLog #4), w jednym z możliwości związanych z hookowaniem transmisji USB, wspomniałem o technice wstrzykiwania kodu do uruchomionego procesu, wykorzystującej popularną metodę ze zdalnym wątkiem (CreateRemoteThread). Sugerując przy tym wykorzystanie dostępnych w sieci injectorów lub napisanie czegoś własnego. Od tego czasu, w wolnych chwilach, próbowałem okiełznać i uporządkować mój kod, jaki używałem do tego typu zabaw. W istocie zrodził się projekt syringe, jako uniwersalnego narzędzia związanego z wstrzykiwaniem kodu i nie tylko… i tak zacząłem pisać stary/nowy kod…
W kodzie Windowsa można znaleźć czasem ciekawe fragmenty, które skrywają pomocne mechanizmy i sposoby ułatwiające debugowanie różnych elementów, nie tylko systemowych. Część, jeśli nie wszystkie, takie wstawki nie są nigdzie udokumentowane. Zatem nic dziwnego, że dziś znów trafiłem na kolejny taki trick w kodzie systemowym. Mowa tutaj o conditional breakpoint przy ustawianiu kodu błędu, co może być bardzo pomocne przy ciężkim debugowaniu nieszczęśliwych przypadków.
Większość systemowych funkcji, ale nie tylko takich, w razie błędu ustawia odpowiednią wartość nie-zerową, określającą zaistniałą sytuację.
Mała przerwa od serii zabaw kodem analizatora logicznego. W ostatnim wpisie o ekstrakcji kodu firmware (SaeLog #4) wspomniałem o kilku innych, ciekawych tematach. Jednym z nich była kwestia związana z przechowywaniem stałych danych w sekcji .rdata, o których teraz chciałbym nieco więcej powiedzieć. A szczególnie o tym jak pisanie kodu rzutuje na generowany przez kompilator/linker plik wynikowy.
Sekcje i segmenty w PE i innych Pliki binarne zawierające kod wykonywalny (executables), czyli zwykle exe, biblioteki DLL, czy pliki obiektowe (a także kilka innych) w większości systemów są zbliżone do siebie formatem lub budową.
Chcąc zajrzeć do kodu firmware zaszytego w urządzeniu Saleae Logic, trzeba go najpierw jakoś zdobyć. Kod ten w typowej aplikacji USB-FX2 ładowany jest do urządzenia po uprzednim jego wykryciu przez oprogramowanie zainstalowane na komputerze, wprost poprzez port USB. Idąc tym tropem można być pewnym, że znajdzie się go gdzieś w paczce z aplikacją lub w samym kodzie programu. Przyszła więc pora na jego wydobycie, bez tego nie będzie możliwa dalsza zabawa…
Już od jakiegoś czasu przyglądałem się kodowi zaszytemu w chipie oraz starałem przypomnieć sobie asemblera 8051. Robiąc sobie małą przerwę od analizy firmware, całkiem przypadkiem trafiłem na małą niespodziankę. Po odłączeniu pamięci EEPROM (wyjęcie zworki) już po wykryciu i załadowaniu oprogramowania do układu, nie stwarza żadnych widocznych problemów z softem. Aplikacja się nie wywala i wydaje się działać poprawnie. Mimo, iż CY7C68013A będzie odpowiadał na odczyty z I2C spod adresu 0xA0 jakimiś losowymi danymi-śmieciami.
Jedną z pierwszych rzeczy niezbędnych do rozwiązania problemu, a może tylko do poznania mechanizmu działania komunikacji programu z pamięcią EEPROM, jest analiza funkcji, które za to odpowiadają. Obiekt LogicAnalyzerDevice udostępnia dwie metody do służące do tego celu, są to ReadEeprom i WriteEeprom. Wspominałem już o nich w poprzedniej części, ale dopiero niedawno udało mi się im bliżej przyjrzeć i wyłonić obraz ich działania. Dodatkowo w czasie analizy, pojawiło się kilka ciekawych, związanych z tymi funkcjami aspektów.
Nowe wersje oprogramowania dla analizatora logicznego Saleae Logic mają problemy z obsługą nieoryginalnego sprzętu opartego na prostej aplikacji kostki CY7C68013A, w którym zastosowano większą pamięć adresowaną wordem. Napomknąłem o tym problemie w poprzedniej notce przy okazji testów płytki deweloperskiej z układem Cypressa w roli analizatora logicznego. Obiecałem sobie również, że spróbuje rozwiązać ten problem programowo, zamiast sprzętowo. Bez ingerencji lutownicą i wymiany pamięci EEPROM, ale za to ingerując w oprogramowanie. Zatem zabrałem się do tego celu, zaglądając do środka programu Logic, aby sprawdzić co się tam w środku dzieje.
Szukając jakiegoś szybkiego narzędzia mogącego zastąpić w działaniu prawdziwy analizator stanów logicznych, trafiłem na wiele modeli klonów, głównie chińskiego pochodzenia, ogólnie znanych producentów tego typu narzędzi, jak Saleaee czy USBee. Większość tych układów (klonów i oryginałów) bazuje na układach Cypressa EZ-USB FX2LP. Drążąc ten temat, znalazłem ciekawą płytkę deweloperską chińskiej firmy Lcsoft, będącej w rzeczywistości typową aplikacją układu CY7C68013A firmy Cypress. Sądząć po zawartości strony producenta, prezentującej układ, płytka ta powstała głównie w celu stworzenia taniego klona Saleae Logic.