привет.
5 день не могу сдвинуца с места. у меня все та же проблема с памятью.. что делаю:
1) ставлю хук, загружаю длл в чужой процесс
2) заказываю память (VirtualAlloc. Пробовал и LocalAlloc)
3) DllEntryPoint создает поток который работает в цикле (пробовал также создавать его не только в DllEntryPoint но и в функции хука)
2) как только я выгружаю длл - процесс сразу выдает page fault. т.е. поток должен был работать но память где он находился винда освобождает почему то....вот он и летит :(((( в этом и проблема... я уже не знаю что еще придумать... помогите пожалуйста справица с этой проблемой...
[Win32] Помогите разобраца с памятью пожалуйста10.06.02 13:40 Автор: IgorR <Igor Razin> Статус: Member
Непонятненько.
Пробовал под 2000 - всё работает.
Делаю так: гружу ДЛЛ, выделяю память, копирую туда код функции потока, запускаю его и выгружаю ДЛЛ. Поток продолжает работать.
> привет. > 5 день не могу сдвинуца с места. у меня все та же проблема > с памятью.. что делаю: > 1) ставлю хук, загружаю длл в чужой процесс > 2) заказываю память (VirtualAlloc. Пробовал и LocalAlloc) > 3) DllEntryPoint создает поток который работает в цикле > (пробовал также создавать его не только в DllEntryPoint но > и в функции хука) > 2) как только я выгружаю длл - процесс сразу выдает page > fault. т.е. поток должен был работать но память где он > находился винда освобождает почему то....вот он и летит > :(((( в этом и проблема... я уже не знаю что еще > придумать... помогите пожалуйста справица с этой > проблемой...
VirtualAlloc и LocalAlloc - резервируют память в локальной куче вызывающих их процессов и при закрытии их память 'портится'. В таких случаях пользоваться надо GlobalAlloc'om...Все параметры CreateThread (в том числе и тело lpfn должны находится за пределами осегмента DLL - освобождаемого сегмента)
хм...Дык и зачем тебе эти хуки...для нового трояна?
я, например, пытаюсь создать стандартную кнопку , которая без хуков и перегистрации класса BUTTON регистрирует событие WM_CHAR...
пока неудачно....
до троянов пока рано.
есть идея сделать "добавление" к 98 винде - када можно с помощью нечто подобного таск менеджера прицеплять любой процесс и поток куда угодно....
видмо идея не имеет большого будущего... но фишка интересная... а далее можно и на трояне и хоть на патче к autoexec'у Ж)) всякие вещи лепить
Если уж реч о написаниии трояна то..05.06.02 18:42 Автор: Duxx Статус: Незарегистрированный пользователь
а нахрен огород городить, я реализовал это все проще, смотри, в каждом файле есть таблица импорта, она обычно небольшая, берем находим свободное место в файле, а его там обычно дохрена, ( это чтобы неувеличивать размер exeшника), туда копируем таблицу иморта, и дописываем свой импорт, какую нить библиотечку где наш троян, правим коне чего, и вуаля, я таким образом при старте трояна своего заражал сразу эксплорер, сперва загружал троян вместо шела, изменял explore.exe, кидал в винду библиотечку и все, комп мой, причем далеко некаждый ламер сможет этот троян убить, и еще плюс, все запросы на открытия порта и тп, идут от имени эксплорера, сырцы могу кинуть если интереесно.
[Win32] не трой а бекдор :)09.06.02 19:42 Автор: BXS Статус: Незарегистрированный пользователь
> а нахрен огород городить, я реализовал это все проще, > смотри, в каждом файле есть таблица импорта, она обычно > небольшая, берем находим свободное место в файле, а его там > обычно дохрена, ( это чтобы неувеличивать размер exeшника), > туда копируем таблицу иморта, и дописываем свой импорт, > какую нить библиотечку где наш троян, правим коне чего, и > вуаля, я таким образом при старте трояна своего заражал > сразу эксплорер, сперва загружал троян вместо шела, изменял > explore.exe, кидал в винду библиотечку и все, комп мой, > причем далеко некаждый ламер сможет этот троян убить, и еще > плюс, все запросы на открытия порта и тп, идут от имени > эксплорера, сырцы могу кинуть если интересно.
из соображений корректности:
я говорил не про трой а про бекдор. в этом принципиальные различия. трой - выдает себя за одно а делает еще и другое. а бекдор - это самый обычный бекдор :) которого и не видно.
за предложение разумееца спасибо.
на исходники я бы взглянул чтоб посмотреть как ты работаешь с импортом.
но все же идея нескоко иная была.
во-1, внедряца в эксплорер - это уже старый фокус... если не ошибаюсь еще с чернобыля. посему этот метод уже устарел и его можно теоретически заподозрить/найти итд... короче нужно писать глубже куданть. хорошо бы в кернел. но как правильно замечено на UINC'е - писать в верхние адреса (как раз где висит кернел и юзер.длл) низя ((((
но сам понимаешь что раз незя - то хочеца еще больше :))) к тому же если это реалиовать, то и все библиотеки под рукой!! кроме кернела то собсно ничего и не надо....
во-2, с такой фигней могут быть проблемы на NT и 2000 маздае...
наконец, хотелось написать тулзу которая бы заменила в 98 винде таск менеджер и добавила бы новых фич: добавление/удаление потоков в чужих процессах, перенос потока из одного процесса в другой итд.... но это пока мне представляеца фантастикой...
что касаеца всяких троянов/бекдоров итд:
я не хочу лепить очередной клон чиха и ему подобных...
хочеца для начала написать зверя который бы динамически по памяти гулял и менял свои "несущие потоки"... т.е. из одного процесса в другой ...итд....
я уверен что такое уже реализовано и без меня, но хотелось бы попробовать свои силы...
да и над всякими супер-гипер-мега-турбо-ультра-синхро-анти-хак тулзами постебаца. :))
а следующим шагом было бы полное локальное сокрытие - никаких портов открытых не видно итд...
кстати интересно но я в сети нигде не видел разговоров об использовании мейлслотов для троянов... а кстати очень зря..
для локалки то лучше и не придумать.... хрен ты заметишь что на тебе висит мейлслотовый бекдор.... три порта по дефолту открыты и хосты постоянно чото сливают, пингуют - поэтому активность не заметишь..
а кроме как посмотреть все unnamed objects в системе и размер используемой памяти - хрен ты его поймаешь просто так... (даже мало кому взбредет в голову это делать... и вообще мало наверное кто слышать про мейлслоты...) а если он приаатачен к такому авторитетному процессу как кернел.... :) а если он и называеца типа DispatchObjectWindowHandler или чтонть типа - то уж он там будет год сидеть.. не меньше :)).
короче идей много...
как только смогу чтонть представить на суд публике - скину соответствующую мессагу на форуме.
вот.
но что то я отвлекся...
если не сложно, кинь на мыло сорцы: b-x-s@yandex.ru
сенкс..
[Win32] не трой а бекдор :)10.06.02 04:20 Автор: Duxx Статус: Незарегистрированный пользователь
> VirtualAlloc и LocalAlloc - резервируют память в локальной > куче вызывающих их процессов и при закрытии их память > 'портится'. В таких случаях пользоваться надо > GlobalAlloc'om...Все параметры CreateThread (в том числе и > тело lpfn должны находится за пределами осегмента DLL - > освобождаемого сегмента)
эээээээээ, насколько я помню для win32, нет вообще понятия глобальная память, все делается в контексте процеса, а LocalAlloc и тп, один @#$ недают доступ к глоб памяти, и после убивания процесса память тоже @$нется, ты наверно перепутал с win16, в вин 32 даже нет понятия сегментов, flat модель, или ты имел в виду что то другое ?
У тебя загружаемая Dll грузиться в контекст памяти процесса, тоесть если у тебя будут разные процессы то твоя длл неувидит другую длл из другого процесса, после завершения процесса мастдай освобождает все что с ним связанно, в том числе и все что связано с твоей длл.
Кстати если интересно, 2 процесса могут обмениваться данными тока через map файлы, это так написано в документации, но можно загрузить dll в совместно используемую память, и она будет едина для всех процессов, а не раздельно как в твоем случае, я как то писал прогу для перехвата функции FindFirst ( нужно было спрятать каталог от обзора), там я перехватывал вызов vxd а саму прогу для обработки вызова помещал в dll а саму dll в совместно юзаемою память. Это все было хорошо описанно в книге Мэта Питрека "Секреты системного програмированя в виндовс 95".