KLEINZACH: jo, tomu rozumim. od urcityho okamziku to tak je. na druhou stranu je treba rict, ze timhle zpusobem se daji ziskat neocenitelny zkusenosti, ze?

KLEINZACH: Bez .pdb se to taky da, i kdyz je to vic prace. Odrazis se z export, import a relocation tables v tech .DLL. To pomuze alespon na ta volani co prekracuji hranici tech .dll. Ale jasne. .pdb je o dooost pohodlnejsi.

dik :) bez tech pdb bych byl v peerdeli, nedokazu si to predstavit delat bez symbolu. mozna nejakej malej izolovanej kousek, ale ne takle pres 2 vrstvy a zpet.

bohuzel kdyz chce clovek programove zachazet s tema jejich virtualnima desktopama, musi, protoze jediny oficialni co nam mrkvosoft dal, jsou 3 naprosto neuzitecny volani: IVirtualDesktopManager::GetWindowDesktopId IVirtualDesktopManager::IsWindowOnCurrentVirtualDesktop a IVirtualDesktopManager::MoveWindowToDesktop. s tim se neda NIC poradnyho delat. ( https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ivirtualdesktopmanager )

SUCHRE: vysoka - prakticky s kazdym novym windows sdk (ted je 22621). v kazdy edici widli se zmenej minualne guidy tech interface. to se da jeste dohledat v registrech, pripadne inspekci actxprxy.dll (ale to jsem jeste nedavno nevedel) a pridaj dalsi volani. na internetu je asi tak 5 open source projektu, ktery todle delaj. z toho 2 podporujou maximalne windows 10 (sdk < 22000). jeden je v pascalu (nejakej organizer chat-botu), jeden v dot netu a jeden v rustu (dll pro prepinani workspace v AutoHotkey). inspirovat jima se muzu, ale moc mi to nepomuze s mym problemem ze na w11 to v nekterych volanich pada. a kdyz prijde ta zmena, nemuzu se na ne spolehnout, ze to udelaj kdyz ja potrebuju.. proto to chci umet z widli vydojit sam a navic - ted uz je to osobni ;)

KLEINZACH: čumím a to jak péro z gauče.
a más můj obdiv.

kdyz to ctu, tak si pripadam tak nejak menejcenne ... jsem uplny pojidac kolacu ...

KLEINZACH:
> attachovat se na explorer je prdel, clovek si ze zacatku neuvedomi co nemuze: je to jak xwindows bez window managera :)

Presne z tohodle duvodu delam tyhle veci zasadne v simulatorech / virtualnich strojich a teprve az to odladim tam, zkousim to na opravdovem zeleze
(ne ze by to resilo vsechno, bug ve firmwaru do bezici pod OS a zpusobujici pad JVM to neodhali - a teda to je take lahudka hledat :-)

blizim se :)

rpc bylo hodne, ale pak mi doslo jedno biblicke rceni: "co je marshalovano, musi byt nekde demarshalovano". takze jsem si dal breakpoint na combase.dll!CoUnmarshalInterface. tech uz nebylo tolik a kdyz jsem je proklikaval, tak se periodicky stridalo rekneme 5 com unmarshalu. po kratke prohlidce stacku jsem na jednom z nich nasel actxprxy.dll a OneCoreCommonProxyStub.dll (ci tak nejak) o kterych vim, ze se me tykaj. tendle thread jsem sledoval a dovedl me do twinui.pcshell.dll, ktery jsem prohlidnul a zacal v nem nachazet fragmenty toho, co me zajima (IVirtualDesktopManagerInternal a podobne). napsal jsem si test, kterej na tomdle interfacu zavola GetCount, attachnul na explorera, dal breakpoint do twinui.pcshell.dll!CVirtualDesktopManager::GetCount, pustil test a bang! :)

co dela klient:
TLDR: com/interface -> com/proxy -> rpc -> alpc

