Jump to content
Калькуляторы

Алгоритм расчёта CRC в бинарнике DES-2108

Собственно проблема такова: угораздило приобрести на доступ энное кол-во (больше сотни) D-LINK DES-2108.

Все бы ничего, но вот пришла пора массово изменить конфигурацию девайсов. Ну дело вроде бы несложное - скриптом готовим нужный конфиг и по snmp льём в свитч. Но не тут-то было!

Непонятно для чего, но именно в этом девайсе конфиг сохраняется почему-то в бинарном виде.. В принципе все известно, где, как и на что необходимо поменять в "бинарнике" конфига. Единственно неразрешимым оказался алгоритм подсчета "CRC" отредактированного файла. "CRC" именно в кавычках, т.к. она убирается в один байт, причём, что примечательно, если например увеличить IP на "1", то "CRC" уменьшится на "1".

Вот "хвост" файла для IP 192.168.5.74

00008020 00 00 00 00 │ 00 CA CA 9B │ 00
(синий - дескриптор файла, красный - "CRC")

А вот для IP 192.168.5.75

00008020 00 00 00 00 │ 00 CA CA 9A │ 00

Также на результат не влияют байты "00" и "FF".

Официальный дилинк естественно отказал в "раскрытии секрета" подсчета CRC.. Других вариантов обновить конфиг за один проход, кроме как заливка готового конфига через web, или snmp на 2108 нет...

Может кому приходилось ковыряться в подобном, поделитесь соображениями пожалуйста!

Edited by AlKov

Share this post


Link to post
Share on other sites

как варианты:

- контрольный байт выставляется так, чтобы сумма всех байт, включая контрольный, равнялась определенному значению, обычно нулю

- то же, но не сумма, а XOR

- то же, что и первое, но с учетом переносов (т.е. первое 80+80=00, а тут 80+80=(1)00=1+00=01

Из описания похоже на 3.

Кроме этого надо точно знать какой регион защищен контрольной суммой...

Share this post


Link to post
Share on other sites

Для 192.168.5.228 КС должна быть равна 0, так?

Посмотрите, чему она окажется равна для 192.168.5.229. Если FF - то собссно сумма всех байт конфига + КС должна оказаться равной некому числу (0 к примеру).

А защищается КС скорее всего весь конфиг :)

Share this post


Link to post
Share on other sites

хм судя по описанию, они и файлы прошивок также проверяют

:020000040000FA
.......
:20FF8000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF81
:20FFA000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF61
:20FFC000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF41
:20FFE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDEAA55AA5540
:00000001FF

контрольная сумма строчки

0x02+0x04+0xFA=0x100

там тупо сумма

Edited by naves

Share this post


Link to post
Share on other sites

Для 192.168.5.228 КС должна быть равна 0, так?

Ничего подобного - КС = Е3..

00008020 00 00 00 00 │ 00 CA CA E3 │ 00

А защищается КС скорее всего весь конфиг :)

Именно так. Пробовал заменять последний "нолик" (тот, что после КС), свитч ругается ошибкой КС.. Если заменять любой из байтов "СА", ругается неверным дескриптором файла. И ещё раз хочу обратить внимание - байты "FF" не влияют на КС, где бы они не находились.

Посмотрите, чему она окажется равна для 192.168.5.229. Если FF - то собссно сумма всех байт конфига + КС должна оказаться равной некому числу (0 к примеру).

Соотв., для 192.168.5.229 КС будет "Е2"..

На КС влияет любой байт файла, кроме "0" и "FF", не только относящийся к IP.

To vitalyb - ни один вариант не прокатил.. Ну смотрите сами: например вар. №3 - явно видно, что XX+CA+CA вернёт либо "1", либо "CB" (CA+1), прибавив к которой КС (9А) никак не получим "0".. Первый и второй вариант проверил - тоже не клеится.. :(

To naves - Вас не понял..

Edited by AlKov

Share this post


Link to post
Share on other sites

Проделал еще пару экспериментов:

1. изменил первый попавшийся "00" на "01", уменьшил КС на "1" и успешно скормил свитчу

00008020 01 00 00 00 │ 00 CA CA 7C │ 00

2. изменил тот же байт на "FF", оставив прежнюю КС, и также успешно скормил.

00008020 FF 00 00 00 │ 00 CA CA 7D │ 00

.

Правда света на проблему это не пролило. Во всяком случае для меня.. :(

Share this post


Link to post
Share on other sites

somedata| 192.168.5.74 |9B|00

AE|C0 A8 05 4A =B7|9B|00

somedata| 192.168.5.100 |81|00

AE|C0 A8 05 64=D1|81|00

 

введите адрес 192.168.5.100

ваша сумма будет 81?

upd: криво сосчитал

Edited by naves

Share this post


Link to post
Share on other sites

somedata| 192.168.5.74 |9B|00

AE|C0 A8 05 4A =B7|9B|00

somedata| 192.168.5.100 |81|00

AE|C0 A8 05 64=D1|81|00

 

введите адрес 192.168.5.100

ваша сумма будет 81?

upd: криво сосчитал

Ничего не понял... Сумма чего? КС файла? Если "да", то конечно же будет другая. Если изменять только IP (на 192.168.5.100), то будет 5A. Если изменить еще что-либо (например системное имя, или VID/name VLAN), то соотв. совсем другая будет..Я же не раз отмечал, что

На КС влияет любой байт файла, кроме "0" и "FF", не только относящийся к IP.

Поясните, пожалуйста, что именно и каким образом Вы считаете?

Edited by AlKov

Share this post


Link to post
Share on other sites

выложите бинарный конфиг наконец :)

с разными адресами, и каким-либо еще параметром

я так считал:

somedata| 192.168.5.74 |9B|00
AE|C0 A8 05 4A =B7     |9B|00
|         |     |      |  |
|         |     |      |  сумма всех байт конфига+байт контроля
|         |     |      байт контрольной суммы
|         |     cумма байт адреса
|         ваш адрес 
сумма байт остального конфига

Edited by naves

Share this post


Link to post
Share on other sites

выложите бинарный конфиг наконец :)

с разными адресами, и каким-либо еще параметром

Да не вопрос! Выкладываю парочку.. В архиве 2 файла.

МАС свитча - 00:26:5A:BD:69:83

1. config5_100.bin - IP: 192.168.5.100, system name - Timiryazeva_18, system location - Timiryazeva-18

2. config5_100_1.bin - IP: 192.168.5.100, system name - Michurina_9, system location - Michurina-9

Еще раз делаю акценты:

1. на КС _НЕ_влияют_ байты "00" и "FF", в любом месте конфига.

2. при увеличении любого байта на единицу(например, вместо буквы "i" написать "j"), КС уменьшается также на единицу.

я так считал:

somedata| 192.168.5.74 |9B|00
AE|C0 A8 05 4A =B7     |9B|00
|         |     |      |  |
|         |     |      |  сумма всех байт конфига+байт контроля
|         |     |      байт контрольной суммы
|         |     cумма байт адреса
|         ваш адрес 
сумма байт остального конфига

Все равно не понял. :)

des-2108.zip

Edited by AlKov

Share this post


Link to post
Share on other sites

1) пропускать FF он не может, просто программа видимо не считает контрольную сумму для всего файла.

измените, например, вашу маску 255.255.252.0 сначала на 255.255.255.0 а потом на 255.255.0.0

2) уменьшается сумма как-то скачками, между 75 и 100 конечная разница больше чем на 25

       addr | checksum
192.168.5.74 | 0x9B
        +01 |-0x01
192.168.5.75 | 0x9A
        +25 |-0x40 
192.168.5.100| 0x5A
        +128|-0x89
192.168.5.228| 0xE3
        + 01|-0x01
192.168.5.229| 0xE2

Edited by naves

Share this post


Link to post
Share on other sites

1) пропускать FF он не может, просто программа видимо не считает контрольную сумму для всего файла.

измените, например, вашу маску 255.255.252.0 сначала на 255.255.255.0 а потом на 255.255.0.0

Пропускает 100%!!! И считает КС для всего файла, писал же!

Пробовал заменять последний "нолик" (тот, что после КС), свитч ругается ошибкой КС
. Маску изменить не могу, т.к. коммутатор сейчас у меня на работе, а я дома. Соотв. изменив маску, я потеряю к нему доступ. Покажу на другом примере.

Вот "исходный файл"

00007FE0 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00  ................................
00008000 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00  ................................
00008020 00 00 00 00 │ 00 CA CA D3 │ 00

Меняю "00" на "FF" в блоке 8000-801F, не изменяя КС..

00007FE0 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00  ................................
00008000 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  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00008020 00 00 00 00 │ 00 CA CA D3 │ 00

Заливаю изменённый файл в свитч, не меняя КС. Затем сливаю конфиг со свитча. Смотрим КС (в принципе можно и не смотреть, т.к. свитч такой конфиг скушал.

00007FE0 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00  ................................
00008000 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  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00008020 00 00 00 00 │ 00 CA CA D3 │ 00

Разницы не наблюдаем..

2) уменьшается сумма как-то скачками, между 75 и 100 конечная разница больше чем на 25

Скачками потому, что кроме IP менял другие байты!

2. при увеличении любого байта на единицу(например, вместо буквы "i" написать "j"), КС уменьшается также на единицу.
Пример нужен? Пожалуйста! Поэкспериментируем в том же блоке 8000-801F..

1. Меняю один байт "00" на "01", уменьшаю КС на "1"

00008000 01 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00  ................................
00008020 00 00 00 00 │ 00 CA CA D2 │ 00

,льем в свитч.. Кушает!!

2. Меняю "00" на "01" во всём блоке 8000-801F, соотв. уменьшаю КС на 20(HEX) D3-20=B3, заливаем.. Кушает!! Проверяем (сливаем конфиг)

00008000 01 01 01 01 │ 01 01 01 01 │ 01 01 01 01 │ 01 01 01 01 │ 01 01 01 01 │ 01 01 01 01 │ 01 01 01 01 │ 01 01 01 01  ................................
00008020 00 00 00 00 │ 00 CA CA B3 │ 00

ЧТД...

И ещё раз в который раз!! При увеличении значения на "1", КС уменьшается на "1", т.е. это 100% НЕ сумма байтов, а либо разность, либо сдвиг битов в каком-то контрольном значении, либо еще что-то...

Share this post


Link to post
Share on other sites

Скачками потому, что кроме IP менял другие байты!

блин, дык, зачем?

,льем в свитч.. Кушает!!

если свитч кушает, нафига она тогда вообще нужна? забить на контрольную сумму, изменить параметры и залить? из-за чего сыр-бор.

И ещё раз в который раз!! При увеличении значения на "1", КС уменьшается на "1", т.е. это 100% НЕ сумма байтов,

блин, программисты-математики вспоминаем школу.

A+B=C, где

A - сумма байт без контроля

B - контрольный байт

С - это сумма всех байт конфига, она равна нулю

если мы увеличиваем A, то должна уменьшиться B!

Share this post


Link to post
Share on other sites

,льем в свитч.. Кушает!!

если свитч кушает, нафига она тогда вообще нужна? забить на контрольную сумму, изменить параметры и залить? из-за чего сыр-бор.

Только из-за того, что если сделать так (выделено), то в итоге НЕ_кушает - "File checksum error!".

И ещё раз в который раз!! При увеличении значения на "1", КС уменьшается на "1", т.е. это 100% НЕ сумма байтов,

блин, программисты-математики вспоминаем школу.

A+B=C, где

A - сумма байт без контроля

B - контрольный байт

С - это сумма всех байт конфига, она равна нулю

если мы увеличиваем A, то должна уменьшиться B!

В таком случае (если я еще не совсем позабыл школу ;) ) "А" - всегда отрицательное(-) число (учитывая то, что "В" положительное, а "С" равно "0"). А каким образом возможно, суммируя положительные (+) значения, получить отрицательный результат??

И вообще, если Вам всё понятно, поделитесь знаниями с заблудшими. ;)

Вы можете показать, как получить нужную КС, на примере тех двух бинарников хотя бы?

Edited by AlKov

Share this post


Link to post
Share on other sites

Информатику в школе совсем не изучал? Уже 5 раз сказали, что сложение ведется по модулю.

Так как размер слова у нас 8 бит, то либо по модулю 256 (без учета переносов), либо 255 (с добавлением переноса назад)

 

Так как 00 и FF на КС не влияют - у тебя сложение по модулю 255.

 

Если тебя смущает вычитание в конце, просто возьми инверсным последний байт. Тогда он будет просто суммой других байт mod 255.

И при увеличении любого байта увеличиваться.

Share this post


Link to post
Share on other sites

Держи бинарник.

 

./recalc < config5_100.bin > config5_100e.bin

 

Выведет во второй фаил конфиг с уже исправленной КС.

 

Проверяй.

Edited by Дегтярев Илья

Share this post


Link to post
Share on other sites

Информатику в школе совсем не изучал?

