Metody do zmniejszenia 16-bitowego algorytmu CRC / Checksum używanego przez plik wykonywalny Windows CE?

Potrzebuję odwrócić algorytm CRC / Checksum zaimplementowany przez plik wykonywalny Windows CE. Jako protokół właściwy nie mówi nic o algorytmie CRC / sumy kontrolnej. Istnieje jednak interfejs konsoli, który zgłasza poprawną / obliczoną sumę kontrolną i mogę skonstruować własne wiadomości z losowymi bitami, jeśli protokół komunikatów jest poprawny:

Zauważyłem to,

Zmiana pojedynczego bitu w wiadomości zmienia bajty sumy kontrolnej całkowicie.

Algorytm wydaje się być zależny od pozycji, ponieważ podałem kilka pojedynczych komunikatów 1-bitowych w różnych pozycjach danych komunikatu z resztą bitów zero, a cała konsola czasu zgłosiła inną sumę kontrolną. Gdyby była to prosta suma kontrolna addytywna, suma kontrolna byłaby identyczna.

Zastosowałem wspólne algorytmy XOR, LRC, addytywne sumy kontrolne, wspólne wielomiany CRC (Standerd, CCITT, X-modem) i przeszedłem przez [CRC Reverse engineering esej] [2], ale niestety nie mogę przejść obok dedukowania wielomianu, ponieważ typ wiadomości został naprawiony nie można utworzyć pojedynczej wiadomości 1-bitowej.

Moje pytania:

Czy są jakieś właściwości algorytmu sumy kontrolnej / sumy kontrolnej, które mogę przetestować pod kątem komunikatów, aby określić, czy algorytm jest sumą kontrolną sumy kontrolnej, czy CRC?

Czy jest jakiś sposób na powiązanie komunikatu o błędzie z demontażu programu z instrukcjami montażu powodującymi korozję?

Jakie są sposoby debugowania / wskazywania kodu demontażu w momencie zgłaszania poprawnej sumy kontrolnej na konsoli? Zrzut pamięci czy coś takiego?

questionAnswers(1)

yourAnswerToTheQuestion