Find hemmelige RDP-registreringsnøgler med IDA Free

Afdæk hemmelige RDP-registreringsnøgler med IDA Free. Følg vores guide, så du kan styrke dine sikre RDP-konfigurationer og forbedre sikkerheden i din fjernadgang.

8. december 2021

Marc-André Moreau

IDA er et førende reverse engineering-værktøj, der ofte bruges i softwarebranchen til at analysere binærfiler med lukket kildekode. Gratis eller billigere alternativer som Ghidra vinder frem, men de kan ikke måle sig med IDA’s decompiler, når det gælder nøjagtighed og modenhed. Heldigvis for os indeholder IDA Free nu en x64-decompiler, som gør reverse engineering mulig uden kendskab til assemblersprog.

Målet med dette blogindlæg er at vise, hvordan alle kan udføre enkle reverse engineering-opgaver med ikke andet end logisk deduktion og det rigtige sæt værktøjer. I stedet for at fokusere på slutresultatet rummer trinnene detaljerede skærmbilleder og kommentarer, så hele tankeprocessen bliver synlig.

Forudsætninger

Download og installér IDA Free. Bemærk, at netop denne udgave af IDA ikke er egnet til kommerciel brug, men da guiden er tænkt som en introduktion, bør det ikke være et problem. Jeg har adgang til IDA Pro på arbejdet, men alle skærmbilleder er taget med IDA Free for at undgå forvirring.

En Windows-maskine med RDP aktiveret anbefales, hvis du vil følge alle trinnene, men det er muligt at udføre nogle af opgaverne fra en anden platform, hvis det er nødvendigt. Jeg har brugt en ren virtuel maskine med Windows Server 2019 til projektet.

Find et mål

Det lyder måske indlysende, men i stedet for at rode rundt i tilfældige binærfiler er det en god idé at starte med et mål for øje. I denne artikel er målet at identificere hemmelige registreringsnøgler, der påvirker RDP-videokoderen til H.264.

Hvordan du vælger målet, er ligegyldigt, men jeg valgte det her, fordi jeg kender H.264 i RDP fra mit arbejde med FreeRDP-projektet.

Microsofts RDP-server håndteres af systemtjenesten Remote Desktop Services, som hedder TermService og bruger termsrv.dll som indgangspunkt:

!!rdp_system_service.png

Kom i gang

Opret en ny mappe med navnet „Reversing“ i „My Documents“, og kopiér „termsrv.dll“ fra „C:\Windows\System32“ ind i den. Start IDA, og klik på New i dialogboksen Quick Start:

!!ida_quick_start.png

Gå til mappen „Reversing“, vælg „termsrv.dll“, og klik derefter på Open:

!!ida_select_file.png

I dialogboksen Load a new file skal du markere „Load resources“ og derefter klikke på OK. Indstillingen er ikke obligatorisk, men ressourcesegmenter kan indimellem indeholde værdifuld information.

!!ida_load_resources.png

Bekræft, at du vil indlæse de matchende debugsymboler, ved at klikke på Yes, når du bliver spurgt:

!!ida_load_symbols.png

Når IDA’s hovedgrænseflade vises, skal du vente, til vinduet Output nederst siger „the initial autoanalysis has been finished“. Det kan tage et par minutter og varierer meget efter binærfilernes størrelse.

!!ida_load_complete.png

Sådan! Nu er du klar til at begynde at undersøge indholdet af „termsrv.dll“. Brug den her fremgangsmåde, når du senere opretter IDA-projekter til nye binærfiler.

Ingen strenge på den

Strings er den mest nyttige visning i IDA, men den er desværre ikke med i standardkonfigurationen. I menuen View går du til Open subviews og vælger derefter Strings:

!!ida_strings_window.png

Den nye visning Strings tilføjes og viser tekststrenge, der findes hvor som helst i binærfilen. Højreklik et vilkårligt sted i visningen for at åbne genvejsmenuen, og vælg derefter Setup…:

!!ida_strings_setup.png

Markér Unicode C-style (16 bits) for at slå Unicode UTF-16-literaler til, som ofte bruges i Windows. Den mindste strenglængde kan ændres, hvis du ønsker det (5 er standard). Klik på OK for at anvende ændringerne:

!!ida_strings_unicode.png

