Тень уязвимости: fake exploit как зеркало реальных техник

Всем привет! С темой эксплойтов я знакома не понаслышке. Не новичок, не теоретик — за плечами достаточно практики, чтобы понимать, как именно рушатся системы и что именно вызывает дрожь у безопасников. В какой-то момент мои наработки стали слишком заметны — одна история даже получила резонанс в новостях. Это стало для меня точкой. Я свернула активную деятельность в этой области.

Прошёл год. В Telegram я веду небольшой закрытый канал для друзей, почти тихую гавань. И вдруг — комментарий от человека, которого я не знаю. Он на полном серьёзе просит меня сделать RCE, ссылается на мой “опыт” и говорит, что готов заплатить.

Я отвечаю честно:

“Я больше этим не занимаюсь.”

Но поток сообщений продолжается. Он явно не понимает, с кем говорит, и бросается громкими терминами, половина которых явно взята из верхней строки поисковой выдачи. И в этот момент я решаю: почему бы не отнестись к этому с иронией?

Так и родился fake exploit — демонстрационный код, который имитирует реальную уязвимость. Он написан как настоящий: используются те же структуры, тот же подход, даже shellcode и JIT-спрей. Но по сути — это макет, который ничего не ломает, ни к чему не ведёт и не может быть доработан в рабочий эксплойт.

Тем не менее, код произвёл впечатление. Даже слишком.

Почему я решила рассказать об этом?

Потому что эта история — отличный повод объяснить, как устроены эксплойты, даже если они фейковые:

1. как обманывается внимание за счёт структуры;

2. почему многие видят “угрозу” там, где есть лишь шоу;

3. и почему даже опытные могут не сразу отличить симуляцию от реального 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 как этот показывает: визуальный реализм ≠ эксплуатация.

Если вам зашло, то?

Если статья вас развлекла, буду очень благодарна за любой фидбек, критику, идеи и предложения.

Статья носит образовательно-демонстрационный характер и не содержит описания или публикации рабочей уязвимости. Код, приведённый в статье, является исключительно имитацией поведения эксплойта без фактической эксплуатации уязвимостей или выхода из песочницы. Материал ориентирован на специалистов в области кибербезопасности для обсуждения принципов работы, ложных индикаторов и симуляции угроз.