Есть ли отлаженные способы загрузки, чтоб и импорт был нормальный и под разными операционками работало?
Поиском посмотрел — есть несколько вариантов, но потом находились баги, и всё как-то затихало, непонятно, было пофиксано или было брошено?
Меня сёдня ещё такая идея посетила: ведь LoadLibraryExW (а именно она зовётся в конце концов, что бы мы ни звали, смотрел сейчас под дебагом) должна же обратиться к файлу, открыть его и зачитать? Хорошо бы в этот момент ей подсунуть свои данные Проблема в том, что ReadFile не перехватить, он в одном модуле с LoadLibraryExW
CEM>Есть ли отлаженные способы загрузки, чтоб и импорт был нормальный и под разными операционками работало? CEM>Поиском посмотрел — есть несколько вариантов, но потом находились баги, и всё как-то затихало, непонятно, было пофиксано или было брошено?
CEM>Меня сёдня ещё такая идея посетила: ведь LoadLibraryExW (а именно она зовётся в конце концов, что бы мы ни звали, смотрел сейчас под дебагом) должна же обратиться к файлу, открыть его и зачитать? Хорошо бы в этот момент ей подсунуть свои данные Проблема в том, что ReadFile не перехватить, он в одном модуле с LoadLibraryExW
LoadLibraryExW (вернее ntdll!LdrLoadDll) вызывает NtCreateSection с флагом SECTION_IMAGE который собственно парсит имадж и раскладывает его по памяти, далее LdrLoadDll настраивает импорты/экспорты etc.
Так что если захукаете NtCreateSection, предыдущий NtOpenFile и до кучи NtQuerySection и NtAreMappedFilesTheSame и может еще NtQueryVirtualMemory, сами распарсите PE заголовок, как это делает ядро, то настройку импортов/экспортов/PEB ldr листов винда и правда сделает за вас.
Как много веселых ребят, и все делают велосипед...
CEM>Здравствуйте, ononim, Вы писали: CEM>[…] CEM>так я не понял, нормальный способ загрузки есть или нету? я лишь написал теорию реализации самого нормального (с вашей т.з.) способа
есть он или нет.. могу лишь сказать что эта теория прекрасно работает в моем проекте, код выкладывать не стану ибо он проприетарный)
Как много веселых ребят, и все делают велосипед...
CEM>так я не понял, нормальный способ загрузки есть или нету?
нормальных — нет. Для загрузки исполняемого файла обязательно нужен файл на диске. На нем создается секция ( читай: файл отображается на память ). Из этого следует один неприятный момент: если система решит засвопить часть кода ( допустим, он давно не выполнялся ), она не будет использовать своп-файл, а подкачает потом код опять прямо из этого файла ( кстати, это одна из причин, почему нельзя удалять файлы запущеннных приложений ) и всякие патчи и другие глупости утеряются. Вот от этого и надо плясать. По хорошему, надо создавать файл на диске, копировать в него код и запускать с диска. А если по плохому — напиши подробнее, чего хочешь
Здравствуйте, CEMb, Вы писали:
CEM>Поиском посмотрел — есть несколько вариантов, но потом находились баги, и всё как-то затихало, непонятно, было пофиксано или было брошено?
Это не баги, а недоработки с PEB.Ldr. Для некоторых случаев это не нужно, и хватает полурабочих вариантов
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, TarasCo, Вы писали:
TC>[…] По хорошему, надо создавать файл на диске, копировать в него код и запускать с диска. А если по плохому — напиши подробнее, чего хочешь
Ну, мы так и хотели сначала — грузить файл в темп из ресурсов, и потом его грузить как библиотеку. Но подумалось: а прикольно было бы сразу в память! К тому же я давно уже краем глаза видел тот пост про три функции Mem...
Здравствуйте, Сергей Савостин, Вы писали:
СС>Можно попробовать соорудить что-то типа RAM disk, но это все равно, что на обычный диск писать. Я так понимаю Вам нужно скрыть сам факт появления dll?
Не, нужна dll-ка с ресурсами, которая сама подцепляется в проекте как ресурс. Т.е. для удобства разработки — эту dll-ку можно делать в отдельном проекте отдельными людями по написанной методологии.
А так же мы бы решили ещё ряд проблем, связанных с большими блоками ресурсов, которые надо грузить время от времени поочерёдно.
Здравствуйте, CEMb, Вы писали:
CEM>Не, нужна dll-ка с ресурсами, которая сама подцепляется в проекте как ресурс. Т.е. для удобства разработки — эту dll-ку можно делать в отдельном проекте отдельными людями по написанной методологии. CEM>А так же мы бы решили ещё ряд проблем, связанных с большими блоками ресурсов, которые надо грузить время от времени поочерёдно.
так в этой dll-ке нету кода, только ресурсы? тогда по идее все легко решается.
в общем, если надо решение для частного случая, то почти всегда можно это (решение) получить
Здравствуйте, CEMb, Вы писали:
CEM>Здравствуйте, Сергей Савостин, Вы писали:
СС>>Можно попробовать соорудить что-то типа RAM disk, но это все равно, что на обычный диск писать. Я так понимаю Вам нужно скрыть сам факт появления dll?
CEM>Не, нужна dll-ка с ресурсами, которая сама подцепляется в проекте как ресурс. Т.е. для удобства разработки — эту dll-ку можно делать в отдельном проекте отдельными людями по написанной методологии.
Есть такая штука — статически линкуемые библиотеки. Не сгодится случайно?
Здравствуйте, Unhandled_Exception, Вы писали:
CEM>>Не, нужна dll-ка с ресурсами, которая сама подцепляется в проекте как ресурс. Т.е. для удобства разработки — эту dll-ку можно делать в отдельном проекте отдельными людями по написанной методологии. CEM>>А так же мы бы решили ещё ряд проблем, связанных с большими блоками ресурсов, которые надо грузить время от времени поочерёдно.
U_E>так в этой dll-ке нету кода, только ресурсы? тогда по идее все легко решается.
U_E>в общем, если надо решение для частного случая, то почти всегда можно это (решение) получить
CEM>>так я не понял, нормальный способ загрузки есть или нету?
TC>нормальных — нет. Для загрузки исполняемого файла обязательно нужен файл на диске. На нем создается секция ( читай: файл отображается на память ). Из этого следует один неприятный момент: если система решит засвопить часть кода ( допустим, он давно не выполнялся ), она не будет использовать своп-файл, а подкачает потом код опять прямо из этого файла ( кстати, это одна из причин, почему нельзя удалять файлы запущеннных приложений ) и всякие патчи и другие глупости утеряются. Вот от этого и надо плясать. По хорошему, надо создавать файл на диске, копировать в него код и запускать с диска. А если по плохому — напиши подробнее, чего хочешь
CEM>>так я не понял, нормальный способ загрузки есть или нету?
TC>нормальных — нет. Для загрузки исполняемого файла обязательно нужен файл на диске. На нем
Нету?
Тогда вопрос -
Каким образом работают ThInstall и ему подобные тулзы?
Здравствуйте, dmitriy_k, Вы писали:
CEM>>>так я не понял, нормальный способ загрузки есть или нету? TC>>нормальных — нет. Для загрузки исполняемого файла обязательно нужен файл на диске. На нем _>Нету? _>Тогда вопрос - _>Каким образом работают ThInstall и ему подобные тулзы?
Этож очевидно!
Они пользуются "ненормальными" способами
Т.е. осуществляют "закат солнца вручную".
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CEMb, Вы писали:
U_E>>так в этой dll-ке нету кода, только ресурсы? тогда по идее все легко решается. U_E>>в общем, если надо решение для частного случая, то почти всегда можно это (решение) получить
CEM>Не мудри, покажи пальцем
если в dll-ке только ресурсы, то разверни ее в памяти (тут где-то на рсдн есть код на дельфи, но его легко перевести на с++, если надо, вот этот код будет работать), а там уже LoadResource и пр. будут (должны) нормально работать, в качестве HMODULE давай базовый адрес.
Здравствуйте, TarasCo, Вы писали:
TC>Вы рассказываете тут про пакеры/крипторы. Это все очень хорошо, но все равно для работы пакера надо его для начала на диск записать.
ну так код который эту DLL хочет загрузить, на машине пользователя откуда то взялся?
вот вместе с ним пусть приезжает статически слинкованный и не требующией ничего вообще рантайм BoxedApp SDK
(причем каким способом код у пользователя оказался — думаю абсолютно без разницы для данного вопроса)
