Требуется из ring3 подменить путь, который возвращает GetCommandLine в чужом приложении. Ну понятно, инжект, сплайс апи. Но потом приложение вычленяет оттуда путь к своей директории и начинает активно работать со своими библиотеками и файлами. Сталобыть нужно делать спуфинг. Собственно вопрос, что хукать для спуфинга?

NtOpenFile, NtCreateFile, SetCurrentDirectory, LdrLoadDll

Что еще?

-----
Yann Tiersen best and do not fuck

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

Насколько я помню, путь берётся из служебных структур, типа пеба (лучше проверить это, могу и ошибаться). Не лучше ли сразу там перерисовать путь и всё?

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

Archer пишет:
Насколько я помню, путь берётся из служебных структур, типа пеба

Да, простой отладкой GetCommandLine можно в этом убедиться, далее патчим адрес там без всяких сплайсов.

-----
Stuck to the plan, always think that we would stand up, never ran.

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

Вопрос не в том, как подменить путь, это не проблема. Вопрос какие апи похукать, чтобы после этого приложение нормально работало.

Т.е. например такой код.

LoadLibrary(ExtractFilePath(GetCommandLine)+'test.dll')

После подмены пути test.dll не загрузится, но если похукать LdrLoadDll и заменить путь на старый, то код отработает нормально.

Т.е. суть в следующем. Нужно для GetCommandLine вернуть несуществующий путь, но при этом во всех апи реплейсить путь на валидный.

-----
Yann Tiersen best and do not fuck

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

Замена пути в пебе сработает только для GetCommandLine, а вот LoadLibrary если не находит по указанному пути библиотеку начинает перелопачивать все директории в пебе.. в поисках файла с указанным именем, помоиму так...
Вот описалово в MSDN --> LoadLibrary Function <--

-----
aLL rIGHTS rEVERSED!

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

PE_Kill
SetCurrentDirectory можно вызвать из процесса (из внедренной длл например)

или самому создавать процесс через CreateProcess с нужной директорией в параметрах

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

GetCommandLine


[YYYY] = XXXX

что если просто подменить XXXX в чужом приложении ?

-----
Nulla aetas ad discendum sera

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

Есть такая идея, нужно запатчить (или указатель модифицировать, что более правильно) GetCommandLine так, чтоб при вызове генерировался иксепшн. Далее добавив векторный обработчик, ловим его и производим раскрутку стека, чтоб определить, откуда шёл вызов. Далее уже решаем, что делать - либо подменить строку GetCommandLine, либо продолжить нормальное исполнение. Как говорится, для этого код GetCommandLine желательно бы отморфить (вау, я заюзал этот термин! ) Но можно и не морфить, это уже как кому нравится.

-----
Stuck to the plan, always think that we would stand up, never ran.

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

Если я правильно понял постановку задачи, то действительно для достижения ее достаточно перехватывать NtCreateFile с постобработчиком: если NtStatus будет "файл не найден", то подменяем путь на нужный и повторяем открытие. В итоге получается правильный хендл, который затем виндой используется для мапирования образа dll в процесс.

Вопрос: зачем так сложно? Можно немного упростить задачу, по-моему: подменяем действительные пути dll-ок на нужные нам сразу. Или я чего-то не понял?

-----
IZ.RU

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

PE_Kill
The search path can be altered using the SetDllDirectory function. This solution is recommended instead of using SetCurrentDirectory or hard-coding the full path to the DLL.

Вот что мелкомягкие советуют для либ, но для файлов такой удобной АПИ нет, так что никуда не деться тут от раскрутки стека, правда, даже она не поможет, если командная строка берётся один раз, сохраняется, а дальше только юзается. Хм... надо подумать...

OnLyOnE
тут не начинает перелопачивать, т.к. задаётся полный путь.

-----
Stuck to the plan, always think that we would stand up, never ran.

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

Ладно, я видимо не правильно описал задачу. Давайте я ее перепишу заново.
---------------------------------------------------------------------- --------------------------------------------
Есть софт. Софт имеет в своей папке кучу файлов, базы данных, библиотеки. Файлы и база зашифрованы хешем от файлового пути, где лежит исполняемый файл софта.

Т.е. что то типа того DecryptBaseByKey(md5hash(GetCommandLine)) таким образом, чтобы софт работал в другой папке, нужно чтобы хеш был всегда одинаковый, а этого можно добиться 2 путями.
1) Запатчить получение хеша
2) Подменить текущий путь на старый

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

