{"id":5456,"date":"2018-10-21T00:10:45","date_gmt":"2018-10-21T00:10:45","guid":{"rendered":"http:\/\/www.hexacorn.com\/blog\/?p=5456"},"modified":"2018-10-21T00:52:19","modified_gmt":"2018-10-21T00:52:19","slug":"possible-anti-sandbox-trick-using-setsystemtimeadjustment-api","status":"publish","type":"post","link":"https:\/\/www.hexacorn.com\/blog\/2018\/10\/21\/possible-anti-sandbox-trick-using-setsystemtimeadjustment-api\/","title":{"rendered":"Possible anti-sandbox trick using SetSystemTimeAdjustment API"},"content":{"rendered":"<p><strong>Update<\/strong><\/p>\n<p>Just to expand on the forensic side of things &#8211; the time adjustment value, if changed, does not survive the reboot; i.e the adjustment value is not stored anywhere (e.g. in Registry).<\/p>\n<p><strong>Old post<\/strong><\/p>\n<p>Today I was browsing some of my archives and (re-)discovered a program written b<strong>y <\/strong>my ex-coworker before Tue Feb 10 20:20:38 2004 (thx PE compilation time ;). The program was written with QA test automation in mind, but when I ran it today on my win7 VM I realized that the very same trick could be used to affect the inner working of the sandbox systems, or even disturb some reversing work&#8230;<\/p>\n<p>The program is simple; it allows the user to modify the &#8216;adjustment&#8217; value for the Windows Clock.<\/p>\n<p>What does it mean?<\/p>\n<p>Googling around I found this <a href=\"http:\/\/www.mathpirate.net\/log\/2010\/03\/20\/temporal-mechanics-changing-the-speed-of-time-part-ii\/\">post<\/a> that explains the inner workings of this mechanism better than I could ever do myself. The magic API is called <em><a href=\"https:\/\/docs.microsoft.com\/en-us\/windows\/desktop\/api\/sysinfoapi\/nf-sysinfoapi-setsystemtimeadjustment\">SetSystemTimeAdjustment<\/a>;<\/em> it&#8217;s good to know that it internally calls <em>NtSetSystemInformation<\/em> with a <em>SystemTimeAdjustmentInformation<\/em> parameter. Sandbox programmers please take a notice.<\/p>\n<p>As per the MSDN article:<\/p>\n<p style=\"padding-left: 30px;\">The <em>GetSystemTimeAdjustment<\/em> and <em>SetSystemTimeAdjustment<\/em> functions support algorithms that synchronize the time-of-day clock, reported via <em>GetSystemTime<\/em> and <em>GetLocalTime<\/em>, with another time source using a periodic time adjustment.<\/p>\n<p>Okay, enough theory.<\/p>\n<p>After I ran the program and adjusted the &#8216;adjustment&#8217; (pun intended) setting to the &#8216;max&#8217; my clock went completely crazy:<\/p>\n<p><a href=\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2018\/10\/SetSystemTimeAdjustment.gif\"><img decoding=\"async\" loading=\"lazy\" class=\"aligncenter size-full wp-image-5457\" src=\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2018\/10\/SetSystemTimeAdjustment.gif\" alt=\"\" width=\"412\" height=\"157\" \/><\/a><\/p>\n<p>(btw. this is tested and recorded on win7; win10 clock is such a &#8216;paradigm shift&#8217; in the user interface that I can&#8217;t even begin to describe my despair&#8230;)<\/p>\n<p>Running <em>timeout 10<\/em> command suddenly doesn&#8217;t work as it should. It exits immediately or almost instantly and shows some funny values on the screen (kinda integer overflow ;). Same goes for timeout 100, 1000, 10000&#8230;<\/p>\n<p><a href=\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2018\/10\/SetSystemTimeAdjustment2.gif\"><img decoding=\"async\" loading=\"lazy\" class=\"aligncenter wp-image-5458\" src=\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2018\/10\/SetSystemTimeAdjustment2.gif\" alt=\"\" width=\"500\" height=\"253\" \/><\/a><\/p>\n<p>Interestingly, running <em>ping 127.0.0.1<\/em> doesn&#8217;t cause any issues.<\/p>\n<p>And this is because <em>timeout<\/em> is using a <em>_time<\/em> API function that is being checked every 100 ms. If we adjust the clock to run faster the <em>_time<\/em> function will produce the result that is immediately much higher than expected under normal circumstances (so, delta between the <em>start<\/em> value and <em>next<\/em> value is big enough o satisfy the exit condition); as a result, the <em>timeout<\/em> program will quit. Ping is using a call to <em>Sleep (1000)<\/em> API in a loop (between the pings, the number of which is default 3 and can be changed by the -n command line argument), and that&#8217;s why it is not affected.<\/p>\n<p>So, the conclusion can be that if any program ran by a sandbox on the test system is relying on a <em>difference<\/em> between two sequential values returned by any of the time function relying on the adjustment (GetSystemTime , GetLocalTime, _time, etc.) &#8211; it will be affected. Sandboxes that don&#8217;t run any &#8216;worker&#8217; programs on the guest system can sleep well, but&#8230; don&#8217;t they all run auto clickers (for GUI programs) these days? And these must rely on some delays\/time functions. Hmm&#8230; As usual, a subject for a further research. I also wonder if changing the settings will affect existing software and potentially introduce some interesting race conditions or at least DoS. The good news is that use of this API requires admin privileges,<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Update Just to expand on the forensic side of things &#8211; the time adjustment value, if changed, does not survive the reboot; i.e the adjustment value is not stored anywhere (e.g. in Registry). Old post Today I was browsing some &hellip; <a href=\"https:\/\/www.hexacorn.com\/blog\/2018\/10\/21\/possible-anti-sandbox-trick-using-setsystemtimeadjustment-api\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[43,28,41],"tags":[],"_links":{"self":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/5456"}],"collection":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/comments?post=5456"}],"version-history":[{"count":10,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/5456\/revisions"}],"predecessor-version":[{"id":5468,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/5456\/revisions\/5468"}],"wp:attachment":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/media?parent=5456"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/categories?post=5456"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/tags?post=5456"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}