Visningen Strings viser nu langt flere strenge end før. Det tog mig årevis, før jeg opdagede, at IDA ikke ledte efter UTF-16-strenge som standard, og det ville have sparet mig for en masse tid!

!!ida_strings_complete.png

Tryk på Alt+T, skriv derefter „H264“, og tryk på Enter for at søge efter netop den delstreng i alle strenge i termsrv.dll. Vinduet Output nederst bør sige „String H264 not found“.

Hvad hedder du?

Så „H264“ som streng findes ikke i termsrv.dll, men måske kan den findes i funktionsnavne eller symboler? I menuen View går du til Open subviews og vælger derefter Names:

!!ida_names_window.png

Visningen Names fungerer på samme måde som visningen Strings. Tryk på Alt+T, skriv derefter „H264“, og tryk på Enter for at søge efter nøgleordet i alle symbolnavne. Desværre har vi stadig ingen resultater for „H264“, hvilket tyder på, at termsrv.dll måske ikke er det rigtige sted at lede.

Er det enden på vejen? Slet ikke! Reverse engineering ligner meget fiskeri: det kan tage tid at fange én fisk, men det er spændende, når det endelig sker. Lad os prøve en anden type madding: Process Explorer fra Sysinternals Suite. Download og start værktøjet på RDP-serveren, og led efter en proces ved navn „svchost.exe“ med underprocesserne „rdpclip.exe“ og „rdpinput.exe“:

!!rdp_procexp_dlls.png

Windows-systemtjenester kører alle i processer af typen „service host“ (svchost), hvilket gør det sværere at skelne dem fra hinanden. Kolonnen Command Line i Process Explorer er ret hjælpsom. Ellers kan PowerShell-cmdlet’en Get-CimInstance bruges til at finde proces-id’et for et givet tjenestenavn:

Get-CimInstance -Class Win32_Service -Filter "Name LIKE 'TermService'"

ProcessId Name        StartMode State   Status ExitCode
--------- ----        --------- -----   ------ --------
1072      TermService Manual    Running OK     0

Det afgørende er, at vi kan se en liste over DLL’er, der er indlæst i RDP-serveren sammen med termsrv.dll. Lad os udvide søgeområdet til at omfatte et par DLL’er, der begynder med „rdp“, og kopiere dem til vores projektmappe „Reversing“:

!!ida_add_more_files.png

Det er muligt at have flere IDA-instanser åbne på samme tid, men det vil jeg ikke anbefale, for det er let at fare vild. I menuen File vælger du Close. I dialogboksen Save database vælger du Pack database (Store) og klikker derefter på OK:

!!ida_save_database.png

Nu har vi nye filer at se på, og jeg har valgt at undersøge dem i denne rækkefølge:

rdpserverbase.dll
rdpbase.dll
rdpcorets.dll
rdpcore.dll
rdpnano.dll

For hver af filerne gentager jeg hele processen:

Opret et nyt IDA-projekt
Søg efter strengen „H264“

Strengen „H264“ findes et par gange i rdpserverbase.dll og rdpbase.dll, men det er ikke noget væsentligt. Vi rammer endelig jackpot, da vi søger efter „H264“ i rdpcorets.dll:

!!ida_strings_jackpot.png

Vi ser ikke kun mange henvisninger til „H264“. Nogle strenge peger også tydeligt på registreringsnøgler. Vi beslutter at fokusere på rdpcorets.dll og lukke alle andre IDA-projekter.

Søgning efter funktioner

Nu hvor vi har fundet strengene, kan vi begynde at lede efter de funktioner, der bruger dem. Dobbeltklik på den streng, der ser ud til at være en sti til en registreringsnøgle med navnet „H264Encoding“:

Software\Policies\Microsoft\Windows NT\Terminal Services\H264Encoding

Det tilhørende symbol vælges automatisk og vises på fanen IDA View-A. Ofte har strenge ikke et ordentligt navn i binærfilen, så IDA genererer et navn til dem. I det her tilfælde hedder vores streng „aSoftwarePolici_0“. Højreklik på symbolnavnet, og vælg derefter Jump to xref to operand…:

!!ida_xref_to_operand.png

En liste over funktioner, der bruger netop det strengsymbol, vises. „SetH264EncodingParametersFromRegistry“ ser ud til at være et godt valg, så dobbeltklik på den:

!!ida_xref_operand_list.png

IDA-visningen viser nu den disassemblerede funktion „SetH264EncodingParametersFromRegistry“ med kommenterede assemblerinstruktioner:

!!ida_function_disassembled.png

Nogle avancerede reverse engineers kan lide den slags visning, men den er ret svær at læse, især uden kendskab til assemblersprog. Tryk på F5 for at dekompilere funktionen til læsbar pseudokode. Når IDA beder om bekræftelse, klikker du på Yes for at fortsætte:

!!ida_decompiler_confirmation.png

Den dekompilerede funktion vises nu i al sin pragt. Husk, at der går en masse information tabt ved kompilering, så IDA kan kun rekonstruere visse ting automatisk og må gætte kvalificeret på resten. Netop det her eksempel er overraskende godt dekompileret, men de fleste funktioner rummer mange unøjagtigheder.

!!ida_decompiled_function.png

Det er spændende at dekompilere en funktion, men fandt vi den rigtige? „EnableQPSingleStep“ og „VideoDetectorRectDisplayMode“ er tydeligvis registreringsnøgler, men de har navne, der ikke siger ret meget, medmindre man kender H.264-codec’ets indre liv. Du kan højreklikke på et funktionsnavn eller en strengkonstant i pseudokoden for at finde flere krydsreferencer til dem. Lad os prøve det på funktionen „RegOpenKeyExW“ og se, hvor vi lander:

!!ida_function_jump_to_xref.png

Som forventet bruges „RegOpenKeyExW“ mange andre steder, der har med registreringsnøgler at gøre, og de fleste har intet med H.264 at gøre. Vi kan dog få øje på et par af funktionerne fra den tidligere liste over krydsreferencer til strengen „H264Encoding“, så lad os gå videre til funktionen „CreateOutputAvc“:

!!ida_function_xref_list.png

Sådan! Vi kan se følgende navne på registreringsnøgler, som peger på optagelsesmuligheder for H.264 i RDP-serveren:

RecordPath
EnableRecord264
EnableRecordYUV

!!rdp_registry_keys_h264_yuv.png

Lad os prøve funktionen „CreateCompressorOutputAvc“ for at se, om vi kan finde mere. Den ligner den forrige funktion, men med et par andre registreringsnøgler:

RecordPath
EnableRecordRGB
EnableRecordRdp264

!!rdp_registry_keys_h264_rgb.png

Vi er helt sikkert på sporet, men vi har stadig ikke set en funktion, der bruger værdierne fra registreringsnøglerne. Klassekonstruktioner eller initialiseringsfunktioner er som regel gode steder, så lad os prøve „OutputAvc::OutputAvc“:

!!rdp_registry_keys_h264_usage.png

Det dekompilerede output fra den her OutputAvc-konstruktør er mere komplekst og rummer flere unøjagtigheder, men vi kan stadig se, at den opretter filer med en bestemt navneformatering. Vi kunne fortsætte sådan i timevis, så lad os stoppe og se, om vi kan handle på den information, vi allerede har.

Indsamling af oplysninger

Når du først er i gang med IDA, er et problem, de fleste møder, at de finder langt mere information, end de kan bearbejde. Du bør se dit primære mål som spillets „hovedmission“ og alt andet som „sidemissioner“. Hvis du begiver dig ud på for mange sidespor, mister du overblikket over dit oprindelige mål.

Den bedste måde at samle information på er at bruge din foretrukne teksteditor til at indsætte alle mulige spor, efterhånden som du finder dem. Prøv ikke at organisere dem for meget. Det kan ikke betale sig. Du lærer ofte den sande værdi af de enkelte oplysninger, først når de er blevet kædet sammen med noget andet.

Lad os gå tilbage til de funktioner, der interesserer os for RDP-registreringsnøglerne til H.264, og lave en ordentlig liste. Vi har navnene, men ikke typerne, så lad os se på API-dokumentationen for RegQueryValueExW.

Outputparameteren lpType indeholder typen, som den er defineret i Registry Value Types, men desværre har vi ikke de numeriske værdier for hver type. Det er et hyppigt problem, som kan løses med en kopi af headerfilerne fra Windows SDK. I det her tilfælde bruges kun to typer: REG_SZ (1) og REG_DWORD (4).