Поэтому мне нужен второй вариант. Но если мы подменим путь, то программа перестанет работать, т.к. использует абсолютные пути для доступа к файлам. Пример с LoadLibrary я показал выше. Так же она открывает свои файлы и базу, т.е. нужен спуфинг путей. Установка фильтра только на NtCreateFile как посоветовал DenCoder не поможет, т.к. еще есть такие апи как FindFirstFile, которые юзают NtOpenFile.

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

ARCHANGEL пишет:
Вот что мелкомягкие советуют для либ, но для файлов такой удобной АПИ нет, так что никуда не деться тут от раскрутки стека
Программа дергает GetCommandLine всего 2-3 раза и сохраняет путь в памяти, поэтому ни о какой раскрутки речи быть не может. SetDLLDirectory тоже не поможет так как используется полный путь к DLL. Да и речь то не об этом, решение - спуфинг, вопрос - какие апи хукать?

-----
Yann Tiersen best and do not fuck

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

PE_Kill пишет:
решение - спуфинг, вопрос - какие апи хукать?

NtQueryDirectoryFile ещё. Так, вроде, всё.

Но мне кажется, что можно и без дровины. Смотрите, т.к. "Программа дергает GetCommandLine всего 2-3 раза и сохраняет путь в памяти", то вы заранее можете узнать, какой по счёту вызов заполнит буфер адреса, который нужно спуфать (даже если нет, то аппартников 4, так что их хватит покрыть все вызовы). Далее, на первый дворд ставим аппаратный бряк, отладочные иксепшены перехватываем внутри VEH. Когда произойдёт нужный останов, мы можем узнать адрес буфера, куда запишется параметр командной строки. Теперь переносим аппаратник на его первый дворд. А далее всё проще - как бряк сработает, смотрим, откуда вызов - если EIP указывает внутрь системных модулей, то подделываем значение буфера, если нет - передаём настоящее. Неудобным моментом тут является поиск буфера, в который будет производиться запись. Придётся юзать дизасм. Если после этого я вас не убедил, и вы хотите юзать спуфинг, то больше приставать с этой реализацией не буду.

-----
Stuck to the plan, always think that we would stand up, never ran.

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

PE_Kill пишет:
T.е. что то типа того DecryptBaseByKey(md5hash(GetCommandLine))
Ну единственное что приходит на ум это делать на хуке проверку,если например вызывается GetCommandLine из ехе файла вернуть нужный путь а остальные вызова игнорировать и исполнять в штатном режиме

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

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

ClockMan
Блин, так вызов один раз идёт, заполняется буфер, а потом его копия юзается.

-----
Stuck to the plan, always think that we would stand up, never ran.

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

ClockMan ARCHANGEL правильно сказал, так не выйдет.

ARCHANGEL пишет:
заранее можете узнать, какой по счёту вызов заполнит буфер адреса, который нужно спуфать
Это вилами на воде писано. Может через 3-4 обновления будет 6 вызовов GetCommandLine.

ARCHANGEL пишет:
Когда произойдёт нужный останов, мы можем узнать адрес буфера, куда запишется параметр командной строки.
Как мы это определим? Дизасм rep movsb, mov, push и прочего? Очень не стабильно.

ARCHANGEL пишет:
Если после этого я вас не убедил, и вы хотите юзать спуфинг, то больше приставать с этой реализацией не буду.
Не убедил Я за более стабильные методы без медитации и эвристики. За NtQueryDirectoryFile спасибо.

-----
Yann Tiersen best and do not fuck

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

PE_Kill
> что хукать для спуфинга?
Ничо не перехватывать. Это нубское решение. Но вы ведь товарищь срёте кирпичами, посему внятного решения не будет, я тока поржу с вашего обсуждения

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

Clerk я тебя лично забанил. За оскорбления участников форума, нецензурные выражения и срач в топиках.

-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным: Enigma, Alchemistry, Coderess, ntldr, OnLyOnE

PE_Kill пишет:
Что еще?

Возможно понадобится еще:

ZwFullAttributesFile
ZwQueryFullAttributesFile
ZwDeleteFile

Менее возможно:
ZwCreateSection
ZwOpenSection

а вот SetCurrentDirectory, LdrLoadDll как раз и не нужны, потому что
SetCurrentDirectory - работает через ZwSetVolumeInformationFile которая получает хэндл от ZwCreateFile и ZwOpenFile (которые ты и так хукаешь), и LdrLoadDll использует ZwCreateFile/ZwOpenFile - ZwCreateSection - ZwMapViewOfSection, т.е. тоже все упирается в перехват открытия файла

Добавлено:
бл.. еще
ZwQueryDirectoryFile - используется как раз для энумерации файлов

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

