You are browsing the archive for Sandboxing.

Coalescable Timers – yet another possible anti-* API

June 16, 2018 in Anti-*, Sandboxing

I was reading about coalescable timers today and it occurred to me that:

a) there is not that much info about them online

b) I have not seen them being mentioned in a context of anti-* evasion (sandbox, reversing).

Quick googling didn’t bring many results, so I guess I will make a note here.

What are Coalescable Timers?

They are not that much different from your regular timers that one can set up using the SetTimer function, except they allow the processor(s) to better manage the resources. Basically, if you have a bunch of software that uses timers, they will end up being quite noisy and will keep popping up forcing the processors to exit the idle mode (so that the software can handle these events).

Many apps don’t really need precise timers that badly; they are often more interested in doing something every once in a while, but very precise intervals between these activities are really really rarely needed. And such regular ‘attention seeking’ is quite expensive, especially for portable devices that need to preserve the battery. So the idea is that instead of using such demanding timers one can set up a timer that can be triggered with a bit of a delay. This way, processor seeing a number of timers triggering can combine all of these falling within a certain threshold into a single event that can notify all the software ‘looking for the attention’ at once. I am simplifying it, but that’s more or less the idea.

The concept is good, and there is an API for it.  It is called SetCoalescableTimer and is present in Windows 8 and Windows Server 2012. Quick look at its implementation shows that it’s just a redirected call to… NtUserSetTimer inside the ntdll.dll. Notably, there is also a kernel function KeSetCoalescableTimer.

And here’s the funny bit.

The SetCoalescableTimer is a true Schrödinger API – it is both documented (I provided the link to MSDN above) and not (most of the information I could find leads me to believe that the proper way to use coalescablee timers is to rely on a completely different API: SetWaitableTimerEx! And this one was available in Windows 7 and Windows Server 2008 R2). Most likely someone let the SetCoalescableTimer out of the bag and now it’s there for anyone to abuse it. At the moment even Windows 10’s Windows Explorer is using it, so it’s probably not going away that soon…

Enter Sandbox – part 17: The clique of clickers

June 8, 2018 in Sandboxing

Every sandbox needs to click stuff. Let it be ‘Next’, ‘Finish’, or ‘OK’ button – when the sample runs and the GUI shows up these buttons must be simply pressed somehow to ensure the execution continues.

Writing a clicker tool that handles it smoothly is not a trivial task.

First, it has to click only windows that are created by new processes – this can be kinda easily achieved by PID filtering f.ex. based on a process snapshot obtained prior to launching the sample, but don’t be fooled – the OS message boxes, or running services or programs may sometimes require additional clicking that are ‘out of band’ (e.g. hard error messages from csrss.exe process). There may also be some issues if sandbox tools don’t handle errors silently (e.g. exceptions in .NET tools).

Next, the actual clicking…

Oh boy… this is a tricky one…

Do we send a keyboard event, or mouse event?

Do we even know where the actual button we must click… is?

For installers that rely on Windows GUI system to draw its components – it’s quite easy. Every sych GUI control is a separate window which we can enumerate, find, inspect its class name, text and, send a message to, if we need to. Unfortunately, the generic solution is much harder to write, because:

  • Borland/Delphi/Embarcadero etc. use VCL and its own components (and programmers often created their own libraries with dedicated owner-drawn controls – this was really popular in late 90s and early naughties)
  • .NET uses its own components (Read about Windows Presentation Foundation (WPF))
  • Office uses its own GUI components (forms, etc.) – read about UI automation below and about Office UI Fabric
  • Java uses its own components; many testing frameworks rely on access to the source code (from what I learnt so far), so it’s hard to do a blackbox test
  • Adobe Flash and Silverlight are also custom drawn, same as Google Chrome, Mozilla Firefox and many other software packages may and often do use their own GUI libraries
  • Some (especially old-school) applications use their own components that are proprietary and only known to the software company that produced them, so it’s hard to write a generic clicker for them (Lotus Notes anyone?)
  • Then there are CLI tools that require manual input; these are impossible to handle in a generic way (interestingly, many executables submitted to VT are student projects and require manual input to produce some results; while not malicious, they pose a significant challenge to sandboxes)
  • The GUI elements can be localized
  • The localization itself is one issue, the other is the fact that localized software, especially the old one, often relies on the old ANSI code pages and ANSI APIs, so you have to guess what code page is being used by the sample’s GUI
  • The GUI elements can be ordered, or not (this may determine which button is ‘default‘ – in the absence of the standard buttons like ‘OK’, of ‘Finish’ this may be important)
  • The GUI elements can be bitmaps so no way to determine what to click… other than via known bitmap hashes, OCR/ICR, or a matrix clicking where you walk through the surface of the window and click every few pixels, moving both horizontally and vertically through the whole window area; it’s prone to errors and may force the app to exit early
  • The GUI elements can be drawn using a HTML code, so you may need to either access it via existing means (eg. via WM_HTML_GETOBJECT) or use Accessibility options (read below about that)
  • Many installers are interactive
    • The Installers often include EULA that has to be accepted (various keys used to accept, depending on language)
    • You may also need to choose options for installation e.g. installed UI languages, destination path, etc.
  • Many installers download other components from the net or drop generic component installers during the installation, so the clicker needs to work across multiple processes w/o disturbing parent while the child process is still being ‘processed’ (e.g. can’t send ‘Next’ to the parent process until the child process exited successfully; for examples, see anything that relies on winpcap)
  • There could be decoy GUI elements (e.g. transparent elements added to fool auto clickers, ad hoc passwords, captchas, etc.)

