Dwa stare Fujitsu PRIMERGY RX100 S5, oba z kontrolerem iRMC S2, oba bez licencji Advanced Pack. Zdalne włączanie działało, podstawowe zarządzanie też. Konsola graficzna AVR/KVM i Remote Storage pozostawały zablokowane.

Zamiast szukać cudzych kluczy, przeanalizowałem firmware i eksport konfiguracji własnego kontrolera. Udało się odtworzyć algorytm, wygenerować klucz i uruchomić brakujące funkcje. Ten sam klucz zadziałał na dwóch serwerach, przetrwał restarty oraz przełączenie banku firmware. Przez zdalną konsolę i podłączony obraz instalacyjny postawiłem nawet system.

Potem pozostała Java. Bo najwyraźniej samo odblokowanie funkcji byłoby zbyt proste.

iRMC S2 a iRMC S3, S4 i S5 — najpierw porządek w nazwach

Ten opis dotyczy Fujitsu iRMC S2 w serwerach PRIMERGY RX100 S5. Oznaczenie „S5” w nazwie serwera nie oznacza kontrolera iRMC S5.

To istotne przy wyszukiwaniu informacji o iRMC license key, Advanced Pack, AVR czy Remote Storage. Internetowe opisy mieszają generacje, a część wyników dotyczy późniejszych kontrolerów, w tym iRMC S5, zamiast starego S2. W przeanalizowanych materiałach znalazł się również przykład algorytmu dla iRMC S4 — z innym nagłówkiem i układem danych.

Nie dało się więc po prostu przekleić gotowej metody.

Poniższy sposób został sprawdzony na dwóch egzemplarzach RX100 S5 z iRMC S2. Nie mam potwierdzenia, że zadziała na iRMC S3, iRMC S4 ani iRMC S5. Podobieństwo użytej kryptografii nie oznacza zgodności kluczy.

1. Analiza pakietu firmware iRMC S2

Punktem wyjścia był pakiet aktualizacyjny dla RX100 S5:

  • dcod571A.bin — firmware iRMC S2 w wersji 5.71A;
  • 0225343.SDR — dane sprzętowe;
  • bootloader i programy aktualizacyjne;
  • pełny eksport konfiguracji własnego kontrolera;
  • dodatkowy eksport obejmujący wyłącznie sekcję licencji.

Analizę zacząłem statycznie, bez flashowania. Obraz firmware miał około 5 MB i zawierał kod ARM/Thumb, teksty interfejsu oraz archiwa JAR klientów zdalnego dostępu.

Eksport samej sekcji licencji był praktycznie pusty. Pasowało to do urządzenia bez Advanced Pack. Pełny eksport konfiguracji okazał się później znacznie bardziej przydatny.

Przy okazji trzeba było oddzielić dwie rzeczy: uprawnienie konta do AVR oraz licencję kontrolera. Administrator może mieć zaznaczoną możliwość korzystania z konsoli, ale bez licencji urządzenia samo zaznaczenie pola niczego nie odblokowuje.

2. Od formularza licencji do odszyfrowania klucza

W firmware odnalazłem kod obsługujący formularz wprowadzania klucza. Dalej prześledziłem kolejne wywołania.

Kontroler wykonuje następujące operacje:

  1. Przyjmuje tekst klucza.
  2. Dekoduje go z Base32.
  3. Odszyfrowuje 16-bajtowy blok.
  4. Sprawdza nagłówek SE01.
  5. Odczytuje maski funkcji oraz pole związane z ważnością.
  6. Scala uprawnienia z istniejącym stanem i zapisuje wynik.

Klucz Advanced Pack jest więc zaszyfrowanym zestawem danych, który iRMC S2 przetwarza lokalnie. W prześledzonej ścieżce nie było potrzeby kontaktowania się z serwerem aktywacyjnym producenta.

3. AES, HMAC-SHA1 i brakujące 16 bajtów

Z deasemblacji udało się ustalić mechanizm kryptograficzny:

  • AES-128-CBC, bez dopełnienia;
  • stały, 16-bajtowy IV zapisany w firmware;
  • klucz AES wyprowadzany przez HMAC-SHA1.

