Есть программа, которая инжектирует свой код в svchost.exe Выполняет в нем какой-то код, а потом выполняет действия наподобии этих: Code: char * szData = (char *) malloc(GetFileSize(hFile, NULL)); ... free(szData); Так вот работает все отлично, но как только доходит до выделения памяти выкидует сообщение о ошибке и просьбе отослать отчет в Microsoft. Кто знает с чем связано?
>>Есть программа, которая инжектирует свой код в svchost.exe ну да, код может и инжекцируется, но вы уверенны, что хэндл hFile имеет место быть в процессе svchost? если нет, то malloc'у передастся -1. не хочется разбираться почему, но malloc возвращает не NULL на -1, однако очевидно, что память такого размера выделиться не может и первые четыре байта до возвращаемого указателя совсем не размер содержат...
Гыыы) Дело в CRT-шных malloc'ах и free'хах)) Code: void *new_malloc(size_t size) { return HeapAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,size); } void new_free(void *p) { HeapFree(GetProcessHeap(),0,p); } при инжекте в процесс многие ф-ие CRT использовать не получится а вообще, автор, отладчики ведь придумали не просто так PS HeapAlloc, HeapFree - это в NT на самом деле экспорт-форвардинг на ntdll.RtlAllocateHeap и соотв. ntdll.RtlFreeHeap. как и getlasterror=RtlGetLastWin32Error
Зако тоже не любит отладченки походу. Для чего нужна инициализация CRT? Вот оно инициализивалась, особенно куча тек. процесса получилась, и тут вдруг кусок кода идет в совсем другой процесс со своей кучей. Подробнее - см. дизасм malloc() и free(). Это примерно тоже, что получить хендлы, справедливые только в текущем процессе (открытые объекты "файл", к примеру) и инжектнуть код, с ними работающий, в другой процесс, удивляясь, почему не работает. А в crt как бы нет ориентировки на то, что её будут хакеры использовать в целях инжекта в бедный svchost
2KEZ ну это ясно. только не понятно зачем ты щас конретизируешь кучу, ведь изначально ошибко кроется в том, что нельзя инжектить код, который использует "родные" адреса для вызова дальних jmp или call. ну в общем-то да, вот только тогда не понятно как автор решил инжектить код со своими адресами.. ахх, если бы винду собирали с crt автору при удачном стечении обстоятельств было бы попроще
Все адреса при инжекте остались родными) В svchost выделили нужные адреса, скопировали туда свой образ целиком (автор, я телепат??) и запустили нужную ф-ию. Проблема не в jmp или call. С джампами и колами - это другая проблема, их надо релочить. А тут - косяк чисто в CRT. Достаточно посмотреть шаги работы malloc(). Помниться, когда я только узнал про инжект в процесс, у меня была точно такая же проблема. хз почему ты так решил
>>В svchost выделили нужные адреса >>Так вот работает все отлично, но как только доходит до выделения памяти выкидует >>сообщение о ошибке и просьбе отослать отчет в Microsoft. не знаю, имхо код был просто скопирован
> не знаю, имхо код был просто скопирован При инжекте у ТС с текущего процесса в адресное пространство другого по _одинаковым_ адресам копируется какой-либо код/+данные/+етц иначе все слетело бы ещё задолго до вызова malloc() о чем тут спорить можно ? : DDD
Почему, есть инструкция call, адресующая функцию относительно текущего EIP, она кстати и используется, данные все можно формировать на стеке, api функции подключать в ходе выполнения...
Не от EIP, а от своего месторасположения. что тут написано и как это относится к бедному razzzar, которому уже все давно объяснили - я пока ещё не понял есть большой кусок кода, сгенерированый компилятором, который при перемещении в другой процесс надо либо релочить, либо перемещать на тот же VA, где он и должен быть в процессе, либо записывать его VA-независимым, например, вместо call [addr] делать mov eax,[addr]\call eax. тут, вроде как, неочем спорить больше.
"от своего месторасположения" это как? 0xE8 опкод инструкции вызова функции, адрес функции вычисляется как EIP + операнд. Ну а почему именно такие варианты? Что мешает не использовать абсолютных адресов, формируя все данные на стеке (а глобальные переменные вынося в динамиечкую память, выделяемую уже в контексте "проинжектинного" процесса, подгружая все системные функции на лету и прыгая с функции на функцию 0xE8 call'ами (или вообще не прыгая, а делать все в __inline)
Это так, что можно вычислять как EIP+операнд в момент выполнения CALL, а можно - в общем случае - адрес инструкции CALL + её операнд. Так как заранее известно, каким будет EIP в момент выполнения инструкции (когда она где-то расположена в виртуальной памяти) - думаю, уж можно сказать, что адрес процедуры будет равен адресу инструкции CALL + её операнду. Да, процессору все равно что и где там расположено, но с точки зрения чисто-человеческой логики, можно сказать про адрес инструкции call, а не про EIP в момент её выполнения, который, по сути, является тем же самым. Ладно, ок, от EIP зависит - это правильно. ну и?)) e8 call то должен быть расположен либо там, где и был, либо его надо корректировать. это и есть "использование абсолютных адресов" Компилятор мешает. Я уже сказал, что можно использовать базонезависимый код - ты как раз и говоришь про такой. Который будет где угодно выполняться. Да, да, это формирование в стеке, глобальные данные в куче, может быть замена call mem на mov reg,mem\call reg и т.п. неудобства. Как видно по первому посту в топике - компилятор c/cpp. Вот он, к примеру, очень часто будет ставить свои __CRT_CheckESP и тому подобное. И ещё много чего делать будет. Про __inline - без комментариев, это явно тут "ни приштопай ни пришей". А так, если самому писать код - да без проблем, можно полно всего придумать.
Этого я так и не понял, почему? В непосредственном операнде стоит только смещение и ему глубоко фиолетово какой там EIP, если код весь копировать монолитно, что видимо является единственно-адекватным решением, все будет работать по любым адресам. Кстати, чтобы call'ы имели такой вид, на сколько я понял, извращаться ненужно, я, например, смог получить call по абсолютному адресу только для 0xFF call'а при вызове функции через функциональную переменную (Borland C++), но что-то мне подсказывает что на MSVS тоже самое.
> Этого я так и не понял, почему? А релоки в длл придумали просто так? Проблема в том, что каким-то инструкциям нужна VA, а каким-то - смещение, относительно EIP. Поэтому - либо релочишь колы и джампы, либо mov'ы и все остальное. Как у тебя CRT инициализируется с таким кодом: ? где _osplatform == 0x42AF20 перенесешь код - будет уже совсем неправильный адрес.
