Пишу я декриптор, который должен "на лету" расшифровывать по 1 ассемблерной команде и после выполнения обратно все шифровать.
Такой вопрос: обязательно за собой при этом тащить самописный "дизассемблер", который будет определять длину команды, которая будет выполнена, или же есть более простые способы? (просто я никогда подобными вещами не занимался, а тут проперло).
Только очень прошу: кто не знает, ничего не писать, а только по теме.

-----
Харе курить веники и нюхать клей, к вам едет из Америки бог Шива, и он еврей.

| Сообщение посчитали полезным:

а как ты без дизасма определишь длинну команды? тебе нужен хотя бы минимальный
дизассемблер длин

-----
[nice coder and reverser]

| Сообщение посчитали полезным:

На васме возьми дизасм длин, лишние 2 килобайта помоему не такая проблема.
Хотя смотря на чем пишеш

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

| Сообщение посчитали полезным:

> после выполнения

Sorry за наивное предположение: а нельзя следить за изменением EIP? (+SEH)

-----
The one derivative you manage is the one I abhore (c) Slipknot

| Сообщение посчитали полезным:

Crawler
Обойтись можно и без дизассемблера, имея заранее подготовленную таблицу длин и адресов зашифрованного кода ;)
Вопрос в другом - как ты планируешь выполнять call'ы и условные джампы и обрабатывать эксепшны? А передавать управление куску "защищенного кода" и обратно своему дизасму + рас\зашифровщику ? Если по одной инструкции дизасмить и исполнять, то тут даже по принципу армы не выйдет
Эта защита, даже если её реализовать - будет как говаривал Борат - "НЕ ОЧЕНЬ!!!", т.к. будет весьма тормозной, для неё достаточно убить обратный зашифровщик и всего делов. Сам знаешь, лучше
Crawler пишет:
"всегда увязывать всё с мат. логикой и комплексными числами. Это просто в реализации и создает трудности для реверсера. Главное - математику включить, функции вызывать по хэшу сложному, вызовы маскировать, защитный код на апи."

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

Smon пишет:
Обойтись можно и без дизассемблера, имея заранее подготовленную таблицу длин и адресов зашифрованного кода ;)
Да а лучше еще ИДБ чтоб сразу видеть гду мув где пуш.
Smon пишет:
Вопрос в другом - как ты планируешь выполнять call'ы и условные джампы и обрабатывать эксепшны? А передавать управление куску "защищенного кода" и обратно своему дизасму + рас\зашифровщику ?
Элементарно ватсон, код бьется на групы куда указывают переходы, составляется таблица source->destination при криптовании когда доходит до команд передачи управления, сохраняется новый адрес source вместо старого, вместо destination сохраняется адрес декриптора, чтоб когда передастсо управление то передавалось на декриптор а не на криптованый код.

Smon пишет:
Эта защита, даже если её реализовать - будет как говаривал Борат - "НЕ ОЧЕНЬ!!!", т.к. будет весьма тормозной, для неё достаточно убить обратный зашифровщик и всего делов
Я смотрю вы не особо вообще представляете о чем идет реч, и неведаете что такое "тормоза" и какие на это причины, подумайте над такой штукой как "виртуальная машина" и решите что будет быстрее, никто не говорит что будет шифроватся весь исполняемый код.


Smon пишет:
для неё достаточно убить обратный зашифровщик и всего делов.
Ну ну, убей 1500 зашифровщиков.

Все зависит от реализации. Такчто Smon учить матчасть.

Sorry за наивное предположение: а нельзя следить за изменением EIP? (+SEH)
И где ты за этим следить будеш? Тыж не выаолняеш код, а читаеш его. Это уже в криптованом приложении уже можна юзать относительные смещения для получения ключа декрипта или для определения длинны.

| Сообщение посчитали полезным:

>> Sorry за наивное предположение: а нельзя следить за изменением EIP? (+SEH)
> И где ты за этим следить будеш?

Ну я имел в виду именно выполнение в какой-нить "песочнице". Берем с запасом байт 12 и передаем управление на них, ограничив выполнение команды: 1) устанавливаем SEH/если в ядре, то обработчики исключений; 2) доступ к памяти ограничиваем фейковым селектором (т.е. DS=ES=SS=...=SPEC), так что любая команда с памятью будет вызвать исключение или, возможно, все же разрешаем работать с некоторыми кусками памяти, но, допустим, сбрасываем бит присутствия чтобы вызвать PageFault...

Но я ж написал - наивное, не обращайте особого внимания

-----
The one derivative you manage is the one I abhore (c) Slipknot

| Сообщение посчитали полезным:

Как вариант (без дизасма длин): перенести все команды защищенного блока в отдельную секцию, дополнив каждую нопами до 15-ти байт, соответственно пересчитав таргеты (без)условных переходов и (де)криптовать во время выполнения блоками по 15 байт.

| Сообщение посчитали полезным:

