Помогите с определением алгоритма контрольной суммы

Доброго дня форумчане.
Есть таблицы DVB PAT которые передаются на устройство.
Выглядит это так:
47 40 00 10 00 00 B0 8D 00 14 F1 00 00 04 06 E6 14 23 29 E6 00 23 2A E6 08 23 2B E6 10 23 2C E6 18 23 2D E6 20 23 2E E6 28 23 2F E6 30 23 30 E6 38 23 31 E6 40 23 32 E6 48 23 33 E6 50 23 34 E6 58 23 35 E6 60 23 36 E6 68 23 37 E6 70 23 38 E6 78 23 39 E6 80 23 3A E6 88 23 3B E6 90 23 3C E6 98 23 40 E6 B8 23 41 E6 C0 23 44 E6 64 46 50 F8 00 46 51 F8 08 46 52 F8 10 46 54 F8 18 4A 60 E6 1C 54 33 E9 F2 61 A9 F0 00 61 AB F0 10 61 AD F0 20 92 19 47 16 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0F 0F 39 39 1C 1C A4 A4
или так:
47 40 00 10 00 00 B0 95 00 1F D5 00 00 00 00 E0 10 00 03 E0 B6 00 04 E0 7C 79 19 F2 00 79 1A F2 08 79 1B F2 10 79 1C F2 18 79 1D F2 20 79 1E F2 28 79 1F F2 30 79 21 F2 40 79 23 F2 50 79 24 F2 58 79 25 F2 60 79 26 F2 68 79 27 F2 70 79 28 F2 78 79 29 F2 80 79 2C F2 98 79 2D F2 A0 79 2E F2 A8 79 2F F2 B0 79 30 F2 B8 79 31 F2 C0 79 32 F2 C8 79 33 F2 D0 79 34 F2 D8 79 35 F2 E0 79 36 F2 E8 79 37 F2 F0 79 38 F2 F8 79 52 E0 21 79 54 F2 BC 79 55 F2 A4 79 56 E9 F2 9C C0 CD 89 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0B 0B 1E 1E 19 19 49 49
последние 8 байт это контрольная сумма сообщения. Но я не могу определить как она считается.
всегда 4 группы повторяющихся байт. Может кто-нибудь помочь с определением алгоритма подсчёта контрольной суммы?

 

Там в конце идёт контрольная суммы CRC-32, но там идёт нестандартный полином по вычислению значения. Вот пример.

Code:

function crc = crc32(data)
% Computes the CRC-32/MPEG-2 checksum value of a byte vector.
% Uses a left shifting (not reflected) CRC along with the
% CRC polynomial 0x04C11DB7 and initial CRC value of 0xFFFFFFFF,
% and is not post complemented.
%--------------------------------------------------------------------------
%   Version:    130
%   Programmer: Oliver Calderbank
%   Date:       21-07-2019
% Initialize variables
crc  = uint32(hex2dec('FFFFFFFF'));
poly = uint32(hex2dec('04C11DB7'));
data = uint8(data);
temp = uint32(data);
for i = 1:length(data)
    % xor next byte to upper bits of crc
    crc = bitxor(crc,uint32(bitshift(temp(i),24)));
    for j = 1:8
        msb = bitsra(crc,31);
        crc = bitsll(crc,1);
        if msb == 1
            crc = bitxor(crc,poly);
        end
    end
end
end

 

Это не MPEG2 CRC. по длине различаются. 32 бита и 64 бита. Хотя могут повторяться по парно. Но полином и начальное значение явно не такие.

 

ну то что байты дублируются, это явно к самой контрольной сумме не относится. То что в DVB спецификации явно стоит CRC32 - это бесспорно.

 

Тут не совсем DVB. Это пакет для передачи на устройство. Далее устройство откидывает контрольную сумму и вещает пакет в DVB сеть. Длина этого пакета 196 байт. В DVB длина пакета 188 байт, за некоторым исключением(не наш случай). CRC определяется внутри пакета и не для его полного размера. К примеру в первом пакете CRC считается для этой части:
00 B0 8D 00 14 F1 00 00 04 06 E6 14 23 29 E6 00 23 2A E6 08 23 2B E6 10 23 2C E6 18 23 2D E6 20 23 2E E6 28 23 2F E6 30 23 30 E6 38 23 31 E6 40 23 32 E6 48 23 33 E6 50 23 34 E6 58 23 35 E6 60 23 36 E6 68 23 37 E6 70 23 38 E6 78 23 39 E6 80 23 3A E6 88 23 3B E6 90 23 3C E6 98 23 40 E6 B8 23 41 E6 C0 23 44 E6 64 46 50 F8 00 46 51 F8 08 46 52 F8 10 46 54 F8 18 4A 60 E6 1C 54 33 E9 F2 61 A9 F0 00 61 AB F0 10 61 AD F0 20
и будет равна 0x92194716 это и отражено в последних 4 байтах до FF....
Имхо здесь может быть что-то другое. Понять бы что, чтобы самому генерировать пакеты...

 

Логика мне подсказывает, что скорее всего алгоритма контрольной суммы который бы генерировал 4 попарно одинаковых байт нет. Просто потому что контрольная сумма это результат хеш функции и попарные повторы как бы не есть хорошо для таких функций с точки зрения возникновений коллизий. Зачем нам 64 байта, если можно юзать 32 байта. Хотя я не эксперт в этих делах, поправьте если это не так.

 

Контрольная сумма и хэш функция это разные вещи, попарные повторы в хэш функции не имеют смысла.
Но в целом, если посмотреть на данные, то идёт такая схема:
[ДАННЫЕ] [НАПОЛНИТЕЛЬ=FF] [Контрольная сумма]
Контрольная сумма обычно делается на данные вместе с наполнителем. Может быть что структура должна быть кратной 32 или 64?

 

Мне не дают покоя эти попарные повторы. Это какая-то искусственная конструкция, точно не результат работы алгоритма контрольной суммы. То есть имхо в результате работы алгоритма скорее всего получается контрольная сумма длинной в 32 байта, а затем она попарно дублируется. Посмотрел все пакеты. Размер у всех подходит под формулу P_Len = 188*n + 8; n- целое. Девайс делит большие пакеты по 188 байт и отправляет их в сеть(есть служебные таблицы в DVB которые имеют размер более 188 байт).
Тупая конечно попытка, но сейчас накидал программу. которая пытается подобрать порождающий полином исходя из того что начальное значение 0xffffffff а алгоритм CRC32

 

я бы сделал наоборот, исходил бы из того что полином тот что наверху и искал границу данных, для которых высчитывается эта контрольная сумма.

 

Ну в общем ни мой, ни ваш подход результатов не дали.
Гуру, подскажите для алгоритма CRC64, можно ли подобрать значения порождающего полинома, начального значения и XorOut чтобы значения повторялись по парно?

 

Для одних данных на входе может быть и можно подобрать, но для всех данных на входе не возможно.