Licznik S34U28 od Taurona

Urządzenia Pomiar zużycia mediów
, ,
43

No i po wielu moich testach okazało się, że klucz jest ok, tylko nagłówki wiadomości są inne. Powoduje to, że w ogole nie chce odszyfrowywać. Na szczęście claude zrobiło mi poprawki do wersji Szczepan 5.0.4. Wszystkie dane są zgodne z amiplus poza nagłówkiem.

Problem był w weryfikacji deszyfrowania w wmbus.cc:1550.

Standardowy przepływ wMBus:

  1. Telegram przychodzi zaszyfrowany AES CBC

  2. potentiallyDecrypt() deszyfruje payload

  3. Sprawdza czy pierwsze 2 bajty odszyfrowanych danych to 2F 2F — to standardowy “check bytes” potwierdzający że klucz był prawidłowy

  4. Jeśli nie 2F 2F → uznaje że klucz jest zły → decryption_failed = true → t.parse() zwraca false

  5. handleTelegram() kończy się przedwcześnie — żadne pola nie są wyciągane, processContent() nigdy nie jest wywoływany

Problem z KPL/Tauron:
Licznik KPL po deszyfracji zamiast standardowych 2F 2F wstawia 60 9B jako prefix. Deszyfracja jest poprawna (widać sensowne dane za prefixem), ale weryfikacja tego nie wie i odrzuca telegram.

Fix — jedna linijka w potentiallyDecrypt(), zaraz po udanej deszyfracji AES:

if ((dll_mfct & 0x7fff) == 0x2E0C && *(pos+0) == 0x60 && *(pos+1) == 0x9B)
{
    *(pos+0) = 0x2F;
    *(pos+1) = 0x2F;
}

Podmienia 60 9B na 2F 2F dla manufacturer KPL (0x2E0C) — weryfikacja przechodzi, parseDV() dostaje czyste dane, pola się parsują normalnie.

Tak, nowy driver (driver_tauronkpl.cc) był potrzebny — ale nie z powodu deszyfrowania, tylko z powodu detekcji.

Bez nowego drivera licznik KPL trafiał do amiplus (albo auto), który:

  • nie miał addDetection(MANUFACTURER_KPL, 0x02, 0x01) — więc nie rozpoznawał producenta KPL (0x2E0C)

  • nie miał usesProcessContent() — więc nawet gdyby fix w wmbus.cc przepuścił telegram, nie byłoby zapasowego mechanizmu reparsowania

1 polubienie