WoLFeR пишет:
Ну ну, убей 1500 зашифровщиков.
Ты их сделай сначала ))) А если он будет всего в нескольких вариациях - то легко раскриптуется и отсеется по шаблону
WoLFeR пишет:
Элементарно ватсон, код бьется на групы куда указывают переходы, составляется таблица source->destination при криптовании когда доходит до команд передачи управления, сохраняется новый адрес source вместо старого, вместо destination сохраняется адрес декриптора, чтоб когда передастсо управление то передавалось на декриптор а не на криптованый код.
Crawler пишет:
Пишу я декриптор, который должен
Заметь, автор имеет в виду один общий декриптор а не кучу декрипторов раскиданных по коду, и расшифровку и выполнение по одной инструкции а не блоками, это будет даже медленней чем тормозной copymemII, так что сам учи матчасть
А то что можно сделать блоки кода типа помеченных маркерами и расшифровщики к ним - это понятно, это давно юзается в современных протекторах и никаких дизасмов для этого не требуется, в данном случае речь идёт о другом, читай внимательней.
А вообще - rmn прав, только нопами не обязательно разбавлять, можно сделать так:
decryptor1
instruction1
encryptor1
decryptor2
instruction2
encryptor2
.............. и т.п.
Соответственно сначала дизасмим полностью код и переносим его в новую секцию соответственно добавив длины энкрипторов\декрипторов и пересчитывая все jcc и call'ы, затем криптуем защищаемые инструкции.

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

Smon пишет:
Заметь, автор имеет в виду один общий декриптор а не кучу декрипторов раскиданных по коду, и расшифровку и выполнение по одной инструкции а не блоками, это будет даже медленней чем тормозной copymemII
ппц, ты дкмаеш декрипт одной команды, будет тормозить медленней, чем виртуальная машина?
Smon пишет:
А то что можно сделать блоки кода типа помеченных маркерами и расшифровщики к ним - это понятно, это давно юзается в современных протекторах и никаких дизасмов для этого не требуется, в данном случае речь идёт о другом, читай внимательней.
Какие нах маркеры, фламастеры. Код анализируется и по нему составляется 3,4,5 таблиц которые нужны в дальнейшем чтоб пофиксить все смещения.
Я вообще говорил про универсал, что есть любой код и его нужно закриптить, а не тот который мы сами писали.
Smon пишет:
это будет даже медленней чем тормозной copymemII
всетаки повторюсь но матчать нужно учить.
декриптор:
crypt_decrypt_proc size_command:dword,key:byte
mov ecx,size_command
mov al,key
xor [edi],al
ret
endp

А теперь сам подумай что будет быстрее copymemII или этод код. И докажи что он будет медленнее.
+ Автор несказал что ему нужно закриптовать таким методом 2ух метровый файл. Естественно это нужно только для выбраных кусков кода.
Прежде чем говорить про плуги можнобыло посмотреть сырсы полиморфных крипторов, или их результат работы, или еще чего. Тогдаб такие утверждения отпалибы сами собой.
Когда там для того чтоб выполнить одну команду проходит 4 цыкла декрипта разбавленых мусором. И никто нежалуется на плуги.

| Сообщение посчитали полезным:

WoLFeR пишет:
ппц, ты дкмаеш декрипт одной команды, будет тормозить медленней, чем виртуальная машина?
ппц а ты сравни соотношение скорости и надёжности вм и такого кода ;) притом заметь - про вм я вообще ни слова не сказал - это твои выдумки.

WoLFeR пишет:
это будет даже медленней чем тормозной copymemII
всетаки повторюсь но матчать нужно учить.
рассмотрим стандартный код с циклами и твой декриптор будет тормозить сильнее копимем

WoLFeR пишет:
декриптор:
crypt_decrypt_proc size_command:dword,key:byte
mov ecx,size_command
mov al,key
xor [edi],al
ret
endp
Ну ты и гений, солидный декриптор написал... И вообще нехер писать такую шнягу, ибо такой код и дебил написать и разобрать сможет.

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

WoLFeR пишет:
декриптор:
crypt_decrypt_proc size_command:dword,key:byte
mov ecx,size_command
mov al,key
xor [edi],al
ret
endp
к тому же еще и нерабочую шнягу

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

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

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

| Сообщение посчитали полезным:

Smon пишет:
к тому же еще и нерабочую шнягу

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

| Сообщение посчитали полезным:

я с тобой тоже не собираюсь
твоя позиция мне тоже ясна

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

Smon пишет:
Вопрос в другом - как ты планируешь выполнять call'ы и условные джампы и обрабатывать эксепшны? А передавать управление куску "защищенного кода" и обратно своему дизасму + рас\зашифровщику ?

Буду запоминать в стек кое-что и потом вставлять на место декриптованной команды jmp decoder+N. И по этому адресу уже все восстанавливать в прежний вид.
И потом, я от памяти, скорее всего, crc или хэш какой-нибудь буду проверять. Так что не гоните на мою защиту =), хотя это тоже просто патчится, в принципе.


rmn пишет:
Как вариант (без дизасма длин): перенести все команды защищенного блока в отдельную секцию, дополнив каждую нопами до 15-ти байт, соответственно пересчитав таргеты (без)условных переходов и (де)криптовать во время выполнения блоками по 15 байт.
=)))) Это садомазохизм =))

