Я не буду защищать автора книги, поскольку не читал, а некоторые перечисленные фрагменты действительно вызывают удивление. Но хочется отметить несколько моментов, которые могут оправдать некоторые из пассажей, просто, скажем так, они вызвали немного вьетнамских флешбеков.
С переводом терминов по криптографии очень часто возникает путаница. Дело в том, что уж очень не любят в английском языке слово crypt из-за связи с кладбищами. Вот и получается, что вместо понятной пары encrypt-decrypt используется encode-decode. Скорее всего переводчики поленились и перевели все с использованием слова "код".
Я встречал два определения симметричной криптографии: в одном один ключ и два тривиально выводимых алгоритма на шифрование и расшифровывание, в другом один алгоритм и два тривиально выводимых ключа. Для наглядности шифр Цезаря по первому будет иметь ключ 3 и алгоритмы в виде сдвига по алфавиту влево и сдвига по алфавиту вправо, а по второму: ключ 3 и ключ -3, а алгоритм просто сдвиг по алфавиту на число. Да, в любом случае, это все равно не похоже на асимметричную крипту, но я вполне допускаю, что это просто косноязычность + попытка смешать разные аксиоматики.
Блочный-блоковый, поточный-потоковый. Хоть и не аргумент, но все же, если обратимся к вики, то основные статьи Блочный шифр и Потоковый шифр, а уже "поточный шифр" перенаправляет на вторую. Так что, я бы тут не стал придираться.
Мне очень импонирует идея внедрения метки с базовой информацией о здоровье - группа крови, аллергии, непереносимость тех или иных лекарств. Чтобы в условной ситуации необходимости экстренной помощи можно было всю эту информацию получить, даже если я буду без сознания.
Но это будет работать, только если такая штука будет массовой.
Ну есть нюанс, в том, что хоть и заявляется, что UAC не является security boundary, но периодически Microsoft что-то все-таки латает, причем в security патчах. Хотя иногда это просто видимость. Например в упомянутом IFileOperation поменяли набор флагов, что сломало готовые эксплоиты, но почти сразу было замечено и исправлено.
"C:\Documents and Settings\Jonathan Ezekiel Cornflour\My Documents\My Music\My Personal Rips\2007\Technological\Operating System Symphony Orchestra\The GNOME Musical Men\I Married Her For Her File System\You Don't Appreciate Marriage Until You've Noticed Tax Pro's Wizard For Married Couples.Track 01.MP5"
Я сначала не понял, а потом как понял. Статья-то 2007 года. Вроде уже в Windows 8 в дефолтной поставке были пути больше 260 символов, из-за чего она не хотела вставать на FAT32.
Давайте посмотрим на исходную задачу "в лоб". Переформулируем ее в необходимость найти f(n, k) - функцию, которая вычисляет количество вариантов получить число n при броске k кубиков.
Пограничные случаи: если n < k или n > 6k, то значение 0.
Если k = 1, то результат 1 (все, кроме чисел от 1 до 6 отсечено выше, а эти числа можно получить только одним образом каждое).
И общий случай: пусть на первом кубике выпало 1, тогда нужно посмотреть сколькими способами можно получить n-1 броском k-1 кубика, если выпало 2, то сколько способов для n-2 те ми же k-1 кубиками. В общем f(n-1, k-1)+f(n-2, k-1)+f(n-3, k-1)+f(n-4, k-1)+f(n-5, k-1)+f(n-6, k-1).
Итого:
int f(int n, int k)
{
if (n < k)
return 0;
if (n > 6*k)
return 0;
if (k == 1)
return 1;
return f(n-1, k-1)+f(n-2, k-1)+f(n-3, k-1)+f(n-4, k-1)+f(n-5, k-1)+f(n-6, k-1);
}
Добавляем сверху кэширование результатов, чтобы не вычислять уже вычисленное и готово.
Смотрим на ваш способ и видим, что он по сути такой же:
Вот как раз визуальная иллюстрация: для трех кубиков считаем количества сумм брошенных двумя кубиками со сдвигом.
То есть ваш способ очевидно корректен, он будет оперировать ровно теми же числами, что попадут в кэш в простом способе. Но вот что ваш код и объяснения легче, я бы не сказал.
Я понимаю, что мой опыт вряд ли обобщаем до автоматизации, но все же поделюсь своим подходом.
Если мне нужно проанализировать большой проект под линукс, то я начинал с создания автономного стенда для проекта, который бы позволял собирать исходники (благо, чаще всего такой стенд могли предоставить разработчики продукта). Дальше просто по стандартным этапам:
1) Разведка. Ищем все возможные компиляторы в системе. Нередко разработчики пользуются chroot'ом, так что слоям данных внутри chroot'а отдельные поиски.
2) Сбор первоначальной информации. Пишется простейший прокси-компилятор, которые собирает информацию о том как его вызвали (грубо говоря, argc, argv, envp) в файл и вызывает бинарник с приписанным к имени -orig. Дальше все настоящие компиляторы перемещались с этим самым дописанным -orig, а на их место помещался свеженаписанный прокси. Убеждаемся, что сборка проходит, получаем первую статистику о том, какие файлы и с какими параметрами компилируются.
3) Внедрение анализаторов. Дальше функциональность прокси-компилятора увеличивается - кроме вызова оригинального компилятора ему навешиваются задачи по вызову анализаторов. Решаются мелки типовые задачи: вызываем оригинальный gcc с расширенным набором проверок, но нужно убрать Werror, если есть, поменять имя выходного файла, чтобы он не мешал. Для вызова cppcheck нужно некоторые параметры переделать или убрать. Для scan-build'а тоже нужно правильно параметры передать. Для других анализаторов тоже свои мелкие доработки приходится делать.
4) Собираем результаты и уже вручную их разбираем.
Для Windows тоже делал подобное - подменял cl.exe на свой прокси, но там что-то не срасталось. В итоге пошел по пути dll hijack - подсовываю свою version.dll к cl.exe и в нем фильтрую чтобы убедится, что вызывают компилятор. Уже из библиотеки вызываются анализаторы.
Ну что-ж, докладываю. Посмотрел пока поверхностно бету 22.3.0.2185, но результаты такие:
1) 2750 - без изменений. Просто повторил действия из своего последнего письма и все отработало.
2) 2798 - вижу исправление. Вот тут готов сказать, что вижу реальную попытку исправления. Nice try, так сказать. Обошел полутора способами. Так что пока не исправили.
3) Нашел третью уязвимость.
А теперь еще все это перепроверять, добивать второй обход 2798, вам в тикеты описывать, видео клепать, PoC'и рисовать...
Я не буду защищать автора книги, поскольку не читал, а некоторые перечисленные фрагменты действительно вызывают удивление. Но хочется отметить несколько моментов, которые могут оправдать некоторые из пассажей, просто, скажем так, они вызвали немного вьетнамских флешбеков.
С переводом терминов по криптографии очень часто возникает путаница. Дело в том, что уж очень не любят в английском языке слово crypt из-за связи с кладбищами. Вот и получается, что вместо понятной пары encrypt-decrypt используется encode-decode. Скорее всего переводчики поленились и перевели все с использованием слова "код".
Я встречал два определения симметричной криптографии: в одном один ключ и два тривиально выводимых алгоритма на шифрование и расшифровывание, в другом один алгоритм и два тривиально выводимых ключа. Для наглядности шифр Цезаря по первому будет иметь ключ 3 и алгоритмы в виде сдвига по алфавиту влево и сдвига по алфавиту вправо, а по второму: ключ 3 и ключ -3, а алгоритм просто сдвиг по алфавиту на число. Да, в любом случае, это все равно не похоже на асимметричную крипту, но я вполне допускаю, что это просто косноязычность + попытка смешать разные аксиоматики.
Блочный-блоковый, поточный-потоковый. Хоть и не аргумент, но все же, если обратимся к вики, то основные статьи Блочный шифр и Потоковый шифр, а уже "поточный шифр" перенаправляет на вторую. Так что, я бы тут не стал придираться.
Статью, где человек думал, что обманул систему, а на самом деле обманул себя.
Эх. Ожидал статью уровня Почти во всех реализациях двоичного поиска и сортировки слиянием есть ошибка, а оказалось, что автор просто не понимает О-нотацию.
На последней картинке в статье, там где карточки с баг репортами, это какой-то сервис?
homm3 battlefield explorer + battlefield searcher
Мне очень импонирует идея внедрения метки с базовой информацией о здоровье - группа крови, аллергии, непереносимость тех или иных лекарств. Чтобы в условной ситуации необходимости экстренной помощи можно было всю эту информацию получить, даже если я буду без сознания.
Но это будет работать, только если такая штука будет массовой.
Нет. UAC bypass это только о пользователях-администраторах.
А вы можете уточнить что вы хотите узнать задавая этот вопрос?
Ну есть нюанс, в том, что хоть и заявляется, что UAC не является security boundary, но периодически Microsoft что-то все-таки латает, причем в security патчах. Хотя иногда это просто видимость. Например в упомянутом IFileOperation поменяли набор флагов, что сломало готовые эксплоиты, но почти сразу было замечено и исправлено.
Спасибо автору. Очень удивило отсутствие нормальных инструкций от разрабов. Теперь может тоже попробую что-то написать.
Наверное, это и хорошо. Недавно Andorid-приложение "Билайн" удивило:
Коллектив авторов задачи передает привет, и благодарит за райтап.
Спойлер из теста по шарпам
pageNumber > 0 всегда истинно, соответственно, я хотел указать на dead code.
Я сначала не понял, а потом как понял. Статья-то 2007 года. Вроде уже в Windows 8 в дефолтной поставке были пути больше 260 символов, из-за чего она не хотела вставать на FAT32.
Задача 12 просто описывает что надо нажимать на клавиатуре вместе с стрелочками.
Ух. Писали интерпретатор bf, а написали учебную программу на переполнение стэка.
Давайте посмотрим на исходную задачу "в лоб". Переформулируем ее в необходимость найти f(n, k) - функцию, которая вычисляет количество вариантов получить число n при броске k кубиков.
Пограничные случаи: если n < k или n > 6k, то значение 0.
Если k = 1, то результат 1 (все, кроме чисел от 1 до 6 отсечено выше, а эти числа можно получить только одним образом каждое).
И общий случай: пусть на первом кубике выпало 1, тогда нужно посмотреть сколькими способами можно получить n-1 броском k-1 кубика, если выпало 2, то сколько способов для n-2 те ми же k-1 кубиками. В общем f(n-1, k-1)+f(n-2, k-1)+f(n-3, k-1)+f(n-4, k-1)+f(n-5, k-1)+f(n-6, k-1).
Итого:
Добавляем сверху кэширование результатов, чтобы не вычислять уже вычисленное и готово.
Смотрим на ваш способ и видим, что он по сути такой же:
Вот как раз визуальная иллюстрация: для трех кубиков считаем количества сумм брошенных двумя кубиками со сдвигом.
То есть ваш способ очевидно корректен, он будет оперировать ровно теми же числами, что попадут в кэш в простом способе. Но вот что ваш код и объяснения легче, я бы не сказал.
Я понимаю, что мой опыт вряд ли обобщаем до автоматизации, но все же поделюсь своим подходом.
Если мне нужно проанализировать большой проект под линукс, то я начинал с создания автономного стенда для проекта, который бы позволял собирать исходники (благо, чаще всего такой стенд могли предоставить разработчики продукта). Дальше просто по стандартным этапам:
1) Разведка. Ищем все возможные компиляторы в системе. Нередко разработчики пользуются chroot'ом, так что слоям данных внутри chroot'а отдельные поиски.
2) Сбор первоначальной информации. Пишется простейший прокси-компилятор, которые собирает информацию о том как его вызвали (грубо говоря, argc, argv, envp) в файл и вызывает бинарник с приписанным к имени -orig. Дальше все настоящие компиляторы перемещались с этим самым дописанным -orig, а на их место помещался свеженаписанный прокси. Убеждаемся, что сборка проходит, получаем первую статистику о том, какие файлы и с какими параметрами компилируются.
3) Внедрение анализаторов. Дальше функциональность прокси-компилятора увеличивается - кроме вызова оригинального компилятора ему навешиваются задачи по вызову анализаторов. Решаются мелки типовые задачи: вызываем оригинальный gcc с расширенным набором проверок, но нужно убрать Werror, если есть, поменять имя выходного файла, чтобы он не мешал. Для вызова cppcheck нужно некоторые параметры переделать или убрать. Для scan-build'а тоже нужно правильно параметры передать. Для других анализаторов тоже свои мелкие доработки приходится делать.
4) Собираем результаты и уже вручную их разбираем.
Для Windows тоже делал подобное - подменял cl.exe на свой прокси, но там что-то не срасталось. В итоге пошел по пути dll hijack - подсовываю свою version.dll к cl.exe и в нем фильтрую чтобы убедится, что вызывают компилятор. Уже из библиотеки вызываются анализаторы.
GPD Pocket
Ну что-ж, докладываю. Посмотрел пока поверхностно бету 22.3.0.2185, но результаты такие:
1) 2750 - без изменений. Просто повторил действия из своего последнего письма и все отработало.
2) 2798 - вижу исправление. Вот тут готов сказать, что вижу реальную попытку исправления. Nice try, так сказать. Обошел полутора способами. Так что пока не исправили.
3) Нашел третью уязвимость.
А теперь еще все это перепроверять, добивать второй обход 2798, вам в тикеты описывать, видео клепать, PoC'и рисовать...