Yesterday I wrote about load time DLL injection and of course somebody (Jurriaan Bremer of cuckoo sandbox) pointed out that there is of course a pre existing tool. Specifically his inject tool that is part of cuckoo sandbox. The tool uses
QueueUserAPC as the way to execute code within the process to call LoadLibrary.

updated: March 6th 2015

I couldn't figure out what the exact difference is between QueueUserAPC and CreateRemoteThread in terms of when it is executed. The RemoteThread only executes while the program is running and if it is running it will execute code. I don't see the obvious difference for QueueUserAPC. I will read up on this but so far I will just continue with my actual project.
For my project I need the guarantee that I can run my code first. That is why I went through all this hassle.

The important information from the QueueUserAPC documentation is:

If an application queues an APC before the thread begins running, the thread begins by calling the APC function. After the thread calls an APC function, it calls the APC functions for all APCs in its APC queue.

This means: if you start the process in suspended mode and call QueueUserAPC before resuming the process the APC function will be called before the thread starts executing.

In my recent adventures into MS Windows land I needed to inject a DLL into a process at load time.
The DLL should hook the program's entrypoint so that it can take control over certain aspects of the process before
the actual program executes any instruction.

I thought that this must be a long solved problem and searched the web for an answer. I found 1001 ways to
implement DLL injection but most of them do not support load time injection and non of them supported load time injection and
hooking the entrypoint.

One solution that is very close to what I need is the AppInit_DLL mechanism. Also various sources on the Internet claim that AppInit_DLL is unstable I didn't have any issues with it in the last couple of month. The issue with AppInit_DLL is that it relies on User32.dll to be used by a particular application. Most applications use it but if User32.dll is not in the application's import list in the PE file but the application loads it manually using LoadLibraryX the AppInit_DLL injection happens too late.

When I started looking into load time DLL injection I had a hard time finding anything useful. The most useful
information I found was this blog post on Injecting DLL into process on load. Their technique worked by overwriting the program's entrypoint
with an endless loop (JMP $-2) to get the process running without executing any code. While the process is looping they
attach a remote thread that calls LoadLibrary to inject the their DLL.

The problem with their approach is that the injected code can't take control over the entrypoint itself. Simply overwriting the endless loop with a jump to DLL code is possible but creates a race condition that mostly leads to NOT being able to hijack the entrypoint from the injected DLL.

The second problem is ASLR. Their code didn't support randomized processes.

The solution I came up with uses pydbg to load the process and carry out the injection.
I also use an endless loop that I place at the program's entrypoint. But my endless loop has a defined
exit, it checks if a register value is non zero and the jumps to the address in the register. The
injected library's DLL main function just needs to write the address of it's entrypoint hook to the specific
memory address to over write zero in the load register instruction (mov eax, 0x00000000).

loop:
mov eax, 0x00000000;
cmp eax, 0x00000000;
je loop;
jmp eax;

The second novel part is to resolve the ASLR problem. I do that by adding a small feature to pydbg that
allows to set a callback for the initial breakpoint on application load. The tiny patch for pydbg is here: pydbg.patch. That breakpoint is late enough that
we can call enumerate_modules() to determine the load address of our executable.

The actual steps are listed below:

load executable (pydbg)

register initial breakpoint callback (pydbg)

when initial break happens

retrieve the base address of the executable module to calculate entrypoint (needed if ASLR is present)

TelcoSecDay @ Troopers looks pretty awesome. Too bad that I can't go because of the 100% overlap with CanSec. Sadly this seems to be a new trend that a number of top conferences overlap or are so close to each other that it is impossible to attend both.

Troopers March. Hacking FinSpy - a Case Study about how to Analyse and Defeat an Android Law-enforcement Spying App by Attila Marosi (not all speaker slots are filled)

31c3 Review

The Chaos Communication Congress was super fun again (no big surprise!). It was really good to see everybody again at the end of the year. As the congress is getting bigger and bigger every year it is hard to see people more once and I even missed a bunch of you guys! The talks were pretty good this year and I saw quite a few of them. Here a short overview of the mobile related talks that I actually saw live at the conference. Recordings are available: here Slides of most talks are linked in the schedule: here.

The SS7 talks were super interesting. I actually only saw 2 of the 3 talks on SS7 but I'll watch the third one once I get home. The summary of all the talks is: once you get access to SS7 you can easily track phones as often shown on TV shows. Commercial products exist to do this via SS7 (but depending on the manufacturer you cannot use it against every country).
SS7-based tracking can be implemented in various ways as Karsten Nohl showed. Very interesting is the fact that IMSI Catchers can benefit from SS7 access as it can be used to access to encryption keys. This basically allows building 3G IMSI catchers. Karsten Nohl showed this live on stage (he intercepted a SMS). SS7 access can be used to steal SMS messages by redirecting the delivery path in the HLR. All in all you can conclude that organizations with SS7 access can do a lot of interesting/bad things. Luckily all the German operators already block many of the security critical SS7 messages from entering their network. SRLabs also released and Android application that analyzes the debug messages from Qualcomm-based phones to determine if your phone is in an unfriendly cellular environment. The tool is called SnoopSnitch.

I also really enjoyed the talk from Sylvain Munaut about GMR-based Sat-Phones (specifically the technology used by Thuraya). He presented the progress of the Osmocom project's implementation of an open GMR stack. One interesting detail was that you can break the GMR crypto within 500msec using a known plain text attack against the control traffic.

The talk about pagers based on the Iridium satellite network was similar interesting. The presenters build an SDR-based Iridium receiver and sniffed some paging traffic as the satellite beam covers a large region they were able to receive quite a lot of interesting messages. Yes, the traffic is not encrypted! Their code is available here.

The guys from @scadasl totally rocked the 31c3 as they also gave a lighting talk on their 4G modem research. No slides unfortunately.

The talk Ich sehe, also bin ich ... Du about biometrics vs. cameras by Starbug also looked into smartphone screen reflections in your eye. He showed that you can partially determine what your screen shows and what area you touched with your finger.

The guys from the 31c3 GSM network where playing with the Alert system while I was visiting them in their NOC. One of the results is this: