{"id":859,"date":"2019-11-11T10:00:00","date_gmt":"2019-11-11T10:00:00","guid":{"rendered":"http:\/\/172.23.1.43\/?p=859"},"modified":"2022-06-07T22:25:59","modified_gmt":"2022-06-07T22:25:59","slug":"wnf-and-task-scheduler","status":"publish","type":"post","link":"https:\/\/blog.n-dol.org\/2019\/11\/11\/wnf-and-task-scheduler\/","title":{"rendered":"WNF and Task Scheduler"},"content":{"rendered":"\n
As I was investing another subject, I came across a scheduled task with a custom trigger and when I looked at the XML, we can see Until I came across a blackhat conference by Alex Ionescu<\/a> and Gabrielle Viala<\/a> where they explain what WNF is.<\/p>\n\n\n\n The interesting thing here is that WNF stand for Windows Notification Facility and is the notification system within the Windows OS. So it seems that the Task Scheduler is capable of subscribing to event and launch task against it. <\/p>\n\n\n\n In a nutshell and as 20k feet view: it’s notification system where processes can subscribe and publish without the need to wait for the other processes to be there. For example, if you want to be notified that wifi is connected then you subscribe to the event and the system will notify you that it did start and also can gives you more information like SSID name etc. The system or a process can also publish information to it.<\/p>\n\n\n\n For (wayyyy) more information, watch the conference and read these: <\/p>\n\n\n\n When you look at this attribute, it’s the same length as a WNF state name which is a 64 Bit int but doesn’t correspond to any WNF state names either well-known, permanent or volatile, when you used directly. When trying to After having a quick look in the PDB of taskschd.dll, I could find information about Finally, after staring for hours at the Task Scheduler state name and usual WNF numbers, I noticed something interesting, the task scheduler state name, I was looking at, end with 41 and start with 75 and WNF ones start with 41 and end with 75 for a lot of them.<\/p>\n\n\n\n It appears that the So 7550bea33e06830d = 0d83063ea3be5075<\/p>\n\n\n\n I’ve created 2 powershell functions to translate the name, it works in both direction, from and to. The first one is using the string and switching around the characters while the second one is doing it at the byte level.<\/p>\n\n\n\n <\/p>\n\n\n\nWnfStateChangeTrigger<\/code> as the trigger type. I began to look for documentation but nothing valuable.<\/p>\n\n\n\n
How WNF works ?<\/h2>\n\n\n\n
WnfStateChangeTrigger<\/h2>\n\n\n\n
XOR<\/code> it with the magic constant
WNF_STATE_KEY<\/code>, it doesn’t output anything meaningful, so it’s definitely not a usual WNF number.<\/p>\n\n\n\n
WnfStateChangeTriggerImpl<\/code> but nothing with regards to the state number conversion. So, I let that go (Frozen style).<\/p>\n\n\n\n
Light bulb Moment<\/h2>\n\n\n\n
StateName<\/code> attribute is indeed a correct WNF number but in the wrong order. Each 8 bits or 2 characters are backward. I understood after, that this change is due to Endianess<\/a>, one is using Big Endian the other Little Endian.<\/p>\n\n\n\n
function Translate-StateName {\n param (\n [ValidateLength(16,16)] [String] $StateName\n )\n \n process {\n $CharArray = (&{for ($i = 0;$i -lt $StateName.length;$i += 2) { $StateName.substring($i,2) }})\n $TranslatedStateName = (&{for ( $i = 7; $i -ge 0; $i-- ) { $CharArray[$i] }}) -join ''\n return $TranslatedStateName\n }\n}\n<\/code><\/pre>\n\n\n\n
function Convert-StateNameEndianness {\n param (\n [ValidateLength(16,16)] [String] $StateName\n )\n process {\n [byte[]] $ByteArray = [System.BitConverter]::GetBytes([Convert]::ToInt64($StateName,16))\n if ([System.BitConverter]::IsLittleEndian -eq $false) { [System.Array]::Reverse($ByteArray) }\n return ([System.BitConverter]::ToString($ByteArray)).Replace('-','')\n }\n}<\/code><\/pre>\n\n\n\n
Testing<\/h2>\n\n\n\n