Гайд Актуальные методы защиты читов

[FruZer]

Перед прочтением основного контента ниже, пожалуйста, обратите внимание на обновление внутри секции Майна на нашем форуме. У нас появились:

• бесплатные читы для Майнкрафт — любое использование на свой страх и риск;
• маркетплейс Майнкрафт — абсолютно любая коммерция, связанная с игрой, за исключением продажи читов (аккаунты, предоставления услуг, поиск кодеров читов и так далее);
• приватные читы для Minecraft — в этом разделе только платные хаки для игры, покупайте группу "Продавец" и выставляйте на продажу свой софт;
• обсуждения и гайды — всё тот же раздел с вопросами, но теперь модернизированный: поиск нужных хаков, пати с игроками-читерами и другая полезная информация.

Спасибо!

Посмотрев в тему от атомова где он плотно навалил говна готорое ломается за 10 минут нейронкой решил написать свое, где адекватно расскажу что в текущий момент используют для защиты. В данной статье предоставленная актуальная информация по защите (под пример взял Kotopushka, который является чуть ли не единственным протером кто сейчас ставит)

JVM
В текущих реалиях по большей части защита строиться вокруг нативки, так что JVM некий контрольный пункт который просто усложняет дальнейший реверс, что в большенстве случаев делается для защиты на этом этапе:

Добавляется кастомный бутстраппер - необходимо для усложнения запуска вашей JVM в обход лаунчера, вариантов реализации до жути много, от банального ключа в агрументах до кастомных методов для создания JVM

Изменение таблицы вызовов JNI - дает возможность усложнить реверс вашей нативки, становится не так легко поставить хуки на все что можно чтобы протрейсить вашу нативку.

Шифрование - под этот пункт выделю побольше места. Вариантов реализации очень много, засунуть можно как в ClassFileParser(кфп) \ ClassFileStream(кфс), так и просто в ConstantPool.

Так же в подпункт шифрования можно внести изменение структуры InstanceKlass, делается эта операция по большей части от так называемых IK-Дамперов, из-за этой процедуры становится очень сложно собрать ваш класс по кусочкам чтобы получить стоковый(который сможет прочитать стандартная джава)
Так же рекомендуется порезать JVMTI на пару с реконструктором, это отрежет -javaagent и прочую хуйню, жить станет чутка безопастней)

NATIVE
Тут необходимо пояснить что такое вообще натив и как оно работает, у нашей джавы есть JNI (Java Native Interface), это позволяет при помощи такой конструкции public static native void pizdec(); выполнить код из под C++, т.е код пишется на плюсах а выполняется на джаве.

Для облегчения данного говна используют J2C(Java to CPP) данное говно помогает хитровыебанным механизмом превратить код из джавы в плюсы, самый ярый пример что сейчас юзается среди пастеров -

Пожалуйста, авторизуйтесь для просмотра ссылки.

(noad), данная нативка обьективно достаточно хуевая, очень хуевая оптимизация и легкий разбор ее (из текущих протеров ее юзают все бездари аля InternalGuard и прочего).

Подробного пояснения ее работы не будет, но подчеркну самый частоиспользуемый в ней метод на текущий момент.

Нативные референсы - собирается адрес какого нить env->FindClass("jopa"), шифруется посредству rtdsc (такты процессора) и cpuid, после чего шифрованные адреса отправляются на сервер, где проходят дополнительный механизм обработки и возвращаются клиенту и уже исходя от этого выполняется ваша нативка, данный прикол используется сейчас везде (У вендокса, котопушки, кекофа и прочих), не так давно кекофф слил нативку где представлен пример такого(эту же нативку но ее сильно улучшенную версию использует котопух). (Линк не дам ищите сами)

Так же дам по мелочи советы которые помогут сделать так чтобы вашу хуйню не расхукали за 15 минут - по максимуму не обертывайте код во всякую хуйню аля такого:

uint64_t getRDSTC() {
    return __rdtsc;
}

В данном случае от шифрования по тикам не будет никакого смысла, ибо найдя паттерн данной функции в дизассемблере - можно будет возвращать статик значение и вы будете сосать хуй со свой протой.

Писать тут можно еще много, но добавив уже все что описано тут - всякие пастеры отвалятся

