Это закрытый китайский блоб. Кто знает, что он делает? Я его пробовал перед тем, как самому заняться исследованием, предварительно сделав factory reset. Он не работает на устройствах Kyocera.
Если такая серьезная уязвимость имеется, то нашел один найдут и другие. А может уже нашли и эксплуатируют.
У меня не достаточно опыта, а особенно времени для reverse engineering. Можно заметить, что в статье нет ни строчки assembler кода. Возможно читатели хабра помогут, для того я и выложил загрузчики.
Возможно, Вы один из тех преподавателей, которые следует этому правилу. Но основному большинству, к сожалению, наплевать. Они прочитали курс и на этом их задача окончена.
Конструкторы "домики" великолепны. В детстве был конструктор из балок, крестовин, уголков и клипс с клеенкой. Пытался найти похожие в продаже сейчас — не нашел. Даже не помню откуда он у меня появился, потом при очередном переезде куда-то пропал. Может подарил кто, а при переезде отдали кому-то. Но самый близкий аналог этого конструктора — ПВХ трубы с клипсами и т.п. Но то, что у меня было в детстве, было одним комплектом.
К сожалению, с разработкой под Linux я знаком на уровне «make && make install».
Не бойтесь экспериментировать. Разработка не сильно уж и отличается от таковой под Win. Я со своими начальными знаниями программирования и то иногда умудряюсь написать правильный патч, который принимают в upstream. Так что, дерзайте.
Низкоуровневые тесты необходимо проводить в полной изоляции.
1) LXC у меня вешал ядро и засорял файловую систему. Виртуальная машина если и зависнет, то с малой долей вероятности повесит хост, а значи рабочему процессу не помешает.
2) Первоначально разрабатывалось только для CoreOS, а CoreOS просто так в Docker не запустишь. Там система обновления, базирующася на GPT, readonly /usr раздел и прочие тонкости.
Все эти пункты меню, стрелочки, далее. А есть уже готовые образы для QEMU/VB? Как, скажем, Ubuntu (https://cloud-images.ubuntu.com/xenial/current/). У них и qcow2 и vmdk, и ova. Бери что хочешь.
UEFI secure boot кстати вполне спокойно работает на MBR (не могу точно сказать насколько это соответствует стандарту, давно проблему решал). Только необходимо osprober пофиксить https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817023
В сноске 2 как раз правильное решение используется.
Теоретически можно исправить, установив пароль, встроив grub.cfg в образ GRUB с помощью grub-mkstandalone и установив в grub.cfg prefix на невалидный путь, чтобы GRUB не мог найти второй grub.cfg на диске. Но опять же требуется подписывать образ самостоятельно.
Статья почти слово в слово повторяет мою запись в личной wiki. Мне порой кажется, что если я что-то подобное опубликую, то в меня полетит критика в роде "капитан очевидность" или "задрот".
У меня вопрос к следующей фразе:
Однако отсутствие верификации initramfs позволяет встроить в него вредоносный код, имея доступ на запись в ESP. Teddy Reed предлагает компилировать ядро, встраивая в него initramfs.
Как это может быть, если initramfs находится на зашифрованном разделе (а не на ESP), а grub при загрузке сначала запросит пароль перед тем как считать initramfs и ядро с зашифрованного диска. Зачем нужна морока со сборкой и подписью своего ядра?
На ESP в моём случае находится лишь только grubx64.efi
Это закрытый китайский блоб. Кто знает, что он делает? Я его пробовал перед тем, как самому заняться исследованием, предварительно сделав factory reset. Он не работает на устройствах Kyocera.
У меня не достаточно опыта, а особенно времени для reverse engineering. Можно заметить, что в статье нет ни строчки assembler кода. Возможно читатели хабра помогут, для того я и выложил загрузчики.
А с помощью каких алгоритмов h.265 (HEVC) добивается лучших результатов сжатия?
Проще с dirtycow root получить.
Бинарник уже скомпилировал. Осталось понять как shadow редактировать
всего два с половиной года. отлично, ребят! не сарказм.
Возможно, Вы один из тех преподавателей, которые следует этому правилу. Но основному большинству, к сожалению, наплевать. Они прочитали курс и на этом их задача окончена.
ой, не смешите.
Нашел таки нечто подобное в штатовском амазоне https://www.amazon.com/Fort-Magic-Building-Construction-Toy/dp/B006WAL3YO
Жаль, что доставка только по США
Изначально была версия 4.4
Такая же проблема. root не получить (слишком редкий девайс), прошивку не обновить, застрял на 4.4
И к сожалению Intel Quick Sync плохо поддерживается в Linux.
Конструкторы "домики" великолепны. В детстве был конструктор из балок, крестовин, уголков и клипс с клеенкой. Пытался найти похожие в продаже сейчас — не нашел. Даже не помню откуда он у меня появился, потом при очередном переезде куда-то пропал. Может подарил кто, а при переезде отдали кому-то. Но самый близкий аналог этого конструктора — ПВХ трубы с клипсами и т.п. Но то, что у меня было в детстве, было одним комплектом.
Не бойтесь экспериментировать. Разработка не сильно уж и отличается от таковой под Win. Я со своими начальными знаниями программирования и то иногда умудряюсь написать правильный патч, который принимают в upstream. Так что, дерзайте.
Полет. До сих пор помню как болели пальцы из-за тугости деталек. Но, несмотря на трудности, играл ведь.
Низкоуровневые тесты необходимо проводить в полной изоляции.
1) LXC у меня вешал ядро и засорял файловую систему. Виртуальная машина если и зависнет, то с малой долей вероятности повесит хост, а значи рабочему процессу не помешает.
2) Первоначально разрабатывалось только для CoreOS, а CoreOS просто так в Docker не запустишь. Там система обновления, базирующася на GPT, readonly /usr раздел и прочие тонкости.
Странно, в европейком магазине максимальная поддержка только 8Gb RAM. В штатовском есть 16Gb.
Все эти пункты меню, стрелочки, далее. А есть уже готовые образы для QEMU/VB? Как, скажем, Ubuntu (https://cloud-images.ubuntu.com/xenial/current/). У них и qcow2 и vmdk, и ova. Бери что хочешь.
Если используются sub keys, то получить из полный fingerprint можно командой:
gpg --fingerprint --fingerprintUEFI secure boot кстати вполне спокойно работает на MBR (не могу точно сказать насколько это соответствует стандарту, давно проблему решал). Только необходимо osprober пофиксить https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817023
В сноске 2 как раз правильное решение используется.
Статья почти слово в слово повторяет мою запись в личной wiki. Мне порой кажется, что если я что-то подобное опубликую, то в меня полетит критика в роде "капитан очевидность" или "задрот".
У меня вопрос к следующей фразе:
Как это может быть, если initramfs находится на зашифрованном разделе (а не на ESP), а grub при загрузке сначала запросит пароль перед тем как считать initramfs и ядро с зашифрованного диска. Зачем нужна морока со сборкой и подписью своего ядра?
На ESP в моём случае находится лишь только grubx64.efi