информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Сетевые кракеры и правда о деле ЛевинаПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Очередное исследование 19 миллиардов... 
 Оптимизация ввода-вывода как инструмент... 
 Зловреды выбирают Lisp и Delphi 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
если вы видите этот текст, отключите в настройках форума использование JavaScript
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
[Win32] не трой а бекдор :) 10.06.02 04:20  Число просмотров: 1021
Автор: Duxx Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> использовании мейлслотов для троянов... а кстати очень
вот тот мой троян как раз и юзаит маил слоты кстати :)
сырцы скину/
<programming>
[Win32] Помогите разобраца с памятью пожалуйста 02.06.02 06:12  
Автор: BXS Статус: Незарегистрированный пользователь
<"чистая" ссылка>
привет.
5 день не могу сдвинуца с места. у меня все та же проблема с памятью.. что делаю:
1) ставлю хук, загружаю длл в чужой процесс
2) заказываю память (VirtualAlloc. Пробовал и LocalAlloc)
3) DllEntryPoint создает поток который работает в цикле (пробовал также создавать его не только в DllEntryPoint но и в функции хука)
2) как только я выгружаю длл - процесс сразу выдает page fault. т.е. поток должен был работать но память где он находился винда освобождает почему то....вот он и летит :(((( в этом и проблема... я уже не знаю что еще придумать... помогите пожалуйста справица с этой проблемой...
[Win32] Помогите разобраца с памятью пожалуйста 10.06.02 13:40  
Автор: IgorR <Igor Razin> Статус: Member
<"чистая" ссылка>
Непонятненько.
Пробовал под 2000 - всё работает.
Делаю так: гружу ДЛЛ, выделяю память, копирую туда код функции потока, запускаю его и выгружаю ДЛЛ. Поток продолжает работать.
[Win32] Помогите разобраца с памятью пожалуйста 04.06.02 03:57  
Автор: [H] Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> привет.
> 5 день не могу сдвинуца с места. у меня все та же проблема
> с памятью.. что делаю:
> 1) ставлю хук, загружаю длл в чужой процесс
> 2) заказываю память (VirtualAlloc. Пробовал и LocalAlloc)
> 3) DllEntryPoint создает поток который работает в цикле
> (пробовал также создавать его не только в DllEntryPoint но
> и в функции хука)
> 2) как только я выгружаю длл - процесс сразу выдает page
> fault. т.е. поток должен был работать но память где он
> находился винда освобождает почему то....вот он и летит
> :(((( в этом и проблема... я уже не знаю что еще
> придумать... помогите пожалуйста справица с этой
> проблемой...

VirtualAlloc и LocalAlloc - резервируют память в локальной куче вызывающих их процессов и при закрытии их память 'портится'. В таких случаях пользоваться надо GlobalAlloc'om...Все параметры CreateThread (в том числе и тело lpfn должны находится за пределами осегмента DLL - освобождаемого сегмента)

хм...Дык и зачем тебе эти хуки...для нового трояна?

я, например, пытаюсь создать стандартную кнопку , которая без хуков и перегистрации класса BUTTON регистрирует событие WM_CHAR...
пока неудачно....
[Win32] Помогите разобраца с памятью пожалуйста 05.06.02 08:18  
Автор: BXS Статус: Незарегистрированный пользователь
<"чистая" ссылка>
до троянов пока рано.
есть идея сделать "добавление" к 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 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> использовании мейлслотов для троянов... а кстати очень
вот тот мой троян как раз и юзаит маил слоты кстати :)
сырцы скину/
[Win32] Помогите разобраца с памятью пожалуйста 04.06.02 07:22  
Автор: Duxx Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> VirtualAlloc и LocalAlloc - резервируют память в локальной
> куче вызывающих их процессов и при закрытии их память
> 'портится'. В таких случаях пользоваться надо
> GlobalAlloc'om...Все параметры CreateThread (в том числе и
> тело lpfn должны находится за пределами осегмента DLL -
> освобождаемого сегмента)

эээээээээ, насколько я помню для win32, нет вообще понятия глобальная память, все делается в контексте процеса, а LocalAlloc и тп, один @#$ недают доступ к глоб памяти, и после убивания процесса память тоже @$нется, ты наверно перепутал с win16, в вин 32 даже нет понятия сегментов, flat модель, или ты имел в виду что то другое ?
[Win32] Помогите разобраца с памятью пожалуйста 03.06.02 04:27  
Автор: Duxx Статус: Незарегистрированный пользователь
<"чистая" ссылка>
У тебя загружаемая Dll грузиться в контекст памяти процесса, тоесть если у тебя будут разные процессы то твоя длл неувидит другую длл из другого процесса, после завершения процесса мастдай освобождает все что с ним связанно, в том числе и все что связано с твоей длл.

Кстати если интересно, 2 процесса могут обмениваться данными тока через map файлы, это так написано в документации, но можно загрузить dll в совместно используемую память, и она будет едина для всех процессов, а не раздельно как в твоем случае, я как то писал прогу для перехвата функции FindFirst ( нужно было спрятать каталог от обзора), там я перехватывал вызов vxd а саму прогу для обработки вызова помещал в dll а саму dll в совместно юзаемою память. Это все было хорошо описанно в книге Мэта Питрека "Секреты системного програмированя в виндовс 95".
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2025 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach