Это не тот случай. Железка сугубо закрытая.

Данные эти находятся в 1-wire EEPROM, представляют собой идентификаторы, флаги, дату/время, калибровочные данные аналоговой части. Оттуда их читает ПК, записывает дату активации устройства,эту CRC и собственно все. Сие выяснено чтением логов общения компа с железкой и поиском потом соотв данных в прошиве.

ПК, записывает дату активации устройства,эту CRC

Стоп. У тебя есть софт, который пишет эту CRC и данные туда? Расковыряй его для начала.

Данные эти находятся в 1-wire EEPROM, представляют собой идентификаторы, флаги, дату/время, калибровочные данные аналоговой части

кто изначально/штатно считает эту вашу «CRC»?

Этим тоже занимаюсь

Пока без особого успеха - закрытое ПО с привязкой к железу, доступ к компу где оно стоит ограничен, ящик куда 1-wire втыкается есть только на этом компе, он далеко не только 1-wire адаптер, забрать играться весь комплект не получится.

Как налету софтайсом ковырять я примерно представляю, имея в распоряжении только набор файлов программы - нет. Советуйте, если знаете способ, попробую.

IDA.

SoftIce — давно это слово не слышал. :) Можно было бы Ida на программу натравить. Вряди там что-то пострипенно. Хотя бы зацепки были, уже по названием функций / константам до много чего догадаться можно.

По поводу самой CRC — подозреваю, что там что-то совсем стандартное. От какого участка оно считается? Можно и методом научного тыка найти, меня по байту с начала и с конца.

Похоже считает комп

Изначально/штатно все выглядит так - устройство подключается к «ящику», предположительно довольно безмозглому,точно аналоговому по большей части, через него устройство «видит» компьютер, о чем радостно сообщает соответствующей надписью после чего происходят следующие изменения:

00760000014D01здесь другая CRC01002500442D313332372D30352D53000000000031373139333930372E30313426F4EE54здесь текущие датавремя00030060000534C03E8D16C03E0E96C43E033C403F4E91403F0EB4443F88F08F3F0169903FB043933FD392C53FD58FC53FC9B5C53F9325C23F130DC23F796BC23F1DC6BE3FBB84BE3F6124BF3FE9AA163F1407D03FFC59044083DDC53F2D053EC09823444006001200B603EC0000001904440214096501510260260D001600D935420100350000000000000000000000000000000005008C00A6E1D53F20730040A374DC3F927589C4276872439E7251445610BDC2FC33614464E642C46A3761449B9333447FDA8D4478A942BF38D04BC4E0478A4476D82D3F9B9188C4955A95C4338B333FA57B36BFE65E672561B7DF3EEB1CDC3EF6434ABFA4B429423046624200000000015E883FDA0881BF3A297A3F4CAE67BFAF103CBE338DE83F7B249F3DC0D5BD3D

а в компьютере появляется информация из устройства.

Если потом отключить устройство от компа и подключив к 1-wire адаптеру вернуть все как было можно подключать к компу снова, опять получая дату и CRC (другие). Если внести любые другие изменения комп пишет EEPROM error и не пишет и не читает ничего.

Сама сверхзадача как раз и «вернуть как было» на тех устройствах, где это «как было» неизвестно. Прошивки разных экземпляров разнятся содержанием, но принцип один, в одни и те же ячейки все пишется.

ну так лет 12 назад дело было) с тех пор далек от программизма/взлома

за наводку на IDA спасибо, читаю чо к чему пока.

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

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

Можно и лежачию. Ещё к ней есть модуль, декомпелирующий обратно в C. Всёж проще читать, чем asm.

уже выяснил. Завтра доберусь до файлов и буду пробовать.

Ещё к ней есть модуль, декомпелирующий обратно в C.

Не в бесплатной версии.

тут - http://habrahabr.ru/post/220245/ пишут что: «Пользовательские функции, которые представляют реализацию задач программы, а не ее обертку из API-шных и системных вызовов, дизассемблер не распознает и называет попросту sub_цифры.»

какие признаки могут указывать на то, что это таки нужный алгоритм?

Оно будет выглядеть примерно вот так: http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/libkern/crc32.c

(Большая таблица в DATA секции и маленький луп с xor и shift)

Тебе надо найти текст сообщения об ошибке «EEPROM error». Найти место, где эта строка используется для вывода сообщения. Потом найти все места, откуда этот код вызывается. Посмотреть, что там проверяют перед тем как прыгнуть на сообщение об ошибке. Выяснить, как считается то число, которое проверяют. Это и будет искомый код валидации EEPROM.

Пока понятно. Спасибо.

Как наковыряю соответствующих «подозрительных» кусков отпишусь, врядли сам осилю найти алгоритм, вся на форум надежда.

Спасибо за информацию. Как расковыряю отпишусь чего нашел.

Выяснить, как считается то число, которое проверяют. Это и будет искомый код валидации EEPROM.

можно не выяснять КАК..а просто всю проверку забить «nop» ом - ломать так ломать..

и не будет сломанный драйвер проверять сломанную прошивку :-)

Идея хороша)

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

я бы не стал взрывать себе мозг - проверить несколько вариантов и если всё мимо, то просто грубый хак..

из возможных вариантов:

• crc32 (широко применимы несколько вариаций)
• оно-же но с учётом порядка байт (просто поменять местами чётные/нечётные)
• xor по 4 байта с заполнением 00 55aa aa55 (или чем там ваш eeprom заполняется)

чисто теоретически на месте CRC может быть криптоподпись - а чтобы угадывать метод,ключ и сахарок - тут совсем не тот вариант :-)

на практике же - не может там быть там чё-то заумного. А максимально простой, опробованный и известный разрабам метод.

Поставь себя на место разработчика: тебе надо проверять целостность данных небольшого блока. В куче разных устройств. Будешь изобретать уникальный метод? нах. он нужен..

Естественно будет взято что-то готовое, быстрое и всем известное.

xor по 4 байта с заполнением 00 55aa aa55 (или чем там ваш eeprom заполняется)

В середине длинная последовательность нулей, так что вряд ли.

Вот чего удалось наковырять

Файл EEPROMGenerator.exe, в нем такое:

seg000:00052981 aHoleEepromCrcU db 'hole EEPROM CRC = %u (0x%08x).',0Ah,0

но подозреваю, что это наоборот чтение текущего значения CRC

табличек расчета невидать