Attention: open in a new window. PDFPrint

HELP! I bricked my HTC Desire using the over-the-air update!

Wednesday, 22 December 2010 16:05

That was what a friend of me told me via ICQ some days ago. He used the OTA update feature that proclaimed a new android version found and accepted the update. What his phone did was updating the bootloader and the android system and got stuck within an infinite bootup loop. So he came over and we have spent some hours of research to fix this issue.

Read more: HELP! I bricked my HTC Desire using the over-the-air update!

Attention: open in a new window. PDFPrint

Hacking your ONYX BOOX 60 (Part II)

Last Updated on Monday, 20 September 2010 07:26 Sunday, 19 September 2010 10:56

Well, it has been a while since I posted my short article about my first attempts to squeeze out some more information from my ONYX BOOX 60. Due to a massive lack of time I stopped my research some time after this article. Today I just decided to proceed a little bit and write down some of my ideas, how it might be possible to gain deeper access to the system.

This article also contains some images of the mainboard of the device.


Read more: Hacking your ONYX BOOX 60 (Part II)

Attention: open in a new window. PDFPrint

How To: Hijacking the syscall table on latest 2.6.x kernel systems

Last Updated on Saturday, 19 June 2010 10:30 Saturday, 19 June 2010 09:40

Well. Some days ago I just wrote a simple how to describing how you could easily add a simple keylogger to the keyboard event chain within the kernal as a module. Now, hooking into the keyboard driver is one thing but there are several other ways to get out valuable information from a system or even modify basic operations to force the system doing some unexpected things. One way to archive this is hijacking the sys_call_table containing all important operations you might perform within userspace that need to be executed by the kernel like: creating, deleting, moving, editing, reading files, forking, executing applications, etc...

All theese operations are handled within the kernel. The operations are knows as sys_calls or kernel_calls and are executed using the software interrupt 0x80 (which might be interesting if you are playing around with assembly language within linux which is quite fun ;) ). To handle those syscall the kernel uses the sys_call_table which contains the addresses of all those syscall operations. So, the sys_call_table is just a big array ordered by the number of the syscall. In assembly this means something like this:

Read more: How To: Hijacking the syscall table on latest 2.6.x kernel systems

Attention: open in a new window. PDFPrint

How To: Building your own kernel space keylogger

Last Updated on Thursday, 10 June 2010 08:28 Wednesday, 09 June 2010 23:50

The linux kernel has been designed as a very modular piece of software. This allows you to load new kernel modules or kernel space drivers during runtime. To allow mdule loading during runtime, the kernel exports a rich set of symbols for module hookup. The problem of this is, that it is very easy to add your own modules to the kernel and read information from the kernel that you might assume to be protected. This is the way, kernel space rootkits work. In this article, I will show you a very simple example that might make clear, why those rootkits are dangerous and why you should never run applications as root or install kernel modules you do not trust.

The most simple example of a very basic rootkit is a keylogger. A keylogger is able to log every keyboard input you type on your keyboard which includes usernames followed by your probably secret password. To understand the following abstract you should have at least some basic understanding of C programming and you should basically understand, how kernel modules work. If you like to try my code snippets on your own system you should also take a look at this kernel module development guide.

Read more: How To: Building your own kernel space keylogger

Attention: open in a new window. PDFPrint

C# and the char* mess

Last Updated on Wednesday, 19 May 2010 23:12 Wednesday, 19 May 2010 21:17

In this article, I will shortly describe, how you could exchange char-array data between a DLL and C# in different ways. It will contain methods of ANSI and Unicode conversion for Windows CE devices and a way to exchange binary data instead of null terminated strings only.

If you ever tried using C# to access native libraries or non-.NET libraries you might have heard something about P/Invoke and marshalling. Marshalling is used by the .NET runtime to create objects that are passable to .NET. Assume that you have a DLL (dynamic linked library) containing a method called foo that looks like this:

void foo(char* bar) {
// do write some information into char* bar

Ans let's assume, that the method parameter bar of the method foo is a pointer on a char array and the method foo writes some information to the char array. The maximum length of the information written to the array is limited to 256 bytes. So calling the method in C would look somewhat like this:

char result[256];
memset(result, 0, sizeof(result));

Read more: C# and the char* mess

Attention: open in a new window. PDFPrint

Tinyproxy supports IPv6!!!

Last Updated on Tuesday, 13 April 2010 19:51 Tuesday, 13 April 2010 19:48

As I reconfigured my IPv6 tunnel over (my tunnel-broker) I just searched for a way to use IPv6 through my proxy. I found out that tinyproxy supports IPv6 since version 1.8.1. So I added it to my layman overlay. The IPv6 support worked right out of the box.


Page 1 of 4