MasterOleg
21.12.2002, 08:00
Не так давно обсуждалась тема, что есть 258мые которые не шьются родным софтом и при изменении прошивки вручную база "замолкает"
Так вот каму нибудь удалось расшифровать контрольную сумму ?
Мои изыскания нашли 5 байт которые нельзя менять как захочешь.
A6 xx 00 04 xxxxxx..xxxx 56 00 - оригинал
B1 xx 0b04 xxxxxxxx 56 00 - работает
B2 xx 0c .... уже нет
Первое число как я понял и есть добавленная контрольная сумма.

http://phoneservice.h1.ru-Ремонт радиотелефонов.

sn258
21.12.2002, 13:29
Если сильно надо, вышли содержимое EEPROM. Будет время - подберу тебе контрольную сумму.

MasterOleg
22.12.2002, 03:39
Так все от чего зависит контрольная сумма я обубликовал. От остальных ячеек ничего независит.
То есть как буд то закрыто изменение делителя для шага частотной сетки, сделали привязку к конкретному типу задающего генератора. Все что нужно это изменить 4 на 2 - контрольная сумма A4 и A8 сразу говорю неподходят.

http://phoneservice.h1.ru-Ремонт радиотелефонов.

Katz
22.12.2002, 10:29
Следует заметить, что в китайских "плюсах" стоит такая же дурацкая защита. Поосторожнее с ними. Нельзя менять ID код и коэффициент деления о*****го генератора.

(c) 2002 Gibel Computers & Communications Co.

MasterOleg
23.12.2002, 04:41
В том то и дело что менять можно, я же опубликовал две рабочих строки в второй строке я изменил делитель. Нужно знать алгоритм расчета контрольной суммы, перебирать 256 комбинаций весьма утомительно.


http://phoneservice.h1.ru-Ремонт радиотелефонов.

Katz
23.12.2002, 08:08
Так раскопайте! При толковом подходе код придется подобрать всего 64 раза.

(c) 2002 Gibel Computers & Communications Co.

avers
24.12.2002, 19:16
Dr Katz, а почему собственно 64 раза, а не 256 и за сколько байт отвечает CRC? Все ли битики учитываются в коэф. о*****го и коде базы?
Остальное содержимое ПЗУ по нашим экспериментам не считается.

Katz
25.12.2002, 08:57
Все биты. То есть 32. В принципе, это минимально необходимое количество кодов, которое придется подбирать. Остальные (для инверсных значений) - только для верности.
Не следует забывать, что 32х256=8192. По закону Мерфи количество перепрограммирований 93С46 окажется весьма близким к этому числу...
П.С....Вот, удостоился... Доктор - и даже без высшего образования. :-)

(c) 2002 Gibel Computers & Communications Co.

avers
25.12.2002, 12:55
SN 258 CRC

а я взял и начал ...

вот ночные результаты... (плачевные)

FO 0200 AD41 11110000 00000010 00000000 10101101 01000001
8B 0200 AD98 10001011 00000010 00000000 10101101 10011000
8B 0200 A8C7 10001011 00000010 00000000 10101000 01111100

44 06A4 980E 01000100 00000110 10100100 10011000 00001110
1D 0352 217E
a6 0400 0056
b1 040b 0056

при одинаковых CRC, колличество 1 и 0 одинаковое в ID и Divisor, хотя может быть совпадением.

функция не арифметическая, так как при одинаковых CRC сумма двух байт разная.

из этого следует, либо я суёчас сильно хочу спать (уж очень часто па клаве промахиваюсь), либо функция логическая, что скорее всего.

В проце двойки есть крутой алгоритм кодировки CRC для медемной посылки, сначало я верил в то, что он там и используется, но1 CRC составляется ил 3х байт, а у нас их 4, но2 я потыкал, и (может быть коряво) и совпадений нет. Вопрос, что кикайцы написали какой то крутой алгоритм CRC. Верится с трудом.

Путём вычитания из 0 04 00 00 56, получатся та самая сумма А6, но в других члучаях это не работает. (коды из первого примера).

при ID AD98 и ID A8C7 CRC одинаковая (8B), хотя их арифметическая сумма, какая бы она не была, разная.

Б%Я!!! Китайцы, от них один геморой. я ухожу спать!!!

У кого ещё есть какие нить мысли по этому поводу.

Значит функция логическая, по AND или OR быть не может. по XOR может, сами по себе числа ничего не дают, может быть FF с 04 00 00 56. или какая нить другая константа, незнаю


одна таблица в проце есть, но что, китайцы вторую таблицу будут писать в проц???, а хотя, что китайцы, что французы - ИХ НЕ ПОЙМЁШЬ!!!

кто ещё может как нить подумает над этим...

P.S Может у кого есть прошивка китайского проца, дайте посмотреть, это наверное решит все проблемы...

Gordonsham
25.12.2002, 19:20
Вот уроды! Лучше бы они сделали нормальную защиту от трубок-двойников, чем парили мозги с этими дурацкими контрольными суммами..

WBR\
Антон

sn258
25.12.2002, 20:17
Все это сделано не спроста. Когда начнете сами писать программы, причем не с нуля, а адаптируя их под уже имеющиеся протоколы, Вы то же добавите что-нибудь такое, что не будет понятно окружающим, но будет необходимо для работы программы.

P.S. Я сам программы не пишу, почти.

Katz
26.12.2002, 09:36
С точки зрения здравого смысла - раз пошла такая пьянка, лучше было бы при несовпадении контрольного байта запускать базу в сервисный режим, а не подвешивать намертво. Не исключено, что это просто недоработка.

(c) 2002 Gibel Computers & Communications Co.

frezer
26.12.2002, 19:49
Мужуки я во первых сегодня уже выпил по поводу подключения нашего нового подразделения к всемирной "поутине" во вторых я не сильно сооброжаю с ходу ( это всегда, мне надо подумать!)и по этому вопросу сейчас учавствовать в дискусии немогу! Но как мне кажется нам надо произвести обработку имеющейся информации, а имено обработать прошивки всех имеющижся трубок/баз я могу напрячь математиков! И вообще я работаю в техническом университете если у сообщества есть глобальные проблемы пребующие времени можно подключить студентов! Всех с наступающим!

Gordonsham
26.12.2002, 21:04
А что, недурная тема для курсовика..

WBR\
Антон

Katz
27.12.2002, 09:56
Ребятки, когда все это расковыряли - я с горя выдул два стакана водки. Из-за того, что это сделал не я - настолько все оказалось просто...
Всех с наступающим!!!

(c) 2002 Gibel Computers & Communications Co.