>	rpcrt4.dll!LRPC_BASE_CCALL::DoSendReceive()	Unknown
 	rpcrt4.dll!LRPC_CCALL::SendReceive()	Unknown
 	rpcrt4.dll!I_RpcSendReceive()	Unknown
 	combase.dll!CMessageCall::RpcSendRequestReceiveResponse(const _GUID & moidForTracing) Line 4281	C++
 	[Inline Frame] combase.dll!ThreadSendReceive(tagRPCOLEMESSAGE *) Line 7282	C++
 	[Inline Frame] combase.dll!CSyncClientCall::SwitchAptAndDispatchCall(tagRPCOLEMESSAGE * pMessage) Line 5735	C++
 	combase.dll!CSyncClientCall::SendReceive2(tagRPCOLEMESSAGE * pMessage, unsigned long * pstatus) Line 5297	C++
 	[Inline Frame] combase.dll!SyncClientCallRetryContext::SendReceiveWithRetry(tagRPCOLEMESSAGE *) Line 1494	C++
 	[Inline Frame] combase.dll!CSyncClientCall::SendReceiveInRetryContext(SyncClientCallRetryContext *) Line 582	C++
 	combase.dll!DefaultSendReceive(CSyncClientCall * pClientCall, tagRPCOLEMESSAGE * pMsg, unsigned long * pulStatus) Line 540	C++
 	combase.dll!CSyncClientCall::SendReceive(tagRPCOLEMESSAGE * pMessage, unsigned long * pulStatus) Line 787	C++
 	combase.dll!CClientChannel::SendReceive(tagRPCOLEMESSAGE * pMessage, unsigned long * pulStatus) Line 659	C++
 	combase.dll!NdrExtpProxySendReceive(void * pThis, _MIDL_STUB_MESSAGE * pStubMsg) Line 1989	C++
 	rpcrt4.dll!NdrpClientCall3()	Unknown
 	combase.dll!ObjectStublessClient(void * ParamAddress, __int64 * FloatRegisters, long Method) Line 366	C++
 	combase.dll!ObjectStubless() Line 176	Unknown

tady je videt druha strana - server - toho volani (nekde okolo NdrStubCall3 je ten CoUnmarshalInterface):
TLDR: alpc -> rpc -> com/stub -> com/interface -> dll