интересно, а можно ли попробовать: в GetCommandLine всегда возвращать нужный фиксированный путь, а для ZwCreateFile взвести флаг поиска альтернативных путей и в Enviroment запихнуть текущий реальный путь. Или я в чем-то ошибаюсь?

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

А запускаться приложение под какой ОС будет? Если админские права и ntfs, то можно просто не заморачиваться, а сделать ему нужную директорию с путем через symlink.
http://en.wikipedia.org/wiki/NTFS_symbolic_link

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

Вместо кучи хуков предлагаю перехватить KiFastSystemCall и дергать из него номер сервиса.

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

Хорошая идея, а как узнать номер сервиса? Дизасмить? Не помню точно, но по моему под win 7 немного по другому вызовы сервисов выглядят.

gloomdemon всё что я знаю, это то, что запускаться будет на NT системах, больше ничего. Т.е. файловая система может быть и фат.

ADD
Сейчас подумал, если я буду хукать KiFastSystemCall то эмулировать то я буду всё равно только нужные API. Тогда железно получить номера севисов можно просто поставив хук на KiFastSystemCall и дернуть по очереди все эмулируемые апи, так соберется табличка всех нужных номеров сервисов.

-----
Yann Tiersen best and do not fuck

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

PE_Kill пишет:
Ну понятно, инжект, сплайс апи.
Может обойдется хуком импортов в самом приложении? Тогда не придется отличать вызовы поступившие из приложения от вызовов из системных библиотек.

Enigma пишет:
Возможно понадобится еще:ZwFullAttributesFile
Если приложение не использует напрямую ZwXXX, то не надо их трогать. Лучше перехватить побольше API верхнего уровня.

Alchemistry пишет:
Вместо кучи хуков предлагаю перехватить KiFastSystemCall и дергать из него номер сервиса.
Решение неадекватно задаче. Задача - сделать лоадер для проги, а запускать эту прогу могут в любой ОС вплоть до вайна, сталобыть хукаем то, что гарантированно есть и 100% документировано.

Список апи навскидку: GetCommandLine, LoadLibrary, LoadLibraryEx, CreateFile, GetFileAttributes, FindFirstFileб. Возможно еще потребуются CopyFile, MoveFile, DeleteFile. Все функции в A и W вариантах. Список велик, но оно не так страшно как кажется, потому что 95% обработки одинакова во всех случаях и сами обработчики функций будут невелики. Тут работы на пару часов.

-----
PGP key <0x1B6A24550F33E44A>

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

ntldr пишет:
Может обойдется хуком импортов в самом приложении?
Там еще используется старт DLL из памяти, и в этих DLL тоже есть проверки.

-----
Yann Tiersen best and do not fuck

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

PE_Kill пишет:
Там еще используется старт DLL из памяти, и в этих DLL тоже есть проверки
5 шт вполне хватит:
LdrLoadDll, NtOpenFile, NtCreateFile, NtQueryInformationFile, NtQueryDirectoryFile

-----
продавец резиновых утёнков

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

HiEndsoft
Нет, ntldr прав. Мы не знаем где, под чем будет запускаться эта программа. Это могут быть различные эмуляции, как уже сказали типа wine. Ваш харкод угробит лоадер. Имхо действительно оптимальным является хук высокоуровневых апи, которые гарантированно присутствуют везде и их поведение документированно и предсказуемо.

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

HiEndsoft посмотрел делфишную FileExist() она юзает GetFileAttributes->NtQueryAttributesFile

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

-----
Yann Tiersen best and do not fuck

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

PE_Kill пишет:
Там еще используется старт DLL из памяти, и в этих DLL тоже есть проверки
Если защита не ищет апи вручную, то хука GetProcAddress в импорте будет достаточно. Зато мы не трогаем код и получаем +1 к совместимости с антивирусами и прочим, что может ставить хуки.

-----
PGP key <0x1B6A24550F33E44A>

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

Т.е. предлагаешь откинуть сплайс и пофиксить табличку импорта у exe и всех его DLL? А как быть подгружаемыми DLL? Т.е. exe дергает LaadLibraryA, допустим мы похукали ее и знаем что грузится DLL. DLL этого софта, там на DLL Main есть проверка на текущую директорию. Мы можем пофиксить импорт только после загрузки DLL, получается пролет.

-----
Yann Tiersen best and do not fuck

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

Тогда фиксим экспорты у системных DLL. Результат тот-же. Сплайс плох тем, что неизвестно сглючит или нет если кто-то засплайсит сверху (зависит от кривости чужого кода).

-----
PGP key <0x1B6A24550F33E44A>

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