Всем привет! Появилась необходимость написать свой собственный криптор. Все вроде ничего работает на программках, но, блин, не на инсталлерах. Трабл состоит в том, что при запуске инсталлера, он открывает свой исполняемый файл (который само сабой уже закриптован) и не найдя в нем необходимой для себя информации, завершает свою работу, что является абсолютно логичным. После 2-х дней раздумий над тем как это можно решить, пришло в голову только 2 мысли: 1) перехватывать все вызовы winapi на открытие и чтения файлов. Тут при попытки открыть файл вставить проверку на открытие самого себя и дальшей дешифрации всего содержимого при попытки прочитать. Данный путь на мой взгляд неверный, т.к. много гемороя, трудно реализуем + увеличивается размер криптованного файла. 2) создавать временный файл при запуске, кидать туда расшифрованное содержимое и запускать. Ну это уже совсем попахивает идиотизмом. Вот собственно и решил написать сюда. Те кто решал такие задачи, натолкните пожалуйста на мысль как решить данный трабл.
Вроде как почти все современные джойнеры файлы кидают в оперативку и оттуда запуцскают, можно в этом направленни посмотреть, но все равно это будет уже расшифрованный файл, АВ ругаться будет. Я бы лучше криптовал файлы, лежащие внутри инсталяхи, а потом уже не палящиеся пихал в инсталяху. Так проще, да и расшифровка кучки маленьких файлов куда быстрее расшифровки одного большого.
Ну по поводу оперативки щас так он и работает: лоадер дешифрует секцию, кидает ее в оперативку правильным образом и передает управление. ))))) На счет того, что авирем палиться будет - скорее всего блин, так что тут работать надо. Но в любом случае исполняемый код должен быть дешифрован (ну или есть второй вариант писать своеобразную среду выполения). По поводу того, что криптовать каждый файл отдельно в инсталяторе то тут вот чего: по сути это билд вирька, и при его запуске начинает работать своеобразный инсталятор: дешифрует сам свой код, пихает в нужное место + автозапуск)))))))))))))))) Так что данный вариант не работает тут. Но все равно спасибо. Как говориться спроси у сотни людей, а потом подумай)))))))
Лучше сразу забить на тему криптования инсталляторов. Что если инсталлятор или какая нибудь другая программа проверяет целостность своего исполняемого файла? Что делать в этом случае? Возьми UPX и попробуй запаковать им свой инсталлятор. Если все будет нормально работать - изучи исходный код UPX, чтобы получить ответ на свой вопрос.
Спасибо за ответ! UPX уже пробывал в самом начале разработки криптора, но жрать этого вирька он отказался (типа инвалид заголовок)((((( Поэтому забил на него. Кстати, очень интересная штучка: на целосность он себя не проверяет, т.к. изначалько это вирь, который необходимо криптовать. Если из моего криптора убрать нафиг шифрацию сегемента , а все остальное оставить (т.е. лоадер, и сегмент добавленный с вирьком), то все воркает блин. Дебажил, и узнал, что он в своем коде сам что-то пытается дешифровать (что пока не понял), но т.к. уже исходные данные ему на дешифровку поступают левые, все обламывается. Кстати, если кто-то криптовал допустим зевса, то он там делает чего-то подобное (дешифрует чего-то по RC4). Если есть кто с опытом его криптования, расскажите плиз, если не жалко ....
У тебя точно инсталлер открывает себя именно как файл? Он не ресурсы в себе ищет случайно? Потому что если ресурсы, тогда ясно, куда смотреть. А вообще, сейчас прячущий от АВ криптор тяжко написать. Я пробовал - у меня не получилось, палят эвристикой все время, даже без полезной нагрузки, т.е. сам лоадер.
Могу попробовать прогнать через последний The Enigma Protector. Думаю должно помочь) P.S. кидайте ссылку в приват чтобы увидел.
СофтАйс для снятия криптора это слишком - не для того он предназначен, а вот OllyDebug вполне справляеться с задачей. Я не знаю зачем пользоваться турбо дэбаггером (кроме случаев мс-досности проги естесвенно - там он крут), когда есть бесплатные удобные конкуренты Та и не поверю я что изъебнуться нельзя даже в самом деревянном отладчике - какимнибудь патчингом начальной инструкции нужной функции - костыли, но иногда приходиться.
D4rkC10ud, не ведаю, какие у тебя конкретные задачи. но свои, с прогами нужными и повседневными, решил именно с ТурбоДебаггером. SoftIce - громко сказано. есть проги и проще и быстрее. но работать со стеком D4rkC10ud всё же не умеет.
Как дополнение к высокоуровневому языку ТД неплох, конечно же. Кто тут о стэке вообще говорил? Не всё что серое - волк. Самомодифицирующийся код не обязательно будет в стэке. Как вариант можно еще в секции атрибуты изменить. Все эти фичи со стэком теперь не канают из-за, DEP/ASLR - http://en.wikipedia.org/wiki/Data_Execution_Prevention и может и не умею, но только сегодня об этом узнал. Век живи - век учись. Кстати, регистр SP был на 16-разрядных компах и сейсчас в режиме совместимости.
Решение проблемы оказалась намного проще чем я мог предположить))))))) Я подсчитал суммарный размер всех секций и за метил, что он меньше размера самого файла. Оказалось, что в конце виря, запихан оверлоад, который он и пытался считать при распаковки. Выход - просто не шифруем этот код. Вот и все))))))))))))
не-а. операции в стеке - исполняются в нативном режиме х86 линейки. теперь узнай, какой компилятор у NVidia CUDA.
