Просмотр полной версии : Теория сканирования
PIC-ador
22.11.2004, 13:45
...и давно пора создать тему теория сканирования...
да вот чето никто не хочет своими изысками делиться :)
Кто готов поделиться :?:
PIC-ador
22.11.2004, 15:51
2 Hotlom. Слово в слово, старый топик.
Ну, тогда продолжим. (с) Ворон.
3R атака...
Итак продолжим ..Я (Ворон) покопался в инете - ничего не нашел.. Написал Dejan-у (Simscan)и SirGraham-у(XSim)...никто не ответил...
Тогда напряг мозги и сам начал иследовать алгоритм... вообшем нашел я метод как на третьем роунде получить вторую пару... правда у меня получилось не 738 ходов, а максимум 512 плюс еще несколько .....
Так что и не знаю,велосипед изобрел или открытие совершил
Для найденной уже первой пары (0 и 8 ) ключа, варьируя (0 и 8 ) байты RAND-а , вычисляем 65536 значений (0,8,16,24) на втором раунде... из них берем такие пары,что отличаются друг от друга лишь первым байтом...(запоминаем соответствуюшие (0,8 )байты RAND ) такие пары на третьем раунде точно дадут коллизию друг с другом при изменении РАНД(4,12) от 0 до 255..
Итак формируем такие РАНД-ы в виде
K11 0 0 0 X 0 0 0 K12 0 0 0 Y 0 0 0
K21 0 0 0 X 0 0 0 K22 0 0 0 Y 0 0 0
где К11,К12 и К21,К22 найденные две пары , при которых на втором роунде результаты отличаются первым байтом... а X,Y меняются от 0 до 255 (X можно даже не менять, только Y).. получаем 256 пар (итого 512) запросов ...
посылаем их всех reader, получаем 256 пар ответов... из них выбираем те которые совпали... Каждой совпаденной паре соответствует 512 значений (4,12) KI ключа ... Опыт показывает что совпавший пар бывает как минимум две ... Если сравнить те что находятся в обеих списках по 512 значений, то получим уже всего несколько возможных значений(не больше десяти ) (4,12) КИ ключа... Ну а дальше проще.. для каждого из них можно вычислить пару значений РАНД(4,12) которые дадут коллизию на втором роунде .. Подаем их все на алгоритм, смотрим выход... для какой пары будет совпадение, то и является (4,12) пара КИ...
PIC-ador
22.11.2004, 16:10
А что слово в слово..
Да собст. ничего.
Описание работы кардинала - (2R) - на каждом шагу
И не только. Я вот например здесь нашел: http://www.okc.ru:8080/okc/publish/imag.nsf/book/5-93378-078-2?OpenDocument&env=8
далее симулируя програмно A38 алгоритм,
фиксируя значения Х1Y1 и Х2Y2, будем перебирать значения А и Б, пока на выходе не получим одинаковые ответы ... это и будет искомая пара KI...
Симулировать весь алгоритм нет смысла, так как это значительно замедляет процесс калькуляции пары КI..."Если результаты после второго раунда получились одинаковые, то на выходе алгоритма они тоже будут одинаковые"...С этого видно, что достаточно симулираовать только первый и второй раунды..и то не для всего входа, а только для байтов i,i+8,i+16,i+24...и того мы работаем всего лишь из четырьмя байтами + еще несколько, вместо 32+16+16+12+еще несколько...да и тут мы выполняем всего несколько циклов при шифровании, вместо той большой кучи(я имею в виду куча - весь а38 алго)...
А Ворону действительно памятник поставить мало! Спасибо тебе, Ворон!!!
для тех кто стремится к знаниям могу выложить книжонку в PDF (140-160рублёв американских стоит ;) ) там больее 1000 страниц, но, на англицком. Скажите куда? в архиве 11м. весит.
John Wiley & Sons - Smart Card Handbook - звать ее так :)
Я могу у себя выложить..Я завтра-послезавтра слеплю почтовый ящик, типа xxxx@unixoid.net.ua туда ее закинешь, и я потом перемещу ее в http://unixoid.net.ua/doc/gsm/xxx.pdf.tgz или что-то вроде того...Короче потом все расскажу, просто сейчас ящик слепить не могу - я дома, нету физического доступа к серваку...:)
За ранее благодарен ;)
PIC-ador
22.11.2004, 17:23
Симулировать весь алгоритм нет смысла, так как это значительно замедляет процесс калькуляции пары КI..."
Есно. Тем более, что при полном переборе, могут возникнуть коллизии не только на 2-ом раунде.
Могут...в принципе...в теории....хотя....
Еще интересная вещь, что Ворон ищет 0 пару 2R, потом 4 - 3R, 2 - 4R, 6 - 3R, 1 - 5R, 5 - 3R, 3 - 4R i последнюю 7 брутит...:) Наверное так быстрее, чем 2R->3R->4R->5R->3R->4R, но если подсчитать запросы, то выходит примерно x+~512+~256+~512+~512+~512+~256+1 против x+~512+~256+~512+~512+~256...
Хотя хто зна..,у меня, на пример 3R атака никогда не превышала 200 запросов(ну это я от руки какой-попало KI симулировал)...да и с ГоблинТелекомовской картой было около 150..может таким методом(Как у Воронскане) и экономнее...Посмотрю, разберусь с 4R и дальше увижу, как делать лучше...но по любом, если искать 4R атакой только одну пару, то будет проще...
И еще интересный прикол: На 2R атаке Воронскан(при одних и тех же условиях) делает на одно обращение меньше, чем получилось у меня, потом на 3R на 2 обращения больше, чем у меня :) проверку пар 2R атакой после 3R я учел тоже...
Вот, на пример для Ки 24301A8769A7C7A5D65A02D7C15FBBFD при старте с нулевой пары Woron на 2R атаке делает 1023 шага, у меня 1024. На 3R Woron - 118, у меня 116 всего(с 2R проверкой)...Почему так - не пойму....
PIC-ador
23.11.2004, 00:03
Цитата:
Проверил твою 2R таблицу. и увидел что у тебя счетчик A3A8 врет, показывает на одно обращение меньше, чем на самом деле.
Может ты где-то пару потерял?
Это навернов я так очки втираю...мол обрашения экономлю
при старте с нулевой пары Woron на 2R атаке делает 1023 шага, у меня 1024. На 3R Woron - 118, у меня 116 всего(с 2R проверкой)...Почему так - не пойму....
Разные ранды у вас однако... У меня тоже различается, на двух реальных Ki в одном случае +392 в мою пользу, в другом - 388. Но общий итог (по десяти разным Кi) приблизительно одинаковый.
Посмотрю, разберусь с 4R и дальше увижу, как делать лучше...но по любом, если искать 4R атакой только одну пару, то будет проще...
Дело в том что когда ишешь сразу две пары на 4R, то у меня вычислительный процесс получался тяжелый и занимал довольно таки приличный промежуток времени.. и при этом сьедал почти все 512 запросов... в тоже время если одну пару находит очень быстро и берет мало запросов, так что в сумме с запросами на последующую 3R aтаку получается почти те же 512, но в тоже время выигрыш во времени намного значительный... то же и вконце только вместо 3R использую брут форс...
Я сначала хотел поставить опцию выбора для 4R aтаки(для первой, для последней бессмысленно), (мол пушай юзер ломает голову как ему лучше :) ) , но многочисленные прогоны показали что fast 4R намного лучше...
Та же история и с 5R атакой.... теоретически можно вычислить все 4 пары , но времени на жизнь не хватит... поэтому допускается сильное упрошение, чтобы найти хотя бы одну пару.... и то как вы заметили вычислительный процесс может занять много времени....
Но опять же, это все мои мозаключения... вполне возможно я пропустил намного лучшие решения, которые найдете вы....
Итак , вводная в 4R атаку...... имея известные пары КИ (0,4,8,12 ) , найти такие два комплекта РАНД (0,4,8,12), чтобы
на третьем роунде полученные наборы Х1(0,4,8,12,16,20,24,28) и
Х2(0,4,8,12,16,20,24,28)отличались любым одним байтом (пусть будет первым)...
В этом случае варьируя любой из байтов РАНД (2,6,10,14) получим на третьем роунде такой набор Х3(2,6,10,14,18,22,26,30) , чтобы Х1Х3 и Х2Х3 (а точнее их первые байты ) давали на четвертом роунде
одинаковые наборы Х(0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30)...
Как будем искать РАНД (0,4,8,12) ?
Что будем делать после нахождения коллизии на четвертом роунде?
Симулировать весь алгоритм нет смысла, так как это значительно замедляет процесс калькуляции пары КI..."Если результаты после второго раунда получились одинаковые, то на выходе алгоритма они тоже будут одинаковые"...С этого видно, что достаточно симулираовать только первый и второй раунды..
Tы тысячу раз прав :) просто когда я писал эти строки, у меня не практически не было кода, все в теории...
Как будем искать РАНД (0,4,8,12) ?
Понятно, что перебирать все байты мы будем оооочень долго...Значит с начала ищем (как и при 3R) такие Ранд (0,8 ), чтобы результаты (0,8,16,24) на 2м раунде отличались одним байтом. Найдя такие пары ищем такие Ранд (4,12), чтобы результаты на 3м раунде отличались одним байтом...
Ну да,все это хорошо, но у меня этот процесс поиска занимает тоже много времени...бывает и 10 минут, бывает и час...Это со специально подобранными "Быстроотдающимися" :) КI...Не исключено, что таким методом в реале искать РАНД (0,4,8,12) можно и полтора дня..:)
Теперь вот сижу думаю, как бы этот процесс ускорить...
Есть немножко мыслей, сейчас буду проверять их на практике....
____________________________
Вот посидел немого подумал...
Если будем искать только вторую пару 4R атакой, то нам нужно работать только из 0,2,4 8,10,12 16,18,20 24,26,28 байтами после 4 раунда...сейчс буду думать дальше...
ЗЫ. Сорри, что думаю в слух:) мне так проще..:))
У меня вопрос по 3R - после нахождения коллизии и вариантов пар для (4,12) мы их проверяем через 2R-коллизию. А если среди вариантов 2 неколлизионных??? Что будем делать?
ну если одна неколлизионная пара среди коллизионных, то я щитаю ее нашей.если две, то я просто выплевываюсь и говорю юзеру, пусть просто подставляет эти пары и пробует....
Может Ворон и придумал какую-нибудь проверку неколлизионных пар :)
И еще, по моему у Воронскане используется таблица неколлизионных пар, чтобы даром не проверять 2R атакой эти пары...
В любом случаи я себе сгенерю такую таблицу и прицеплю к своей приблуде...
Ну такая таблица у меня тоже есть (там всего-то 769 элементов). А вот что придумать для проверки неколлизионных пар... Ведь насколько я знаю - для Ворона неколлизионность важна только при 2R-атаке, а дальше - пофигу. Ибо он же легко находит ключи с неколлизионными парами. Хотя может я и ошибаюсь...
Лично у меня на симке KI с 3 неколлизионными парами. Ворон его нашел ;)
Я ею потом займусь, когда с 4R справлюсь...
Если после 3R в списке возможных пар есть одна неколлизионная, то Ворон полюбом все найдет...И я тоже найду(считая эту одну пару нашей) ;)
А неколлизионные эти пары(769 элементов) на втором раунде. Кто сказал, что они не дадут коллизию на 3м,4м,5м раунде?...С этого и надо исходить....Но вернусь я к этому после разбора с 4R :)
Интересно какова вероятность, чтобы из нескольких (три-четыре) возможных вариантов сразу две оказались неколлизионные?
Но допустим все таки не повезло... Что мешает продолжит 3R (да и 4R,5R) и искать другие такие пары которые дадут другие наборы
на 2R(3R,4R), отличающиеся одним байтом? И получить другой список возможных значений... вряд ли и этом списке будут две неколизионки... Уже не говорю о том что сравнение обеих списков скорее всего даст однозначно искомую пару и без дополнительной 2R проверки...
Ворон, хмм... а это мысль - седня вечером попробую запрограммировать сию вещь ;-) (то есть сравнение 2-х списков).
А что касается вероятности - то примерно (769/65536)*(768/65535)=0.014% Не совсем нулевая ;-)
в смысле нужно клонировать 100 тыс. карт чтоб одна была такая ? :)
кроме вышеприведенного, есть еще варианты...
Можно начать последующую атаку, предполагая что одна из коллизионок и есть искомая пара..если атака провалится, повторяем атаку уже с другой искомой парой...
В свете этого легко понять как работает режим Strong KI, который запускаешь, если уверен, что первая пара неколлизионная...
Проводится сразу 3R атака, в предположении что первая пара одна из 769 неколизионок... если атака провалится, повторяем атаку со следующей неколлизионкой..и так до тех пор пока 3R не даст положительный результат... в худшем случае понадобиться
769*512 запросов.... При должной оптимизации тыс. сто попыток еще можно скостить...
Ворон, ну это (про подбор неколлизионок) вобщем понятно. Более того, я это уже реализовал ;-) Дело в том, что Ивановский Мегафон все таки всех наколол! У него v1, но все ключи из неколлизионок! Поэтому сразу начиная подбирать такую пару мы с вероятностью 65000/769*512=16.5% (реально даже больше - оптимизация рулит!) такую карту ломаем. В других случаях - она дохнет :-( Лично у меня уже есть две сломанных карты Ивановского Мегафона (и куча убитых).
ЗЫ. Работает ли это в Москве - сейчас проверяется. Но похоже, что в Москве честный v2.
Как будем искать РАНД (0,4,8,12) ?
Ну я ищу так:
Для найденых (0,4,8,12) КI крутим РАНД(0,8 ) и ищем такие пары (0,4,8,12,16,20,24,28 ) после 3го раунда, которые отличаются одним байтом(0м,8м,16м или 24м)..Но они могут еще и отличаться 4м,12м,20м или 28м СоответственнО...Далее начинаем крутить (4,12)байты в обеих рандах и искать такие пары после 4го раунда, что отличаются друг от друга одним байтом (0,8,16 или 24 соответственно). Далее варьируем любой из (2,6,10,14)байтов от 0 до FF в обеих рандах и берем такие пары после 4го раунда, которые совпали(запоминаем РАНД1(0,4,8,12) и РАНД2(0,4,8,12)). Это и будут наши искомые ранды.
Далее посылаем запросы такого вида в ридер:
K10 0 X1 0 K11 0 X2 0 K12 0 X3 0 K13 0 X4 0
K14 0 X1 0 K11 0 X2 0 K15 0 X3 0 K13 0 X4 0
Где Kxx - найденные соответствующие байты рандов. А любой из байтов X меняем от 0 до 256.
Выбираем то, что совпало...(запоминаем соответствующие X). Для fast 4R нам достаточно 8и штук X, для полной 4R достаточно 16(вобще по идее надо 32)....
....Продолжение следует...;)
PIC-ador
26.11.2004, 17:00
но у меня этот процесс поиска занимает тоже много времени...бывает и 10 минут, бывает и час...Это со специально подобранными "Быстроотдающимися" КI...Не исключено, что таким методом в реале искать РАНД (0,4,8,12) можно и полтора дня..
Проверь свои циклы! Такого не может быть, разве, что на XT.
Та не нужно уже ничего проверять..Ту идею я грохнул...Сейчас у меня эти ранды быстренько(максимум 50 сек со специально-подобранными "тугими" парами KI, не реальными..) ищутся по вышеизложенному методу...тут тоже колличество запросов в разных случаях очень отличается от Воронскана...В одних случаях у меня 82 запроса - у Ворона 143...в иных у Ворона 120, у меня 244....
Теперь парюсь над посиком нужной пары KI...Она должна присудствовать во всех 8ми списках по 8192 значения...Но она будет там присудствовать только тогда, когда у нас будет противоположная пара...не знаю, как правильно ее назвать, я называю ее "Опорной"...Вот если она известна, то ищется нужная пара очень просто:
Фиксируем нашу "Опорную" пару KI и остальные ранее найдены байты KI.
A0 0 X 0 A1 0 K0 0 A2 0 Y 0 A3 0 K1 0
Где А0,А1,А2,А3 - найденые ранее байты. К0 К1 - наша "Опорная пара". X,Y варьируем....
Делаем ранды вида
K10 0 X1 0 K11 0 X2 0 K12 0 X3 0 K13 0 X4 0
K14 0 X1 0 K11 0 X2 0 K15 0 X3 0 K13 0 X4 0
Где Кxx - ранее найденные соответствующие байты РАНД. X1,X2,X3,X4 вместо одного из них подставляем 8 ранее найденных байтов X(тех, когда мы коллизии искали)..
Далее строим 8 списков из таких XY KI, при которых результаты после 4го раунда для этого всего совпали...
Наша искомая пара пара должна присудствовать во всех этих 8и списках...
А вот как быстро найти эту "Опорную" пару я еще не придумал...Пробовал крутить ее и повторять выше описанную процедуру,- работает, но жрет много времени...1,3,5 минут...много...должно искаться за пару сек...
PS. Еще хотелось бы узнать, что такое "Common" в Воронскане? Для чего он служит?
Common - это...
вообшем когда находишь такие ранды (0,8 ), чтоб наборы (0,8,16,24 )на втором роунде отличаелись одним байтом,
то common это соответсвующий байт из набора (4,12,20,28 ) с которым
вышеупомянутые байты из (0,8,16,24 ) дадут коллизию на третьем роунде... Common - смысле этот байт обший для обоих байтов... Более умной ассоциации в голову не пришло... :)
Вариьруя любой из байтов (4,12 ) этот common и подгонятся...
Понял...А ты этот байт просто выводишь или гдето далее используешь?
лично у меня он нигде не используется....
Что-то я не могу догнать, как искать одну пару Ki при 4R атаке...
Весь вечер и день мучился....
Обе пары ищутся, но долго..минут 15...ну это читывая то, что я пишу под FreeBSD, а в ней все проги на много медленнее работают, чем под виндой...Здесь совсем иная раздача приоритетов и все идет через ядро...но все же,..15 минут под FreeBSD ~=5 минут под виндой...долго...
Кто подскажет, как искать одну пару? ;)
Думай сам...итак все разжевали...
PIC-ador
28.11.2004, 15:53
Описание работы кардинала - (2R) - на каждом шагу, ну и смысл, если сейчас сразу 4Р и 5Р сразу выложить?
Думай сам...итак все разжевали...
Я так понимаю, топик надо закрывать?
Незачем всем объяснять работу алгоритма.
А то завтра появятся SimScan 4,5.. и каждый со своим трояном.
Думай сам...итак все разжевали...
Да как то уже додумаюсь...В принципе, это даже будет более полезно для меня...
Да и так за все спасибо!...
Я так понимаю, топик надо закрывать?
Незачем всем объяснять работу алгоритма.
А то завтра появятся SimScan 4,5.. и каждый со своим трояном.
Закрыть или нет это дело уже ваше...Я специально с начала не хотел открывать такой топик, хотя инфа была очень нужна....Нужно закрыть - закрывайте....
И цель у нас(меня) совсем не симскан с трояном..Цель - изучить это алго и перейти к "вскрытию"(в кавычках!) нового алго....также цель свой сканнер - для себя....
А что касается СимСкан 4,5 с трояном, то достаточно написать только троян, скан писать не нужно...Тебе сейчас представить симскан 6 с трояном(если нужно, забабахаем это все за 2 часа..) Я то шучю, но интерфейс того же скана очень легко меняется и алго совсем знать не нужно....
как регистр сместить..
А это что за регистр? и куда его надо двигать?
не надо ничего закрывать... пусть просто у людей будут оригинальные идеи...
unixoid, для упрощения твоей задачи (работа со списками с кучей значений) - надо использовать хэши. В Перле - оно есть из коробки, для FPC - у меня есть модуль, эмулирующий Перловские хэши. Для С такой тоже есть - поищи в инете.
PIC-ador
29.11.2004, 10:38
не надо ничего закрывать... пусть просто у людей будут оригинальные идеи...
Ну. да ладно! Тогда еще для стимула: (c) Ворон
Сгенеришь таблицу хоть на элемент меньше моей, считай себя моим Гуру
Прикладываю программулю для генерации полной таблицы коллизий:
Формирует 3 файла в корне диска C:
Collisions.txt
Collisions.bin
No_Collisions.txt
Формат бинарника:
WORD Ki;
BYTE n; // Число пар
BYTE Pairs[]; // Собст. пары
Советую внимательно скурить исходник проги с названием comp128v1.c ;-) Курить до тех пор, пока не придет просветление ;-) А вот то, что написано в этой теме помогает приходу этого просветления.
Сидел вот вчера вечером и сегодня с утра на работе и НАШЕЛ ПАРУ!!!Додул на конец то :)
Все очень просто...Но долговато..примерно от трех до шести минут на фре.на винде будет 1-2..В принципе пойдет..но у Ворона все равно быстрее.. ну то ладно..куда спешить:)) сойдеть..:P
Выкладывать теорию или нет?
PS. А таблицу неколлизионных пар KI сгенерил вчера за 2 часа...
Хотя сначала делал тупой перебор, на который нужно 16 часов..Типа думал, не дождусь:)
PPS.Спасибо PIC-ador`у за прогу..попробую, мож будет за 10 мин генерить.:)
а с хешами связываться не хочу..спасибо конечно..но мне больше нравится здоровенная область (типа malloc(65536*32) байт) и в ней все строить, запоминая лишь адреса..а потом по завершению думания срезать размер до минимума..сейчас у меня эта область занимает всего примерно 1.2 метра...в ней все атаки крутятся, все апду,все вобщем...
Спасибо! Тогда вопрос Wert-у :) Ты взломал пару карт Ивановского мегафона, так? Там V1 но с "перемешанными" таблицами -так?
Разве знание Ki что либо дает если таблицы всй равно не известны?
Или простая заливка Ki в Sim Emu с стандартным V1 позволяет работатьв сети?
Тогда как быть с регистром у опсоса, в смысле что у него должно быть четко прописано по какому алгоритму работает каждая из выпущенных карт? И какого ответа от неё ждать? Либо это означает что БС сверяет ответ по обоим алгоритмам?
Либо даже перемешанная таблица никак не влияет на sres и он остаеится таким же, вот только колизионные пары хрен нащупаеш?
Да насчет прокрутить алгоритм в голове Unixsoid писал сильно он накрученный. У меня точно IQ не хватит :( Почитаю о Хеш функция может потом докумекаю.
Соррри если много! :) Если вопрос туповат ,звиняйте видет бог не хотел я вам мозги парить :)
Впроче глупых вопросов не бывает бывают глупые ответы :)
Прокуривается алго в голове...Только надо сильно хотеть..Тебе те 8 циклов и все остальное не нужно(пока)..Главное знай те пару правил, что где-то в начале этого топика есть..И еще почитай в топике Wert-scan о раундах шифрования.именно это тебе с начала и надо!!! Раунды видно в алго в самом внутреннем вложенном цикле..ну в том раене где-то :))
будешь знать это - алго без проблем..
Это просо я леньтай и тугодум, потому и спрашиваю o разных мелочах и подгонках, хотя все оно элементарно просто...
По поводу взлома...Верт же писал, что там просто КИ состоят из неколлизионок(все пары такие)...и метод взлома их очень хорошо изложен в этом топике выше...
К стати, себе тоже уже бахнул..Буду пробовать старые UMC с дельфинами(те, которые не сканятся) ломать..Тем более они без а38 лимита :P
Не фига не понимаю, Сам Ворон где то тут писав дескать скорее второе, таблицы умело подобраны(или перемешанны), а не Ki не из коллизионных пар!!
А почему только старые UMC c дельфинами, ведь UMC "честно" пишет где V1 а где V2 На безлимитниках стабильно пишут V2 и на контрактах також.
По идее четко должны определятся по хвосту Sres-а? Я кщо нули-V1 Якщо Нi- V2 а то и V3 местами
Сам непроверял, но говорят. Да и здесь это обсуждали.
Насчет лентяя и тугодума я сам такой :)) Лень это подсознательная мудрость :)
Метод взлома:
кроме вышеприведенного, есть еще варианты...
Можно начать последующую атаку, предполагая что одна из коллизионок и есть искомая пара..если атака провалится, повторяем атаку уже с другой искомой парой...
В свете этого легко понять как работает режим Strong KI, который запускаешь, если уверен, что первая пара неколлизионная...
Проводится сразу 3R атака, в предположении что первая пара одна из 769 неколизионок... если атака провалится, повторяем атаку со следующей неколлизионкой..и так до тех пор пока 3R не даст положительный результат... в худшем случае понадобиться
769*512 запросов.... При должной оптимизации тыс. сто попыток еще можно скостить...
Дело в том, что Ивановский Мегафон все таки всех наколол! У него v1, но все ключи из неколлизионок!
И где тут идется про перемешивание?
Читать надо все подряд внимательно.........
Дорогой, Надпись V1,V2 на симках означает, что симка с менЮ :)
У V1 i V2 хвост среса одинаковый - 10 бит нулей.у V3 - не нули...
Об этом тоже писали..внимательнее.....
Ты взломал пару карт Ивановского мегафона, так? Там V1 но с "перемешанными" таблицами -так?
Нет, там обычный V1 с обычными таблицами, но ki - только из неколлизионных пар (то есть пар, которые нельзя найти 2R-атакой).
Я судорожно шукаю по форуму где я це вичитал! Похоже недопонял :(
Или дофантазировал.
Мне казалось что колличество коллизионных пар будет определятся именно таблицами алгоритма.
Rand 128Bit преобразовуется в Sres 32Bit
Преобразование через алгортм с константой Ki одинаковой размерности с Random.
Понижение размерности всегда связано с коллизиями.
Количество коллизионных пар (вполне возможны и тройни, и выше..)=
(2^128) - (2^32) велико.
Что опять не туда понесло? :)) Вот поэтому и просил дать почитать старые ветки.
Но насчет того что вряд ли Ki составлен из неколлизионных пар Ворон всё же где то писал!!!
Он там даже процент указал 99,9 что ли :)
Хотя скорее всего я опять недопонял и наговариваю на Ворона :))
А нет! Вот надыбал, цитата:
Мы ж уже убедились что симскан однозначно берет в режиме Strong Ki
такие пары ..максимум до 300 тысяч.. легко проверяется на картах , у которых нет ограничения A38...
Так что на 99% КИ из неколлизионок можно отбросить...
PIC-ador
29.11.2004, 17:55
Спасибо PIC-ador`у за прогу..попробую, мож будет за 10 мин генерить
P.S. 10 мин на P4-2,6
Я все это на дюроне 900 делал...512 метров памяти...FreeBSD-4.10
BigMan, похоже на разговор слепого с глухим. Я говорю об конкретном случае, а Ворон говорил об проверке того, что V2 все-таки используется кое-где ;-)
PIC-ador
29.11.2004, 19:40
Я все это на дюроне 900 делал...512 метров памяти...
:D И что? Мне теперь проц. менять, память лишнюю убирать?
Когда я говорил
Мы ж уже убедились что симскан однозначно берет в режиме Strong Ki
такие пары ..максимум до 300 тысяч.. легко проверяется на картах , у которых нет ограничения A38...
Так что на 99% КИ из неколлизионок можно отбросить..
имелось ввиду, что 99% операторов не будут строить КИ из неколлизионок, поскольку они однозначно берутся Стронг КИ..т.е. особого смысла нет... Лично я ни разу такие КИ не встречал...
очевидно ивановский оператор, о котором тут толкуют относится к этому 1% :) ..
Хотя сам этого не видел..
постараюсь как нить достать ивановскую карту чтоб самому и наглядно проверить...
Ивановский оператор самым дешевым способом обломил халявщиков - карты имеют ограничение A38 на 65000 попыток + неколлизионные ключи. Дешево и сердито. То есть доказать-то мы доказали сей факт, но никто не будет подключаться 5-6 раз, чтобы с высокой вероятностью (не 100%) отсканировать хотя бы 1 такую карту. То есть практической пользы - НИКАКОЙ.
карты имеют ограничение A38 на 65000 попыток + неколлизионные ключи.
В принципе да... Неколлизионки с лимитом это сила...
То что для Стронг КИ нужно много попыток( превышающих стандартный лимит в несколько раз) было основной причиной
,что я не реализовал его в Woron_Scane... не хотелось быть причиной
кучи паленных карт :)
Вот если подобрать более удачный алгоритм, чтоб уложиться в лимит...
И что? Мне теперь проц. менять, память лишнюю убирать?
Успокойся..это я просто сказал к тому, что я таблицу сгенерил за 2 часа на таком корче...
И еще сегодня скомпилил свою бадягу под винду(только эму,без ридера) так работает оно гораздо быстрее...почти как Ворон_Скан...
Теперь вот думаю о 5R..У Ворон_Скане она и так может долго крутится, сколько тогда она будет крутится у меня под Free...
Вот если подобрать более удачный алгоритм, чтоб уложиться в лимит...
Над таким алгоритмом сейчас сижу думаю...пока идей нету...
да еще с 5R надо как-то разобраться...:P
Над таким алгоритмом сейчас сижу думаю...пока идей нету...
Попробуй использовать такую... при стронг ки проводится 3R атака (769*512 ) для поиска второй пары (первая неколлизионка), которая
может быть любой из 65 тыс... если же и вторая пара неколлзионка (как ивановские),то их уже 769... надо както использовать сей факт для уменьшения запросов...
Ну у меня стронг ки реализован..в худшем случаи это 393728 запросов...
Я думаю надо как-то проверять сразу 2 неколлизионки...Может как-то 4R сюда подключить...
На самом деле предполагая, что все пары неколлизионные можно уменьшить число запросов для 3R-атаки (Ворон прав). А вот как это сделать - надо думать. Седня вечерком помозгую. Пока идея такая. Всего вариантов 1-2 пар 769*769=591361. Для каждого из этих вариантов построить все нужные для 3R варианты запросов к карте, а потом выбрать из полученного массива минимальное подмножество, однозначно идентифицирующее пару 1-2. То есть построить таблицу, как для 2R, только для 3R. Имхо, может получиться...
По поводу 393728 запросов. Это много. Unixoid, подумай вот над чем - "для каждого из 769 вариантов первой пары ты заново ведешь 3R-атаку. А если сохранять и использовать ранее проведенные запросы?"
И еще, Unixoid - почему у тебя FreeBSD медленнее Win? У меня скорость под Linux примерно такая же, как и в Win. А скорость работы с портом - вроде даже чуть выше. Сегодня померяю точно и выложу результаты (на одной и той же карте, одной скорости и одном реадере проведу 2R-атаку на одну и ту же пару Вороном и Вертом. Скорости сравню).
На самом деле предполагая, что все пары неколлизионные можно уменьшить число запросов для 3R-атаки (Ворон прав). А вот как это сделать - надо думать. Седня вечерком помозгую. Пока идея такая. Всего вариантов 1-2 пар 769*769=591361. Для каждого из этих вариантов построить все нужные для 3R варианты запросов к карте, а потом выбрать из полученного массива минимальное подмножество, однозначно идентифицирующее пару 1-2. То есть построить таблицу, как для 2R, только для 3R. Имхо, может получиться...
Да.. хорошая идея..Подумаю тоже седня....
По поводу 393728 запросов. Это много. Unixoid, подумай вот над чем - "для каждого из 769 вариантов первой пары ты заново ведешь 3R-атаку. А если сохранять и использовать ранее проведенные запросы?"
А :)) Спасибо за идею!..Просто склепать таблицу и пихать туда все новые запросы...перед подачей следующего запроса провврять его,если он есть в таблице - брать следующий, если нет - суем его в таблицу и подаем в ридер..и тд..сейчас сделаю..
И еще, Unixoid - почему у тебя FreeBSD медленнее Win? У меня скорость под Linux примерно такая же, как и в Win. А скорость работы с портом - вроде даже чуть выше. Сегодня померяю точно и выложу результаты (на одной и той же карте, одной скорости и одном реадере проведу 2R-атаку на одну и ту же пару Вороном и Вертом. Скорости сравню).
Я не картами доганяюсь, я эмуль юзаю..:)
А что Free работает медленнее линукса, так это тоже факт...Просто тут немного приоритеты подругому раздаются...В принципе скорость можно приблизить до винды, просто sys.uid_pc.0 тысяч 60 дать...
Ясно. Фря тебе все процессорное время не отдает ;) Да, я к своей проге тоже эмуль прикрутил, чтобы карту всегда не дергать ;)
Ясно. Фря тебе все процессорное время не отдает ;)
да.в ней приоритеты раздаются единица(измерения)/процесс и единица/юзер.и так для каждого юзера...руту действует только первый лимит.второй - нет.
У меня на винде как вы заметили n IDLE по дефолту работает...
эт в смысле пользуйся тем и тогда, чем другие процессы в данный момент не пользуются :)
Ну в Фре приоритеты по другому раздаются...Хотя сам процесс тоже может ТОЛЬКО уменьшить себе приоритет...
а так у тебя вообще оптимизация хорошая...
Сверял твои четверки, шестерки, так результаты на втором(третем) раунде отличаются не фиксированным байтом, как у меня..Ты, видимо перебираешь все варианты и ищешь первое отличие любым байтом...
Ну мне, в принципе пофиг...я все последний байт юзаю..сойдет...
Ворон(или еще кто нибудь), напишите пожалуйста вводную(или еще что нибудь) о 5R атаке....
Ладно.Вводную напишу я :D
Значит для поиска коллизий на 5м раунде нам нужны RAND1(0,2,4,6,8,10,12,14) и RAND2(0,2,4,6,8,10,14).
Далее варьируем любой из байтов RAND(1,3,5,7,9,11,13,15) и подаем это все в ридер. Ищем 8 коллизий...
Как будем искать RAND2(0,2,4,6,8,10,14)? :)
Что будем делать после нахождения коллизий? :)
PS. 5R - это 4R в квадрате :D
По поводу Стронг КИ...
Сидел думал, а что если сгенерить для каждых KI(0,4,8,12) (их у нас 769*769) по таблице коллизий, которые(каждая из таблиц) будут содержать все варианты коллизионных RAND1(0,4,8,12) и RAND2(0,4,8,12). Далее роясь в этих всех таблицах находим максимально-совпадающие RAND1(0,4,8,12) и RAND2(0,4,8,12) и тулим их всех в новую таблицу, которая и будет таблицей для 3R для неколлизионок.
:?:
unixoid, ага. именно это я вчерась попробовал сделать - понял, что мой ноут (1000/128 мегов) не место для этой операции, посему завтра (седня я туда не попадаю) запущу сей процесс на 4-х процессорном серваке на P-IV-Xeon. Может что и получится ;-)
По поводу измерений (вчера обещал) - работа с портом Ворона и Верта почти одинаковая по скорости. При прочих равных условиях (скорость 19200) Ворон провел 10000 попыток подбора на 2R за 9 min 34 sec, Верт под Виндой - за 9 min 27 sec, а Верт под Линухом - за 9 min 54 sec. Как видите - разница совсем не критичная (то есть скорее всего мы уже упираемся в скорость карты).
А вот этот момент интереснее (хотя может все про него знают, но я столкнулся впервые) - при проведении 2R атаки на пару KI=19D6, по таблице Ворона - находим коллизию B6F9 и DF9E, однако при попытке подобрать KI видим, что это коллизия не после 2-го раунда! О как. Придется переписывать алгоритм (чтобы продолжал дальше искать следующую коллизию).
Ну давай! Я тоже замутил софтину..Сегодня буду для каждой серии таблиц на кождом компе на работе запускать..:) Нагенерим,блин!:D
То ты мерял 2R...Ты померяй сами подсчеты(3R,4R,5R)..
По поводу 19D6. Использовал таблицу Ворона.
Вот работа моей проги:
Starting 2R attack on pair 0...
Dont stop this process!
100
200
300
400
..........................
24500
Collision found! DA9C 824C
Used 24531 steps. Calculating pair 0 of KI...
Pair 0: 19D6
Please wait. Calculating data for 3R attack...
Found Data: 3D0A 4A9D
Starting 3R attack on 4 pair...
100
3R attack 2 collisions found! Used 188 steps. 24719 - all steps.
Calculating 4`t pair...
Possible pair 4: 69C1
Possible pair 4: A7C1
Please wait. Searching 2R collision for pair 4...
Collision found 69C1! DA01 D352
Used 24721 - all steps.
Pair 4: 69C1
Please wait. Calculating data for 4R attack...
Found Data: 8108 492E 2200
Starting 4R attack on 2 pair...
100
4R attack 8 collisions found! Used 156 steps. 24877 - all steps.
Please wait. Calculating 2`t pair...
1A02 0018
Please wait. Searching 2R collision for pair 2...
Collision found 1A02! FE7D FCB3
Used 24879 - all steps.
Pair 2: 1A02
Please wait. Calculating data for 3R attack...
Found Data: 20EE 68B8
Starting 3R attack on 6 pair...
100
200
300
400
3R attack 2 collisions found! Used 474 steps. 25353 - all steps.
Calculating 6`t pair...
Possible pair 6: C7BB
Possible pair 6: D5BB
Please wait. Searching 2R collision for pair 6...
Collision found C7BB! 3EF4 B1D0
Used 25355 - all steps.
Pair 6: C7BB
Please wait. Calculating data for 5R attack...
Found Data: 0F02 001F 3100 0A00
Starting 5R attack on 1 pair...
100
200
300
400
500
5R attack 8 collisions found! Used 512 steps. 25867 - all steps.
Please wait. Calculating 1`t pair...
PIC-ador
01.12.2004, 10:00
однако при попытке подобрать KI видим, что это коллизия не после 2-го раунда! О как.
Есно, ведь раундов аш 40 штук. Почему бы и нет?
unixoid, скорее всего ты не натолкнулся на то, о чем я писал, потому что для такой коллизии важен весь KI ;-)
Итак: вот сам ki - 41537D8424F019E5B8985D6B9CDBD6E2.
Попробуй провести 2R на 6-ю пару. Вот эти запросы
000000000000B600000000000000F900 и 000000000000DF000000000000009E00 дадут коллизию, но пару Ki ты не найдешь. Таблица - Ворона.
А теперь сделай тоже самое , но замени нули скажем на единицы :)
PIC-ador
01.12.2004, 10:54
Collision pair: B6,F9 DF,9E
Collision pair: 82,4C DA,9C
Found by 2R Attack: 19,D6
Used steps: 24531
А в чем проблемма?;)
/usr/home/root/files/prog/scan > ./uscan -e `cat kis/i` -t tables/vrn.bin -k6
<======================== Unixoid SIM Scanner v0.94 =========================>
Starting 2R attack on pair 6...
Dont stop this process!
100
200
300
400
500
.....................
11900
Collision found! DF9E B6F9
Used 11910 steps. Calculating pair 6 of KI...
12000
12100
12200
12300
12400
12500
....................
Collision found! DA9C 824C
Used 24531 steps. Calculating pair 6 of KI...
Pair 6: 19D6
Please wait. Calculating data for 3R attack...
Found Data: 3D0A 4A9D
Starting 3R attack on 2 pair...
100
200
300
3R attack 2 collisions found! Used 352 steps. 24883 - all steps.
Calculating 2`t pair...
Possible pair 2: 454A
Possible pair 2: 7D5D
Possible pair 2: 925D
Possible pair 2: BE4A
Please wait. Searching 2R collision for pair 2...
Collision found 454A! CC85 0E30
454A is wrong.
Please wait. Searching 2R collision for pair 2...
Collision found 7D5D! CB70 034C
Used 24887 - all steps.
Pair 2: 7D5D
Please wait. Calculating data for 4R attack...
Found Data: 6A02 EB7A 6D00
Starting 4R attack on 0 pair...
100
4R attack 8 collisions found! Used 136 steps. 25023 - all steps.
Please wait. Calculating 0`t pair...
41B8 0009
Please wait. Searching 2R collision for pair 0...
Collision found 41B8! 4A83 084E
Used 25025 - all steps.
Pair 0: 41B8
Please wait. Calculating data for 3R attack...
Found Data: 0B79 0E55
Starting 3R attack on 4 pair...
100
3R attack 2 collisions found! Used 124 steps. 25149 - all steps.
Calculating 4`t pair...
Possible pair 4: 249C
Possible pair 4: 33B1
Possible pair 4: 8D9C
Possible pair 4: DCB1
Please wait. Searching 2R collision for pair 4...
Collision found 249C! F93B B88B
Used 25151 - all steps.
Pair 4: 249C
Please wait. Calculating data for 5R attack...
Found Data: D916 4F17 7C00 9C00
Starting 5R attack on 1 pair...
100
200
300
5R attack 8 collisions found! Used 390 steps. 25541 - all steps.
Please wait. Calculating 1`t pair...
А теперь сделай тоже самое , но замени нули скажем на единицы :)
Точно! После нахождения коллизии на "00" достаточно проверить ее на "11" или еще на чем. Если это 2R-коллизия, то она останется, а если нет - исчезнет. Но вот всегда-ли исчезнет? То есть достаточно ли одного шага для такой проверки??? Или лучше просто искать коллизию дальше, а эту пропустить???
В принципе можно не заморачиваться проверкой, если по коллизии не удалось вычислить пару, то просто ищем дальше...
А теперь сделай тоже самое , но замени нули скажем на единицы :)
Точно! После нахождения коллизии на "00" достаточно проверить ее на "11" или еще на чем. Если это 2R-коллизия, то она останется, а если нет - исчезнет. Но вот всегда-ли исчезнет? То есть достаточно ли одного шага для такой проверки??? Или лучше просто искать коллизию дальше, а эту пропустить???
Зачем мучится,подавать лишние проверочные запросы карте???
Сделай как у меня, ищи коллизию, ищи KI-не нешел KI - иши далее коллизию..
PS. У меня такой алго вышел изначально..Автоматически:))
Если ты проверишь 2R это киллизия или нет, то если нет-ты все равно далее будешь искать следующую.Так зачем тогда проверять?,проще(и быстрее) сразу далее искать(если провал в калькуляции KI)...
Ну вобщем я уже понял ;-) Поэтому так и сделал. Лишние 2 запроса к карте сэкономил ;-)
Ok...
теперь представьте , идет 3R атака, а одна из коллизий произошла на четвертом роунде...
Ну понятно, коллизия на 4m раунде для RAND1(0,2,4,6,8,10,12,14) и RAND2(0,2,4,6,8,10,12,14), где (2,6,10,14) нули...может и такое быть, тогда просто аналогично проверяем 3R это коллизия или нет...
к стати, Воронскан при одних и тех же RAND(0,4,8,12) делает на 2 запроса больше, чем моя бадяга...Теперь понятно почему :P
PS. Ворон, у тебя есть реальный KI и реальные RAND'ы, где такое произошло? Дай, если есть.я поюзаю....;)
ты думаешь я хранил все такие КИ? сколько времени прошло...
Да ты не волнуйся...это встречается намного чаше чем хотелось бы..
Ну тогда после нахождения коллизий меняем любой из (2,6,10,14) байтов в обеих рандах и посылаем их симке. Коллизия исчезла - вычисляем новые RAND1(0,8 ) RAND2(0,8 ) и повторяем атаку...
Если при 3R атаке появляются коллизии на 4м раунде часто, то при 4R на 5м раунде они будут появлятся еще чаще? или как?
:?:
Ну статистику не вел, но в принципе достаточно часто... Именно так я и узнал об таких случаях..гоняя разные КИ...будь это редкость мог бы даже и не подозревать... Хотя и теоретически можно было бы предположить....
Ок...Спасибо.
Уже реализовал такие проверки для 3R и 4R...
Да ты не волнуйся...это встречается намного чаше чем хотелось бы..
Ага. И правда. Из 15 моих генернутых(random) KI 2 штуки таких(при 3R дают коллизию на 4R)...:)
Уже отладил...и 4R тоже отладил..
И еще вопрос. Что, если при 5R коллизия возникнет на 6m раунде? Такое быть может или нет? Раундов всего-то 40(ны 5 штук повторяются 8 раз..)...
а какие проблемы? делаешь такую же проверку...
P.S. кстати здесь есть только wertscan , a где твоя прога?
а какие проблемы? делаешь такую же проверку...
Ну на 4м раунде я меняю любой из (1,3,5,7) байтов..
А как быть на 5м? У нас же выход на 5м раунде зависит от всех 32х байтов входа..
Потому и спросил Что, если при 5R коллизия возникнет на 6m раунде?
P.S. кстати здесь есть только wertscan , a где твоя прога?
Ну там 5R калькуляция KI еще не полностю готова...Сделаю - выкладу готовый бинарник под linux,FreeBSD,WIN..
Или может так, как есть в исходном виде положить?
Просто спрашиваю - не хочу, чтобы пошла массовая CTR-C CTRL-V исходников....
А как быть на 5м? У нас же выход на 5м раунде зависит от всех 32х байтов входа..
Ах ну да... не думаю чтоб были коллизии после пятого роунда...
Или может так, как есть в исходном виде положить?
Это дело хозяйское... как считаешь нужным так и делай...
Да, после 5R-коллизию не проверишь. Так что здесь только считать до конца и проверять, что получилось.
А по поводу исходников - я тоже не выкладываю, пока полный поиск не доделаю и не отлажу. Как только без глюков заработает - так сразу выложу.
Woron_scan 1.05. Что бы это значило:
18:16:30
Starting 2R attack on 0 pair....
Found 2R attack collisions:used 29595 steps
18:50:41
Found by 2R attack the 0 pair=596A
18:50:43
Calculating data for 3R attack....
18:50:46
Found data: common=64 first=0BC1 second=55A2
Finding 3R attack collision...
18:50:55
3R attack collisions found...used 122 steps
3R attack 0 possible pairs found
18:50:55
3R attack failed...
И еще подобное в инете видел...И правда очень часто при 3R атаке возникают коллизи на последующих раундах...
Спасибо Ворон,что предупредил...
У меня еще вопрос к Ворону...
Как у тебя работает 2R проверка? В том смысле, что без разницы, какой КИ она работает всегда с одинаковой скоростью,т.е моментально:)...Или у тебя сразу таблица, типа KI(0,8 ) - RAND1(0,8 ),RAND2(0,8 )?
Да нет...нафиг еще таблицу держать... это же еще лишние 250 кбайт
Просто вычисляю ...
То Unixoid> тебе и прямь 17 ? вундеркинд..
Да нет...нафиг еще таблицу держать... это же еще лишние 250 кбайт
Просто вычисляю ...
Понятно..Сейчас подумаю, как можно моментально вычислить 2 коллизионных ранда:)
Меня в принципе устраивает моя скорость 2R проверки - максимум 15 сек..
но если я научусь проводить ее за 1-2 сек, то может появятся идеи на счет ускорения подсчета 5R...он у меня и на пол часика может затянутся...
4R максимум 2 минуты - устраивает, в принципе...
тебе и прямь 17 ?
Да...
вундеркинд..
Да нет, просто увлекаюсь подобными задачами..
Да нет, просто увлекаюсь подобными задачами..
В 17 я даже не знал слов програмирование и компьютер :mrgreen:
Меня в принципе устраивает моя скорость 2R проверки - максимум 15 сек..
Дык ты небось весь алгоритм гоняешь ...а надо лишь до 2R..
Дык ты небось весь алгоритм гоняешь ...а надо лишь до 2R..
Да нет. :) я же сам писал об этом...
для имеющейся (0, 8)КИ по таблице для 2R-atakи вычисляю 2 значения(после 2го раунда), сравниваю их, генерю следующее, сравниваю с 2мя предыдущими..и т д...
Получается максимум 31044(с твоей таблицей, своей покачто еще нету..:))*31044 шагов...
По поводу проваленной 3R - у меня другой вопрос. Вот смотрите. Идет 3R-атака. Нашли 2 rand (0,8), которые отличаются 1-м байтом результата после 2R. Проверили могут ли они дать коллизию на 3-м раунде (вычислили байт 4 результата после 2R). Начинаем подбирать коллизию - фиксируем rand4 в 0, а rand12 перебираем от 0 до 255. Частельно мы коллизию не находим!!! Приходится продолжать 3R атаку с другими парами rand(0,8), а это лишние попытки. Что я не так делаю???
И еще - 3R атака на 0 пару (F4CC) при 4-й паре AE7A - нету двух rand(0,8) отличающихся 1-м байтом после 2R. Что делать?
PIC-ador
05.12.2004, 12:17
И еще - 3R атака на 0 пару (F4CC) при 4-й паре AE7A - нету двух rand(0, отличающихся 1-м байтом после 2R. Что делать?
А это что:
Starting 3R attack at 12:11:25
Collisions pair: 3E,14 FE,92
Possible Pair: B7,1E
Possible Pair: AE,7A
Possible Pair: 87,97
Possible Pair: 87,9D
Possible Pair: B7,C8
Possible Pair: AE,DF
Found by 3R Attack: AE,7A
Used steps: 410
Ended at 12:11:31
Хотя искать лучше любое отличие (быстрей)
А это отличие во-втором байте. Хотя я уже переписал код - чтобы искать любое отличие ;-) Заработало ;-)
To Unixoid, зачем делать 31044*31044 попыток? У меня всего 31044 попыток (при проверке 2R). Укладывается в 1-2 секунды. Я просто запоминаю в хэше результаты вычислений после 2 раунда. Хэш следующий - пара KI от результата. ;-)
PIC-ador
05.12.2004, 15:51
А это отличие во-втором байте.
Это как? Вот два выхода после 2-го ранда:
5E1C1C1C501C1C1C141C1C1C5C1C1C1C5F1C1C1C291C1C1C51 1C1C1C7C1C1C1C
671C1C1C501C1C1C141C1C1C5C1C1C1C5F1C1C1C291C1C1C51 1C1C1C7C1C1C1C
5E1C1C1C501C1C1C141C1C1C5C1C1C1C5F1C1C1C291C1C1C51 1C1C1C7C1C1C1C
671C1C1C501C1C1C141C1C1C5C1C1C1C5F1C1C1C291C1C1C51 1C1C1C7C1C1C1C
Дохрена лишних операций делаешь...Достаточно просчитывать (0,8,16,24)....
Хотя я уже переписал код - чтобы искать любое отличие Заработало
Я тоже в первый раз на это наткнулся...Потом сделал, чтобы искало любое отличие..стало в роде нормально..в роде..потом погонял этот : 24301A8769A7C7A5D65A02D7C15FBBFD КИ и увидел, что коллизии опять не ищутся...думал,думал и решил проверять, могут ли они дать коллизию на 3-м раунде в обеих вариантах, тоесть, сначала меняю байт 4 от 0 до 256, нахожу как минимум 2 коллизии, потом 4 обнуляю и начинаю менять байт 12 и опять ищу 2 коллизии...вот только тогда подаю 0,8 в ридер и меняя 12 от 0 до 256..и то, в случаи провала 3R атаки вычисляю новые ранды и опють повторяю атаку..и так три раза...и проверка 3р это коллизия или нет тоже обязательно должна быть...
Я просто запоминаю в хэше результаты вычислений после 2 раунда. Хэш следующий - пара KI от результата. вобще не понял теории...
Ну вычисляешь ты 31044 ответа, суешь их в хеш..а найти 2 одинаковых ответа, это же все равно максимум 31044*31044 шага..или как?
вот код, как я делаю..ничего умнее придумать не смог..
for(j=0x0000;j<=0xFFFF;j++){
if(read(td,&r,2)!=2)break;
tmp[j][0]=r>>8;
tmp[j][1]=htons(r)>>8;
ctrand[pn]=r>>8;
ctrand[pn+8]=htons(r)>>8;
r2(ctrand,ctki,&tmp[j][2],pn);
if(j==0xFFFF)break;
for(i=0;i<l;i++){
for(t=0;t<4;t++)if(tmp[2+i]!=tmp[2+j])break;
if(t==4){
Ну тут мы формируем полные ранды и посылаем их карте. Результаты совпали - возвращаем 1, не совпали - 0..
}
}
}
tmp[65536][6] - где первые 2 байта - это РАНД(0.8 ), следующие 4 байта - результат(0,8,16,24) после 2го раунда.
r2 - функия, которая вычисляет выход после 2го раунда для байтов 0+pn,8+pn,16+pn,24+pn...
PIC-ador
05.12.2004, 23:57
Дохрена лишних операций делаешь...
:D Да, ну? Полный x[32] я привел для наглядности.
void TA3A8_Scaner::Round2 ( BYTE k1, BYTE k2, BYTE r1, BYTE r2, BYTE *sres )
{
sres[0] = table[1][table[0][k1+r1+r1]+2*table[0][k2+r2+r2]];
sres[1] = table[1][table[0][k1+r1+r1]*2+table[0][k2+r2+r2]];
sres[2] = table[1][table[0][k1+k1+r1]+2*table[0][k2+k2+r2]];
sres[3] = table[1][table[0][k1+k1+r1]*2+table[0][k2+k2+r2]];
}
Если спросишь где %512, или %256. Отвечу- похерил. Просто расширил таблицу на недостающие %.
тоесть, сначала меняю байт 4 от 0 до 256, нахожу как минимум 2 коллизии, потом 4 обнуляю и начинаю менять байт 12 и опять ищу 2 коллизии...вот только тогда
:?: Совершенно бесмысленно.
PIC-ador, по поводу пар - может я ошибся чуть-чуть (по памяти писал), но то, что такие пары есть (не дающие отличия в 1-м байте после 2R - это точно). По поводу - "совершенно бессмысленно" - а как же тогда делать?
Unixoid, хэш работает по принципу индекса. То есть - берем первую пару rand - считаем 4 байта ответа и пишем в хэш $H{'ANSWER'}='RAND'. Далее - берем вторую пару - считаем 4 байта ответа и пишем:
if $H{'ANSWER'} then Нашли коллизию else $H{'ANSWER'}='RAND'.
При этом поиск, указанный в if-е идет почти мгновенно, так как хэш проверяет не подряд, а по бинарному дереву. В итоге в среднем (при равномерном распределении ответов) и переборе всех 31044 вариантов нам надо 31044*log[2](31044). Что есть около 450 тыс вариантов, а не 960 млн (в твоем случае). Ку?
PIC-ador
06.12.2004, 11:16
По поводу - "совершенно бессмысленно" - а как же тогда делать?
1. Почему крутя R4 ищем 2 коллизии, а затем еще две для R12. Почему скажем не 22? Метод "научного" тыка?
2. Зачем бесполезный 65535 раз оператор:
if ( j== 0xFFFF )
break;
3. А постоянные (в цикле) сдвиги вправо. Это зачем? Не проще ли разобраться со своими структурами данных, чтобы такого не было.
P.s. только не подумайте, что хочу кого-то обидеть.
Учиться писать надо сразу правильно, потом переучиваться сложнее.