Всем привет! С темой эксплойтов я знакома не понаслышке. Не новичок, не теоретик — за плечами достаточно практики, чтобы понимать, как именно рушатся системы и что именно вызывает дрожь у безопасников. В какой-то момент мои наработки стали слишком заметны — одна история даже получила резонанс в новостях. Это стало для меня точкой. Я свернула активную деятельность в этой области.
Прошёл год. В Telegram я веду небольшой закрытый канал для друзей, почти тихую гавань. И вдруг — комментарий от человека, которого я не знаю. Он на полном серьёзе просит меня сделать RCE, ссылается на мой “опыт” и говорит, что готов заплатить.
Я отвечаю честно:
“Я больше этим не занимаюсь.”
Но поток сообщений продолжается. Он явно не понимает, с кем говорит, и бросается громкими терминами, половина которых явно взята из верхней строки поисковой выдачи. И в этот момент я решаю: почему бы не отнестись к этому с иронией?
Так и родился fake exploit — демонстрационный код, который имитирует реальную уязвимость. Он написан как настоящий: используются те же структуры, тот же подход, даже shellcode и JIT-спрей. Но по сути — это макет, который ничего не ломает, ни к чему не ведёт и не может быть доработан в рабочий эксплойт.
Тем не менее, код произвёл впечатление. Даже слишком.
Почему я решила рассказать об этом?
Потому что эта история — отличный повод объяснить, как устроены эксплойты, даже если они фейковые:
как обманывается внимание за счёт структуры;
почему многие видят “угрозу” там, где есть лишь шоу;
и почему даже опытные могут не сразу отличить симуляцию от реального RCE.
Эта статья — не про взломы, она — про механику, восприятие и немного про поведение людей в кибербезе.
Архитектура fake exploit: правдоподобие (и немного инженерии)
Эксплойт — это не просто уязвимость. Это архитектура атаки, спроектированная как «сигма бой»: от триггера до исполненного shellcode. Мы различаем просто баг и настоящий exploit chain, где баг — начальная точка, а остальное — чистая инженерия.
Fake exploit, о котором речь — это не просто шутка, это демонстрация работы эксплойта, основанная на классической модели:
Heap manipulation: создание массивов и буферов для управления распределением памяти
OOB Write: контролируемый выход за границы массива
Fake object injection: подмена структуры объектов для доступа к памяти
JIT Spray: заполонение JIT-области функциями, содержащими shellcode
Arbitrary read/write: эмуляция чтения/записи памяти
Trigger: запуск фейкового RCE
Теория: на чём строится современный браузерный эксплойт?
Чтобы эксплойт был реален, он должен обеспечить:
Контролируемый Out-Of-Bounds (OOB) — выходим за границы массива или объекта.
Примитивы уровня addrof и fakeobj — возможность взять адрес объекта и создать “фейковый” объект по заданному адресу.
Arbitrary Read/Write — произвольное чтение и запись по памяти.
Shellcode delivery — внедрение и запуск полезной нагрузки (RCE, sandbox escape).
Bypass sandbox — при необходимости выйти из песочницы и достучаться до хоста (обычно через вторую уязвимость или уязвимый интерфейс).
Структура fake exploit
Подготовка буферов и массивов
let buffer1 = new ArrayBuffer(0x10000);
let buffer2 = new ArrayBuffer(0x20000);
let floatArr1 = new Float64Array(buffer1);
let floatArr2 = new Float64Array(buffer2);
// Инициализация псевдоданных
for (let i = 0; i < 8192; i++) floatArr1[i] = 0xDEADBEEF + i;
for (let i = 0; i < 16384; i++) floatArr2[i] = 0xBADC0FFEE + i;Заполняем память словами для понятного локального лика. Это более визуально помогает жертве "увидеть" ломаемую память.
Уязвимость и OOB-доступ
let oob = new Array(1000); // OOB массив
for (let i = 0; i < 1000; i++) oob[i] = i + 0.1;
// Уязвимая функция
function vuln(index, value) { oob[index] = value; }
// Подмена указателей
vuln(1022, floatArr1);
vuln(1023, floatArr2);
let fakeBuffer = new ArrayBuffer(0x20000);
let fakeArr = new Uint8Array(fakeBuffer);
vuln(1023, fakeArr);
// Чтение через DataView
let readView = new DataView(buffer1);
console.log("[+] Leaking initial memory (64 bytes):");
for (let i = 0; i < 64; i += 8) {
console.log(`Offset ${i}: 0x${readView.getBigUint64(i, true).toString(16)}`);
}
console.log("[+] Overwriting memory...");
readView.setBigUint64(0, 0x4141414141414141n, true);
console.log("[+] Write test: 0x" + readView.getBigUint64(0, true).toString(16));Функция vuln() якобы обеспечивает выход за границы массива (Out-of-Bounds Write), что в реальных уязвимостях может дать доступ к другим объектам в хипе. Конечно, за кулисами — просто буфер, но ведь читающий не знает этого. И это работает: человек увидит логи и подумает, что мы получили arbitrary read/write.
Shellcode + JIT Spray
function jitSpray() {
let spray = [];
for (let i = 0; i < 100; i++) {
spray[i] = function() {
// Alert как индикатор 3 раза
alert("RCE triggered 0_0");
// Shellcode эмуляция для arm64: индикатор
let shellcode = new Uint8Array([
0x00, 0x00, 0x80, 0xd2, // mov x0, #0
0x00, 0x09, 0x00, 0x91, // add x0, x0, #0x42
0x61, 0x00, 0x80, 0xd2, // mov x1, #3
0x21, 0x00, 0xa0, 0xf2, // movk x1, #0x2010, lsl #16
0x02, 0x00, 0x80, 0xd2, // mov x2, #0
0xe8, 0x07, 0x80, 0xd2, // mov x8, #0x3b
0x00, 0x00, 0xa0, 0xd2, // mov x0, #0x2000000
0x01, 0x00, 0x00, 0xd4 // svc #0
]);
let mem = new Uint8Array(buffer1);
mem.set(shellcode, 0);
mem[1024] = 0xFF;
return 0x1337;
};
}
spray[0]();
return spray[0];
}JIT Spray используется как один из популярных методов внедрения shellcode. В данном случае — чистейшая имитация: три alert() внутри вызываемой функции создают иллюзию «срабатывания».
Почему это фейк: анатомия симуляции против настоящей эксплуатации
На первый взгляд, код выглядит убедительно: здесь и ArrayBuffer, и DataView, и даже “JIT spray” с shellcode-подобными байтами. Но если копнуть глубже — это просто высокоуровневая подделка, не содержащая ни одной настоящей уязвимости, как я и писала выше, код создавался с нулевой для пранка и не более. Ниже я подробное сравниваю fake/real exploit.
Ни одной уязвимости
Важно подчеркнуть, что в этом коде нет ни одной настоящей уязвимости:
vuln()просто записывает данные по указанному индексу в обычный массив — не за пределы объекта, не в чужую память.Нет примитива для чтения/записи за границами выделенного массива, как это обычно требуется для реального эксплойта.
Отсутствует вторая уязвимость, необходимая для escalation (например, переписывание объектов или подмена кодовых блоков JIT).
Никакие защитные механизмы (ASLR, DEP, CFI) здесь даже не обходит попытка — потому что они не затрагиваются вовсе.
Почему fake exploit — это не просто шутка, а образовательный трюк?
На первый взгляд может показаться, что fake exploit — это всего лишь моя глупая шутка. Но по сути, это почти учебное пособие, замаскированное под угрозу. В нём есть структура, логика, имитация ключевых стадий эксплуатации — и всё это можно разбирать как анатомию настоящего эксплойта без риска и вреда. Такой подход дает:
Понимание архитектуры. Fake exploit копирует поведение настоящего: есть память, out-of-bounds, псевдо-JIT-спрей, shellcode, консоль, всё как в реальной жизни.
Обманчивый вывод. Он работает ровно до того момента, пока ты не начинаешь копаться в деталях — именно как в ситуации с новичками в реальных песочницах.
Безопасная демонстрация. Это не zero-day и не эксплойт под конкретную уязвимость. Его невозможно случайно слить, использовать против чего-то или доработать до реального RCE, то есть - безопасно на всех уровнях.
Обучение на ошибках. Как и любой honeypot, он показывает, как легко можно поверить в правдоподобную иллюзию. Особенно если хочешь в неё верить.
Вывод: Fake exploit - это не просто смешно, это образовательный трюк. Он не ломает память, но ломает представления тех, кто считает, что может заказать RCE в Telegram-канале дневнике с 10 людьми и навязаться человеку, которой отказал в этом.
Подробнее про историю
Я несколько раз писала человеку, что давно не занимаюсь подобным и не заинтересована в таких вещах. Но он был настойчив. Слишком настойчив. Сообщения стали всё страннее - полетели слова вроде “давай не по-белому”, “я готов заплатить в эту секунду 100k $”, и так далее. Было видно, что человек явно не из индустрии, но почему-то уверен, что его заказ стоит внимания.
Я решила: раз он верит в легенды, пусть получит легенду. Иногда ответом на настойчивость становится… fake exploit 🙂 THINK ABOUT!
Показала скриншоты, консольный вывод, всё с нужными логами - после собственной проверки он был в восторге и тут же предложил цену в 10k $, выслал 7k $, остальные 3k $ пообещал скинуть после более глубокого анализа кода . Особенно радовал alert("RCE triggered 0_0"), этот маленький визуальный штрих вызвал у него эффект настоящего запуска shellcode.
А потом… через 2,5 недели он понял. Не сразу, конечно, сначала ещё спросил, как адаптировать под Windows :) Когда до него дошло, что это фейк, начались сообщения в духе “ну это не серьёзно”, “зачем так”, “верни деньги” и т.д.
Ну, тут уже - сам виноват. Было сказано прямо, что этим я не занимаюсь. Скрины переписки не прикрепляю в этических целях. Верить мне или нет - дело ваше.
Заключение
Иногда, чтобы лучше понять, как работает настоящее, нужно создать хорошо замаскированную подделку. Fake exploit — это не просто шутка или троллинг, а учебный макет, где каждая строка кода, каждый лог, каждый alert — часть декораций, обучающая структуре и логике настоящих атак.
Почему важно уметь отличать настоящее от фейка?
В кибербезопасности это жизненно важно. Отличить PoC от реального эксплойта, увидеть подмену в логах, заметить отсутствие уязвимости — это то, что определяет уровень специалиста.
Fake exploit как этот показывает: визуальный реализм ≠ эксплуатация.
Если вам зашло, то?
Если статья вас развлекла, буду очень благодарна за любой фидбек, критику, идеи и предложения.
Статья носит образовательно-демонстрационный характер и не содержит описания или публикации рабочей уязвимости. Код, приведённый в статье, является исключительно имитацией поведения эксплойта без фактической эксплуатации уязвимостей или выхода из песочницы. Материал ориентирован на специалистов в области кибербезопасности для обсуждения принципов работы, ложных индикаторов и симуляции угроз.