Klucz AES powstaje z pierwszych 16 bajtów wyniku:

HMAC-SHA1(parametr_konfiguracji, wiadomość)

Wiadomość ma 64 bajty. Składa się z czterech powtórzeń bloku:

"SE000001"
+ 01 01
+ 4 bajty tabeli sprzętowej
+ 2 bajty tabeli sprzętowej

Największą niewiadomą był 16-bajtowy parametr spod logicznego offsetu konfiguracji 0x10C7. To adres w przestrzeni konfiguracji kontrolera, a nie offset pliku firmware.

Bez ustalenia tego parametru znajomość samego AES niewiele dawała.

4. Brakujący parametr znalazłem w eksporcie konfiguracji

Prześledziłem inicjalizację struktury konfiguracji. Kod mógł korzystać ze wskazanego bloku albo z wartości domyślnych zapisanych w firmware.

Domyślna struktura znajdowała się pod offsetem pliku 0x242C16. Potrzebny parametr wypadał pod 0x243CED.

Następnie porównałem go z pełnym eksportem własnego kontrolera. Te same 16 bajtów występowało pod offsetem 0x1411. Zgodność nagłówka i większego fragmentu otaczającej konfiguracji pozwoliła potwierdzić mapowanie.

Brakujący element od początku leżał więc w posiadanych plikach. Nie potrzebowałem zrzutu RAM ani dostępu do pamięci przez programator.

Osobno odtworzyłem wybór tabeli sprzętowej z pliku SDR. W analizowanym 0225343.SDR domyślna tabela zaczynała się pod offsetem 0x48. Z niej pochodziły pozostałe bajty wejściowe HMAC.

5. Zbudowanie klucza Advanced Pack dla iRMC S2

Po ustaleniu danych wejściowych przygotowałem 16-bajtowy blok licencji:

Offset Zawartość
0–3 Nagłówek ASCII SE01
4–7 FFFFFFFF
8–9 Maska funkcji czasowych: 0000
10–11 Maska funkcji bezterminowych: 0001
12–15 00000000

Pola liczbowe są zapisane jako little-endian.

Kod pokazywał, że wartość FFFFFFFF uruchamia specjalną ścieżkę obsługi ważności. Maska z offsetu 10 jest sprawdzana bez kontroli czasu, a znalezione wywołania kontroli funkcji przekazywały bit 1.

Tak przygotowany blok zaszyfrowałem przez AES-128-CBC, a wynik zakodowałem w Base32. Powstał klucz:

PEFQIFZPIERRHODZCPQUY2IY3E

Generator przeszedł test znanej odpowiedzi AES, test Base32 oraz sprawdzenie, czy odszyfrowanie wyniku odtwarza wejściowy blok.

To potwierdzało poprawność lokalnych obliczeń. Dopiero urządzenie mogło potwierdzić zgodność z implementacją iRMC S2.

6. Aktywacja na dwóch serwerach i test obu banków firmware

Po wpisaniu klucza kontroler wyświetlił:

You do have a valid permanent license key installed

Następnie ten sam klucz zadziałał na drugim RX100 S5.

Sprawdziłem również działanie odblokowanych funkcji:

  • konsola AVR/KVM pokazywała obraz i pozwalała sterować serwerem;
  • Remote Storage pozwalał podłączyć zdalny nośnik;
  • przez konsolę i podłączony obraz udało się zainstalować system;
  • licencja oraz funkcje pozostały aktywne po restartach;
  • przełączenie banku zmieniło wersję firmware, ale klucz nadal działał.

To ostatnie potwierdza, że w sprawdzonej konfiguracji licencja nie była związana wyłącznie z jednym bankiem firmware. Sam test nie ustala fizycznego miejsca jej przechowywania, ale praktyczny wynik jest jasny: zmiana banku jej nie usunęła.

W odtworzonym obliczeniu nie podstawiałem MAC ani numeru seryjnego. Korzystałem z parametru konfiguracji i pól SDR. Działanie na dwóch urządzeniach jest potwierdzone; uniwersalność dla wszystkich modeli iRMC S2 pozostaje niesprawdzona.

