SFDK (25.11.2005 21:09, просмотров: 1) ответил Павел В. на DES, 3DES... Самое лучшее - свое, дилетантское. не похожее ни на что!XOR Sucks... well, almost.ARC4 does XOR but NOT sucks. http://127.0.0.1
http://127.0.0.1
>> В смысле самописное. Допустим, в бутлоадер кладется ключ - 1024 >> байта хаотичного мусора. И по нему банально ксорим. Ломабельно.Ибо... - некоторые места прошивки, особенно большие области 00 и FF можно угадать, выцепив в итоге неслабый кусок ключа а то и его весь. - имея эн апдейтов прошивок можно предпринять какой-никакой анализ ключа если реально прикинуть что и где менялось. В общем у меня такое оптимизма не вызывает - ламеризм откровенный. Мну делал так:ключик (поменьше) в камне, в бутере.Юзер его не знает ессно.И ессно защита от чтения.Алгоритм ARC4(крайне похож на RC4:) от rsa data security) - только упаси вас боже его RC4 называть, ибо trademark RSA).Почему он?Ибо легко и просто впихивается даже в ненавернутые камни, прост а потому быстр.И даже с XOR для любителей оной "хакерской" операции.Ну табличку надо на 256 байтиков, не развалитесь, можно ее временно выделить.И это - алгоритм без явных про%%ов.За столько лет ничего фатального в нем не нашли.Если правильно использовать. Ах да... один и тот же ключ юзать все-таки не рекомендуется из-за возможностей какого-никакого анализа потока данныз.Стоит делать апдейт так: 1) В девайс засунут ключ шифрования DeviceKey.В идеале еще и у всех разный (тогда вы без проблем попалите кто был пират, но вам придется делать персональные апдейты каждому юзеру и вести БД с ключиками - можно но сложно) 2)А чтоб не сильно светить DeviceKey и затруднить его анализ: 1й блок апдейта - это "временный" (Encrypted)SessionKey.Сам по себе SessionKey - просто random ключ которым зашиварован весь дальнейший апдейт.Дабы не было халявы, он зашифровывается вами и в потоке данных апдейта он шифроанный ака (Encrypted)SessionKey, а потом расшифровывается девайсом(опять в SessionKey) - с юзежом и вами и деваcом DeviceKey(только он и позволяет сделать из (Encrypted)SessionKey простой SessionKey которым все и зашифровано).Так что умникам на анализ перепадет лишь какие-нибудь десятки случайных байтов зашифрованные с юзежом DeviceKey что мягко говоря, негусто для анализа и шифрование временных ключиков никто не поломает в итоге(а предсказуемости то и нету, ибо рандом...). 3) Весь дальнейший поток шифруется временным ключиком SessionKey.Его светить на большом потоке данных не жаль, ибо юзается он 1 раз всего и случайный вообще.Ничего такого ценного для анализа это в итоге никому не даст. Что в итоге? - Апдейты, даже с одной и той же версией будут всегда разные и их анализ в криптографическом плане достаточно беспонтовая затея. - Не слишком дилетантское, ибо FAQ фидошного RU.CRYPT я читал чего и прочим рекомендую, весьма грамотно и доходчиво написано:).Все достаточно честно.И без явной халявы для хакерофф.Используется проверенный временем алгоритм, нет явных дырок ака алгоритм использован так чтобы не выставлять его слабые места и поюзать сильные(критика спецов - велкам, ламеры - факофф) - Юзайте длинные ключи(RC4 позволяет до 256 байтов ака 2048 битов что для СИММЕТРИЧНОГО шифрования просто немеряно, это для RSA оно "так себе").Правда 32 random байта (256 бит ключа) вам скорее всего хватит по самые нидерланды.Брутфорсить это скажем по сериальному линку хакеры сдохнут.От старости.Если совсем уж страшно сделайте delay на 100 миллисекунд при расшифровке SessionKey'я :) при апдейте ее никто и не заметит а вот хацкеры будут иметь скорость брута 10 паролей/сек при немеряном 256бит ключе.Ну типа удачи им :) - достаточно несложно сделать в lite варианте затеи :) - для неленивых:можно на основе этого сделать систему отслеживающую кто спиратил(для совсем неленивых еще и с блэклистингом их на предмет апдейтов, ибо нефиг), а также непиратабельные :P апдейты которые ставятся только на девайс ОДНОГО юзверя (ну пропишите при записи бутера разные DeviceKey всем юзерам-все кроме 1 обломаются это расшифровать..[придется вести БД с ключиками у кого какой и генерить апдейты персонально]). - Из минусов :) я не сказал ничего про integrity checking.Но зашивать мусор в случае апдейта склепаного хакером - это не особо правильно(хакер не зная DeviceKey один фиг не сможет сделать его осмысленным в расшифрованном в девайс виде ... но все равно не очень правильно это, поэтому... хакеру должно быть трудно сбрутфорсить состояние в котором integrity checking признает это за валидную прошивку).Над этим дочитавшие досюда (if any) подумают самостоятельно :).Замечу только что бутеру вообще не стоит запускать corrupted основной код.Проверяя это по меткам в начале\конце программы, чексуммам и прочему.
http://127.0.0.1
>> В смысле самописное. Допустим, в бутлоадер кладется ключ - 1024 >> байта хаотичного мусора. И по нему банально ксорим. Ломабельно.Ибо... - некоторые места прошивки, особенно большие области 00 и FF можно угадать, выцепив в итоге неслабый кусок ключа а то и его весь. - имея эн апдейтов прошивок можно предпринять какой-никакой анализ ключа если реально прикинуть что и где менялось. В общем у меня такое оптимизма не вызывает - ламеризм откровенный. Мну делал так:ключик (поменьше) в камне, в бутере.Юзер его не знает ессно.И ессно защита от чтения.Алгоритм ARC4(крайне похож на RC4:) от rsa data security) - только упаси вас боже его RC4 называть, ибо trademark RSA).Почему он?Ибо легко и просто впихивается даже в ненавернутые камни, прост а потому быстр.И даже с XOR для любителей оной "хакерской" операции.Ну табличку надо на 256 байтиков, не развалитесь, можно ее временно выделить.И это - алгоритм без явных про%%ов.За столько лет ничего фатального в нем не нашли.Если правильно использовать. Ах да... один и тот же ключ юзать все-таки не рекомендуется из-за возможностей какого-никакого анализа потока данныз.Стоит делать апдейт так: 1) В девайс засунут ключ шифрования DeviceKey.В идеале еще и у всех разный (тогда вы без проблем попалите кто был пират, но вам придется делать персональные апдейты каждому юзеру и вести БД с ключиками - можно но сложно) 2)А чтоб не сильно светить DeviceKey и затруднить его анализ: 1й блок апдейта - это "временный" (Encrypted)SessionKey.Сам по себе SessionKey - просто random ключ которым зашиварован весь дальнейший апдейт.Дабы не было халявы, он зашифровывается вами и в потоке данных апдейта он шифроанный ака (Encrypted)SessionKey, а потом расшифровывается девайсом(опять в SessionKey) - с юзежом и вами и деваcом DeviceKey(только он и позволяет сделать из (Encrypted)SessionKey простой SessionKey которым все и зашифровано).Так что умникам на анализ перепадет лишь какие-нибудь десятки случайных байтов зашифрованные с юзежом DeviceKey что мягко говоря, негусто для анализа и шифрование временных ключиков никто не поломает в итоге(а предсказуемости то и нету, ибо рандом...). 3) Весь дальнейший поток шифруется временным ключиком SessionKey.Его светить на большом потоке данных не жаль, ибо юзается он 1 раз всего и случайный вообще.Ничего такого ценного для анализа это в итоге никому не даст. Что в итоге? - Апдейты, даже с одной и той же версией будут всегда разные и их анализ в криптографическом плане достаточно беспонтовая затея. - Не слишком дилетантское, ибо FAQ фидошного RU.CRYPT я читал чего и прочим рекомендую, весьма грамотно и доходчиво написано:).Все достаточно честно.И без явной халявы для хакерофф.Используется проверенный временем алгоритм, нет явных дырок ака алгоритм использован так чтобы не выставлять его слабые места и поюзать сильные(критика спецов - велкам, ламеры - факофф) - Юзайте длинные ключи(RC4 позволяет до 256 байтов ака 2048 битов что для СИММЕТРИЧНОГО шифрования просто немеряно, это для RSA оно "так себе").Правда 32 random байта (256 бит ключа) вам скорее всего хватит по самые нидерланды.Брутфорсить это скажем по сериальному линку хакеры сдохнут.От старости.Если совсем уж страшно сделайте delay на 100 миллисекунд при расшифровке SessionKey'я :) при апдейте ее никто и не заметит а вот хацкеры будут иметь скорость брута 10 паролей/сек при немеряном 256бит ключе.Ну типа удачи им :) - достаточно несложно сделать в lite варианте затеи :) - для неленивых:можно на основе этого сделать систему отслеживающую кто спиратил(для совсем неленивых еще и с блэклистингом их на предмет апдейтов, ибо нефиг), а также непиратабельные :P апдейты которые ставятся только на девайс ОДНОГО юзверя (ну пропишите при записи бутера разные DeviceKey всем юзерам-все кроме 1 обломаются это расшифровать..[придется вести БД с ключиками у кого какой и генерить апдейты персонально]). - Из минусов :) я не сказал ничего про integrity checking.Но зашивать мусор в случае апдейта склепаного хакером - это не особо правильно(хакер не зная DeviceKey один фиг не сможет сделать его осмысленным в расшифрованном в девайс виде ... но все равно не очень правильно это, поэтому... хакеру должно быть трудно сбрутфорсить состояние в котором integrity checking признает это за валидную прошивку).Над этим дочитавшие досюда (if any) подумают самостоятельно :).Замечу только что бутеру вообще не стоит запускать corrupted основной код.Проверяя это по меткам в начале\конце программы, чексуммам и прочему.