В "двух словах" — автоматизируется некоторая функциональность (T) и при этом доступна старая версия программы поддержка экспортных файлов которой уже реализована — нужен кроме того свой экспорт/импорт (T используется в регионах) — в принципе мне нравится идея сделать его в том же формате что и в старой программе (переход легче будет) чем "придумывать новый" — теперь проблема — в экспортных файлах старой версии во всех данных присутствует контрольная сумма алгоритм подсчета которой неизвестен
замечено что контрольная сумма 32bit и чем больше кол-во данных тем больше число — таже тенденция и в простом CheckSum алгоритме как на codeproject.com (ссылка ниже)...
Меня интересует — если какие то способы определения "типа" контрольной суммы — возможные варианты "стандартных" алгоритмов и насколько могут варьироваться константные данные в них использующиеся
Здравствуйте, SWAN, Вы писали:
SWA>В "двух словах" — автоматизируется некоторая функциональность (T) и при этом доступна старая версия программы поддержка экспортных файлов которой уже реализована — нужен кроме того свой экспорт/импорт (T используется в регионах) — в принципе мне нравится идея сделать его в том же формате что и в старой программе (переход легче будет) чем "придумывать новый" — теперь проблема — в экспортных файлах старой версии во всех данных присутствует контрольная сумма алгоритм подсчета которой неизвестен
SWA>замечено что контрольная сумма 32bit и чем больше кол-во данных тем больше число — таже тенденция и в простом CheckSum алгоритме как на codeproject.com (ссылка ниже)...
SWA>Попробовал "в лоб" следующие варианты SWA>здесь SWA>здесь
SWA>Меня интересует — если какие то способы определения "типа" контрольной суммы — возможные варианты "стандартных" алгоритмов и насколько могут варьироваться константные данные в них использующиеся
если есть программа, ИМХО проще пдойти со стороны реверс инженеринга кода
Здравствуйте, SWAN, Вы писали:
SWA>Меня интересует — если какие то способы определения "типа" контрольной суммы — возможные варианты "стандартных" алгоритмов и насколько могут варьироваться константные данные в них использующиеся
Есть ещё тупейшие варианты: обычное суммирование (с переполнением) или xor-енье байтов (dword'ов). Но возрастания числа с увеличением длины файла они не дают. Хотя... Если файл невелик, а суммируются байты в DWORD, то может быть. Попробуйте.
Здравствуйте, ilnar, Вы писали:
I>если есть программа, ИМХО проще пдойти со стороны реверс инженеринга кода
Спасибо уже в процессе
Cтарая программа написана на Builder и нужный кусок алгоритма на asm имеет достаточно накрученную структуру c множеством внутренних переходов и вызовом функций в том числе и виртуальных — с учетом того что опыта в раскручивании asm кода немного то на такой кусок может до недели уйти — конечно пробую но перебор существующих алгоритмов может быть более результативен и с гораздо меньшей трудоемкостью — откуда и данный вопрос
патчик отключающий проверку контрольной суммы я конечно уже готов сделать но хотелось бы все таки цивилизованного подхода к тому же предлагать подобное гос структуре я бы все таки стал в очень крайнем случае...
Здравствуйте, tarkil, Вы писали:
T>Здравствуйте, SWAN, Вы писали:
SWA>>Меня интересует — если какие то способы определения "типа" контрольной суммы — возможные варианты "стандартных" алгоритмов и насколько могут варьироваться константные данные в них использующиеся
T>Есть ещё тупейшие варианты: обычное суммирование (с переполнением) или xor-енье байтов (dword'ов). Но возрастания числа с увеличением длины файла они не дают. Хотя... Если файл невелик, а суммируются байты в DWORD, то может быть. Попробуйте.
Спасибо — забыл уточнить но обычное суммирование пробовал — получается сумма на три порядка меньше...
Здравствуйте, SWAN, Вы писали:
SWA>Спасибо — забыл уточнить но обычное суммирование пробовал — получается сумма на три порядка меньше...
Смущает то, что нормальные алгоритмы хэшей, типа md5 (да и CRC тоже) не дают такой закономерности, чтоб хэш возрастал с увеличением длины последовательности. Скорее всего там что-то тупенькое и самописное. 16-битные величины пробовали в 32-битной суммировать? Попробуйте.
А иначе, imho, остаётся только исходники ковырять.
SWAN wrote: > > Здравствуйте, tarkil, Вы писали: > > T>Здравствуйте, SWAN, Вы писали: > > SWA>>Меня интересует — если какие то способы определения "типа" > контрольной суммы — возможные варианты "стандартных" алгоритмов и > насколько могут варьироваться константные данные в них использующиеся > > T>Есть ещё тупейшие варианты: обычное суммирование (с переполнением) или > xor-енье байтов (dword'ов). Но возрастания числа с увеличением длины > файла они не дают. Хотя... Если файл невелик, а суммируются байты в > DWORD, то может быть. Попробуйте. > > Спасибо — забыл уточнить но обычное суммирование пробовал — получается > сумма на три порядка меньше...
Три порядка? Может, попробовать слова (word) складывать?
Здравствуйте, tarkil, Вы писали:
T>Здравствуйте, SWAN, Вы писали:
SWA>>Спасибо — забыл уточнить но обычное суммирование пробовал — получается сумма на три порядка меньше...
T>Смущает то, что нормальные алгоритмы хэшей, типа md5 (да и CRC тоже) не дают такой закономерности, чтоб хэш возрастал с увеличением длины последовательности. Скорее всего там что-то тупенькое и самописное. 16-битные величины пробовали в 32-битной суммировать? Попробуйте.
T>А иначе, imho, остаётся только исходники ковырять.
SWAN wrote: > Здравствуйте, tarkil, Вы писали: > > T>Здравствуйте, SWAN, Вы писали: > > SWA>>Спасибо — забыл уточнить но обычное суммирование пробовал — > получается сумма на три порядка меньше... > > T>Смущает то, что нормальные алгоритмы хэшей, типа md5 (да и CRC тоже) > не дают такой закономерности, чтоб хэш возрастал с увеличением длины > последовательности. Скорее всего там что-то тупенькое и самописное. > 16-битные величины пробовали в 32-битной суммировать? Попробуйте. > > T>А иначе, imho, остаётся только исходники ковырять. > > Спасибо судя по получающимся значениям уже теплее
А ещё можно байты в слове переставлять и биты в байте тоже.
Здравствуйте, raskin, Вы писали:
R>SWAN wrote: >> Здравствуйте, tarkil, Вы писали: >> >> T>Здравствуйте, SWAN, Вы писали: >> >> SWA>>Спасибо — забыл уточнить но обычное суммирование пробовал — >> получается сумма на три порядка меньше... >> >> T>Смущает то, что нормальные алгоритмы хэшей, типа md5 (да и CRC тоже) >> не дают такой закономерности, чтоб хэш возрастал с увеличением длины >> последовательности. Скорее всего там что-то тупенькое и самописное. >> 16-битные величины пробовали в 32-битной суммировать? Попробуйте. >> >> T>А иначе, imho, остаётся только исходники ковырять. >> >> Спасибо судя по получающимся значениям уже теплее R>А ещё можно байты в слове переставлять и биты в байте тоже.
Всем Спасибо !
Алгоритм локализован — использовалось суммирование символов перемноженных на байты из "ключевого" массива[1024]