Den eneste strengtype (REG_SZ) er „RecordPath“. Alle andre registreringsnøgler er tal (REG_DWORD) med værdien 1 eller 0. Bemærk, at fordi „RecordPath“ er af typen „REG_SZ“ og ikke „REG_EXPAND_SZ“, kan den ikke indeholde miljøvariabler som „%SystemRoot%“. Vi ender med følgende liste over registreringsnøgler med kommentarer:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Terminal Services\H264Encoding

RecordPath: fuld sti til en outputmappe til optagelse
Enable264Log: slår H.264-logning til og skal sættes til 1
EnableRecordYUV: slår dump af rå YUV-optagelse til (meget stort!)
EnableRecordRGB: slår dump af rå RGB-optagelse til (meget stort!)
EnableRecord264: slår dump af rå H.264-bitstrøm til
EnableRecordRdp264: slår dump af rå RDP H.264-strøm til

Afprøvning

Nu hvor vi har samlet værdifuld information, så lad os prøve at bruge registreringsnøglerne for at bekræfte, at de faktisk virker. Åbn registreringseditoren (regedit.exe), og opret derefter registreringsnøglen „H264Encoding“. Opret mappen „C:\Windows\Temp\RdpRecording“, og sæt derefter værdien af nøglen „RecordPath“ tilsvarende. Opret og sæt alle de andre registreringsnøgleværdier til 1 for at slå alle typer optagelse til.

!!rdp_registry_keys_h264_new.png

RDP-registreringsnøglerne til H.264 bruges kun, hvis H.264 bruges til RDP-forbindelsen, så lad os justere konfigurationen af RDP-serveren. Åbn gruppepolitikeditoren (gpedit.msc), og gå derefter til følgende sektion under Computer Configuration:

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment

Aktivér følgende politikker:

Prioritize H.264/AVC 444 graphics mode for remote desktop connections
Configure H.264/AVC hardware encoding for remote desktop connections

Aktivér politikken Limit maximum color depth, og sæt den til 32 bit, da den også kan påvirke forhandlingen af codec.

!!rdp_enable_h264_gpedit.png

Genstart RDP-serveren for at anvende ændringerne, forbind derefter med RDP, lav et par ting, der skaber billedopdateringer, og log derefter af. Forbind igen med RDP, og åbn derefter mappen „C:\Windows\Temp\RdpRecording“ for at se, om det virkede:

!!rdp_recording_files.png

Tomme filer er som regel dem, RDP-serveren bruger i øjeblikket. De skrives først til disken, når sessionen afsluttes, og derfor kræves et fuldt logaf. Fordi det er rå datadumps til intern fejlfinding, kræver de en smule omdannelse.

De ukomprimerede YUV-pixels kan afspilles direkte med VLC og de rigtige kommandolinjeparametre:

choco install vlc
cd "C:\Windows\Temp\RdpRecording"
$Env:Path += ";$Env:ProgramFiles\VideoLAN\VLC"
vlc --rawvid-fps 24 --rawvid-width 1920 --rawvid-height 1088 --rawvid-chroma I420 rdp_record_0_1920x1088_24p.yuv

Alternativt kan den rå H.264-bitstrøm indlejres i en .mp4-videofil med ffmpeg:

choco install ffmpeg
cd "C:\Windows\Temp\RdpRecording"
ffmpeg -i rdp_record_0_1920x1088_24p.264 -codec copy rdp_record_0_1920x1088_24p.mp4

De faktiske filnavne og parametre varierer, så tilpas dem tilsvarende. Sådan bør det se ud, når det virker:

!!rdp_recording_sample.gif

Ligesom de fleste „hemmelige“ registreringsnøgler var de ikke skjult, men de var ikke beregnet til at blive brugt eller stolet på. Der er heller ingen garanti for, at de understøttes i fremtiden.

Afsluttende tanker

Uden adgang til kildekoden kan man stadig få indsigt i binærfiler med lukket kildekode, som bruges på millioner af enheder. Der er et vist adrenalinsus forbundet med at finde måder at udrette nyttige ting på, som normalt ikke understøttes. Avanceret reverse engineering kræver langt mere arbejde, men man skal starte et sted. Hvis du er begynder i reverse engineering, fandt du så dette blogindlæg nyttigt? Hvis ja, hvad vil du gerne lære som det næste?