Давайте еще предложения, а то таблицу буду считать =)))

-----
Харе курить веники и нюхать клей, к вам едет из Америки бог Шива, и он еврей.

| Сообщение посчитали полезным:

>>>
WoLFeR пишет:
Хотя смотря на чем пишеш
Пишу на асме под отладчиком (олька), вручную бабахаю все в секцию ноликов после конца .text, вроде пока все нормально, только муторно. Тренируюсь на notepade.
Скоро, когда метод подберем, писать буду навесную версию по-человечески.

-----
Харе курить веники и нюхать клей, к вам едет из Америки бог Шива, и он еврей.

| Сообщение посчитали полезным:

Crawler пишет:
Smon пишет:
Вопрос в другом - как ты планируешь выполнять call'ы и условные джампы и обрабатывать эксепшны? А передавать управление куску "защищенного кода" и обратно своему дизасму + рас\зашифровщику ?

Про исключения интересно =)

-----
Тут не могла быть ваша реклама

| Сообщение посчитали полезным:

Crawler пишет:
Скоро, когда метод подберем, писать буду навесную версию по-человечески.
ссылке по теме
http://wasm.ru/srclist.php?list=2 http://wasm.ru/srclist.php?list=2
http://www.wasm.ru/baixado.php?mode=tool&id=249 http://www.wasm.ru/baixado.php?mode=tool&id=249

в основном криптуется код "лоадер" который имеет не такой большей размер (востановление импорта, распаковка) лоадер в свою очередь уже может распаковывать и декриптить сам защищяемый код.

| Сообщение посчитали полезным:

lord_Phoenix пишет:
Про исключения интересно =)
До этого еще пока далеко =)

-----
Харе курить веники и нюхать клей, к вам едет из Америки бог Шива, и он еврей.

| Сообщение посчитали полезным:

WoLFeR
данный код:
crypt_decrypt_proc size_command:dword,key:byte
mov ecx,size_command
mov al,key
xor [edi],al
ret
endp

не более чем бред сивой кобылы.
1) кто будет инициализировать edi?!
2) кто будет декриптить всю команду, а не только 1-й байт?

>в основном криптуется код "лоадер" который имеет не такой большей размер
>(востановление импорта, распаковка) лоадер в свою очередь уже может распаковывать и
>декриптить сам защищяемый код.
стандартная щелуха, присутствующая в (почти) любом крипторе. сабжем в утверждении "распаковывать и декриптить сам защищяемый код." не пахнет.

| Сообщение посчитали полезным:

WoLFeR
По поводу того что копимемII будет быстрее.
Значит пример такой - стандартный код с циклами находится в пределах одной страницы, арма после расшифровки страницы работает с "чистым кодом" на этой странице, а твой закриптованный по одной инструкции код да еще и с полиморфным рас\зашифровщиком будет в этих циклах расшифровывать\зашифровывать каждую инструкцию - что очень и очень тормозно. В любом случае всё зависит от реализации и структуры кода - вполне естественно что криптованный код без циклов будет работать быстрее чем копимемII и возможно даже быстрее чем дебугблокер

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

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

Smon пишет:
В любом случае всё зависит от реализации
Я про это и говорил в 6том посте.

WolfHunter пишет:
1) кто будет инициализировать edi?!
2) кто будет декриптить всю команду, а не только 1-й байт?

1) тот кто пишет декриптор и будет инициалезировать edi
2) см. п.1 вопрос и стоял чтоб декриптить всю команду а не первый байт.

Если кто досихпор непонял что значед недописаный код
crypt_decrypt_proc size_command:dword,key:byte ; Edi - pointer crypt code
mov ecx,size_command
mov al,key
@@:
xor [edi],al
dec ecx
jnz @b
ret
endp
Для увеличения скорости этого выполняемого кода, его рекомендуется разместить не в секции где находятся криптованые данные.

| Сообщение посчитали полезным:

>Если кто досихпор непонял что значед недописаный код
му-а-ха-ха, открой наконец учебник по ассемблеру(лучше в картинках) и не позорься. читать противно.
команду не забыл? (опять декриптуешь/криптуешь первый байт команды )
mov ecx,size_command
mov al,key
@@:
xor [edi],al
inc edi
dec ecx
jnz @b
ret

| Сообщение посчитали полезным:

угу, втыкнул

| Сообщение посчитали полезным:

Просил же только по теме.

Придется по 15 байт, по методу rmn =(
Пересчитываем, так сказать, jmp-ы и тому подобное и шифруем наш код.
Пока нормальной альтернативы (кроме дизасма с wasm) я не увидел.
Жаль только, что сессия не дает покоя.
Еще вопросы: кто знает какие хорошие антиотладочные (нетривиальные) приемы, приемы нетривиальные убивания сайса, и т.п.?
Ну и, конечно, принимаются методы новые по поводу криптора.

-----
Харе курить веники и нюхать клей, к вам едет из Америки бог Шива, и он еврей.

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным: