home

forums
    Show me new threads!

bookmarks

view blogs

vault

downloads

Rootkit Collection

BootRootkit (eEye) : message board

post a message Show all posts in this forum view options: unpacked threads | collapsed threads | old style view

how many threads to display: 15305075100300800 search board (text+titles):

---

I am ignorant password for the archive (by WinDie (Normal user) Oct 29 2008, 15:14 (UTC+0) ) Please tell me what the password for the archive. Re: I am ignorant password for the archive (by superolive (Normal user) Jan 15 2009, 20:48 (UTC+0) ) "eeye" Re: I am ignorant password for the archive (by KernelCracker (Normal user) Jul 07 2009, 06:01 (UTC+0) ) Eye?

---

Install BootRootKit (by black_is_beautiful (Untrusted stranger) Oct 22 2006, 09:53 (UTC+0) ) Hello, How can we install on a computer this rootkit? I tried to make diskette with the .img, but at startup there is nothing... With the CD, it's the same think. Can anybody help me?

---

install from bios (by gareth (Normal user) Dec 31 2005, 06:30 (UTC+0) ) i think this could easily be implemented as a bios patch, using the ideas from the codebreakers journal. then you will have a truely terrifying tool. Re: install from bios (by needhelp (Normal user) Jun 24 2006, 17:42 (UTC+0) ) Hi, I have it. Its in my computer.

---

blue smiley (by dystopia (Normal user) Oct 05 2005, 15:56 (UTC+0) ) In your presentation you mention the blue smiley as indicator for the rootkit installation... About 3 years ago I installed a ring 0 debugger, and then there was a Blue smiley, too. How old is BootRoot really ? Re: blue smiley (by dereksoeder () Oct 05 2005, 23:36 (UTC+0) ) An ordinary blue smiley is just two consecutive 01h bytes in color text memory -- one for the character (1=smiley) and one for the color (1=blue). Boot driver problems, hardware glitches, and even viruses may cause such a blue smiley to appear. But don't be fooled by cheap imitations! Our Blue Smiley is actually bright blue (color 9) -- that's 99% more blue intensity than other brands! -- and appears after the "Starting Windows..." bar has filled up, but before any boot drivers execute. But wait, there's more! This Blue Smiley is backed by a 100% Lifetime Guarantee*. If at any time you feel your Blue Smiley has lost its chipper demeanor, simply return the unused portion for a full refund. It's that easy! * Void where prohibited. Some restrictions apply. Offer may not be available in all areas. We apologize for any inconvenience.

---

access violation at address 0 (by dereksoeder () Sep 20 2005, 12:51 (UTC+0) ) Wanted to post this for others who might be making BootRootKit-derivative works... If you're hooking something that gets called after Phase1Initialization, and as part of that hook, you're re-mapping the conventional (real-mode-addressable physical) memory containing your code, there's a chance that your code may get wiped out in the call to MmZeroPageThread. It could be that this specific system's BIOS doesn't reflect the conventional memory boundary at 0040h:0013h in INT 15h/EAX=E820h responses -- which is what Windows uses to form its map of free physical memory. If so, then one possible fix is write an INT 15h hook to "correct" the memory map output as it's returned. An alternative solution is to instead hook something reached after Phase 0, so that more virtual memory will be available to relocate into, but before Phase1Initialization completes, so that your code in conventional memory will not have been zeroed out yet. I'll update with more information as soon as I figure out exactly why this is happening. By the way, BootRootKit itself does not experience this problem, because it needs to relocate only about 40h bytes of itself into driver image memory, and does so during OSLOADER, when conventional memory is still virtually visible. Re: access violation at address 0 (by dereksoeder () Oct 17 2005, 19:14 (UTC+0) ) Confirmed, an incorrect INT 15h/EAX=E820h memory map is the cause of the access violation. Here are the results of the code following this post: 027B 0000000000000000  000000000009F000  00000001 000000000009F000  0000000000001000  00000002 0000000000100000  000000001FDC9000  00000001 000000001FEC9000  0000000000037000  00000002 000000001FF00000  0000000000100000  00000002 00000000FEDA0000  0000000000060000  00000002 The first value is KB of conventional memory (0040h:0013h) after decrementing; the limit on free conventional memory should now be 027Bh * 1024 = 9EC00h, but the first entry in the system memory map still indicates 9F000h as the top. Apparently it's only representing as reserved the conventional memory the BIOS itself allotted, and not consulting 0040h:0013h ever again. The system is a Dell Inspiron 1100 with (Phoenix) BIOS version A32, so definitely not a fringe case. My current inclination is to install an INT 15h filter; I'll try this and eventually release some code. Speaking of code, here's the (pretty sloppy) bootstrap code for generating that output: ;=============================================================== ; int15mm1.asm ;--------------------------------------------------------------- ; Displays an INT 15h/EAX=E820h memory map. ; ; Derek Soeder - eEye Digital Security - 10/17/2005 ;=============================================================== .486p .model tiny ;---------------- CODE16 SEGMENT use16 CODE_START EQU $     ;     ; Initialization     ;     cld     push    0     pop     ds     push    0B800h      ; color text memory starting segment     pop     es     xor     di, di     xor     eax, eax     ;     ; Reserve 1KB conventional memory and display new value     ;     dec     word ptr ds:[0413h]     ; 0040h:0013h - base memory size in KBs     mov     ax, ds:[0413h]     mov     cl, 4     call    @DisplayHex     mov     di, (80*2) * 2     ;     ; Display system memory map     ;     xor     ebx, ebx     sub     sp, 20     mov     bp, sp @Main_memloop:     push    es     push    di     mov     eax, 0000E820h     mov     edx, 534D4150h     mov     ecx, 20     push    ss     pop     es     mov     di, bp     int     15h         ; INT 15h/EAX=E820h: BIOS - GET SYSTEM MEMORY MAP     jc      @Main_memloop_done     test    ebx, ebx     jz      @Main_memloop_done     pop     di     pop     es     mov     cl, 8     mov     eax, [bp+4]     call    @DisplayHex     add     di, 8 * 2     mov     eax, [bp]     call    @DisplayHex     add     di, 10 * 2     mov     eax, [bp+0Ch]     call    @DisplayHex     add     di, 8 * 2     mov     eax, [bp+08h]     call    @DisplayHex     add     di, 10 * 2     mov     eax, [bp+10h]     call    @DisplayHex     add     di, (80 - 8 - 10 - 8 - 10) * 2     jmp     @Main_memloop @Main_memloop_done:     ;     ; Wait for keypress, then reboot     ;     xor     ax, ax     int     16h         ; INT 16h/AH=00h: KEYBOARD - GET KEYSTROKE     db      0EAh        ; JMP FAR F0F0h:F0F0h -- reset     dw      0F0F0h, 0F0F0h ; ; @DisplayHex ; ; Parameters:  EAX = value to display ;               CL = number of hexadecimal digits to display ; @DisplayHex:     push    di     push    cx     shl     cx, 2     ror     eax, cl     pop     cx     push    cx     mov     ch, 0 @DisplayHex_digitloop:     rol     eax, 4     push    ax     and     al, 0Fh     cmp     al, 0Ah     ; old trick to convert {0..15} ==> {'0'..'9','A'..'F'}     sbb     al, 69h     das     mov     ah, 07h     stosw     pop     ax     loop    @DisplayHex_digitloop     pop     cx     pop     di     ret CODE_END EQU $     db      (510 - (CODE_END - CODE_START)) dup (?)     dw      0AA55h      ; BIOS boot signature CODE16 ENDS END

---

It's so cool. (by linux2linux (Normal user) Sep 02 2005, 07:28 (UTC+0) ) NOT JUST HOOK INT 13, BUT IN INT 13. A WELL DESIGNED BIOS ROOTKIT, VERY SUITABLE. Re: It's so cool. (by fyiceworld (Untrusted stranger) Apr 21 2008, 08:00 (UTC+0) ) how can I see it