SERVER
Данный пункт особо многого в себе не хранит, но он очень важен, ибо именно засчет этого пункта мною были крякнуты многие читы (Все читы на защите сержа (дельта арбуз и т.п), Котопушка (Meow, Toffi), Crashdami (Atom, и еще какая то паста)).

Тут в статье атомова все было +- по факту, используйте максимально задроченные системы для шифрования запросов \ ответов, сервер НИКОГДА не должен отправлять статичный ответ, все должно быть на динамике, хоть тот же RDTSC блять используйте, JWT токены, и шифрование на приватных \ публичных ключах наше все.

Именно на данный пункт я первым делом смотрю когда крякаю что либо, ибо куда проще спуфнуть сервер чем проебать жизнь на подробный анализ твоей защиты в дизассемблере)

Итоги
В текущий момент в статье описана информация которая необходима для самой базовой проты, понятное дело что я опустил очень многие моменты, в той же нативке с вм-кой очень много приколов, про лоадер в статье ничего не было написано поскольку почти у всех он используется только для загрузки файлов и запуска джавы, что вполне легко делается ручками)

Ну а если не хочешь писать свою защиту - скоро релизнется (надеюсь) XTZProtect с автоматизированной постановкой на защиту по принципу ежемесечной подписки.

UPD: Ну а в следующем посте я сделаю туториал как крякается то что я описал выше :)

 

[AtomoV]

начал подавать признаки жизни после моего гайда

 

[lustman]

и шифрование на приватных \ публичных ключах наше все

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

 

[Iaiw]

Терпимо, полную статью с примерами. Не тот форум чтобы думать

 

[FruZer]

Терпимо, полную статью с примерами. Не тот форум чтобы думать

да чет я ебал примеры добавлять, каша полная получится

 

[Iaiw]

да чет я ебал примеры добавлять, каша полная получится

Думаю нормально выйди, ибо сейчас статья представляет из себя:
Сделай вот это и ну типо хватит.

Мне как человеку не посвященному в низкий уровень jvm интересно было бы прочитать с примерами, дабы понять в какую сторону копать, если мне когда-то это понадобиться.
А вообще переходим на Котлин и забываем про виртуальные потоки

 

[FruZer]

Думаю нормально выйди, ибо сейчас статья представляет из себя:
Сделай вот это и ну типо хватит.

Мне как человеку не посвященному в низкий уровень jvm интересно было бы прочитать с примерами, дабы понять в какую сторону копать, если мне когда-то это понадобиться.
А вообще переходим на Котлин и забываем про виртуальные потоки

Про JVM вообще в формате статьи достаточно сложно рассказать, каждый раз все делается +- по разному, если в нативке условно я могу показать, то в случае с джавой - это сотни переписанных строк с добавлением кучи разного дерьма, все обьяснять головой поплыть можно, тут скорее поможет документация JDK)

 

[Iaiw]

Про JVM вообще в формате статьи достаточно сложно рассказать, каждый раз все делается +- по разному, если в нативке условно я могу показать, то в случае с джавой - это сотни переписанных строк с добавлением кучи разного дерьма, все обьяснять головой поплыть можно, тут скорее поможет документация JDK)

Понял, в таком случае при открой зановес нативок.

 

[WantToFreak]

Так же в подпункт шифрования можно внести изменение структуры InstanceKlass, делается эта операция по большей части от так называемых IK-Дамперов

почему нельзя зашифровать адреса?

Так же дам по мелочи советы которые помогут сделать так чтобы вашу хуйню не расхукали за 15 минут - по максимуму не обертывайте код во всякую хуйню аля такого:

почему нельзя сделать на геттеры и сеттеры поля

SERVER

почему не хранить адреса на сервере и ключи? а для соединения использовать openssl а не винсокеты как хохлопушки

 

[Intrspct]

Это какой-то пиздец... Про кастомный бутстраппер.
Ты несешь какую-то хуйню. "Усложнить запуск"? Серьёзно? Цель не усложнить, а сделать так, чтобы твою жопу ВООБЩЕ НИКТО НЕ ЗАПУСТИЛ без твоего лаунчера. Никаких "ключей в аргументах", нахер это никому не упало. бутстраппер — это когда ты ПОЛНОСТЬЮ выебываешься со своей либой, инициализируешь всю хуйню сам, патчишь рантайм, и только потом поднимаешь JVM. То, что ты описал — это уровень школьника из второго класса, который нашёл первую статью на югейме.
"Изменение таблицы вызовов JNI". Блять, да ты просто копируешь слова без понимания. Это называется JNIEnv*, долбоёб. Меняешь указатели функций в этой структуре, чтобы все стандартные хуки полетели к хуям и крашнули всех, кто пытается их поставить. Это не "усложняет реверс". Научись терминологии прежде чем нести хуйню.
Шифрование. Ты написал про ConstantPool? Ты хоть понимаешь, что это такое? Ты либо шифруешь ВЕСЬ класс до того, как он попадёт в парсер (ClassFileStream), либо ты ебешь мозги самой JVM, патчишь ClassFileParser нативно и заставляешь его понимать твою кастомную, сломанную структуру класса. Второе — это и есть защита от дамперов, про которую ты ляпнул дальше. Это две большие разницы, а у тебя это выглядит как два одинаковых пункта.. Ты смешал всё в кучу, наговорил хуйни и в конце сделал рекламу своей "защиты" (ОХУЕТЬ, КАК НОВО, ТОЧНО КУПЛЮ).
Всем остальным: не учитесь по этому говну. Открывайте документацию Oracle, смотрите исходники JDK, учите C++ и ассемблер. Всё, что описано у этого автора — жалкая пародия на реальные методы защиты.
Кубоголовые не удивили, надеюсь когда через пару лет зайду в этот раздел, они вырастут и поумнеют

почему нельзя зашифровать адреса?

почему нельзя сделать на геттеры и сеттеры поля

почему не хранить адреса на сервере и ключи? а для соединения использовать openssl а не винсокеты как хохлопушки

Плюс минус в правильном направлении мыслишь
Я хуй знает, вьебите мне 10 клоунов я вам гайд что-ли по защите напишу или разберу полностью пост выше

 

[FruZer]

почему нельзя зашифровать адреса?

почему нельзя сделать на геттеры и сеттеры поля

почему не хранить адреса на сервере и ключи? а для соединения использовать openssl а не винсокеты как хохлопушки

Насчет адресов - никто не запрещает, делай че хочешь в этом плане, сломать структуру всю нахуй - самый легкий способ задефаться.
геттеры \ сеттеры - подхукать проще, опять же про рдтск, если обернуть в геттер - нужно найти паттерн и хуйнуть в него и от твоего шифрования по тактам смысла нет, но вот напрямую уже все более весело, там уж нужно поебаться патча каждое место где ты юзаешь рдтск (более простого метода я буквально не знаю).
Ласт сообщение ваще не понял.. разберем на примере пуха, часть адресов у него и так лежит на сервере (привет вхессу с экспешн генератором), а в использовании openssl ваще какой смысл да и че разница что он юзает для общения с сервером? Он может хоть голубями байты отправлять тя эт трахать не должно, openssl твое соединение не дефает никак если крэкера есть доступ к самой твоей апке, буквально одним хуком я могу любого говна насовать в ответ сервера не используя дополнительные средства.

 

[FruZer]

Это какой-то пиздец... Про кастомный бутстраппер.
Ты несешь какую-то хуйню. "Усложнить запуск"? Серьёзно? Цель не усложнить, а сделать так, чтобы твою жопу ВООБЩЕ НИКТО НЕ ЗАПУСТИЛ без твоего лаунчера. Никаких "ключей в аргументах", нахер это никому не упало. бутстраппер — это когда ты ПОЛНОСТЬЮ выебываешься со своей либой, инициализируешь всю хуйню сам, патчишь рантайм, и только потом поднимаешь JVM. То, что ты описал — это уровень школьника из второго класса, который нашёл первую статью на югейме.
"Изменение таблицы вызовов JNI". Блять, да ты просто копируешь слова без понимания. Это называется JNIEnv*, долбоёб. Меняешь указатели функций в этой структуре, чтобы все стандартные хуки полетели к хуям и крашнули всех, кто пытается их поставить. Это не "усложняет реверс". Научись терминологии прежде чем нести хуйню.
Шифрование. Ты написал про ConstantPool? Ты хоть понимаешь, что это такое? Ты либо шифруешь ВЕСЬ класс до того, как он попадёт в парсер (ClassFileStream), либо ты ебешь мозги самой JVM, патчишь ClassFileParser нативно и заставляешь его понимать твою кастомную, сломанную структуру класса. Второе — это и есть защита от дамперов, про которую ты ляпнул дальше. Это две большие разницы, а у тебя это выглядит как два одинаковых пункта.. Ты смешал всё в кучу, наговорил хуйни и в конце сделал рекламу своей "защиты" (ОХУЕТЬ, КАК НОВО, ТОЧНО КУПЛЮ).
Всем остальным: не учитесь по этому говну. Открывайте документацию Oracle, смотрите исходники JDK, учите C++ и ассемблер. Всё, что описано у этого автора — жалкая пародия на реальные методы защиты.
Кубоголовые не удивили, надеюсь когда через пару лет зайду в этот раздел, они вырастут и поумнеют

Плюс минус в правильном направлении мыслишь
Я хуй знает, вьебите мне 10 клоунов я вам гайд что-ли по защите напишу или разберу полностью пост выше

Так ладно теперь тебе поясню.. я в своей статье описал ТЕКУЩИЕ РЕАЛИИ ПРОТЕРОВ, ясен хуй что в адекватном варианте нужно полностью связывать все части твоей защиты в единое целое чтоб никто не смог отдельно что запустить, но сейчас никто этим не занимается и нахуй оно никому не надо.

Про енв ваще плотно дерьма навалил, сказал ровно тоже самое более умными словами, по другому я это блять назвать не могу))))) Про усложнее реверса не будь ебланом, речь про это шла в формате того что основная часть твоей защиты это блядская нативка) И то что типу придется найти указатели на почти что каждую функцию JNI - та еще дрочь (поясню для непонятливых, в случае с серверными референсами проще протрейсить нахуй все вызовы и пересобрать твою нативку - так дримикс вексайд выебал), так что да по факту это усложняет реверс (ну или хотя бы блять анализ).

ПРО КПУЛЛ ТЫ ЧЕ ВАЩЕ ЕБАНАТ??? У тебя есть куча вариантов как сделать шифрование твоего ебаного класса в JVM, у тебя идет порядок cfs -> cfp -> cpull, в кфс тебе приходит ебаный стрим байтов класса, тут можно закриптить нахуй весь стрим но толку особо не будет, в cfp ты криптишь часть каких либо данных класса - хочешь вьеби все константы, хочешь передрочи вообще весь класс как тебе надо, поменяй порядок парса и т.п. Ну а в кпулле шифрование делается расшифровывая константы когда они уже прошли парс и собираются в полноценный ik.
Ну а про то что это и есть защита от дамперов я молчу вообще нахуй))))) У тебя вариантов где можно спиздить класс с вм-ки до жути блять много, все что лежит сейчас в паблике по запросу java дампер - вытягивает с кфп кфс дефайн класса, ты просто не видел дамперы которые работают блять ниже собирая твой класс по частицам.

Ну вроде на твои доебы ответил, можешь идти дальше размазывать говно по вентилятору надеясь что статья где описаны текущие методы что используют = это максимум на что способны люди

Так ладно теперь тебе поясню.. я в своей статье описал ТЕКУЩИЕ РЕАЛИИ ПРОТЕРОВ, ясен хуй что в адекватном варианте нужно полностью связывать все части твоей защиты в единое целое чтоб никто не смог отдельно что запустить, но сейчас никто этим не занимается и нахуй оно никому не надо.

Про енв ваще плотно дерьма навалил, сказал ровно тоже самое более умными словами, по другому я это блять назвать не могу))))) Про усложнее реверса не будь ебланом, речь про это шла в формате того что основная часть твоей защиты это блядская нативка) И то что типу придется найти указатели на почти что каждую функцию JNI - та еще дрочь (поясню для непонятливых, в случае с серверными референсами проще протрейсить нахуй все вызовы и пересобрать твою нативку - так дримикс вексайд выебал), так что да по факту это усложняет реверс (ну или хотя бы блять анализ).

ПРО КПУЛЛ ТЫ ЧЕ ВАЩЕ ЕБАНАТ??? У тебя есть куча вариантов как сделать шифрование твоего ебаного класса в JVM, у тебя идет порядок cfs -> cfp -> cpull, в кфс тебе приходит ебаный стрим байтов класса, тут можно закриптить нахуй весь стрим но толку особо не будет, в cfp ты криптишь часть каких либо данных класса - хочешь вьеби все константы, хочешь передрочи вообще весь класс как тебе надо, поменяй порядок парса и т.п. Ну а в кпулле шифрование делается расшифровывая константы когда они уже прошли парс и собираются в полноценный ik.
Ну а про то что это и есть защита от дамперов я молчу вообще нахуй))))) У тебя вариантов где можно спиздить класс с вм-ки до жути блять много, все что лежит сейчас в паблике по запросу java дампер - вытягивает с кфп кфс дефайн класса, ты просто не видел дамперы которые работают блять ниже собирая твой класс по частицам.

Ну вроде на твои доебы ответил, можешь идти дальше размазывать говно по вентилятору надеясь что статья где описаны текущие методы что используют = это максимум на что способны люди

не блять я еще пиздану за пункт про шифрование, прочитав твое сообщение еще разок сложилось мнение что ты не понимаешь сути что делается в румайне, в кфп ты не ломаешь структуру самого класса как его будет понимать твоя джава обоссаная, ты ломаешь\редачишь именно парс так как оно тебе надо

 

[WantToFreak]

openssl твое соединение не дефает никак если крэкера есть доступ к самой твоей апке, буквально одним хуком я могу любого говна насовать в ответ сервера не используя дополнительные средства.

зачем тогда люди используют криптографию, давайте все на ГОЛУЮ ПЕРЕДАЧУ БАЙТОВ ака UDP и радоваться жизни ведь захукать можно

 

[FruZer]

зачем тогда люди используют криптографию, давайте все на ГОЛУЮ ПЕРЕДАЧУ БАЙТОВ ака UDP и радоваться жизни ведь захукать можно

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

 

[WantToFreak]

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

а зачем тогда

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

 

[FruZer]

а зачем тогда

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

типа условно тг в пример взять, там используется и ssl и mtproto, но на клиенте я один хуй достану твое сообщение хоть ты обосрись чисто потому что у меня есть куда надавить в самом приложении, но вне доступа к апке, условно если я просто траффик читать пойду - меня выебет в жопу и тут да тебе поможет и ссл и стороннее шифрование, так же работает и в читах, но в них нет смысла прятать траффик от внешнего мира так чт как то похуй

 

[algorithmABCDE]

Посмотрев в тему от атомова где он плотно навалил говна готорое ломается за 10 минут нейронкой решил написать свое, где адекватно расскажу что в текущий момент используют для защиты. В данной статье предоставленная актуальная информация по защите (под пример взял Kotopushka, который является чуть ли не единственным протером кто сейчас ставит)

JVM
В текущих реалиях по большей части защита строиться вокруг нативки, так что JVM некий контрольный пункт который просто усложняет дальнейший реверс, что в большенстве случаев делается для защиты на этом этапе:

Добавляется кастомный бутстраппер - необходимо для усложнения запуска вашей JVM в обход лаунчера, вариантов реализации до жути много, от банального ключа в агрументах до кастомных методов для создания JVM

Изменение таблицы вызовов JNI - дает возможность усложнить реверс вашей нативки, становится не так легко поставить хуки на все что можно чтобы протрейсить вашу нативку.

Шифрование - под этот пункт выделю побольше места. Вариантов реализации очень много, засунуть можно как в ClassFileParser(кфп) \ ClassFileStream(кфс), так и просто в ConstantPool.

Так же в подпункт шифрования можно внести изменение структуры InstanceKlass, делается эта операция по большей части от так называемых IK-Дамперов, из-за этой процедуры становится очень сложно собрать ваш класс по кусочкам чтобы получить стоковый(который сможет прочитать стандартная джава)
Так же рекомендуется порезать JVMTI на пару с реконструктором, это отрежет -javaagent и прочую хуйню, жить станет чутка безопастней)

NATIVE
Тут необходимо пояснить что такое вообще натив и как оно работает, у нашей джавы есть JNI (Java Native Interface), это позволяет при помощи такой конструкции public static native void pizdec(); выполнить код из под C++, т.е код пишется на плюсах а выполняется на джаве.

Для облегчения данного говна используют J2C(Java to CPP) данное говно помогает хитровыебанным механизмом превратить код из джавы в плюсы, самый ярый пример что сейчас юзается среди пастеров -

Пожалуйста, авторизуйтесь для просмотра ссылки.

(noad), данная нативка обьективно достаточно хуевая, очень хуевая оптимизация и легкий разбор ее (из текущих протеров ее юзают все бездари аля InternalGuard и прочего).

Подробного пояснения ее работы не будет, но подчеркну самый частоиспользуемый в ней метод на текущий момент.

Нативные референсы - собирается адрес какого нить env->FindClass("jopa"), шифруется посредству rtdsc (такты процессора) и cpuid, после чего шифрованные адреса отправляются на сервер, где проходят дополнительный механизм обработки и возвращаются клиенту и уже исходя от этого выполняется ваша нативка, данный прикол используется сейчас везде (У вендокса, котопушки, кекофа и прочих), не так давно кекофф слил нативку где представлен пример такого(эту же нативку но ее сильно улучшенную версию использует котопух). (Линк не дам ищите сами)

Так же дам по мелочи советы которые помогут сделать так чтобы вашу хуйню не расхукали за 15 минут - по максимуму не обертывайте код во всякую хуйню аля такого:

uint64_t getRDSTC() {
    return __rdtsc;
}

В данном случае от шифрования по тикам не будет никакого смысла, ибо найдя паттерн данной функции в дизассемблере - можно будет возвращать статик значение и вы будете сосать хуй со свой протой.

Писать тут можно еще много, но добавив уже все что описано тут - всякие пастеры отвалятся

SERVER
Данный пункт особо многого в себе не хранит, но он очень важен, ибо именно засчет этого пункта мною были крякнуты многие читы (Все читы на защите сержа (дельта арбуз и т.п), Котопушка (Meow, Toffi), Crashdami (Atom, и еще какая то паста)).

Тут в статье атомова все было +- по факту, используйте максимально задроченные системы для шифрования запросов \ ответов, сервер НИКОГДА не должен отправлять статичный ответ, все должно быть на динамике, хоть тот же RDTSC блять используйте, JWT токены, и шифрование на приватных \ публичных ключах наше все.

Именно на данный пункт я первым делом смотрю когда крякаю что либо, ибо куда проще спуфнуть сервер чем проебать жизнь на подробный анализ твоей защиты в дизассемблере)

Итоги
В текущий момент в статье описана информация которая необходима для самой базовой проты, понятное дело что я опустил очень многие моменты, в той же нативке с вм-кой очень много приколов, про лоадер в статье ничего не было написано поскольку почти у всех он используется только для загрузки файлов и запуска джавы, что вполне легко делается ручками)

Ну а если не хочешь писать свою защиту - скоро релизнется (надеюсь) XTZProtect с автоматизированной постановкой на защиту по принципу ежемесечной подписки.

UPD: Ну а в следующем посте я сделаю туториал как крякается то что я описал выше :)

Сливаю приватный метод крипта XOR для вашей крипты!

public static EncryptionResult encrypt(byte[] data) {
    final int rounds = 3;
    try {
        byte[] salt = new byte[16];
        byte[] iv = new byte[12];
        random.nextBytes(salt);
        random.nextBytes(iv);
        byte[] baseKey = generateKey(11);
        byte[] strengthenedKey = strengthenKey(baseKey, salt, 10000);
        byte[] finalKey = combineKeyWithIV(strengthenedKey, iv);
        byte[] encrypted = multiRoundXOR(data, finalKey, rounds);
        encrypted = addRandomPadding(encrypted);
        byte[] result = new byte[16 + 12 + encrypted.length];
        System.arraycopy(salt, 0, result, 0, 16);
        System.arraycopy(iv, 0, result, 16, 12);
        System.arraycopy(encrypted, 0, result, 16 + 12, encrypted.length);
        return new EncryptionResult(result, baseKey);
    } catch (Exception e) {
        return encryptSimple(data);
    }
}