Привет. Люди, подскажите место где можно скачать литературу Криса Касперски в электронном виде. Был какой-то фтп, но туда почему-то постоянно не было доступа. Буду очень благодарен. :]
фтп, но туда почему-то постоянно не было доступа. Крис спит -- доступа нет Жди. Или здесь посмотри: http://kpnc.opennet.ru/
Люди, подскажите, а у него есть сайт? Что-то я не нашел его... :-( или может кто скажет e-mail Криса? Очень нужно ему несколько вопросов задать..
ссылка выше - ну что за барахло! адрес ftp вот - ftp://nezumi.org.ru только он не все время доступен, т.к. стоит на рабочей машине, а мыщъх последнее время ходит под феназепамом, то есть дрыхнет, поддолкнув под себя хвост и тихо ходит умом в неизвестном направлении. kpnc.opennet.ru давно не обновлялся (времени нет) а барахла за последнее время много написано, только сейчас в "разработке" шесть книг "хакерские трюки" (ну это вообще барахло), "программирование для гурманов" (бархало), "хакерство с паяльником в руках" (барахло), "записки исследователя вирусов 3" (бааарахло), "черная и белая магия Windows" (для юзеров) "хакерская копилка - россыпи полезных советов" весь материал уже написан, сейчас пытаюсь найти время, чтобы свести его до кучи, но времени не хватает ;( да тут еще крыша прохудилась, экспериментирую со всякими психотропными веществами, пытаясь найти те, под которыми хоть как-то можно работать (кто пробовал галоперидол - тот знает, остальных веслом по яйцам не били, они не поймут) только вот куда всю эту ораву книг девать? надо будет рассовать по издательствам, которые... ну блин.. ну короче... за два последних месяца мои гонорары составили: 170 рэ и 11 рэ. так что электронный дистибушьен я горячо привествовать. меня, кстати, легко найти в осле в отличии от ftp он (осел) работает постоянно, и источников довольно прилично... только следует учесть, что мыщъх со старостью стал сдавать и опустился ниже уровня wasm'а, так что... хотя за последнее время нашел довольно элегатный способ борьбы с обуфскаторами. 1) трассируем прогамму в лог 2) конвертим asm в си 3) пропускаем через оптимизирующий компилятор результат - компилер удаляет большую часть избыточности. одна заковыка: компилер стремается убирать ссылки на память! потому код вида: xxx: xor [esi],eax ... xor [esi],eax loop xxx ниииифига не оптимизируется. во всяком случае до тех пор, пока не загнать [esi] в локальыные переменные. все равно при конвертации asm'а в си, мы создаем виртуальную машишу, верно? так что нам это не трудно... сейчас ковыряю gcc, хочу доработать его так, чтобы он понимал живой асмвоый код и немного более "смело" удалял избыточность первый результат весьма впечатляющий: после gcc листинг приобретает осмысленность, и хотя там еще дофига мусора, с ним по крайнйе мере уже можно _работать_, а не страдать, ковырясь в мегабайтах дерьма... кстати, на уровне деревьев полиморфики лажают и дают идентичный код, стоит только подняться на метауровень и тогда конструкция mov eax, offset x mov ebx, eax mov ecx, [eax] будет _автоматически_ совпадать с lea esi, x lodsd поскольку в метакоде(и промежуточном коде gcc) это записывается как: a = *x; что позволяет нам использовать gcc как инструмент для ловли полиморфиков и распаковщик программ. кстати, про распаковку... нашел прием, "пробивающий" ~99% паковщиков и протектов, осонованный на тех фактах, что: 1) код упакованной программы отделен от кода распаковщика 2) распаковщики восстанавливают esp 3) распакованная программа использует стек отсюда - ставим бряк на esp - 4, и "всплываем" когда окажется в пределах распакованной секции... это простейший случай, конечно, на практике приходится вводить несклько дополнительных "обработчиков нештатных ситуаций", но мысль думаю ясна... единственная проблема (возвращаясь к оптимизации лога трассера) - распознавание циклов. ms vc и gcc на этом лажают, а вот hp число конкретно их сворачивает, даже если они содержает несколько ветвлений внутри... но не хочется привязываться к hp, хочется самому это сделать есть желающие заняться этим? в смысле написать деобфускатор?
n2k Скомпилировал я недавно одну несложную прогу в gcc v3.4.x. Прога прямо на старте (первая линия в main) выводила сообщение в консоль типа "Welcome to my cool program!" Когда я включил максимальную оптимизацию по скорости (/O3), компилятор "смело" вырезал это самое первое сообщение Посчитал его избыточным А баг связан был с тем, что сразу после этого сообщения следовал вызов ассемблерной ф-ции и у компилятора, видимо, поехала крыша, когда он попытался её заинлайнить. В последних версиях gcc 4.x, говорят, ещё больше багов. Всегда именно так и распаковывали всякие аспаки, fsg и прочюю мелочь. А если в [esi] окажется глобальный флаг, который используется в другой ф-ции? Типичная ведь ситуация.
глюки оптимизации в gcc - тема отдельного разговора, но для поставленной задачи достаточно и менее аргрессивной оптимизации... суть ведь в чем. все статьи об антиобфускации, которые я прочел, фактически сводились к пяти словам: "надо гнаь код на графы"... так ведь и gcc, и любой другой оптимизатор поступает _точно_также_!!! спрашивается, зачем писать то, что уже есть?! тут меня вот какой вопрос спать не дает. как лучше быть? толи преобразовывать лог трассера в Си или в промежуточный gcc-язык, в последнем случае мы имеем больше возможностей сообщать оптимизатору, что мы от него хотим минусы: - мы "подсаживаемся" на gcc - с промежуточным кодом еще разбираться надо и еще. нужен качественный трассер. очень качественный... или даже целая виртуальная машина, (например, BOCHS)... может, у народа будут другие соображения? по поводу распаковки. ну... не знаю... наверное я остал от жизни. сколько не потрошил разных универсальных распаковщиков - они _трассировали_ код, я же предлагаю от этого отказаться.. естественно, на первенство идеи не претендую, просто из всех перепробованных мной способов поиска oep, этот оказался самым лучшим но это я к чему... это просто чтобы народ мог оценить уровень статей, которые я сейчас пишу и их полезность (бесполезность) для каждого из вас. я же говорю. это не уровень wasm'а. это уровень ксапека в котором я осел (в смысле обосновался, хотя и опарнокопытился тоже) правда, скоро выйдет довольно достойная книжка по ремонту хардов (с PC-3000 и без него) и восстановлению данных на NTFS/EXT2|3fs/UFS, а так полный штиль и отсуствие новых идей... P.s. никто мне не объяснит за каким хреном aspack выполняет следующий код? (edi указывает на начало первой, еще не распакованной секции) push dword ptr [edi] mov byte ptr [edi], 0C3h call edi pop dword ptr [edi] это просто мусор для отвода глаз или...?
Крис, к чему ты про колеса говорил? ) Это 'fake-OEP-trick', для распаковщиков, которые ждут момента передачи управления в первую секцию.
_BC_ вот я и говорю - колеса. под ними очень тяжело работатать. клавиатуру приходится находить буквально на ощуп. сознание как в дыму. а иначе - глюки. птицы там всякие... тем не менее, предложенный мной способ __работает__ (проверено на свой шкуре), первой "жертвой" стара армила. я просто поразился как быстро gcc выбил весь пух нах. Харон говорил, что gcc может оптимизировать и асмовый код (если его перевести в at), но у меня он ниихрена не оптимизируюся... то есть абсолютно. все остается как есть. может кто знает как и чем оптимизировать асмовый код? "Оптмизировать" - удалять избыточность, вносимую обфускаторами... спасибо за 'fake-OEP-trick'! я так и чувстовал, что здесь это не спроста, ночей не спал, но не мог догадаться. кстати, на "мой" (ну условно "мой") способ поиска oep этот трик не распростаняется вот потому я и не мог понять - что это такое. Quantum забыл отписать на счет глобальных флагов. нет, это исключено. при преобразовании asm'а в си мы _все_ ячейки памяти из user'а объявляем локальными переменными, что гарантирует _непротиворечивость_ и компилятор может отследить все ссылки. это работает на все 100%.
EvilsInterrupt Таких примеров полно на линуксовых форумах. Моя прога не опенсорсная... Если очень надо, могу предоставить, но только приватом. n2k Не знаю, что значит "at". Возможно, под оптимизацией поразумевается гибкость в использовании extended assembler. Ячейки памяти из user'а = секции данных в эльфе? Идея не ясна, IMHO.
IceStudent угу, синтаксис "ихнего" асма, что делается проще паренной репы, но вот код не оптимизируется ;( Quantum идея в том, что если переменные будут глобальными, то компилятор не будет оптимизировать их, т.к. не уверен, что смог отследить все обращения, а вот локальные переменные - он остлежививает! следовательно, при трансляции из асма в си, необходимо выделить в стеке большой блок, который будет представлять нашу память. в него мы будем класть как стековые данные, так и "глобальные" переменные. иначе компилятор не справится...
n2k GCC передаёт ассемблерные вставки gas'у, а gas, как адекватный ассемблер, не вырезает избыточность и т.п. Вся оптимизация должна происходить на уровне IL. Может быть, разработчики GCC не читали классиков и воплотили какую-то оптимизацию на уровне ассемблерного листинга... Но! Теперь я почти уверен, что под оптимизацией подразумевалось именно то, что пишут по ссылке в предыдущем посте. Extended asm - удобная вещь. Ясно. И это действительно работает или пока только идея на стадии гипотезы?
Quantum что есть сейчас: 1) в качестве трайсера используется ice и olly (соотв. трассируется далеко не все) 2) полученный лог преобразуется в си (пока только базовые x86 команды) 3) си транслируется любым оптимизирующим компилером 4) на выходе мы имеем код, с нехило устраненной избыточностью, который реально проанлизровать за конечное время пока тестировал на армиле. сотни строк сокращаются в одну но! до стадии "работает" необходимо научиться сворачивать циклы, а я пока этого еще не делаю... и трассер нужен нормальный, эмулирующий... хотя... даже простая ручная правка лога трассера в TSEPro + макросы позволяет очень быстро выкинуть весь shit, оставляя только значимый код...
ssx давай! буду благодарен! я просто не в курсе, чем сейчас "дышит" народ и с какими обфускаторами сражается