раскрыть ветку (16)
С хера ли? Они все соответствовали workstation ядром и остальным. Ну кроме может 2003 которая 5.2, но и XP64 сделана внезапно на ней 5.2 и формально XP.
https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_vers...
Новые идут от висты и выше на тех же ядрах, у некоторых даже смены чаще сохраняя имя.
раскрыть ветку (14)
раскрыть ветку (13)
Ну, во-первых тех кто посылает в русскую вики надо учить розгами, ибо они же её видимо и писали, настолько она говно и переврана(в частности на твоей страничке нет ни версии NT, ни версии ядер, ни билдов хотя бы, а они далеко не только у 10 есть).
А во-вторых соответствие ядер и окружения(они в винде неразделимы) в виде версии NT я уже привёл, всё ясно и однозначно.
раскрыть ветку (12)
ну а вдруг английским не владеете. и зачем усложнять номерами билдов, когда в комиксе подразумевается просто название?
раскрыть ветку (11)
Так именно что зачем усложнять когда каждый сервер соответствует обычной, просто серверная версия.
раскрыть ветку (10)
ок, ладно. вы мне лучше подскажите одну тему (я в курсе что разбираетесь, по крайней мере - должны). вот брякнулся я на точке rpcrt4!Invoke, скажем, в lsass. как разобраться с какого процесса вызов? (вызывающая сторона точно на той же локальной машине)
раскрыть ветку (9)
Куда ты брякнулся? В bsod? Такое отлаживать с уходом принятых отладчиков ад. А так пока на юзерлевеле легко выйдешь по retам на уровень сервиса, не выше, там уже смотреть по данным надо откуда пришёл запрос и как в зависимости от типа, но всё равно гемор ещё тот.
раскрыть ветку (6)
да не, в kd. юзермодным там толком не подебажишь (хотя хз, может кто-то и умудряется чем-то кроме windbg) - после аттача начинаешь символы грузить и виснет дебаггер намертво.
по ретам то логично, но гемор. да. да и главное что искать не могу понять, выглядит то оно вот так:
...
RPCRT4!Invoke
...
RPCRT4!LRPC_ADDRESS::ProcessIO
RPCRT4!LrpcIoComplete
ntdll!TppAlpcpExecuteCallback <--- тут чтоли ковырять получается
ntdll!TppWorkerThread
KERNEL32!BaseThreadInitThunk
ntdll!RtlUserThreadStart
раскрыть ветку (5)
Я не про то. Это rpc! Caller не будет в вызовах, его ещё вычислить надо по данным в ретах на момент коннекта.
Ты получаешь только серверную часть и процесс, и что это будет как бы очевидно, но что вызвало rpc ты не узнаешь, это надо поднимать механизм и на определенном этапе возврата поднимать сетевой или локальный сокет итд..
Кстати я про rpc не копал, но там могут быть свои ньюансы.
раскрыть ветку (4)
да я вкурсе, в рамках локальной тачки вроде как rpc alpc юзает, а по сети - транспорт. но вдруг какой поинтер на какойнить инфоблок прилетает с тредпула или что-то в этом жанре. что-то гдето слышал про экзепшны RpcTryExcept итд - но не понял что оттуда можно вытянуть, может инфа о хендлерах где-то кладётся.
и еще вот мысль была, если рпц уходит скажем в NtReadFile<-WriteFile<-...<-rpcrt4!Invoke отследить доступ к буферу на обратном пути, и какое-то место диспетчеризации отыскать (клиент так или иначе использует полученные данные, другое дело в том что они еще модифицируются(декриптятся) и наверное стопицот раз перемещаются/копируются непонятно на чьей стороне - тоже гемор)
раскрыть ветку (3)
С ядерной точки такое ловить толку... Ловить надо сам вызов, так как он у тебя локальный, так 99% проще. С ядерной точки логично что только ото всех процессов просто сразу поймать. Однако это всё общее, я конкретикой такой не занимался и точно сказать не могу.
И неясна задача такое ловить, их куча в секунду бывает на работе софта.
раскрыть ветку (2)
не, кд в этом плане няшная штука - бряки ставятся с указанием eprocess, и как срабатывают в юзермоде (весь таргет морозится полностью, так что другое ничего не мешает) - то и контекст автоматически переключается (хотя его и так в любое время можно куда угодно переключать), задачка то - advapi32->sechost/vault->RPC->lsass: расшифровать учётные данные, точнее найти место в котором пошифрованное становится плейном.
раскрыть ветку (1)
Так суть что они разлинкованы на уровне кода , в середине rpc транспорт, там есть варианты что, но суть не меняется, и я такое никогда не пытался ловить именно ища кто вызывал, такое надо не слабо порыть. Лови на вызывающей стороне например с фильтром.
IT-юмор
7.5K постов53.3K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору