Блог*
Open in Telegram
Блог со звёздочкой. Много репостов, немножко программирования. Небольшое прикольное комьюнити: @decltype_chat_ptr_t Автор: @insert_reference_here
Show more1 985
Subscribers
+124 hours
-17 days
No data30 days
Posts Archive
1 984
#prog #article (и #performancetrap, видимо?)
The RAM myth (перевод)
Или о оптимизационных трюках, которые позволяют шардировать данные в RAM значительно быстрее наивного подхода (спойлер: они лучше утилизируют кэш). Бенчмарки наглядно показывают, насколько неадекватным является представление о RAM как о линейной памяти с константным доступом.
1 984
#prog #article
Bunnyhopping from the Programmer's Perspective
Или про то, как реализовать багофичу "банни-хопинг" в коде
1 984
Repost from Гепардово гнездо
https://www.ryanliptak.com/blog/every-rc-exe-bug-quirk-probably/
Не знаю, как вы, а я просто обожаю такие посты.
Здесь автор попытался написать альтернативную реализацию компилятора ресурсов Windows. Это программа, которая принимает текстовый написать все на новом модном современном Zig как можно точнее сохранить совместимость с оригинальной версией от Microsoft, вплоть до багов и незадокументированного поведения.
Как достичь этой цели? Например, можно написать код, а затем пофаззить оригинальную реализацию с альтернативной и найти, на каких данных они выдают разные результаты. В результате этого процесса автор нашел горы странного поведения в компиляторе ресурсов от Microsoft.
Пост длинный; если хотите посмотреть только самое интересное, можно поискать по странице по словам
.rc файл с описанием менюшек, кнопочек, окошек, иконок, курсоров и прочего, и компилирует это описание в бинарный .res файл, который потом встраивается в бинарник приложения под Windows.
Альтернативных реализаций компилятора ресурсов много, но у автора была цель, которой не добивались остальные: utterly baffling. Если же у вас много времени и вам не лень, можно прочесть и все :)1 984
Repost from Гепардово гнездо
Еще про проклятые фичи баша
https://yossarian.net/til/post/some-surprising-code-execution-sources-in-bash
tl;dr: вот эта функция на баше при передаче «правильного» аргумента может привести к выполнению произвольного кода:
не пишите на баше не передавайте в bash-скрипты недоверенные данные
function guess() {
num="${1}"
if [[ "${num}" -eq 42 ]]
then
echo "Correct"
else
echo "Wrong"
fi
}
Мораль проста: 1 984
Repost from Neural Machine
Сейчас мы можем делать все, что захотим, но скоро Бог будет судить нас.
1 984
Жалобы на пустопорожние ТГ-каналы (которые я полностью разделяю): https://t.me/trueresearch/1899
(thanks @tech_priestess)
1 984
#itsec
Uncovering GStreamer secrets
TL;DR: чел написал кастомный генератор начальных данных для фаззера и нашёл 29 новых потенциальных уязвимостей в GStreamer.
Фаззинг программ, разбирающих медиа-форматы, затруднителен тем, что готовые медиа-файлы слишком большие, чтобы эффективно использовать фаззинг, поскольку фаззеры обычно применяют побайтовые мутации к входным данным. Конкретно в случае с MP4 проблема усугубляется строением формата. Именно, файл MP4 состоит из нескольких box-ов, которые могут быть вложенными, и каждый из них начинается с заголовка, который включает в себя размер всего box-а. Если фаззер применяет мутацию, которая вставляет новые данные, он не в состоянии одновременно также и скорректировать размеры в нужных местах.
В статье описан алгоритм для генерирования случайных MP4-файлов. Коротко:
* создаётся случайное дерево, описывающее вложенные box-ы
* по узлам раскидываются теги
* листья дерева получают случайные размеры, размер остальных подсчитывается из суммы вложенных
* для каждого узла генерируются случайные данные в рамках выбранных размеров
* итоговое дерево сериализуется
К сожалению, из статьи непонятно, написал ли автор только генератор тестовых данных или ещё и мутатор.
Сами найденные ошибки, кстати, все типичные сишные: OOB-чтение/запись, разыменовывания NULL-указателей и даже одно use after free.
