Посчитайте до 10
1, 2, 3, 3.1, 3.11, NT 3.5, NT 4.0, 95, OSR2, 98, 98 SE, Millennium, 2000, XP, Vista, 7, 8, 8.1, 10
Вы приняты!
1, 2, 3, 3.1, 3.11, NT 3.5, NT 4.0, 95, OSR2, 98, 98 SE, Millennium, 2000, XP, Vista, 7, 8, 8.1, 10
Вы приняты!
С хера ли? Они все соответствовали workstation ядром и остальным. Ну кроме может 2003 которая 5.2, но и XP64 сделана внезапно на ней 5.2 и формально XP.
https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_vers...
Новые идут от висты и выше на тех же ядрах, у некоторых даже смены чаще сохраняя имя.
Ну, во-первых тех кто посылает в русскую вики надо учить розгами, ибо они же её видимо и писали, настолько она говно и переврана(в частности на твоей страничке нет ни версии NT, ни версии ядер, ни билдов хотя бы, а они далеко не только у 10 есть).
А во-вторых соответствие ядер и окружения(они в винде неразделимы) в виде версии NT я уже привёл, всё ясно и однозначно.
ну а вдруг английским не владеете. и зачем усложнять номерами билдов, когда в комиксе подразумевается просто название?
Так именно что зачем усложнять когда каждый сервер соответствует обычной, просто серверная версия.
ок, ладно. вы мне лучше подскажите одну тему (я в курсе что разбираетесь, по крайней мере - должны). вот брякнулся я на точке rpcrt4!Invoke, скажем, в lsass. как разобраться с какого процесса вызов? (вызывающая сторона точно на той же локальной машине)
Куда ты брякнулся? В bsod? Такое отлаживать с уходом принятых отладчиков ад. А так пока на юзерлевеле легко выйдешь по retам на уровень сервиса, не выше, там уже смотреть по данным надо откуда пришёл запрос и как в зависимости от типа, но всё равно гемор ещё тот.
да не, в kd. юзермодным там толком не подебажишь (хотя хз, может кто-то и умудряется чем-то кроме windbg) - после аттача начинаешь символы грузить и виснет дебаггер намертво.
по ретам то логично, но гемор. да. да и главное что искать не могу понять, выглядит то оно вот так:
...
RPCRT4!Invoke
...
RPCRT4!LRPC_ADDRESS::ProcessIO
RPCRT4!LrpcIoComplete
ntdll!TppAlpcpExecuteCallback <--- тут чтоли ковырять получается
ntdll!TppWorkerThread
KERNEL32!BaseThreadInitThunk
ntdll!RtlUserThreadStart
Я не про то. Это rpc! Caller не будет в вызовах, его ещё вычислить надо по данным в ретах на момент коннекта.
Ты получаешь только серверную часть и процесс, и что это будет как бы очевидно, но что вызвало rpc ты не узнаешь, это надо поднимать механизм и на определенном этапе возврата поднимать сетевой или локальный сокет итд..
Кстати я про rpc не копал, но там могут быть свои ньюансы.
да я вкурсе, в рамках локальной тачки вроде как rpc alpc юзает, а по сети - транспорт. но вдруг какой поинтер на какойнить инфоблок прилетает с тредпула или что-то в этом жанре. что-то гдето слышал про экзепшны RpcTryExcept итд - но не понял что оттуда можно вытянуть, может инфа о хендлерах где-то кладётся.
и еще вот мысль была, если рпц уходит скажем в NtReadFile<-WriteFile<-...<-rpcrt4!Invoke отследить доступ к буферу на обратном пути, и какое-то место диспетчеризации отыскать (клиент так или иначе использует полученные данные, другое дело в том что они еще модифицируются(декриптятся) и наверное стопицот раз перемещаются/копируются непонятно на чьей стороне - тоже гемор)
IT-юмор
5.6K поста52.5K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору