Проблемы с циклом FOR
- Войдите на сайт для отправки комментариев
Сб, 07/03/2020 - 09:15
for(key.keyByte[0]=0x00; key.keyByte[0]<0xFF; key.keyByte[0]+=0x01) { for(key.keyByte[1]=0x00; key.keyByte[1]<0xFF; key.keyByte[1]+=0x01) { for(key.keyByte[2]=0x00; key.keyByte[2]<0xFF; key.keyByte[2]+=0x01) { for(key.keyByte[3]=0x00; key.keyByte[3]<0xFF; key.keyByte[3]+=0x01) { for(key.keyByte[4]=0x00; key.keyByte[4]<0xFF; key.keyByte[4]+=0x01) { for(key.keyByte[5]=0x00; key.keyByte[5]<0xFF; key.keyByte[5]+=0x01)// FE not FF //for(key.keyByte[5]=0x00; key.keyByte[5]<=0xFF; key.keyByte[5]+=0x01)//ok FF not FE //not ring {
Если установить key.keyByte[5]<0xFF то заканчиватся на 0xFE и переходит на следущий цикл
А если key.keyByte[5]<=0xFF то не переходит на следущий цикл
А нужно чтоб переходило на следующий цикл после 0xFF
То есть конечный результат должен получится после перебора FF FF FF FF FF FF
Байт не может быть больше 0xFF.
Код надо публиковать полностью.
Вы опустили описание переменных, а это в данном случае важно.
Измените тип счетчиков цикла на int. Переменная типа byte не может принимать 257 различных значений.
Само сабой!!! Но при key.keyByte[5]<0xFF конечный результат 0xFE и переход!!! а нужно чтоб переход был после 0XFF
или заменить на цикл c do {}while )))
Байт не может быть больше 0xFF.
Это в основном зависит от уровня площадки(форума). Помнишь анекдот про танки и температуру + -300 градусов?
Само сабой!!! Но при key.keyByte[5]<0xFF конечный результат 0xFE и переход!!! а нужно чтоб переход был после 0XFF
А зачем вот так вот непонятно как из-за угла лопатить вложенные пустые циклы? Это новый delay() ???
+++
А, фсё, код добавил, я все понял. Брутфорс.
Мда. Жулики уже ничего не стесняюца. Хорошо, что тупые.
Мда. Жулики уже ничего не стесняюца. Хорошо, что тупые.
Дет, ну такое "фуфло" предусмотрено на этапе разработки. Там 130 лет помому перебор вот таким способом в датащях детерминирован. Так-шо пущщай развлекаюцца поколениями.
или заменить на цикл c do {}while )))
При таком подходе в байт уже больше 255 влезет???
Ну насчет тупых...
Эт пишится для спортивного интересса...
Так как все сделано на много проще при linux и ARC122U... Если тупые слишали про Crypto1 ))
и про уязвимости MIFARE Clossic
или заменить на цикл c do {}while )))
При таком подходе в байт уже больше 255 влезет???
А именно 256!)
или заменить на цикл c do {}while )))
При таком подходе в байт уже больше 255 влезет???
ДА! ДА!! и ещЁ раз ДА!!!
Ну насчет тупых...
Эт пишится для спортивного интересса...
Так как все сделано на много проще при linux и ARC122U... Если тупые слишали про Crypto1 ))
и про уязвимости MIFARE Clossic
Если б это про тебя было написано, ты б таких вопросов не задавал.
А именно 256!)
Т.о. при while (until, repeat, do) буит 256 итераций а при for 0 255 ++ будет 255 итераций??? Дануна...
Потому что for проверку делает в начале цикла, в отличие от do while.
А именно 256!)
Т.о. при while (until, repeat, do) буит 256 итераций а при for 0 255 ++ будет 255 итераций??? Дануна...
ну так он же проверяет на выходе, цикл то прошёл жеж
Кому то уже приходила идея))
Потому что for проверку делает в начале цикла, в отличие от do while.
Твое утверждение прям как в квн: -патамуШО хладиолус и ниип@т!!!
А теперь произведём подход к снаряду: т.о. цикл вида
сработает РОВНО от а==0 до а== 255 и никак по другому!!!
ну так он же проверяет на выходе, цикл то прошёл жеж
ну давай вообще вот так сделаем, без циклоФ:
int a=0
L_001:
чотоделаем
a++
if (a != 255)
goto L_001
В этом случае оператор сравнения можно ставить хоть сверху, хоть снизу, всёравно "прокрутит" с 0 до 255.
Само сабой!!! Но при key.keyByte[5]<0xFF конечный результат 0xFE и переход!!! а нужно чтоб переход был после 0XFF
256 это число итераций, на 0 жеж тоже проход цикла был и при 0хFF тоже
Зачем ты пытаешься лукавить? Счёт по while у тебя по i=0 а сцукоблее вывод по s=1. Ичо? Вот тебе и расхождение, ибо в математике усёбуит "чики-чики", просто здеся имеет место быть концепция ZERO, уотт и весь фокус-покус)))