What can significantly help to code a good clicker is the use of mixed technologies and in general – be ready for lots of tuning:

  • Recognize installer / sample file type and apply appropriate playbook
    • This is very important, because sometimes you can use unattended options, if available
    • You can also try to decompile the installer to extract files w/o GUI
  • In a generic way:
    • If possible, enumerate windows and their children, and recognize standard controls
    • Ensure you you use proper windows APIs e.g. RealChildWindowFromPoint vs. ChildWindowFromPoint/ChildWindowFromPointEx
    • Recognize standard shortcuts/accelerators
    • Recognize default buttons (depends on the sequence of resources compiled into the binary)
    • Recognize ‘Next’, ‘Finish’, OK class of buttons, etc.
    • Recognize button classes in general (substrings: ‘button’, ‘btn’, etc.)
    • Recognize Window texts e.g. ‘Accept EULA’ type of buttons (checkboxes, or radiobuttons)
    • Recognize localized versions of the above
    • Recognize automation possibilities
      • The problem of automatic clicking is actually not reserved to sandboxes only
      • QA testing of any sort relies on it a lot: regression tests for coding and localization projects etc. involves lots of clicking and a huge progress has been made over the years to make it work smoothly, and fast
      • Luckily, many software packages support GUI controls’ automation via IAccessible interface
      • Have a read about Automated UI testing and Microsoft UI Automation
    • Have a look at other large projects where the localized strings for standard buttons are already localized e.g. LibreOffice
    • During windows enumeration search for both Unicode, and ANSI versions of these strings while enumerating windows
    • If no success, consider injecting instrumentation code that is ‘native’ to the installer’s platform
    • If no success, consider OCR/ICRing elements of the screen, or use the Babylon technique of hooking API/redrawing text and catching text printed using Text APIs
    • For Delphi, it’s a mundane task of understanding all versions of their VCLs (I have code some PoC code and it was painful, but I was able to read some labels from Delphi programs)
    • As a last resort, redirect trouble samples to a team doing manual malware analysis so the clicker can be tuned

And just to give you a localization sample… this is a list of ‘Agree’ buttons in various languages extracted from one of the Open Source projects:

  • Afrikaans Regso
  • Albanian Pranoj
  • Arabic موافق
  • Armenian Համաձայն եմ
  • Basque Onartu
  • Belarusian Згодзен
  • Bosnian Prihvatam
  • Breton A-du emaon
  • Bulgarian Съгласен
  • Catalan Hi estic d’acord
  • Cibemba Nasumina
  • Croatian Prihvaćam
  • Czech Souhlasím
  • Danish Acceptér
  • Dutch Akkoord
  • Efik Ami Mmenyịme
  • English I Agree
  • Esperanto Akceptite
  • Estonian Nõustun
  • Farsi موافقم
  • Finnish Hyväksyn
  • French J’accepte
  • Galician Aceito
  • Georgian ვეთანხმები
  • German Annehmen
  • Greek Συμφωνώ
  • Hebrew אני מסכים
  • Hindi सहमत
  • Hungarian Elfogadom
  • Icelandic Ég Samþykki
  • Igbo M Kwere
  • Indonesian Saya Setuju
  • Irish Glacaim Leis
  • Italian Accetto
  • Khmer I យល់​ព្រម​
  • Korean 동의함
  • Kurdish Ez Dipejirînim
  • Latvian Es piekrītu
  • Lithuanian Sutinku
  • Luxembourgish Unhuelen
  • Macedonian Да
  • Malagasy Ekeko
  • Mongolian Зєвшєєрлєє
  • Norwegian Godta
  • Pashto زه منم
  • Polish Zgadzam się
  • Portuguese Brasilian Eu Concordo
  • Romanian De acord
  • Russian Принимаю
  • Serbian Прихватам
  • Sesotho Kea Lumela
  • Shona Ndinobvuma
  • Simplified Chinese 我接受
  • Slovak Súhlasím
  • Slovenian Se strinjam
  • Spanish Acepto
  • Swahili Nakubali
  • Swedish Jag Godkänner
  • Tamil A நான் ஒப்புக்கொள்ளுகிறேன்
  • Thai ตกลง
  • Turkish Kabul Ediyorum
  • Twi Migye Tom
  • Ukrainian Приймаю
  • Uyghur قوشۇلىمەن
  • Uzbek Qabul qilaman
  • Valencian Accepte
  • Vietnamese Tôi đồng ý
  • Welsh Cytuno
  • Yoruba Mo Gbà
  • Zulu Ngiyavuma