Powered By Blogger

Friday, September 7, 2018

Recon 2018 day 3

This dump is puzzle

The talk is about  the methodology followed by the researcher to extract GSM APN credentials from an eSIM on IOT gateway device (the device bridges LPWAN to GSM/Private APN).
The challenge that had to solve the researcher here after dumping the chip is to construct the fragmented Zip files chunks (J2ME data). 

The researcher considered that a zip file contains a lot of metadata and structures (Ange Albertini ). Then the idea is to find clues to spot these metadata and write a puzzle solver.

So the approach consists in finding within the Zip file the End of the Central Directory. that gives the final record in a zip file, the total size of file headers and data and the total number of file entries.

Some complications were faced during the implementation of this idea as the fact that basing on the signature of the End of the Central Directory (PK\x05\x06), two instances can be found in the dump. That explains the need to classify fragments. For classification automation the researcher decided to apply K-means clustering method.


Slides can be downloaded from here.

Sandbagility - Reverse Engineering Framework for Windows dynamic analysis

The talk was about a malware analysis toolset based on a modified version of virtualbox and fast debugging protocol. The objective of creating this kind of environment is to avoid having an agent (like a driver) on the guest.

So the talk gave

  • an overview on the state of the art of malware analysis and fast debugging protocol 
  • a detailed explanation about Sandbagility 
  • an overview about some techniques implemented by the tool  


Slides are here.

A Code Pirate's Cutlass

The speaker tackled here a serious problem in reverse engineering. The context of his research is vulnerability analysis for embedded devices. Generally, in this context, a reverser has to deal with a single and large binary where there is no distinction between application threads, libraries and operating system. Within this all mess, understanding the software architecture is critical for the reverser.

The researcher defines the CodeCut problem as the result of liking multiple object files (multiple compiled source files) into one huge binary file (concatenation of the object files).

So given a call graph can reverser recover the different regions of the program (identify the boundaries of the different object files) ?

The speaker mentioned here that he blocked when he decided to solve this problem by using graph theory algorithms (scaling problems). So he decided to approach it as a numerical problem and introduced the LFA (Local Function Affinity) concept. And the receipt (As I got it):

  • If we eliminate external calls 
  • Directionality of calls at the beginning of the module is in the positive direction
  • Directionality of calls generally switch to the negative direction towards the end of the module
  • We can detect edges by finding the switch from negative back to positive

I'm not a math guy, if you're interested, you will find a math definition of LFA.

The tool is not  yet published but the speaker noted that he'll open source it as a futur work.

You can check for the slides here.

Taint-based return oriented programming

Sorry but I did not take much notes here and unfortunately the speaker did not published his slides.

After a brief introduction about ROP exploitation techniques, the researchers presented an approach based on taint analysis to identify a ROP chain. T-Brop is a tool that implements this technique.


Modern Linux Malware Exposed

The speakers begun their talk by stating that real life malware analyst does not turn only around Windows malware.
Then all the talk, as far as I'm concerned, a comparison between Windows and Linux malware in terms of stats, protections , obfuscation , packing and analysis techniques?


Slides are here.

Analyzing TRISIS - the first Safety Instrumented System malware

That was one of the talks that I really appreciated.

The talk is about REing an ICS malware code named TRISIS. This latter targeted a gas facility in Saudi Arabia (August 2017). The malware targeted the Safety Controller and caused a system shut down.
The SIS (Safety Instrument System) controller is a programmable logic controller designed to shut down a platform or a reactor safely. In a nutshell, This equipment is designed to protect people from being injured.
Basically, hacking a SIS doesn't mean that you won. You still have to overcome fail safe mechanism.
The attack consisted mainly in compromising a SIS-connected workstation, and then rebound to SIS system.
TRISIS malware components are:

  • SIS rootkit 
  • PC applications : TRilog.exe, py2exe 
  • 3 PowerPC payloads
  • A 4th unknown payload

