{"id":38,"date":"2020-05-07T17:10:20","date_gmt":"2020-05-07T15:10:20","guid":{"rendered":"http:\/\/pusha.be\/?p=38"},"modified":"2020-05-07T17:10:20","modified_gmt":"2020-05-07T15:10:20","slug":"exploration-of-svchost-exe-p-flag","status":"publish","type":"post","link":"https:\/\/pusha.be\/index.php\/2020\/05\/07\/exploration-of-svchost-exe-p-flag\/","title":{"rendered":"Exploration of svchost.exe \/P flag"},"content":{"rendered":"\n

Hey there!<\/p>\n\n\n\n

In this blog post, we are gonna take a look at the mysterious “\/P” flag of svchost.exe. TL;DR: P flag enforces different policies: DynamicCodePolicy, BinarySignaturePolicy and ExtensionPolicy.<\/p>\n\n\n\n

So first of all, what is svchost.exe? Following Wikipedia “svchost.exe<\/strong> (Service Host<\/strong>, or SvcHost<\/strong>) is a system process<\/a> that can host from one to many Windows services<\/a> in the Windows NT<\/a> family of operating systems<\/a>“. It’s basically the loader of your different services.<\/p>\n\n\n\n

Before diving into svchost with Cutter (or your favorite disassembler\/decompiler), it’s good to have the PDB of executable beforehand. PDB is short for “Program DataBase” and is storing the debug information of an executable. You can have it with PDBDownloader.exe (which you can grab here https:\/\/techcommunity.microsoft.com\/t5\/iis-support-blog\/pdb-downloader\/ba-p\/342969<\/a>) Microsoft lets you access some of the debug information for its different component so you can debug them with Windbg or import them in IDA which is cool. It’s important to note that you don’t have access to ALL<\/strong> the debug information. Only the symbols that Microsoft made public.<\/p>\n\n\n\n

Now can begin the fun part. So, this static analysis was made with Cutter (GUI for radare2). Beforehand, you have an option to select a PDB file to load when you select advanced analysis. If you don’t do that, no worries, you can add it after.<\/p>\n\n\n\n

We are first landing in the entrypoint of our executable. You can see some common functions for an PE executable. A lot of them are just boilerplate like initialization of the arguments, security cookie, … We can go ahead and take a look at wmain<\/em>.
\"\"<\/p>\n\n\n\n

There is not a lot going in wmain<\/em>. The only function that could be interesting is InitializeSvcHostLib<\/em>. The others seem to register a new service, set up some timer and wait for it.
\"\"<\/p>\n\n\n\n

Now, this begins to be a lot more interesting. We see multiple calls there but what seems to be relevant for our goal is the GetCommandLineW<\/em> call followed by BuildCommandOption<\/em>. Surely BuildCommandOption<\/em> should help us.
\"\"<\/p>\n\n\n\n

BuildCommandOption<\/em> is a lot more dense than the other functions so we need to take it piece by piece. From the previous function, we could see that the parameter passed to it is the return value of GetCommandLineW<\/em> which from https:\/\/docs.microsoft.com\/en-us\/windows\/win32\/api\/processenv\/nf-processenv-getcommandlinew<\/a> is the command-line string for the current process (surprising for a function called GetCommandLineW<\/em>). Now, when we follow the parameter inside BuildCommandOption<\/em>, we could see something interesting
\"\"
The parameter is copied with memcopy<\/em> to “ppiVar5 + 0xf” and with ppivar5 the result of HeapAlloc<\/em>. From these two elements, we can say that ppiVar5 is a structure or an object. So we can try to create a structure in the type<\/em> menu. Moreover, when looking at the end of the function, we can see that ppiVar5 is returned.<\/p>\n\n\n\n

Because I’m leazy, I won’t reverse engineer the whole function. By looking roughly at the function we can see some interesting things. We see a bunch of operations with familiar values like “0x20” (space character), “0x2d” (minus character) or “0x50” (P character). Normally, you would think that you will find a switch case or multiple “if else if” comparing a character with different hexadecimal values. But not here. Weirdly, we find subtraction followed by a comparison with 0. At the end, it’s still a comparison but not as straightforward as one would imagine.
\"\"
Because of these values, we can make an educated guess that iVar2 (which comes from piVar8) is pointing to a character from command line and this loop is parsing it.<\/p>\n\n\n\n

Taking a closer look at this loop and particularly at the action made when the flag is found, we can see that our ppiVar5 is modified (at least different fields of ppiVar5 are modified). Here are the different cases:
– if K (0x4B) is set: *(ppiVar5 + 2) = 1
– else if S (0x53) is set: ppiVar5 is not modified, counter increases
– else if P (0x50) is set: *(ppiVar5 + 0x5c) = 1
We know that ppiVar5’s fields are set following the different flags that we put in our command lines. Officially we know that K is the service group and S the service from this group. But no information about P. At the end of this function, our ppiVar5 is a structure looking like that:
<\/p>\n\n\n\n

struct cmd_parsed {\n    int64_t field_0;\n    int64_t field_1;\n    char k_flag;\n    char gap_0[75];\n    char p_flag;\n    char gap_1[27];\n    char *argv;\n};<\/code><\/pre>\n\n\n\n
So know, we can step back a little bit and come back to InitializeSvcHostLib<\/em>. We see that the return value of BuildCommandOption<\/em> is iVar4 and it’s passed to CallPerInstanceInitFunctions<\/em> and so is our next stop.<\/p>\n\n\n\n
The first thing that we see is that Ghidra plugin for Cutter couldn’t decompile this function so we need to rely on the other plugin r2dec and disassembly. The second thing is that no cmd_parsed<\/em> field set from BuildCommandOption<\/em> are used but totally new ones… Hum weird. Maybe it’s time to step back again and look at our code.<\/p>\n\n\n\n
In InitializeSvcHostLib<\/em>, we can see that the pointer to the object returned by BuildCommandOption<\/em> (so in rax) is immediately copied to rbx. Now, if we follow rbx a little bit, we can see that its content is copied to rdx just after BuildServiceArray<\/em>. Meaning that it’s in fact a parameter that Ghidra didn’t recognize.
\"\"<\/p>\n\n\n\n
Let’s dig into BuildServiceArray<\/em>. By modifying the function in order to use the ms calling convention (passing the parameter to rcx, rdx, r8 and r9 as described here https:\/\/docs.microsoft.com\/en-us\/cpp\/build\/x64-calling-convention?view=vs-2019<\/a>), we can follow param2 which is rdx (our cmd_parsed<\/em> object).
\"\"
We won’t be long in this function because param2 is quickly used by ReadPerInstanceRegistryParameters as the third parameter.<\/p>\n\n\n\n
From this new function, we can see that other fields are set and used from our main structure depending on different values queries from the registry key Software\\Microsoft\\Windows NT\\CurrentVersion\\Svchost<\/em> like CoInitializeSecurityParam<\/em> or CoInitializeSecurityAllowLowBox<\/em>. But more importantly, we see that this function accesses our field set by P flag (cmd_parsed.p_flag<\/em> or ppiVar5 + 0x5c).
\"\"
And as you can see, if the flag is set and the handle to the registry key is 0 (iStack664 holds the handle to the registry key), *(ppiVar5 + 0x60) is set. It’s interesting to note in what other occasion this field is modified. It is later set if the value DynamicCodePolicy<\/em> exists. That’s interesting. So, maybe our P flag from the command line enforces the DynamicCodePolicy?<\/p>\n\n\n\n
In the next reference to uVar17 (holding the value of our P flag), we see that the field *(ppiVar5 + 0x64) is set to 1. And this field is also set when BinarySignaturePolicy<\/em> exists.
\"\"
And last one, for *(ppiVar5 + 0x68) which is set when ExtensionPointsPolicy is set.
\"\"<\/p>\n\n\n\n
What does it mean for us? It means that if P flag is set, the different fields related to DynamicCodePolicy, BinarySignaturePolicy and ExtensionPolicy are set to 1. If it’s not the case, it depends of the different values found in the Registry Key.<\/p>At the end of this function, our structure should be like this:<\/p>\n\n\n\n
struct cmd_parsed {\n\tint64_t field_0;\n\tint64_t field_1;\n\tchar k_flag;\n\tchar gap_0;\n\tchar gap_1;\n\tchar gap_2;\n\tchar gap_3;\n\tchar gap_4;\n\tchar gap_5;\n\tchar gap_6;\n\tint64_t lpValue_reg;\n\tint64_t field_3;\n\tint64_t field_4;\n\tint64_t field_5;\n\tint64_t field_6;\n\tint64_t field_7;\n\tint64_t field_8;\n\tint64_t field_9;\n\tchar gap_7;\n\tchar gap_8;\n\tchar gap_9;\n\tchar gap_9_0;\n\tchar p_flag;\n\tchar gap_10;\n\tchar gap_11;\n\tchar gap_12;\n\tchar DynamicCodePolicy_flag;\n\tchar gap_13;\n\tchar gap_14;\n\tchar gap_15;\n\tchar BinarySignaturePolicy_flag;\n\tchar gap_16;\n\tchar gap_17;\n\tchar gap_18;\n\tchar ExtensionPointsPolicy_flag;\n\tchar gap_19;\n\tchar gap_20;\n\tchar gap_21;\n\tchar gap_22;\n\tchar gap_23;\n\tchar gap_24;\n\tchar gap_25;\n\tchar gap_26;\n\tchar gap_27;\n\tchar gap_28;\n\tchar gap_29;\n\tchar gap_30;\n\tchar gap_31;\n\tchar gap_32;\n\tchar gap_33;\n\tchar *argv;\n};<\/code><\/pre>\n\n\n\n
Finally, we can go out of this function. BuildServiceTable<\/em> doesn’t access our structure and CallPerInstanceInitFunctions<\/em> is. When analyzing it and applying the different field offsets to rbx, we can see that they are checked and followed by a call to SetProcessMitigationPolicy<\/em> which confirms that these fields set up the different Mitigation Policies! And this is the end of our journey into svchost!<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
If there is any question, remark or mistake, don’t hesitate to contact me on Twitter @redmed666<\/a><\/p>\n\n\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Hey there! In this blog post, we are gonna take a look at the mysterious “\/P” flag of svchost.exe. TL;DR: P flag enforces different policies: DynamicCodePolicy, BinarySignaturePolicy and ExtensionPolicy. So first of all, what is svchost.exe? Following Wikipedia “svchost.exe (Service Host, or SvcHost) is a system process that can host from one to many Windows … Continue reading Exploration of svchost.exe \/P flag<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/pusha.be\/index.php\/wp-json\/wp\/v2\/posts\/38"}],"collection":[{"href":"https:\/\/pusha.be\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/pusha.be\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/pusha.be\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/pusha.be\/index.php\/wp-json\/wp\/v2\/comments?post=38"}],"version-history":[{"count":23,"href":"https:\/\/pusha.be\/index.php\/wp-json\/wp\/v2\/posts\/38\/revisions"}],"predecessor-version":[{"id":85,"href":"https:\/\/pusha.be\/index.php\/wp-json\/wp\/v2\/posts\/38\/revisions\/85"}],"wp:attachment":[{"href":"https:\/\/pusha.be\/index.php\/wp-json\/wp\/v2\/media?parent=38"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/pusha.be\/index.php\/wp-json\/wp\/v2\/categories?post=38"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/pusha.be\/index.php\/wp-json\/wp\/v2\/tags?post=38"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}