ЦАП стоит после декодера.
В контексте обработки данных такой декодер точнее называть декомпрессором-деархиватором, но тут речь про аудио, где "компрессией" давно принято называть изменение динамического диапазона, возможное даже в чисто аналоговом виде (логарифмическая нелинейность в усилителе).
Наш деархиватор берёт сжатое цифровое аудио и выдаёт, по сути, WAV-файл, который занимает дохуя места, зато подходит для самого тупого ЦАП, даже типа R-2R.
Тупой деархиватор чересчур верит исходным данным и вслепую делает то, что в них предписано сделать, даже если это "смертельно". Возьмём в качестве примера сжатие по алгорифму RLE (для аудио не годится, зато наглядно). Идея в том, что серию постоянных байтов можно превратить в два байта: число повторов и повторяемое значение. Пусть обратным действием занимается индусский код, который каждую такую пару сначала превращает в цепочку байтов нужной длины, затем копирует её на выход. Но буфер для такого превращения сделали почему-то меньше, чем наихудший вариант, и как обычно его поместили в стек, где рядом хранят какую-нибудь важную переменную или вообще адрес возврата. Определённая "вредная" пара байтов выйдет за пределы буфера, испортит те другие данные рядом и приведёт к изменениям в самой работе деархиватора.
Бывало, что алгоритм сжатия в принципе даёт возможность во время такой атаки переполнением буфера подсунуть кусок тела вируса и выполнить его. А открытые исходники -- чувакам, у которых паранойи больше, чем у авторов, найти такие дыры достаточно быстро. Потому что когда капиталисты исходников не дали, то остаётся исследовать готовый кодек в дизассемблере, и это под силу лишь чувакам с маниакальной усидчивостью; но их слишком мало, чтобы среди них встретился "белый хакер", не обращающий находку во зло. Конечно, иногда и в открытых исходниках дыру сначала находят плохиши.
Это сообщение отредактировал saimhe - 17.01.2026 - 15:55
yaplakal.com