{"id":5299,"date":"2019-04-27T00:39:27","date_gmt":"2019-04-27T00:39:27","guid":{"rendered":"http:\/\/www.hexacorn.com\/blog\/?p=5299"},"modified":"2019-04-27T00:39:29","modified_gmt":"2019-04-27T00:39:29","slug":"returning-the-call-moshi-moshi-the-api-way-a-k-a-api-cold-calling-part-2","status":"publish","type":"post","link":"https:\/\/www.hexacorn.com\/blog\/2019\/04\/27\/returning-the-call-moshi-moshi-the-api-way-a-k-a-api-cold-calling-part-2\/","title":{"rendered":"Returning the call \u2013 \u2018moshi moshi\u2019, the API way (a.k.a. API cold calling), Part 2"},"content":{"rendered":"<p>In my <a href=\"https:\/\/www.hexacorn.com\/blog\/2016\/07\/31\/returning-the-call-moshi-moshi-the-api-way-a-k-a-api-cold-calling\/\">old post<\/a> I described an idea of initializing registers with a predefined value using calls to APIs that return predictable values; such approach can help to develop novelty anti-* tricks, in particular targeting emulation of any sort &amp; imho this is certainly worth an attention of anyone who tries to:<\/p>\n<ul>\n<li>write code bypassing AV\/EDR in a generic way<\/li>\n<li>create obfuscators that may try to hide some logic of the program&#8230; outside of it&#8230;<\/li>\n<li>reverse static analysis in a more generic way &#8212; reversers will need to take these into account to cover additional cases of opaque predicates<\/li>\n<\/ul>\n<p>The idea of expanding on the old post was with me for a while and I finally decided to provide more examples of OS code that can be &#8216;repurposed&#8217;.<\/p>\n<p>It took a long time, because it takes a lot of code browsing\/searches. And I think I only touched the surface, because to be effective in this area one needs a proper database of OS code snippets that is searchable the same way as ROP gadgets databases.<\/p>\n<p>So, there you go&#8230; if you are looking for an interesting reversing project: try to automate finding opaque predicates in as many libs as possible!<\/p>\n<p>Browsing through the MSDN documentation and code of various OS libraries it&#8217;s quite easy to spot the functions that are no longer supported\/deprecated or otherwise not <a href=\"https:\/\/docs.microsoft.com\/en-us\/windows\/desktop\/apiindex\/windows-api-list\">maintained<\/a>; they are a perfect target for abuse:<\/p>\n<ul>\n<li>For example, looking at &#8216;<a href=\"https:\/\/docs.microsoft.com\/en-us\/windows\/desktop\/ipc\/network-dde-reference\">Network DDE Reference<\/a>&#8216; one can immediately recognize potential of old functions exported by Nddeapi.dll; they are returning NDDE_NOT_IMPLEMENTED (14) by default; there are exceptions of course &#8211; a couple of NetDDE APIs return 0, but this DLL can help to initialize registers to one of these two values w\/o much effort<\/li>\n<li>The good ol&#8217; kernel32.dll is also full of surprises. The 16-bit legacy code is still there, even if in a dormant state. Calling a very old exported function UTRegister with wrong parameters can give you 1 in the eax, but if you provide 3 good arguments i.e.<\/li>\n<\/ul>\n<pre style=\"padding-left: 60px;\">UTRegister(0, \"mem16.dll\", 0, \"GetMemory\", &amp;ptr, 0, 0)<\/pre>\n<p style=\"padding-left: 60px;\">You will get 0 in eax, plus a bonus &#8211; a pointer to a call back (a function in ptr variable). If you call this callback function, you will get 0x2000 in eax.<\/p>\n<p style=\"padding-left: 60px;\">So, you can use this particular API to get 0, 1, or 0x2000 into eax.<\/p>\n<ul>\n<li>Incorrect parameters passed to some very well-known functions can provide some unexpected results &#8211; we just need to make a deliberate mistake in our code \ud83d\ude42<br \/>\nFor example, the good old LoadLibraryEx can help to initialize eax to 0x57 (ERROR_INVALID_PARAMETER) if you pass a nonzero value as a second argument when you call the function<\/li>\n<li>LockResource is one of the best wrappers &#8211; it is doing nothing other than moving the first argument passed to the function to eax<\/li>\n<li>I_CryptGetLruEntryIdentifier is similar, but the value will be increased by 8 (there are tones functions that are similar)<\/li>\n<li>FreeResource does nothing and returns 0<\/li>\n<li>If we need to initialize a DWORD value at some specific location (pointer), the msvcr120_clr0400 ! _vacopy API may come handy; it takes a pointer, and a value as its arguments and does the dirty job for us<\/li>\n<li>Many GDI functions return 0 by default e.g. EngQueryEMFInfo, FixBrushOrgEx, GdiPlayJournal<\/li>\n<li>Then there is always a trivial example of GetCurrentProcess that is always returning 0xFFFFFFFF<\/li>\n<li>CloseProfileUserMapping, GdiSupportsFontChangeEvent, GdiEntry16, ImmReleaseContext, SetConsoleMaximumWindowSize always return 1; there is lots of APIs that behave this way<\/li>\n<li>NtVdm64CreateProcessInternalW, VerifyConsoleIoHandle always return 0<\/li>\n<li>Many unimplemented functions return 0x78 (ERROR_CALL_NOT_IMPLEMENTED) e.g. RegLoadMUIStringA<\/li>\n<li>Many unimplemented functions return 0x32 (ERROR_NOT_SUPPORTED) e.g. SetEncryptedFileMetadata<\/li>\n<li>ElfReportEventAndSourceW will give you 0xC0000002 (NT_STATUS_NOT_IMPLEMENTED)<\/li>\n<li>SslChangeNotify will give you 0x80090029 (NTE_NOT_SUPPORTED )<\/li>\n<li>MD5Init and similar functions can initialize some buffers with MD5 (or other hash functions&#8217;) initial values e.g. 0x67452301, 0x0EFCDAB89, 0x98BADCFE, 0x10325476; these could be used w\/o using actual hash calculation code<\/li>\n<li>Cleverly used encryption functions can give you a predictable set of values (e.g. initialize a buffer with a specific pattern, encrypt it, use some the data from the buffer as offsets to other data structures\/callbacks)<\/li>\n<li>FlushInstructionCache returns 1; I was curious about it and even asked on Twitter about it; It would seem x86 architecture doesn&#8217;t need it, but it&#8217;s good to call it for future compatibility; So, eax=1 it is<\/li>\n<li>GetLargePageMinimum can give you a predictable value if you discard the lower bits of it e.g. 0x7FFExxxxh<\/li>\n<li>Many DLLs with DllInstall, DllRegisterServer exports will return 0 when these APIs are called<\/li>\n<li>SetLastError\/GetLastError can transfer data via OS data buffers<\/li>\n<li>Many msvbvm60 functions return 0x80010007 (RPC_E_SERVER_DIED)<\/li>\n<li>msvcr* and msvcp* DLLs contain lots of functions that can help to transform data in a more or less unpredictable way<\/li>\n<li>Some of the exported functions are so old school that they can be used to cause predictable exceptions e.g. reading\/writing to I\/O ports<\/li>\n<li>COM return values can be predictable as well:\n<ul>\n<li>S_OK Operation successful 0x00000000<\/li>\n<li>E_ABORT Operation aborted 0x80004004<\/li>\n<li>E_ACCESSDENIED General access denied error 0x80070005<\/li>\n<li>E_FAIL Unspecified failure 0x80004005<\/li>\n<li>E_HANDLE Handle that is not valid 0x80070006<\/li>\n<li>E_INVALIDARG One or more arguments are not valid 0x80070057<\/li>\n<li>E_NOINTERFACE No such interface supported 0x80004002<\/li>\n<li>E_NOTIMPL Not implemented 0x80004001<\/li>\n<li>E_OUTOFMEMORY Failed to allocate necessary memory 0x8007000E<\/li>\n<li>E_POINTER Pointer that is not valid 0x80004003<\/li>\n<li>E_UNEXPECTED Unexpected failure 0x8000FFFF<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>And so on and so forth.<\/p>\n<p>Many API functions can be called with incorrect parameters only to return a predictable error. Some of them are mentioned above, but these I looked for are primarily focused on returning error immediately (i.e. they are deprecated or legacy and are just a simple block of &#8216;mov eax, error_value\/ret&#8217; code); they are not the best choice.<\/p>\n<p>It is much better to look for existing, popular, and working APIs, and call them with some unexpected error-prone arguments. Not necessarily fuzzing them, but fuzzing itself could be used to get some predictable results too.<\/p>\n<p>Also&#8230;<\/p>\n<p>Many DLLs that are created as traditional &#8216;utility&#8217; DLLs export tones of mathematical, logical, worker, environmental, string functions that can be used to deliver (un)predictable code and data. Not a single sandbox or emulator handles them all, let alone scripts for IDA or Ghidra.<\/p>\n<p>Finally, there are tones of <a href=\"https:\/\/www.hexacorn.com\/blog\/2017\/11\/10\/reusigned-binaries-living-off-the-signed-land\/\">other DLLs provided by 3rd party vendors<\/a>, where the signed code offers all the primitives to deliver some value, string, or an opportunity to execute a more complex code block (e.g. adding stuff to Registry, writing files, hooking keyboard, mouse, etc.) that can be re-used.<\/p>\n<p>Also&#8230;<\/p>\n<p>Remember that there is always a way to instrument your own program.<\/p>\n<p>Debugging functions, SEH, VEH, VirtualProtect, etc. can help to modify buffers as they are processed by the OS code or external DLL APIs. It&#8217;s hard to manipulate these buffers on a kernel level of course, but in the userland you can do lots of trickery this way. Causing predictable exceptions triggered inside the OS libs is a nice way to swap these buffers on the way to be processed (and outside of the actual program&#8217;s code). You can do the same for the return values.<\/p>\n<p>You could even use a Trap Flag to fully trace through a certain API and only change the returned value at the very last moment&#8230;<\/p>\n<p>I don&#8217;t know how many available &#8216;APIs are out there atm, but there is enough to make some interesting code decisions.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In my old post I described an idea of initializing registers with a predefined value using calls to APIs that return predictable values; such approach can help to develop novelty anti-* tricks, in particular targeting emulation of any sort &amp; &hellip; <a href=\"https:\/\/www.hexacorn.com\/blog\/2019\/04\/27\/returning-the-call-moshi-moshi-the-api-way-a-k-a-api-cold-calling-part-2\/\">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":[9,44],"tags":[],"_links":{"self":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/5299"}],"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=5299"}],"version-history":[{"count":19,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/5299\/revisions"}],"predecessor-version":[{"id":6266,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/5299\/revisions\/6266"}],"wp:attachment":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/media?parent=5299"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/categories?post=5299"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/tags?post=5299"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}