7. Jak uruchomić konsolę iRMC S2 przez Java Web Start

Po aktywacji Advanced Pack pojawiła się następna przeszkoda: stary klient Java.

Konsola AVR korzysta z Java Web Start. Strona iRMC dostarcza plik .jnlp, wskazujący archiwum:

avr_iRMC_S2.jar

i klasę startową:

com.serverengines.mahogany.MahoganyViewer

Plik JNLP zawiera również adres kontrolera, porty oraz dane sesji. Do kolejnych prób najlepiej pobierać świeży plik z panelu iRMC. Pełnego JNLP nie należy wrzucać do publicznych zgłoszeń błędów — parametry sesji nie są potrzebne do opisywania problemu z Javą.

Gdy pojawia się okno Java Web Start, przeglądarka wykonała już swoją część zadania. Komunikat o blokadzie podpisu trzeba wtedy rozwiązać po stronie środowiska Java.

Dla appletów uruchamianych bezpośrednio w przeglądarce historycznym rozwiązaniem jest Firefox 52.9.0 ESR 32-bit z Javą 32-bit. Przy pobranym pliku JNLP wtyczka przeglądarki nie jest potrzebna — plik uruchamia Java Web Start, czyli javaws.exe.

8. Java 8u151 i błąd podpisu MD5withRSA

W użytej instalacji Java 8 Update 151 aplikacja początkowo kończyła pracę komunikatem:

Unable to launch the application

Bardzo pomocne. Prawie jak „nie działa, bo nie”.

Dopiero szczegóły błędu wskazały przyczynę:

The following resource is signed with a weak signature
algorithm MD5withRSA and is treated as unsigned

Klient AVR żąda pełnych uprawnień przez all-permissions. Java blokuje stary podpis MD5withRSA, traktuje JAR jako niepodpisany i odmawia uruchomienia.

Dla tej konkretnej blokady potrzebna jest zmiana ustawień aktywnej instalacji JRE:

  1. Zamknąć aplikacje Java.

  2. Znaleźć plik java.security, przykładowo:

    C:\Program Files (x86)\Java\jre1.8.0_151\lib\security\java.security

  3. Wykonać kopię pliku.

  4. Otworzyć oryginał edytorem uruchomionym jako administrator.

  5. W pozycji jdk.jar.disabledAlgorithms usunąć wyłącznie element MD5.

Przykład przed zmianą:

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

Po zmianie:

jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024

Jeżeli lista zawiera więcej ograniczeń albo zajmuje kilka wierszy, pozostałą zawartość należy zachować. Istotne jest edytowanie pliku tej Javy, która faktycznie uruchamia JNLP.

Zmiana obejmuje wszystkie aplikacje korzystające z tej instalacji JRE. Najrozsądniej przeznaczyć ją do obsługi starego sprzętu zamiast używać jako ogólnego środowiska Java.

W panelu Java → Security → Edit Site List należy też dodać adres kontrolera, w tym przypadku:

http://192.168.1.137

Następnie ponownie uruchomić świeżo pobrany plik JNLP. Kolejne komunikaty warto czytać w szczegółach, zamiast wyłączać po kolei wszystko, co ma w nazwie „security”.

Po przejściu przez problemy z uruchamianiem klienta konsola AVR i Remote Storage działały na tyle dobrze, że udało się zdalnie zainstalować system.

Wynik: pełny zdalny dostęp do starego Fujitsu

Na dwóch Fujitsu PRIMERGY RX100 S5 z iRMC S2 udało się aktywować bezterminową licencję Advanced Pack, uruchomić konsolę AVR/KVM i Remote Storage oraz przeprowadzić zdalną instalację systemu.

Całość przetrwała restarty i przełączenie banku firmware. Nie było potrzeby patchowania obrazu ani flashowania zmodyfikowanego kodu.

Metoda jest potwierdzona dla opisanych urządzeń z iRMC S2. Zgodność z iRMC S3, S4 i S5 wymaga osobnej analizy i testów — sama nazwa Advanced Pack nie gwarantuje wspólnego formatu licencji.

Elektrośmieci wróciły do roboty. Java też, chociaż musiała najpierw zrobić scenę.