Увы, не довелось.. В те далёкие 70-е не было такого предмета в общеобразовательных школах..
Уже 5 раз сказали, что сложение ведется по модулю.

Гм.. И где интересно об этом так много было сказано? ;) Пока что слышу в первый раз. Ну разве вот еще здесь "прозрачно намекнули"

- то же, что и первое, но с учетом переносов (т.е. первое 80+80=00, а тут 80+80=(1)00=1+00=01

Так как размер слова у нас 8 бит, то либо по модулю 256 (без учета переносов), либо 255 (с добавлением переноса назад)

 

Так как 00 и FF на КС не влияют - у тебя сложение по модулю 255.

 

Если тебя смущает вычитание в конце, просто возьми инверсным последний байт. Тогда он будет просто суммой других байт mod 255.

И при увеличении любого байта увеличиваться.

Попытался реализовать сиё на php - не получилось.. Вместо "8D", например здесь

00008020 00 00 00 00 │ 00 CA CA 8D │ 00

у меня получается "5F".. :(

> Sum = A0
> CRC = 5F

Вот собственно мой "калькулятор"

<?php
//
$checksum = 0;
$crc = 0;
$file = fopen("/tmp/config.bin","r+w");
fseek($file,-2,SEEK_END);
fwrite($file,pack("HH",0,0));
fseek($file,0,SEEK_SET);
//
 while (!feof($file))
  {
   $a = ord(fread($file,1));
   $checksum = (($checksum + $a)%255);
  }
fclose($file);
$crc = (255 - $checksum);
//
printf("> Sum = %X\n> CRC = %X\n",$checksum,$crc);
//
?>

Где ошибка??

Держи бинарник.

 

./recalc < config5_100.bin > config5_100e.bin

 

Выведет во второй фаил конфиг с уже исправленной КС.

 

Проверяй.

Ваш работает "на ура".. А чем мой провинился? ;)

Share this post


Link to post
Share on other sites

пхп не програмил, ИМХО, при открытии файла нужно режим бинарный использовать.

 

црц это не контрольная сумма и считается по иному.

 

 

Share this post


Link to post
Share on other sites

пхп не програмил, ИМХО, при открытии файла нужно режим бинарный использовать.

Так как бы оно так и есть..

fopen - открывает файл или URL.

 

Описание

int fopen (string filename, string mode [, int use_include_path])

....skip...

Примечание: mode может содержать букву 'b'. Это используется только в системах, различающих двоичные и текстовые файлы (т.е. в Windows. В Unix это бесполезно). Если не нужен, он игнорируется.

Работаю в *nix.

црц это не контрольная сумма и считается по иному.

А вы тему сначала читали?

Share this post


Link to post
Share on other sites

Нормальной матиматики при подсчете кс врядли будет, а будут простые операции, байтов всего 8 и можно просто их все проверить, а далее понять логику, например перебрать ипы

5.1 - бит 1

5.2 - бит 2

5.3

5.4 - бит 3

5.5

5.7

5.8 - бит 4

5.9

5.15

5.16 - бит 5

5.17

5.31

5.32 - бит 6

5.33

Может быть сумма/разность половинок битов итд..

Share this post


Link to post
Share on other sites
Примечание: mode может содержать букву 'b'. Это используется только в системах, различающих двоичные и текстовые файлы (т.е. в Windows. В Unix это бесполезно). Если не нужен, он игнорируется.

 

У виндовс CreateFile, которая ничего не различает и прочие апи ничего не различают и всё у них бинарно. Ставьте b, хуже не будет.

 

 

Share this post


Link to post
Share on other sites

У виндовс CreateFile, которая ничего не различает и прочие апи ничего не различают и всё у них бинарно. Ставьте b, хуже не будет.

.. и лучше тоже.. :)

Share this post


Link to post
Share on other sites

Есть мнение, что для расчета КС (возможно CRC8) используется какой-то конкретный полином, который может быть как-то связан с чипом свитча. А вот откуда его выковырять, непонятно..

Share this post


Link to post
Share on other sites

Есть мнение, что для расчета КС (возможно CRC8) используется какой-то конкретный полином

Нет там никакого полинома. Ибо сумма линейно зависит от значений байтов.

Share this post


Link to post
Share on other sites

Нет там никакого полинома. Ибо сумма линейно зависит от значений байтов.

Т.е. Вы хотите сказать, что если бы был расчёт с применением полинома, то линейной зависимости КС 100% не было бы?

В таком случае, что еще можете посоветовать?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this