- About us
- Code of Conduct
- Google SoC
- Recent posts
- Security Workshops
Today Apple unveiled the next generation of OS X, Lion and new iOS 5. Among the features, I'm concerned about two features: AriDrop and iCloud.
There is a paper at WOOT 10' described how to use smudges on the touch sceen of a smartphone to get largely decrease the time an attacker need to guess the right password to unlock the screen. For example, by for 4 passcode based iPhone, one just need to try at most P(4,4) = 4! = 24 times before he get the right one.
I'm developing a syscall interception tool for Android as a course's project. While it is relatively simple to intercept calling into the system services (introduced at the end), it is harder to get the syscall return. The reason is, the latest Android emulator is build upon QEMU 0.10.50, meaning it's TCG based. So we cannot use the same way Qebek or TEMU uses to intercept the syscall return. Therefore I looked into the new code to find if I could find a way to solve this problem.
Generally, in my understanding, in the old QEMU, the code translation is done as:
Here is a brief introduction on Qebek, answering some questions.
As the console spy is almost finished, the next stage is mainly for network activities. Sebek Win32 version uses TDI hook to get this done. However, since getting driver object in virtualization layer is hard and TDI is TDI is on the path to deprecation, I need to find another way. The best solution seems to be hooking NtDeviceIoControlFile, the API Windows uses to do network related stuff and has been widely mentioned in malware behavior analysis papers. After some days of searching, I encounter a very useful resources today, a master thesis from TTAnalyze team:
This phenomenon is first observed when I tried the NtReadFile test last week, sometimes when the postNtReadFile is called, the handle value, buffer address and buffer size got from the stack is quite different from values got in preNtReadFile. I didn't pay much attention to this problem that time, but, when I tried to debug the NtSecureConnectPort API with WinDBG today, this phenomenon appeared again. So I did a further study on it.
First, I set a break point at nt!NtSecureConnectPort:
This is supposed to be the first Qebek blog, but unfortunately, it cannot pass the check of mod_security (even today), so I posted here.
When using hooking technology to intercept system calls, there are two different places to collect information: before the original function is called (precall) and after the original function returns (postcall). For example, in Sebek Win32 client, when callback function OnZwReadFile is called, it first calls the original function s_fnZwReadFile, after the original function returns, it checks whether the original call succeeds, if does, it then calls the data collection function LogIfStdHandle:
Sebek Windows client has two keystroke sources, one is read or write std stream, the other is csrss port. In the callback function of NtReadFile and NtWriteFile, Sebek will check if the given file handle match one of the three standard stream handles. if matches, it then logs the given data of keystrokes:
One difference in Qebek from other existing virtualization based honeypot monitoring tool is that I want to 'hook' the function of system service instead of the dispatcher, more precisely, the 'sysenter' or 'int 2e' instruction. This is similar to the difference between SSDT (System Service Descriptor Table) hook and kernel inline hook. However, doing it this way must face a problem: how to get the function address? One way is get it directly from SSDT.