[ Pobierz całość w formacie PDF ]
Native API are documented by Microsoft in the Windows DDK [19] and the Windows IFS
kit [21]. Moreover, Gery Nebbett has written an unofficial documentation of the native
API [26], which covers about 90% of the functions in the Native API. Malware authors
sometimes use the Native API directly in order to avoid DLL dependencies and in order
to confuse virus scanner s emulators. For this reason, TTAnalyze monitors not only the
Windows API function calls of an application, but also its Native API function calls.
Native API functions are more uncomfortable to use (they tend to have many parameters)
and they are only badly documented or not documented at all. Consequently, hooking the
native API is more work than hooking the Windows API. Nevertheless, hooking the Native
API is a worthwhile task. It increases the reliability of the analysis. If we only monitored
the Windows API, we could never be sure that the application does not circumvent the
Windows API by directly calling a Windows Native API function.
4.3.2 Architecture
This section gives an overview about the architecture and design of the analysis framework.
Figure 4.2, an UML class diagram, shows the important classes.
6
The native API may change between Windows and service pack versions.
33
InsideTM &QEMU
Microsoft RPC
provides
CRpcClient
QEMU DLL Interface void uploadClientFile(filename);
Rproc_Handle executeSP(filename);
my_qemu_main(int argc, char **argv)
PhysicalAddress getPageDirAddr(..);
my_qemu_set_analyze_callback(..)
resumeExecution(..);
my_qemu_cpu_memory_rw_debug(..)
VirtualAddress getPEBAddress(..);
uses
1:1
CVirtualSystem (Singleton)
static CVirtualSystem* getInstance();
void powerOn(CAnalysisCoordinator, cmdlineOptions)
void powerOff()
void execute(string testSubject, string args)
...
Bit32u getEBP()
Bit32u getESP()
..
Bit8u readMemory(VirtualAddress addr, int size)
1:1
CEventObject
CAnalysisCoordinator virtual void event(const CEvent& event) = 0;
1:*
void registerAnalyzerObject
(CAnalyzerObject*, string , ECallbackMode);
void registerEventObject(CEventObject*, unsigned priority); 1:*
void reportEvent(CEvent&); CAnalyzerObject
CAnalyzerObject* findAnalyzer(string);
virtual void analyze(CTranslationBlock *b) = 0;
CAnalysisInformation* getAnalysisInfo();
void analyzeCallback(CTranslationBlock*);
CDisassembler CFunctionCoordinator
virtual void analyze(CTranslationBlock*); void registerCallback(string& functionName, string& dllName,
CCallbackObject *, EFindMode);
CAnalysisCoordinator* getAnalysisCoordinator();
virtual void analyze(CTranslationBlock *tb);
virtual void event(const CEvent& event);
1:1
1:*
CCallbackObject
virtual ECallBackMode
getCallbackMode(
string& interfaceName) = 0;
CNtCloseInterface
«generated»
CAnalysisInformation
virtual void NtCloseWasCalled(unsigned __int32 Handle) = 0;
void setTsFilename(const string& filename);
virtual void NtCloseHasReturned(unsigned __int32 Handle,
string getTsFilename();
__int32 _functionResult) = 0;
PhysicalAddress getTsPageDirAddr();
void setTsPageDirAddr(PhysicalAddress);
void setTsExitCode(int exitCode)
int getTsExitCode();
CPEFile* getTsPEFile();
VirtualAddress getApiFunction(const string& dllName, const string& functionName);
void addInfo(CInfoItem);
CFileAnalyzer
void printReports(bool fullReport);
Figure 4.2: Analysis framework
34
CVirtualSystem
As can be seen in Figure 4.2, the classCVirtualSystem7 shields the rest of TTAnalyze s
source code from QEMU.CVirtualSystemis the only class that talks to QEMU. The
rest of the system talks toCVirtualSystem. If we replace QEMU with another emulator,
we will only have to change the implementation ofCVirtualSystem(and probably the
emulator itself).
CVirtualSystemprovides methods for reading the registers of the emulated CPU, for
reading the virtual system s main memory, for starting the system and for stopping the
system. Most importantly, it provides the method execute. It is used for running the
test-subject in the emulated environment.
CVirtualSystemis a singleton-class (i.e., only one instance of this class can be created).
This makes sense because qemu.dll is not suited for running multiple emulator instances.
Moreover, it provides every class in the analysis-framework with an easy way to obtain a
reference to the virtual system.
CVirtualSystemdepends on the classCRpcClientfor communicating with the In-
sideTM RPC server, which runs inside the virtual system. CRpcClienthides all RPC
interaction behind its interface.
CAnalysisCoordinator
The classCAnalysisCoordinatorcoordinates the analysis work. EachCVirtualSystem
instance has exactly oneCAnalysisCoordinatorinstance assigned. SinceCVirtualSystem
is a singleton, only one instance ofCAnalysisCoordinatorexists. In the following, the
analysis coordinator refers to this single instance ofCAnalysisCoordinator.
The analysis work is distributed among several analyzer objects. An analyzer object
is an instance of a class that implements theCAnalyzerObjectinterface. For exam-
ple, TTAnalyze has two analyzer objects. There isCDisassembler, which disassembles
a translation block, and there isCFunctionCoordinator, which we explain in the follow-
ing paragraph. Each analyzer object has to be registered with an appropriate instance of
CAnalysisCoordinator by calling itsregisterAnalyzerObjectmethod.
CAnalysisCoordinator sanalyzeCallbackmethod is indirectly called by QEMU
before a translation block is called. Note that QEMU executes a sequence of instructions,
called a translation block, at once as explained in Chapter 2.3.2. The analysis coordinator
performs some basic analysis work, but its main task is to call back all registered analyzer
objects, whenever QEMU is about to execute another translation block. To be precise, the
[ Pobierz całość w formacie PDF ]