Injected DLL

Уважаемый, вы вообще куда-то не в ту степь... Читайте внимательно мой вопрос... Мне именно экзешник нужно было пропатчить, чтобы он мою dll грузил, вызывал её функцию dllmain, в которой я уже что хочу, то и творю, заставляя т.о. посторонний экзешник выполнить то, что мне нужно! Как это сделать, не штудируя PE формат, я не знаю... Если вы такой мегамозг, подскажите! Хотя задача уже и так решена...

 

HelloweenStranger
ваши сообщение полны гнусного настроя по отношению к товарищам = негодно!

положите свой длл рядом с таргет ехе в папке и назовите его UxTheme.dll, например.

 

Прошу заметить, что не ко всем, а к тем, у кого такой настрой по отношению ко мне. Ага, хороший способ, а внутри dllmain делать LoadLibrary("C:\\WINDOWS\\system32\\uxtheme.dll"), ну или другой путь, не суть в общем... Только вот первый же экзешник, над которым так подшутили, к слову firefox, почему-то crash report захотел отправить... Как-то не гламурно ни разу... )))))))))))

 

Внутри дллмайн какбэ не рекомендуеца юзать всякие лоадлибрейр'ы, креатпроцесс'ы и прочие креаттред'ы с лдрлоаддлл'ами и всеми негодными функциями из юзер32.
А пробовать загрузить из своей дллмайн саму себя в свое адресное пространство тут любая длл опупеет, а каждый кто увидит такой кодес просто чокнеца.
Такчто, таки да, крешили, крешим и будем крешить пока не перестанем путать нтдлл с пе-форматом.
ПС: прочитайте пожалуйста внимательно мой ответ два раза прежде чем опять называть меня бездушным гадким поцыфистом.

 

Во-первых, LoadLibrary как и CreateProcess находится в kernel32.dll, которая, что касается того же firefox, в зависимостях есть, а uxtheme.dll нет. Следовательно загрузка kernel32.dll происходит раньше, нежели uxtheme.dll, что подтверждает и тот факт, что LoadLibrary("C:\\WINDOWS\\system32\\uxtheme.dll") корректно отрабатывает. Во-вторых, когда я свою библиотеку обозвал как uxtheme.dll и положил к firefox, который у меня лежит в D:\Program Files\Mozila... blablabla, то она грузится по своему предпочтительному базовому адресу, а не по prefer image base системной uxtheme.dll. Когда происходит вызов LoadLibrary("C:\\WINDOWS\\system32\\uxtheme.dll"), образ грузится уже из файла в system32 по prefer image base системной uxtheme.dll, а не из Program Files, поэтому "А пробовать загрузить из своей дллмайн саму себя в свое адресное пространство тут любая длл опупеет, а каждый кто увидит такой кодес просто чокнеца." вы вообще не в тему брякнули, умник. )))))) И да будет вам известно, если в dllmain какой-либо библиотеки написать что-то наподобие MessageBox(blablabla), то в depends данной библиотеки появится USER32.dll, поэтому, даже, если наша библиотека будет прописана в разделе импорта "таргет exe" раньше USER32.dll, то перед вызовом dllmain нашей библиотеки загрузится USER32.dll, и вызов MessageBox из dllmain завершится корректно!

Что я и говорил, каждый прыщавый малолетка, строящий из себя хакера, может только говно лить на форуме, в то время как компетентные люди дают совет, из которого всё сразу становится ясно, и не строят из себя Касперского!

 

HelloweenStranger
в длл_меин думаю стоило бы поменять путь к своей длл в PEB_LDR_DATA,а то фаерфокс чот там шаманит лоад_либрари и т.п., видать изза того что фейкдлл первая грузиться он там адресс ищет и колает его, не разбирался но когда кернел32 скопировал\переименовал и положил фоксу в папку он крешиться при попытке кольнуть 0 адресок, видать проверки не сделали при получении экспортируемых фунок.
Ну и подгружать ничо не надо самому, темболее в ДллМеин.

 

Я вам сказал прочитать мой предыдущий пост два раза, похоже я вас переоценил, перечитайте есчо пять раз.

 

Если не из dllmain, то в любом случае каким-то макаром исходную библиотеку, под которую мы нашу закосили, грузить надо. Всё-равно с бубном плясать. Куда лучше со всех точек зрения залезть в таблицу импорта и прописать там свою dll, обозвав её как-нить умно, чтобы у конечного пользователя создалось впечатление, что библиотека по зарез нужна экзешнику, а не просто активирует этот экзешник через инет. ) Эту проблему я решил, но появились новые, примерно половина заражённых экзешников перестают запускаться корректно, но это, я думаю, уже с каждым экзешником конкретно разбираться, что ему не нравится.

 

да не надо ничо грузить(в варианте с ух_тема) - само там все прогружаеться. Вы за альтернативные варианты спрашивале - вот и сказал самое простое. А чо ехе не запускаються - видать чот вы там партачите - олькой вам в помощь

 

Прыщавый хэккер-малолетка в лице ТрещГена зоявляет: опишите способ, которым вы изменяете импорт в испытуемом ексе и мы предположим вам почему это происходит

 

Ну есть предположения, где косячу... Скажите, когда заполняем новый IMAGE_IMPORT_DESCRIPTOR, обязательно ука-зывать и OriginalFirstThunk и FirstThunk?.. Я обхожусь только указанием FirstThunk, может в этом и косяк?..

 

TrashGen

Изучайте свойства критических секций. LdrpLoaderLock - кс, и как всякая кс поддерживает рекурсивные вызовы из текущего потока. Посему LoadLibrary() из InitRoutine отработает без проблем.

А с шадовом может быть только одна проблема - деадлок в InitRoutine изза вызова его другим тредом. В остальном шадов никакого отношения к ntldr не имеет. Можите вызывать всё что угодно.

HelloweenStranger
Прекрати трепаться и иди изучай PE-формат. Если вы не знаете как работает RtlImageDirectoryEntryToData(), тоесть не понимаете разница между VirtualSize и RawSize, то о чём есчо можно говорить.

 

Эту разницу я прекрасно понимаю, и на основе исходников RtlImageDirectoryEntryToData() писал обратную функцию перевода fileoffset -> RVa, и она замечательно работает, так что, если тебе нечего делать, не делай этого здесь.

 

HelloweenStranger & gaeprust
почему вот только двое таких умных, духовно богатых и интересных парней есчо не на wasm@conference.jabber.ru?
Такие глобальные вопросы нужно решать в реалтайме, а то тут на пять лет растянеца обсуждение!

 

А вообще, пришел инде и всем раздал по матчасти. Все как обычно

 

gaeprust

как всегда, блиа/тонкости - надо мс по новой почитать по поводу длл_маина, да и повнимательней - чо они там угрожали.

ну и чо там вышло? - каким макаром вы преобразовываете адресочки?

 

В одну сторону: RtlImageRVaToVa, обратно: написал аналогичную функцию. Примерно так:

Code (Text):

1. PIMAGE_SECTION_HEADER NTAPI InternalRtlDataRvaToSection (PIMAGE_NT_HEADERS NtHeader,
2.                                                                 ULONG   Rva)           
3. {
4.     PIMAGE_SECTION_HEADER Section;
5.     ULONG InternalFileOffset;
6.     ULONG Count;
7.  
8.     Count = NtHeader->FileHeader.NumberOfSections;
9.     Section = IMAGE_FIRST_SECTION(NtHeader);
10.  
11.     while (Count--)
12.     {
13.         InternalFileOffset = Section->PointerToRawData;
14.         if ((InternalFileOffset <= Rva) &&
15.             (Rva < InternalFileOffset + Section->SizeOfRawData))
16.             return Section;
17.         Section++;
18.     }
19.     return NULL;
20. }
21.  
22. PVOID NTAPI InternalRtlDataRvaToImageRva (PIMAGE_NT_HEADERS     NtHeader,
23.                                             ULONG   Rva,
24.                                             PIMAGE_SECTION_HEADER *     SectionHeader)
25. {
26.     PIMAGE_SECTION_HEADER Section = NULL;
27.    
28.     if (SectionHeader)
29.         Section = *SectionHeader;
30.    
31.     if (Section == NULL ||
32.         Rva < (Section->PointerToRawData) ||
33.         Rva >= (Section->PointerToRawData) + (Section->SizeOfRawData))
34.     {
35.         Section = InternalRtlDataRvaToSection(NtHeader, Rva);
36.         if (Section == NULL)
37.             return 0;
38.    
39.         if (SectionHeader)
40.             *SectionHeader = Section;
41.     }
42.    
43.     return (PVOID)(ULONG_PTR)(Rva - Section->PointerToRawData + Section->VirtualAddress); // ImageRva
44. }

ImageBase не передаю, так как передаётся Rva.

 

HelloweenStranger

и ни с того ни с сего смысленно стало.

 

Так канешна станет тут ежеле в есходном тексте то так нописано. Свое чтоле ТС чо выдумает без знания и желания знать РЕ то?

 

TrashGen

Ага, а то тут вам разгуляться не дадут.... Матом ругаться и фигачить по 10 раз одно и тоже нельзя... трудновато вам тут....