Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
[upd]посмотрел на своей висте сп1 nestat -a -n -o 15.04.08 00:05 Число просмотров: 4629
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 15.04.08 01:50 Количество правок: 3
|
посмотрел на своей висте сп1 nestat -a -n -o
> 49152,
wininit.exe
> 49153,
непонятно. Держит svchost в котором пачка сервисов. Стопнул все кроме event log и dhcp - порт открыт. Убил svchost и перезапустил event log и dhp - порта никто не открыл ;-\
>49154,49155,
тоже есть
>49156,49157,49159,61215,62715,61214
а нету
зато есть 53380 и 53740, которые впрочем закрылись при стопании сервисов/драйверов методом научного тыка. Слегка погуглил - все очень темно. Вот нашел маленький прикол - http://www.eggheadcafe.com/software/aspnet/29259229/tcp-ports-6287964854-blo.aspx
Ладно, приатачился к одному из svchost'ов. Конкретно к тому который держит 49153. Понаставлял бряк и стал к нему телнетом коннектиться. В результате пришел к выводу что это имеет какое то отношение к RPC.
Итак сокет нарисовался так:
WS2_32!WSASocketW+0x2
RPCRT4!WS_SubmitAccept+0x43
RPCRT4!WS_NewConnection+0x13c
RPCRT4!COMMON_ProcessCalls+0x2b6
RPCRT4!LOADABLE_TRANSPORT::ProcessIOEvents+0x138
RPCRT4!ProcessIOEventsWrapper+0xd
RPCRT4!BaseCachedThreadRoutine+0x5c
RPCRT4!ThreadStartRoutine+0x1e
kernel32!BaseThreadInitThunk+0xe
ntdll!__RtlUserThreadStart+0x23
ntdll!_RtlUserThreadStart+0x1b
Аксептить микрософт не стал стандартным способом, а позвал mswsock!MSAFD_AcceptEx
Далее были такие вызовы:
762dfca4 e89683f7ff call RPCRT4!IsHTTPv1Protocol
762dfcb0 e8b44ffdff call RPCRT4!HttpSendIdentifyResponse
На что я просто не знал что сказать ему в телнете и закрыл нафиг. RPC закрыл сокет честно позвав closesocket.
Остальных не дебажил, спать охота. Есть предположение что какие то сервисы поднимают RPC сервера, и RPCRT4 открывает порты под них сразу. 135й порт - это ведь просто mapper, через который RPC договаривается куда будет идти подключение дальше для конкретного RPC подключения. RPC под вистой был переписан на корню, возможно теперь RPC все время сервера держат порты открытыми порты. А указанные процессы просто юзают RPC.
[upd]
Предположение подтвердилось экспериментом: убил svchost "содержащий" сервисы eventlog, audiosrv, dhcp и еще чета. svchost держал порт 49153. Ручками стартанул dhcp - svchost поднялся, в нем dhcp. портов не занимает. Потом стартанул eventlog - и новорожденный svchost открыл порт 49180. Т.е. это явно порты, поднимаемые RPC рантаймом. Причем из определенного пула >=49152, возможно для облегчения конфигурения файрволла.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
[upd]посмотрел на своей висте сп1 nestat -a -n -o - Killer{R}