По идее симметричный ключ, используемый на лету для фактической шифровки-дешифровки, должен существовать в памяти вне зависимости от того, кто его порождал или что использовалось для дешифровки его с диска.
Если само шифрование каждого сектора не происходит где-то в отдельном чипе.
Дайте угадаю, в пачке мест в битлокере есть что-то типа useKey() { memcpy(); decrypt(); memset(); }, благодаря чему ключ остаётся в памяти... Как сказал бы @Andrey2008, "надо было пользоваться PVS-Studio" :D
Я так понимаю, всё же профиль "запуск локальный и для кода, который и так разработчик обрабатывает" предполагает, что если только что-то внезапно совсем плохо не окажется, то обработка должна быть на уровне времени работы компилятора, то есть "медленно, но терпимо".
Я помню игрался с триальной версией PVS на большом проекте -- время проверки было где-то 60% от времени полной компиляции. То есть можно было сходить за кофе -- но не на обед :)
Просто краевые случаи на которых распухают ASTы это самые тривиальные вещи -- (((((((((((((((((((((((((((((((((((((((((((2+2)))))))))))))))))))))))))))))))))))))), if() else if() else и так далее -- когда бинарность дерева начинает кусаться. И сколько бы не пытался их обойти {я собственноручно грамматики многократно перепиливал чтоб 2+2+2+2+2 сворачивалось в ('+', [2, 2, 2, 2, ...]) вместо ('+', 2, ('+', 2, ('+', 2, ('+', ...))))} -- а всё равно где-нибудь встретишь ужасы типа цепочки в 100500 ифов, и по очереди то out-of-mem, то out-of-stack, то просто на бэктрекинге на минуты зависает из-за квадратичного нежданчика.
И да, встречается в живом коде, не только синтетика.
А если интересно синтетику на которой можно пошатать деревья разбора и обхода их -- советую подглядеть в глубинные тесты у ZetaSQL: этим подходом я очень много яблок с деревьев стряс, заодно убедил избавиться от javacc :))
"Не в даваясь в подробности" и вводим тета-большое и о-большое, обозвав о-большое "пойдёт для печати".
А ничего, что тета-большое это средняя сложность алгоритма, а о-большое это худший случай, это РАЗНЫЕ термины? Лучше бы не вдаваясь в подробности не упоминали тета-большое, чем наврать.
Практическое применение -- обход проверки на длину строки, чтобы вызвать buffer overflow или просто стриггерить DoS вызванный медленной обработкой данных
По идее симметричный ключ, используемый на лету для фактической шифровки-дешифровки, должен существовать в памяти вне зависимости от того, кто его порождал или что использовалось для дешифровки его с диска.
Если само шифрование каждого сектора не происходит где-то в отдельном чипе.
То есть 9070 хуже чем 4090?
Дайте угадаю, в пачке мест в битлокере есть что-то типа
useKey() { memcpy(); decrypt(); memset(); }, благодаря чему ключ остаётся в памяти... Как сказал бы @Andrey2008, "надо было пользоваться PVS-Studio" :DЯ так понимаю, всё же профиль "запуск локальный и для кода, который и так разработчик обрабатывает" предполагает, что если только что-то внезапно совсем плохо не окажется, то обработка должна быть на уровне времени работы компилятора, то есть "медленно, но терпимо".
Я помню игрался с триальной версией PVS на большом проекте -- время проверки было где-то 60% от времени полной компиляции. То есть можно было сходить за кофе -- но не на обед :)
Просто краевые случаи на которых распухают ASTы это самые тривиальные вещи --
(((((((((((((((((((((((((((((((((((((((((((2+2)))))))))))))))))))))))))))))))))))))),if() else if() elseи так далее -- когда бинарность дерева начинает кусаться. И сколько бы не пытался их обойти {я собственноручно грамматики многократно перепиливал чтоб2+2+2+2+2сворачивалось в('+', [2, 2, 2, 2, ...])вместо('+', 2, ('+', 2, ('+', 2, ('+', ...))))} -- а всё равно где-нибудь встретишь ужасы типа цепочки в 100500 ифов, и по очереди то out-of-mem, то out-of-stack, то просто на бэктрекинге на минуты зависает из-за квадратичного нежданчика.И да, встречается в живом коде, не только синтетика.
А если интересно синтетику на которой можно пошатать деревья разбора и обхода их -- советую подглядеть в глубинные тесты у ZetaSQL: этим подходом я очень много яблок с деревьев стряс, заодно убедил избавиться от javacc :))
В очередной раз стало интересно: а как у вас с разбором вещей типа цепочки ифов, после автогенераторов?
Графы в памяти не разбухают? Анализатор не начинает тормозить как Гомер после пива? :D
"Не в даваясь в подробности" и вводим тета-большое и о-большое, обозвав о-большое "пойдёт для печати".
А ничего, что тета-большое это средняя сложность алгоритма, а о-большое это худший случай, это РАЗНЫЕ термины? Лучше бы не вдаваясь в подробности не упоминали тета-большое, чем наврать.
цЫган на цЫпочках подошел к цЫпленку и сказал: ЦЫЦ
Поиск работает то есть термин существует. Может и не словарный -- но распространённый.
Другие это как минимум openai, gemini
Вопрос как он понимает пользователя.
Другие -- понимают
Именно поэтому ни одна сетка не может нарисовать часы показывающие что-то другое.
Но более-менее справляются, если просить сетку сгенерировать аналоговые часы в SVG
Песочные часы он рисует просто чудесные:
Hidden text
И отлично понимает физику процесса и что от него хотят:
Hidden text
В целом, он провалил все классические тесты на понимание при рисовании.
Кто на ком стоял?
Можно еще попросить пиццу вверх тормашками, 24-часовые часы со стрелками, либо стандартные аналоговые часы показывающие 14:27...
Ух какой запас вкуснотищи! На чай! С козинаками!
UPX есть под все платформы
Это объясняет обилие DVI торчалок и HDD в корзине :)
Собственно, см. ниже :))
Использовать длину в символах вместо длины в байтах... :)
Там, чтобы при обрезании не получать поломанных символов...
Практическое применение -- обход проверки на длину строки, чтобы вызвать buffer overflow или просто стриггерить DoS вызванный медленной обработкой данных
Книга - лучший подарок! 🤣
А уно вообще интересный зверь, напоминает что-то из детства, что игралось обычной колодой... 👍
https://raelize.com/blog/espressif-systems-esp32-glitching-otp-transfer/ ?
или https://courk.cc/esp32-c3-c6-fault-injection