The researchers introduced then Triconex hardware specifications that help them to start digging into the code. Blocked by some memory offsets located in the malware code they bought a Triconex controller. They explained then how they extracted and disassembled the Triconex firmware.


Slides can be downloaded from here.





Friday, August 31, 2018

Recon 2018 day 2

After a short break (I had to teach the sec 504 in Paris for a week) I had finally the time to carry on parsing my hand written notes taken in recon Montreal 2018.

Tracing Struct accesses with struct stalker
First all let me mention that this tool works only at source code level. Yes, I was bit disappointed when I knew that. As you know C++ reversing is a very time consuming process and the tools that already exist and work at binary level depend on a lot of parameters (compilation chain, compilers, IDA version, etc). The second point that made more disappointed, is that when you read the talk title you guess that you're going to learn a lot about how identifying C++ structures techniques. The talk was more about LLDB internals than the tool itself!

The speaker started his talk by introducing libfuzzer (LLVM project). He pointed out that this tool mainly takes an entry point as an argument, but he underlined the fact that you might encounter some problems when you want to fuzz some arbitrary code that takes complicated structs. That was the main starting point that motivated him to write "Struct Stalker" tool by monitoring accesses to structures fields. To solve this latter problem, the researcher used the techniques of a second tool (Pointer Sequence Reverser)developed by his colleague (Nicholas Collisson).

Before moving to the main part of the talk, which deals with LLDB, he demoed "Struct Stalker" tool. Normally you can get the tool here, but once again I got a 404 error when writing this post.

The main part of this talk , as I said before, was about the lessons learned bout LLDB during the development of the previous tools. So the speaker went trough a lecture about LLDB:

  • OK, at first glance LLDB , LLVM debugger ,seems to be compared to gdb, pretty scriptable and can deal with source and binary code.
  • LLDB uses .lldbinit (as .gdbinit) where you can set your favorite parameters as settings set target.x86-disassembly-flavor intel
  • Most useful LLDB commands : process, handle,status, continue, disassemble, breakpoint, thread, frame,memory, target, expression.
  • LLDP exposes a python API (not very documented) : public API are prefixed by SB: SBBreakpoint, SBDebugger,SBTarget,SBProcess,SBThread,etc.
  • Regarding LLDB python script skeleton(see slides), it should be noted that to setup a breakpoints you should write a callback function which can be sometime magic.  


At this time I stopped taking notes, as far as I'm concerned this kind of content like LLDB internals can be read quietly with a cup of coffee so I won't bother you by these details.

You can check the slides here.


Static instrumentation based on executable formats
The speaker presented a framework called LIEF. The idea behind this framework is to modify an executable structure (PE, ELF, Mach-O,etc) to do static instrumentation.
So modification that can be realized on the executable structure as: changing segment permissions, disabling ASLR, will be then managed by the OS loader and then the kernel.

Here LIEF comes to hand, this library developed in C++ exposes a friendly API and different languages bindings (Python,etc).

Some interesting modification that can be achieved by LIEF are

  • Hooking: by adding for example a trampoline code into the import table
  • Exporting hidden function 
  • Code injection through shared librairies

Finally, the speaker presented how FRIDA can be combined with LIEF to instrument Android applications. This technique consists in adding two files (libgadget.so and libgadget.config.so) into the target APK.


Slides can be downloaded here.

Discovering the iOS Instrument Server
Troy Browman goal's through this talk is to share his experience of reverse engineering Apple Instruments server.

So what is an Instruments server ?  The speaker defines as a set of debugging tools as Time profiling, Leak checking, Tracking file I/O,etc.
The main question that the speaker attempted to answer is : How OSX Xcode side communicates with the iOS instruments server ? For that he started by analyzing how Xcode queries the Instruments server for the processes list.

The first step of the analysis consists in identifying the Service in charge of implementing Instruments server.  That lead to DVTInstrumentsFoundation binary where core functionalities of Instruments server are located.

In that binary, the method DTDeviceInfoService runningProcesses seems to be the one called to list processes. The problem then is no cross call to this method is found.

The speaker introduced at this time the notion of DTXMessage. This latter is a class in charge of  serializing/deserializing Objective-C messages. More interesting fact about this class, is that DTXMessage  is a mechanism for transmitting Objective-C messages over the network.

To create a DTXMessage, the speaker decided to write a tool (dtxmsg)  to log this type of messages and replay them. By the way, he presented the structure of a DTXMessage. The RE of this component helped him to write a second tool called dtxmsg_client to send his own DTXMessage buffers.

Slides can be downloaded here.

Bushwhacking your way around a bootloader

What I remember about this Talk is how the speaker managed to keep calm even if she noticed the she was presenting the wrong version of the slides :).
So I won't bullshit you here I tried to take some notes but I was lost after a while. It is all about an analysis of u-boot.  A great summary of the talk can be found here  and the slides here.


Exploiting User-land vulnerabilities to Get Rogue App Installed Remotely on iOS 11

Yeah, KeenTeam dropped a bomb again in this talk. These guys are really amazing !
In this talk the team presented their methodology used during Pwn2Own 2017 to pawn an iOS 11.
The talk was organized as the following:

  • iOS remote exploitation chain overview 
  • Sandbox bypass and explnation of the used Bug (CVE-2017-7162)
  • Rogue application installation 
  • Demo
  • iOS 12 hardening 

Globally th exploitation scheme that is followed for iOS exploitation can be described as below:



For the Pwn2Own challenge there is no need to go for a Kernel bug to escape the Sandbox, the team said. However, they have to respect the OneClick policy that states that the exploit chain has to disable all the popups and alert messages.

For the Safari code execution:

  • OS sandbox is enforced by process , but some crticial daemons don't have sandbox launched
  • All 3rd webcontent app are applied with Sandbox profile
  • Sandbox configuration is compiled 

The strategy then is :

  • Not use a kernel bug 
  • Find a service/daemon with no sandbox 
  • That service has to be reached from Safari Sandbox 
  • For that purpose, a tool to review each process  and check Sandbox profile has been written (sb profile  =0)

One of the candidate service was Backboardd:

  • No Sandbox 
  • Complex MIG (Mach Interface Generator) interfaces (you can use jtool to list MIG interfaces)
  • reachable from Safari 


Regarding the exploitation the following CVEs were used/explained by the team:

  • CVE-2107-13861 (iOS/MacOS kernel double free due to IOSurfaceRootUserClient not respecting MIG ownership rules)
  • CVE-2017-7162 (Double free in backboardd)

The speakers explained then their techniques to exploit the double free vulnerability ,
a race condition (brute force approach is not stable, user instead OOL serailized messages with a slow parsing using CFAllocCtorAllocate with 0x20000 size instead of CFObject)
and how they bypassed ASLR (iOS share the same dyld_shared_cache_base) .


The last challenge that the team had to solve was code signing . In iOS CodeSign is enforced on code. All code must be signed by Apple, by a developer or by an Entreprise (in this two last cases a user interaction is required which is not compliant with the One Click Policy).

Webclips seems to be the solution. It appears that this not documented technology allows to install an HTML based application. The team then adopted the same approach as Pegasus APT. The technique consists in using a jsc script to trigger the vulnerability. Before that the content of the script into /Library/Webclips/Keelab/Exploit.html with an info.plist file(ULR= Attackerwebsite and fullscreen= TRUE to not open Safari). Exploit.html file will trigger the bug and bypass the SandBox  and install a rogue app.

Finally the team ended their talk with a Demo of iOS 12 jailbreak !


Malware Analysis and Automation using Binary Ninja

