Перейти к содержимому
Калькуляторы

Алгоритм расчёта 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 нет...

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

Изменено пользователем AlKov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

0x02+0x04+0xFA=0x100

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

Изменено пользователем naves

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Для 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 - Вас не понял..

Изменено пользователем AlKov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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: криво сосчитал

Изменено пользователем naves

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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.

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

Изменено пользователем AlKov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

я так считал:

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

Изменено пользователем naves

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Да не вопрос! Выкладываю парочку.. В архиве 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

Изменено пользователем AlKov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем naves

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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% НЕ сумма байтов, а либо разность, либо сдвиг битов в каком-то контрольном значении, либо еще что-то...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

A+B=C, где

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

A+B=C, где

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

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

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

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

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

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

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

Изменено пользователем AlKov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

./recalc < config5_100.bin > config5_100e.bin

 

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

 

Проверяй.

Изменено пользователем Дегтярев Илья

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Увы, не довелось.. В те далёкие 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

 

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

 

Проверяй.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

Описание

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

....skip...

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

Работаю в *nix.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нормальной матиматики при подсчете кс врядли будет, а будут простые операции, байтов всего 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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.