>	twinui.pcshell.dll!CVirtualDesktopManager::GetCount(unsigned int *)	Unknown
 	rpcrt4.dll!Invoke()	Unknown
 	rpcrt4.dll!Ndr64StubWorker()	Unknown
 	rpcrt4.dll!NdrStubCall3()	Unknown
 	combase.dll!CStdStubBuffer_Invoke(IRpcStubBuffer * This, tagRPCOLEMESSAGE * prpcmsg, IRpcChannelBuffer * pRpcChannelBuffer) Line 1479	C++
 	[Inline Frame] combase.dll!InvokeStubWithExceptionPolicyAndTracing::__l6::::operator()() Line 1151	C++
 	combase.dll!ObjectMethodExceptionHandlingAction<>(InvokeStubWithExceptionPolicyAndTracing::__l6:: action, ObjectMethodExceptionHandlingInfo * pExceptionHandlingInfo, ExceptionHandlingResult * pExceptionHandlingResult, void *) Line 94	C++
 	[Inline Frame] combase.dll!InvokeStubWithExceptionPolicyAndTracing(IRpcStubBuffer * pMsg, tagRPCOLEMESSAGE *) Line 1149	C++
 	combase.dll!DefaultStubInvoke(bool bIsAsyncBeginMethod, IServerCall * pServerCall, IRpcChannelBuffer * pChannel, IRpcStubBuffer * pStub, unsigned long * pdwFault) Line 1218	C++
 	combase.dll!SyncServerCall::StubInvoke(IRpcChannelBuffer * pChannel, IRpcStubBuffer * pStub, unsigned long * pdwFault) Line 791	C++
 	[Inline Frame] combase.dll!StubInvoke(tagRPCOLEMESSAGE * pMsg, const _GUID &) Line 1483	C++
 	combase.dll!ServerCall::ContextInvoke(tagIPIDEntry * ipidEntry) Line 1421	C++
 	combase.dll!ComInvokeWithLockAndIPID(ServerCall * pServerCall, tagIPIDEntry * pIPIDEntry) Line 2152	C++
 	[Inline Frame] combase.dll!ThreadInvokeReturnHresult(_RPC_MESSAGE *) Line 6944	C++
 	combase.dll!ThreadInvoke(_RPC_MESSAGE * message) Line 7044	C++
 	rpcrt4.dll!DispatchToStubInCNoAvrf()	Unknown
 	rpcrt4.dll!RPC_INTERFACE::DispatchToStubWorker()	Unknown
 	rpcrt4.dll!RPC_INTERFACE::DispatchToStubWithObject()	Unknown
 	rpcrt4.dll!LRPC_SCALL::DispatchRequest()	Unknown
 	rpcrt4.dll!LRPC_SCALL::HandleRequest(struct _PORT_MESSAGE *,struct _PORT_MESSAGE *,void *,unsigned __int64,class RPCP_ALPC_HANDLE_ATTR *)	Unknown
 	rpcrt4.dll!LRPC_SASSOCIATION::HandleRequest()	Unknown
 	rpcrt4.dll!LRPC_ADDRESS::HandleRequest()	Unknown
 	rpcrt4.dll!LRPC_ADDRESS::ProcessIO(void *)	Unknown
 	rpcrt4.dll!LrpcIoComplete()	Unknown
 	ntdll.dll!TppAlpcpExecuteCallback()	Unknown
 	ntdll.dll!TppWorkerThread()	Unknown
 	kernel32.dll!BaseThreadInitThunk()	Unknown
 	ntdll.dll!RtlUserThreadStart()	Unknown

dalsim krokem je tedy vytahnout z toho dll/pdb/debugu interface toho, co me zajima a udelat z toho headery (ty nezdokumentovany interfacy ne ze by tam byly nejak explicitne, ze bych je vykopiroval a hotovo, spis ve forme forward deklaraci nebo tak neco)

--
attachovat se na explorer je prdel, clovek si ze zacatku neuvedomi co nemuze: je to jak xwindows bez window managera :)
napr: jdu od kompu, loaduje to symboly tak to zamknu, aby mi to deti nestoply... shit! uz to neodemknu! dam breakpoint do klavesovy zkratky win+tab, abych videl kam to vede, attachnu, zmacknu, breakpoint hitne, ale zustanu viset v nabidce virtualnich desktopu, protoze explorer visi v breakpointu v debuggeru na pozadi :) po kazdym takovymdle omylu hard reset, pac z toho neni cesta ven

hehe :) stouram se v exploderu (kdyz mam cas: jsme po rekonstrukci, takze ho zase tolik neni.. od patku jsem presouval predmety a cistil plochy).

to moje RPC konci ve volani NtAlpcSendWaitReceivePort. pokracuje se dal pres nedokumentovane Asynchronous Local Procedure Call ( ALPC ), ktere je zdokumentovane (reverzne) zde, docela zajimave cteni:
Offensive Windows IPC Internals 3: ALPC · csandker.io
https://csandker.io/2022/05/24/Offensive-Windows-IPC-3-ALPC.html

druhej konec je tedy ALPC port OLExxxxxx v exploreru.

ted se snazim v exploderu neceho chytnout. kdyz se pichnu na rpcrt4.dll!I_RpcSendReceive, tak tam toho chodi strasne moc (mozna bych mel to debugovat na cisty instalaci, treba by toho bylo min.. mam ruzny shell extensions atp). uz jsem zahlid na callstacku ServiceProvider a ImmersiveShell *), coz jsou cca keywordy ktery by mohly vest k cili. musim to nejak odfiltrovat podle toho ALPC portu, nebo podle guidu ci tak neco.

do toho zkousim tooly co by mi pomohly - decompilery (relyze, cutter, jeste me ceka ghidra) atp. hodne pouzivam IDA pro (free) protoze je to strasne pohodlny na hrabani v symbolech a tak. skoda ze jejich dekompiler je standalone a tak drahej (~2700$), protoze samotna ida home by mozna za tech $300 stala. $2700 uz je zavazek :) windbg je hodne spartansky, ale narozdil od vizualka aspon nepada (dela mu problem krokovani asembleru kdyz se attachnu na explorer, na brouzdani callstackama je to ok).

taky jsem zkousel v polospanku prochazet windousi dll, ktery by se mohly tykat tematu, ale widle maj tech dll strasne moc, tudy asi ne-e

--

*) tvl proc se ve widlich jmenuje takova spousta veci Immersive.* (ImmersiveTask, ImmersiveIcon, ImmersiveShell, ImmersiveWindow, ImmersiveColorImpl, ImmersiveContextMenuHelper.. na tech vecech neni nic imersivniho, to jsou zakladni veci! cejtim vliv managementu ;)

KLEINZACH: Nevim jak ostatni, ale ja netrpelive cekam na dalsi epizodu! :-)

(update)
nasel jsem vcera volani bez argumentu, ktere necrashuje a pak jsem to odkrokoval v asm ve windbg, az to skoncilo v synchronnim volani rpcrt4.dll!I_RpcSendReceive, pak do __impl_NtAlpcSendWaitReceivePort a tam syscall a konec/navrat. trosku jsem doufal, ze to rpc treba povede synchronne do nejakyho jinyho dll, ale ne, by bylo moc jednoduchy. lol, uz se mi o tom v noci i zdalo :) takze rano plnej (jednoho) napadu jsem pustil 'rpc investigator', ten ma v sobe nejakej sniffer, ten mi ukazal to rpc (podle IID toho hledaneho interface), to me navedlo na nejakej endpoint OLE_xxxxxxx, a to me dovedlo do explorer.exe (hm, sem mel cekat.. napinava detektivka bez plot twistu). takze dnes v noci expedice do exploreru... zrejme.

JANFROG: "obcas keca" = "nerika uplnou pravdu" :-)

KLEINZACH: Jeste me napadlo, co mi trosku pomahlo bylo:
1) ze WinDBG si samo stahovalo .pdb z nejakych MS serveru. Teda ne ze by v tom MS .pdb bylo neco vic nez jmena funkci ale lepsi nez dratem do oka.
2) ze to byly MS binarky, MS od jiste doby zacal prekladat s -fno-omit-frame-pointer (tedy s MS alternativou tehoz), takze i kdyz mas mizerne debug info (nebo nemas vubec), zrekonstruujes backtrace plus minus verohodne.

Dobry je zjistit cim to DLL bylo prelozene, to muze napovedet kdyz se v tom stouras. A jestli je to MSVC, tak nepredpokladej, ze kod funkce je na jednom miste v souvislem kusu pameti (to teda neni dobre predpokladat nikdy). Chvili mi trvalo, nez jsem se tohodle zbavil.

Rovnez, pokud to vola nejake WinAPI kde se predavaj struktury (v MS oblibene co jsem si vsiml), vzdy se podivej do headru a ne na MSDN, MSDN obcas keca co se tyce obsahu tech struktur a pak to nedava smysl v memory dumpu.

Kazdopadne good luck.

JARDABEREZA: U nás to teď vypadá takhle

KLEINZACH: bleee...

KLEINZACH: Uff..to mi ani nepripominej. Stravil jsem rok reverzovanim COM interfacu do .NETu aby se to dalo volat
z nasi aplikace. Jednou to stacilo - 'no amount of money will make me do it again" - ale zase to byla dobre pripomenuti o cem ten open-source vlastne je :-)

Jinak ja to studoval ve WinDBG, sysinternals a pak jsem mel vlastni sadu custom toolu na analyzu tracu a kodu.