Actually, I was a bit disappointed by this talk. Yeah the speaker attempted to promote a potential great tool Binary Ninja, but she (in my point of view) did not present a real case with real challenges that tried to solve using Binary Ninja. Instead she went for a description of the tool. Ok may be 5 slides are sufficient to introduce the tool.  Yeah !In the slides , you'll find some slides about PlugX but it still the tool description took a lot of place in the talk.

Also, I do not agree with people who always try to compare a new tool to IDA pro.  IDA pro is IDA pro full stop.


Slides can be downloaded here.


An Open-Source Machine-Code Decompiler
The talk is about RetDec : a tool for machine-code decompilation based on LLVM.
Actually RetDec is a set of Reversing tools chained together to get a generic code decompilation tool.
The core is based on LLVM and supports mainly 32 bits architecture as x86, ARM, PowerPC and MIPS.


RetDec starts by preprocessing a binary to extract as much information as possible from it. Indeed, this phase calls a set of file format libraries to get a binary representation of the the given file and then process it to identify the use of potential packers (yara signatures). The tool embeds a set of unpackers in addition to Avast unpacker to get the original binary image.

Another layer/tool that is implemented in RetDec is Stacofin which can be useful to detetc statically linked code.

FileInfo, is a tool in RetDec suite that can parse a lot of binary formats (PE, ELF, Mach-O,etc) and returns the results in json format.

RetDec core is based on LLVM and is in charge to transform the binary machine code to LLVM IR (using Capstone engine -Capstone2LLVMIR):

  • hand coded sequences for core instructions
  • Full semantics for only simple instructions

It is interesting to underline that RetDec can be used from IDA pro by adding RetDec plugin.

Slides can be downloaded here.


Unknown Known DLLs and other Code Integrity Trust Violations

No word can be said here to describe this talk. Alex Ionescu and James Forshaw did a great job !
I'll try to describe as much as possible their talk even if the content was very dense regarding the time slot they were given to speak.
Unfortunately, the slides are not available yet, so you have to wait a bit more ...

I put here all my notes, may be they are incomplete or even not accurate.


So the talk was about code integrity technologies in Windows and the flaws in its robustness. For that some notions were firstly explained by the speakers:

  • Background on Windows code Integrity 
  • Protected processes 
  • Signature caching
  • Trust SIDs and Trust ACEs
  • Trust links in Tokens 
  • Known DLLs and mSection Object Mappings 

Code Intergrity technology can be distinguished for:

  • Kernel Mode Code Signing  (KMCS): with x64 an secure boot  windows drivers must be signed to be loaded. And from win 10 an extended validation certification was added  
  • User Mode Code Signing (UMCI) -v1: from windows 8/surface. An application can be 
    • 0->Unchecked, 1->Unsigned, 4->Authenticode, 8->Microsoft, 12->Windows .
  • User Mode Code Signing (UMCI) -v2: Fine grained signed levels (1-15)
    •  6->Store, 7->Anti Malware, 14->Windows TCB 

Protected Processes :

  • Deployed from Windows vista for DRM 
  • From Windows 8.1 Protected Processes Light (PPL) mechanism was deployed (Lsass.exe, Antivirus processes are protected)
  • Hierarchy of process protection levels (Matrix)
  • PP/PPL are used across the system and expanded dramatically by Windows Defender 
  • PP/PPL is not a security feature

When a binary is loaded, CI checks are carried out to specify its context ( if the process is PP/PLL, policy, cache,etc). These checks depends on the machine (Phone, Xbox, Defender,etc) . CI module reads the DLLs on the disk.

Different cache levels exist :

  • First on the disk cache 
  • Second : once the image is proven 
  • Third : once mapped (no checks)

James Forshaw tool (sandbox-attacksurface-analysis-tools)  has Get-NtDirectory cmdlet to get information about KnowDLLs:

$d = Get-NtDirectory \knownDLLs
$d.SecurityDescriptor.ProcessTrustLabel

Unknown DLLs are loaded at boot then mapped.


Here, the question that the speakers will answer is : How to break the code signing a the beginning ?

To create a protected process service  (Admin Only)
CreateProcessW (...,CREATE_PROTECTED_PROCESS,...) and the code ahs to have a correct signature

Trust SID : SID which defines a partial Trust : S-1-19-XXXX(process level)-YYYY(signer level)
(see RTLSidDomainForestTrust)

$p = New-Win32Process -creationFlags suspended,ProtectedProcess "....exe"
$t  = Get-NtToken -Primary -Process $p.process

Trust ACEs:
SYSTEM_PROCESS_TRUST_LABEL=ACE_TYPE, you can read unknown DLLs and write unless you are a PPL process (majority of files on Windows ara catalog files signed).

Kernel Extended attributes (EA):

$Kernel (can only set by the Kernel)
$kernel-purge (don't look at it again)

EA.bin : EA cache format : _CI_ESB_EA_V3 / _CI_DATA_BLOB


Who sets the cake ?
NtSetCachedSigningLevel (undocumented API). The API allows a caller to set "validated" level ("Trust me") as long as the caller is PPL. Flag 0x02 and flag 0x40.

For driver signing the cache is not trusted at all.

Section creation bugs:

NtSatus NtSetCacheSigningLevel {
Flags --> 0 (needs ppl)
               4 : to cache the signature
}

CVE 2017-11830


PPL cache attack:

Win the race as we are PPL (flag 0x02), write  flag 0x40.

The USN Zero change journal Rebirth
Attempt to change USN journal before a change (CI does not check USN0 assumes it is signed) --> need physical attack.
Once you delete USN journal (USN has unique 64 bit ID however they are not randomly generated) , create a new one.
This case has been patched, you can not delet USN Journal.


The cached signing level duality
CVE 2018-8142

Section Mapping bugs
Abusing Known DLLs : write in KnownDLLs?

In conclusion , that was interesting to see how CI can be bypassed.




Monday, June 25, 2018

Recon 2018 day 1

Recon the con ! 

Recon is a very famous Reverse engineering oriented conference held  in Montreal. This year I had the opportunity to attend this year Bruce Dang training training and the conference.
My first feedback is that this conference is an amazing one for those interested by computer security in general and in reverse engineering in special. And Let me tell you that this year the conference materials was extremely mind blowing !

Before I go for a summary of the main notes that I took, here are the best talks in my point of view. I put them following their  given slot in the the conference:
  • Day 1 
    • Reverse Engineering Windows Defender Part II (Alexei Bulazel)
    • PreVice: Static Detection of Hooking Capabilities in Machine Code (Andy Wortman,Claudiu Teodorescu,Derek Soeder)
    • Meet Salinas, the first ever SMS-commanded Car Infotainment RAT (Daniel Regalado,Ken Hsu, Gerardo Iglesias)
    • Pwning Intel PIN(Julian Kirsch,Zhechko Zhechev)
  • Day 2 
    • Static instrumentation based on executable file formats (Romain Thomas)
    • Discovering the iOS Instruments Server (Troy Bowman)
    • Exploiting User-land vulnerabilities to Get Rogue App Installed Remotely on iOS 11 (Liang Chen, Marco Grassi)
    • Unknown Known DLLs and other Code Integrity Trust Violations (Alex Ionescu, James Forshaw)
  • Day 3 
    • Analyzing TRISIS - the first Safety Instrumented System malware (K. Reid Wightman, Jimmy Wylie)
    • SiliVaccine: North Korea's weapon of Mass Detection (Mark Lechtik, Michael Kajiloti)
    • PWN Flash with Reflection and HashTables (Tao Yan, Bo Qu)

Reverse Engineering Windows Defender Part II
You might go and start following this guy on Twitter, his talk is one of the best that I can recommend.  His previous studies concern inner working of antivirus engines. The talk, which can be considered a second part of a fist talk.

The speaker explains in his talk the methodology that he adopted to reverse Windows Defender Antivirus engine and sheds light on all the challenges where he struggled during his analysis. The cool thing that I appreciate in his talk is the fact that he went through the talk smoothly by insisting on the process itself and not throwing technical details ont the face of the attendees. 

Windows defender is a the builtin Windows antivirus engine, that run with SYSTEM privileges in an unsandboxed process. Alexei's research focuses this time on reing the binary emulator in charge to scan malicious code.
The Antivirus engine is an emulator (not virtualization) that loads an unknown binary, run it from its entrypoint and collect observations basing on various heuristics. For that the emulator has to manage to emulate the cpu, OS, OS Api and the environnement (filesystem, processes, settings,etc).
Alexei's used his previous works about antivirus engine that allowed him to develop techniques for introspecting the antivirus engine and leaking his internal structures and functions. 

The main targets of the research are:
  • Microsoft Malware Protection Engine: mpam-fe.exe 
  • Microsoft Malware Protection: mpengine.dll
  • Signature Update Stub: MPSigStub.exe
  • Signature databases
    • mpasbase.vdm
    • mpasdlta.vdm
    • mpavbase.vdm
    • mpavdlta.vdm 
The analysis process as for each reing project consisted in :
  • Static analysis phase : using IDa pro, public MS Pdbs and bindiffs basing on Google Project 0 findings. Some other tools were used especially for code coverage as Lighthouse IDA plugin  and Taviso's Coverage tool.
  • Dynamic phase: this one seemed to be complicated knowing the defender components run in a protected Windows process and the scanning process may not be triggered on demand and that could reduce the code reachability.  That where Taviso's tool comes in hand, LoadLibrary and especially mpclient.exe allows load Defender engine and exposes its interfaces. Alexei's demoed this tool the main workflow was : mpclient.exe Eicar.com --> WinApi emulation --> _rsignal(Defender engine interface)  --> Engine emulator. 
Reing the engine components allowed to make some observations: When a malware is getting emulated, _rsignal (main entrypoint) function is called, it takes a buffer as an argument. The emulation initialization step starts then to allocate memory, init various objects, load the binary, init emulated DLLs and start recording heuristics. The cpu emulation consists in a dynamic translation of instructions (IL lifting : IL-tox-86 Jit translation). 

For emulator instrumentation task, the idea was writing a custom malware that can install a hook in an internal engine structure called g_syscalls (Winexec). And for mapping emulator adresses a hook has been installed on OutputDebugStringA. However, a binary might not be emulated if it has some characteristics(low entropy, linking against unknown DLLs).
Alexei's then explained how he dumped the virtual file system and virtual processes (apparently using the same trick as OutputDebugStringA).

Windows API emulation seems to be based on two DLL types: 
  • Emulated ones : VDLL, that stay inside the emulator, and complex ones are coded to return hard coded valus
  • Normal ones: triggers a syscall outside the emulator.
The UM-KM emulator communication is carried out using an internal emulator instraction function called api_call that takes as arguments : crc32(Dll_name) ^ crc32(dll_function). The disaseembky of api_call still a challenge and may be presented in a future GTFO || POC paper. 
api_call links emulator Apis to the outside world.

Kernel emulator functions are embedded in native code. This kernel has its own Object manager but the managed objects are fewer than a normal kernel, there are aonly : File, Thread, Event, Mutant and semaphore objects (dt mpengine!objectmanager.FileObject). Objects are stored in a map 

Last but not least, Alexei exposes some intersing Defender engine functions : MpaddToScanqueue, MpCreateMemeryEngine and MpReportEvent.

Finally, Alexei pointed out that mpengine.dll embeds also other components as unpackers, parsers, scanning engines,etc. And It might be interesting to bootstrap a research project on that. Main developed code will be published at BH.

NB: Emulator IL was not dumped but it can be doable.

Cloudy With a Chance of Malware
I was not very excited by talk may be because I'm not interested by Threat Intelligence field. However, I'll try to stay partial when writing my notes.

Marika Chauvin presented a comparison between two malwares KasperAgent and  Cloudy in order to highlight their differences and similarities.
The story begins with KasperAgent which seemed linked to Micropsia Android malware. The first campaign was in May 2017, one of the main indicator related to this malware was the use of a specific User Agent : OPAER. This malware targeted Palestinian authorities using fake administrative documents. Some pdb strings seem to be used by this malware.
The analysis of KasperAgent allowed to spot a second variety called Cloudy, however the attack vector used by this malware consisted in fake document used to be exchanged between inter-nation relation states.
At the opposite of KasperAgent, Cloudy malware target other countries as : Israel, India and UAE.
Both malware were attributed UAE.

SiliVaccine: North Korea's weapon of Mass Detection 
That was an interesting talk where the speakers shed light on some shady zones inside a north Korean antivirus known as Silivaccine.

First of all, Checkpoint resarchers said that they obtained the antivirus from Martyn Wiliams who's a journalist specialized in North Korea.
After its installation, the speakers presented the general picture of the antivirus architecture. The antivirus components can be splitted into:

  • UM components: SVshell.dll, SVkernel.dll (file scanning engine), SVregsrv.dll, SV2Tray.exe, SVupdate.exe, SVDiffUpd.exe (integrity checker), SVMain.exe and SVdealer.exe
  • KM components: SVhook.sys, SVstdi2.sys (supposed to hook tcp communication but it does nothing), SVFiltmsg.sys

During their investigation, the researcher stumbled from surprise to surprise. Looking at the strings, allows them to spot a DLL name (vspai32.dll) which belongs to Trend Micro Antivirus. In addition to that the bindiffing between Silivaccine and Trend Micro dlls resulted in 100% match and similar call graphs. The only differences concern inlining some functions in Sillivaccine (that might let suppose that Silivvacine has access to some source code) .

As Silivaccine has potentially the same antivirus engine as TrendMicro, Checkpoint researchers wondered if it has the same database signature format.  Hence, they find that Silivaccine has added an encryption layer to Trend Micro signature databases (using "Pattern Encryption" as an encryption key in Korean keyboard). Moreover, Silivaccine authors modified the naming convention of the virus  and malwares that can be identified (TM : MAL_NUCRP_5 becomes mal.nucrp.f in SV) . By the way they discovered that this malware is white-listed by SV even this specimen is a generic one. They did not come across about the reason of this exception.

 Regarding KM drivers, it seems that they were packed using an old Russian packer (simple xor with 0x42):

  • SVFilter is loaded by SVdealer.exe and it's in charge of real time scanning and protection of SV binaries
  • SVhook.sys: loaded by SVMain.exe and only query kernel objects without any hooking techniques and contains a lot of code that is never used.

Some coding styles made the analysis funnier. For example, the researchers spotted that in a UM component the length of a buffer can be set to a fixed value (0x12) and when the KM module receives the buffer it checks its length as : if ( len(buffer) == 0x12 return ERROR). Maybe the two modules were written by two different person who does not communicate.
Another joke concerns the use of  debugging message with IDA pro names : Dbgprint (" sub_xxxx bah"), which may indicate that SV authors dumped a lot of code from their TrendMicro reversing sessions.

The last part of the talk  focused on Silivaccine origins. Different hypothesis were emitted here (STS tech service: a ghost company, a collaboration with a Japanese company).
In all cases, it seems that Silivaccine is distributed with a MS patch signed by Kaspersky and that latter corresponds to Jaku malware first stage (may be because it targeted Martyn Wiliams).


Building a Damned Good Watch
Actually, this field is not my cup of tea. However  Travis Goodspeed is a passionate security researcher and he's able to communicate his passion. So let's see if I picked up something or not !

So yeah Travis one day dreamed about "a nifty wristwatch. It would have years of battery life, with an MSP430 microcontroller and RPN calculator. It would be able to receive and transmit on amateur radio frequencies, in a variety of digital modes. It would look spiffy."

I suspect that you guess it, it's better for you to go to his blog and read the article, either I'll confuse with my notes.


PreVice: Static Detection of Hooking Capabilities in Machine Code
The main idea if PreVice tool is to detect hooking capabilities in Windows PE before it happens. The speakers began their talk by a demo of the tool. Then the went through a brief introduction of the different hooking (Unsanctioned interception of execution, unofficial, no contract) techniques. They distinguished between:

  • Code hooking (detours): export and import table
  • System Call  : SYSCALL, SYSENTER, MSR, IDT and SSDT

Before presenting the internals of PreVice tool, the speakers gave an overview of existent tools:


The static analysis approach exposed by the speaker consists in considering a program as a set of functions that gives a state instead of taking it as state that changes during the execution. The main challenges that they fixed are performance and accuracy.

So, Previce inner working includes:

  • Code machine to instructions translation 
  • Constraint propagation 
  • Symbolic execution
  • Type information propagation  
  • Static Single Assignment (SSA)  

Having a code view of the code they can apply a set of signature to identify potential hooking regions  (ex: FS → TEB → PEB → ImageBase → ImortTable).

Meet Salinas, the first ever SMS-commanded Car Infotainment RAT
This talk was just amazing, the speakers were very enthusiastic and engaged in their explanations.
The idea here is to find a way to compromise a car infotainment system by targeting the car driver (especially his phone) instead of the car directly.

The first challenge that they had to overcome was to find an Infotainment system and its wiring diagram. Moreover, the infotainment ideally has to be an ARM architecture with a bluetooth stack, a CAN bus, USB and ethernet  plug.

The first step that they achieve, once they got their Infotainment system (201B 0920-201B) is they got a shell access (after a port scan that pops up a SSH access and a password brute force attack).

To have a persistant access to the Infotainment system, the researchers exploited similar to Windows Service management (SCM) based on a configuration file (sm.conf) to add a new service after remounting system partition in read/write. This service will be used a component in the RAT design.

Before introducing how the RAT actually was developed, it is interesting to know that some Infotainment internal architecture. This latter is organized around the MMUI -Multi Medi User Interface (an opera browser + local webserver + websocket) . The MMUI is linked to other components (Service manager, Radio, GPS, Bluetooth stack, CAN bus,etc) over DBUS.

To interact with these different component, the speakers discovered a test application left by the vendor that can be configured using a xml file to trigger specific tests. Thus reversing this application allowed them to understand how to communicate with these components. By the way they crashed at this stage their infotainment 3 weeks before recon CFP closing. Hopefully they got a second access through an UART port.

Analyzing the communication between MMUI and a linked phone via Bluetooth, it was possible for them to understand how a SMS is handled by the Infotainment system.

Infotainment --> MMUI --> MSG interface/DBUS --> BDS (Bluetooth Developer Studio) --> Phone

  • Receiving a SMS triggers an event in BDS 
  • BDS sends a notification over DBUSto MSG interface (service)
  • At the other hand  the MMUI usi MSG interface apis to to respond to an incoming SMS 
  • The SMS is stored then in a local sqlite DB (not encrypted)
The last that they have to resolve before completing the RAT is to identify the phone number linked to the car. For that they opted to sniffing DBUS communication (use dbus_monitor and dbus_send).

Finally, the attack demo consisted in:
  • connecting a USB key with Salinas RAT to be installed on the Infotainment system
  • Disconnecting the paired phone 
  • Intercepting the new pairing session 
  • grab the phone number by sniffing DBUS communication 
  • send SMS commands to the paired phone that will transfer it to the RAT.
I hope that I did  not missed a point !