Page 1 of 2 12 LastLast
Results 1 to 15 of 16

Thread: Question about Rootkit Unhooker

  1. #1

    Question about Rootkit Unhooker

    There was a thread on our board that linked to Rootkit Unhooker.

    http://www.woodmann.com/forum/showthread.php?t=12159&highlight=unhooker

    and their site is here: http://www.rootkit.com/newsread.php?newsid=902

    Can someone fill me in on the controversy surrounding this product? I heard that Micro$oft had taken over the product or were working in cahoots with them. Now I see the guy defending his product against assertions that he is doing something weird (read article at 2nd link above).

    Has anyone actually used version 3.8, either from his site or from the link provided in URL #1 above? Is it safe?

  2. #2
    Quote Originally Posted by WaxfordSqueers View Post
    and their site is here: http://www.rootkit.com/newsread.php?newsid=902
    BTW...there's an interesting article on this site at :

    http://www.rootkit.com/blog.php?newsid=903

    On how to adjust Filemon/Regmon for Vista. In the FAQ, in the manual that comes with RKU from the site, is this interesting ditty:

    Q: Can I disassemble/reverse this?
    A: No, but you can try.

    The gauntlet has been thrown down for you advanced reversers.

  3. #3
    Don't listen to people say RkU is backdoored .
    And yes, RkU 4.1 sold to M$, but they still own rights on its developments, name etc.

  4. #4
    Quote Originally Posted by GamingMasteR View Post
    Don't listen to people say RkU is backdoored .
    And yes, RkU 4.1 sold to M$, but they still own rights on its developments, name etc.
    Thanks for info.

  5. #5
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,124
    Blog Entries
    5
    Hi

    A couple of notes about this, one reassuring, the other not.

    To start with, for reference the latest (last?) version of RKU is here:

    http://www.rootkit.com/vault/DiabloNova/RkU3.8.342.554.rar
    http://www.rootkit.com/blog.php?newsid=912


    First, in case anyone sees some "funny" stuff in their system logs and gets worried and goes off chasing ghosts, as I did... when you select Scan from the Files tab of RKU, it creates a separate service. The filename will be a random 8 hexadecimal character name temporarily created as ../windows/system32/********.exe

    The action will be logged by ZoneAlarm, or probably by any other process monitor you may have active. As well, the Windows System Event Log will record the events through the Service Control Manager (SCM). For example:

    The 2F07D778 service was successfully sent a start control.
    The 2F07D778 service entered the running state.
    The 2F07D778 service entered the stopped state.
    The 2F07D778 service was successfully sent a stop control.


    If you are quick you can grab a copy of the file in the system32 directory before it deletes itself. If you are even quicker you can set a breakpoint on StartServiceCtrlDispatcherW and live trace the actions of the service. I see no problems with this file, in fact it's quite interesting to analyse.


    I'm sorry, but I find no evidence of "backdoors" in RKU

    I've read most of the garbage surrounding RKU from the last couple of years, and it's seems to be just that - the usual internet flame war garbage we've all seen before.



    However, I do have one major concern about RKU at this point. I saw it mentioned in one Sysinternals forum thread that the RKU driver has changed from a randomly named one in recent versions to a constantly named one, i.e. karlchen.sys. If you read between the lines of the flames, this appears to be an inside joke and slap of the face at a certain moderator on that forum, ..whatever.

    That's all fine and dandy, but it appears to me that this is a MAJOR vulnerability to the covertness of RKU against malware, primarily because loading of karlchen.sys can now be detected through a PsSetLoadImageNotifyRoutine callback.


    I have my own app (which I'll release + source soon btw) for detecting, dumping and optionally preventing execution of drivers through such a callback routine. I've already determined that I can detect the RKU driver loading, suspend execution of the callback thread, and notify usermode of the fact. If I was a malware I would then have unlimited time to clean up any userland hooks or send an IOCTL to my driver to clean up kernelmode hooks.

    Immediately after sending an event to resume execution of the callback thread (and continue loading of the RKU driver), as a test I modified my code to then remove my PsSetLoadImageNotifyRoutine callback and terminate my app. By the time RKU has started fully it should see no trace of me, and indeed no longer records the PsSetLoadImageNotifyRoutine in its list.


    So, if I can be so bold to say, I would NOT fully put my faith in RKU that your system is clean, unless you FIRST determine independantly that you have no covert PsSetLoadImageNotifyRoutine callbacks running.


    I don't know of any other app that lists these system callbacks (PsSetLoadImageNotifyRoutine, PsSetCreateProcessNotifyRoutine, PsSetCreateThreadNotifyRoutine) that you could use independantly. I've described how to manually find one of them, somewhere else on this board (I believe the Ring 0 anti-debugger code in Daemon Tools thread), but I myself have never gotten around to coding an app to do that.


    This kind of preventative measure (if a rootkit malware detects it might be being scanned it simply removes itself from active duty), has been talked about before of course so it's nothing new. Unfortunately, the fact that RKU now uses a "known" driver name has made it vulnerable to this action. So that is the point of my writing this cautionary warning.


    Hopefully there is a good future for all this. If MS now owns the "VX" version of RKU, as it sounds, the innovations might be incorporated in a new/improved RootkitRevealer at some point. Then we can all rest easier knowing the only "backdoors" will come from MS itself.

    Cheers,
    Kayaker

  6. #6
    Registered User
    Join Date
    Aug 2005
    Location
    Italy
    Posts
    133
    Blog Entries
    31
    Really easy to deceive PsSetCreateProcessNotifyRoutine, the old aged trick of manually switching down the callback activation still works:

    Code:
    for(i = 0x80000000; i < 0xFFFFFFFF; i++)
    {
        PsSetCreateProcessNotifyRoutine((PCREATE_PROCESS_NOTIFY_ROUTINE)i, TRUE);
    }


    About rumors around RKU Backdoors, every person with a bit of k/u space knowledge can read sources here http://antiprotect.com ( at the moment down) for paranoid++ just use the compile 'n compare approach

    Have a nice Day,
    Giuseppe 'Evilcry' Bonfa'
    Last edited by evilcry; January 14th, 2009 at 03:23.

    http://evilcry.netsons.org (Repository)
    http://evilcodecave.blogspot.com
    http://evilcodecave.wordpress.com

  7. #7
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,124
    Blog Entries
    5
    That's a cute trick, more malware than anti-malware oriented. Extrapolating on that idea though, if one were paranoid++, you should be able to secure your own system with a "home-brew" protection by taking a normal baseline reading and "filling up" the unused slots for each of those system callbacks (maximum of 8) with your own blank ones.

    If a malware then tries to register one of those system callbacks it should receive a STATUS_INSUFFICIENT_RESOURCES error and the attempt will fail.

    For example, on my system (according to RKU) there are 2 CreateProcess, 1 CreateThread, and 2 LoadImage callbacks registered, all by ZoneAlarm. For me this would be a "clean" baseline reading. If I then create my own autostart app to register 6 more PsSetLoadImageNotifyRoutine callbacks for example on bootup, then all 8 system callbacks of that type will be used.

    If it so happens that at some future time my autostart app receives a STATUS_INSUFFICIENT_RESOURCES message while attempting to register those 6 extra callbacks, then it's quite likely a boot loading malware might have invaded my system and already installed its own and I should send up a red flag.

    Hmmm, methinks a new coding project is in order..

  8. #8
    Registered User
    Join Date
    Aug 2005
    Location
    Italy
    Posts
    133
    Blog Entries
    31
    Hi,

    Extrapolating on that idea though, if one were paranoid++, you should be able to secure your own system with a "home-brew" protection by taking a normal baseline reading and "filling up" the unused slots for each of those system callbacks (maximum of 8) with your own blank ones.
    Exactly!
    indeed another Anti anti-rootkit technique is to render PsSetCreateProcessNotifyRoutine useless by filling up all 8 slots with dummy routines

    http://evilcry.netsons.org (Repository)
    http://evilcodecave.blogspot.com
    http://evilcodecave.wordpress.com

  9. #9
    Another Anti-ARK technique is to modify the NtBuildNumber value, if you do it properly (that means not putting any value) most ARK tools will show the message of "OS not supported"

    This technique was mentioned by Fyyre .

  10. #10
    rzr
    Guest
    Quote Originally Posted by evilcry View Post
    Really easy to deceive PsSetCreateProcessNotifyRoutine, the old aged trick of manually switching down the callback activation still works:

    Code:
    for(i = 0x80000000; i < 0xFFFFFFFF; i++)
    {
        PsSetCreateProcessNotifyRoutine((PCREATE_PROCESS_NOTIFY_ROUTINE)i, TRUE);
    }


    About rumors around RKU Backdoors, every person with a bit of k/u space knowledge can read sources here http://antiprotect.com ( at the moment down) for paranoid++ just use the compile 'n compare approach

    Have a nice Day,
    Giuseppe 'Evilcry' Bonfa'
    Well,

    really unoptimized and dangerous routine but yes, it could work. It's easier to overwrite all slots or, even better, reset the counter.

    RkU sources at antiprotect.com are far from being full sources. There are just some routine used to search for some stuff. Anyway yes, there aren't really any backdoor or malicious code inside it.
    Last edited by rzr; January 25th, 2009 at 09:25.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  11. #11
    Quote Originally Posted by Kayaker View Post
    Hi A couple of notes about this, one reassuring, the other not.
    Thanks for your detailed explanation, Kayaker, and sorry about not replying sooner. As I explained on another occasion, my main concern was the safety of online banking. I am now convinced that it is not that safe. I used RKU to check which apps were hooking what and identified all but one.

    Most of the hooks were done by Sygate firewall, so I unloaded it and a few other drivers to see if I could eliminate the unknown hook. Rootkitrevealer, Sophos and F-secure antirootkit revealed nothing, so I still don't know what the hook is. I noticed some inconsistencies in RKU when used in console mode, especially in safe mode. I finally got it to load in safe mode, but it kept reporting a process that was loading as a 'parasite'. I found that odd because the so-called parasite only loaded immediately above it in thread ID.

    For example, on one occasion, RKU was running thread id 1996 and reported a parasite at thread id 2000. I opened task manager, which was at thread id 2004. There was nothing showing in task manager at thread id 2000. If that was a rootkit, why would it open a thread with an id right above RKU? It could be some other driver monitoring, and I wondered about the softice driver, even though softice was not loaded. I unloaded softice as well, and I 'think' the hook was still there.

    The unknown hook was listed at ntoskrnl +0x00005032 0x804DC032 -> 804DC039. otherwise, everything was accounted for.

    With respect to online banking, I am now paranoid about keyloggers. The banks seem to be concerned only about phishing scams in which a popup window is presented asking for a re-entry of login info. It seems to me they should be worrying about a keylogger intercepting the keyboard data before it is encrypted. I have scanned my system fairly well with several antivirus apps, including a trial version of F-secure 2009 and Ewido, all with the most recent signatures. I also updated to the most recent version of Spybot. No viruses were detected.

    If there is a rootkit running a keylogger, it is all for nought. Banks don't seem to understand that. When I talked to one of their security experts, they had no idea what I was talking about.

    One question I asked them is where the 128 bit online encryption kicks in. I know the keyboard was directly accessible in the bad old days but with XP that has all been virtualized. What are the chances of a keylogger intercepting unencrypted information before it is encrypted to go online?

  12. #12
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,511
    Blog Entries
    15
    oh well then there are lots of simpletricks to avoid the shit keyloggers from stealing your password

    most simplest form of fooling would be
    when you have logged into the form
    go to the edit box where you need to supply your user name blah blah blah

    type w then remove focus from edit box but not from form (click a bit outside and type random crap
    then refocus on editbox type a
    unfocus type some crap and so on so even if logged deciphering an usefull thing out of the maze will be a problem

    if the keylogger is screen capturing
    try using virtual onscreen keyboards (copy letter from charmap in start run accessories systemtools)

    some ideas i state are summarized here

    http://www.raymond.cc/blog/archives/2007/09/20/how-to-beat-keyloggers-to-protect-your-identity/

    and here

    http://www.nomad4ever.com/2008/02/21/8-tips-to-fool-keyloggers-in-public-internet-cafes/

  13. #13
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,124
    Blog Entries
    5
    The unknown hook was listed at ntoskrnl +0x00005032 0x804DC032 -> 804DC039
    You should crack open Sice or Livekd and check it out. 7 byte difference - that looks like the same false positive I get. Actually it's not really a false positive, RKU has correctly identified that ntoskrnl has been patched, presumably by comparing the disk file with the memory image, but it appears to be a normal Windows process during boot up.

    Kind of an interesting code snippet. I get a similar report by RKU under Code Hooks:

    ntoskrnl.exe + 0x00006056 0x804DD056 -> 804DD05D Inline - relative jump


    Softice identifies the affected function as KeFlushCurrentTb. This is ntoskrnl as it is loaded in memory:

    Code:
    _KeFlushCurrentTb
    0008:804DD054  0F20E0              MOV       EAX,CR4
    0008:804DD057  257FFFFFFF          AND       EAX,FFFFFF7F
    0008:804DD05C  0F22E0              MOV       CR4,EAX
    0008:804DD05F  0D80000000          OR        EAX,00000080
    0008:804DD064  0F22E0              MOV       CR4,EAX
    0008:804DD067  C3                  RET
    0008:804DD068  0000                ADD       [EAX],AL
    0008:804DD06A  000F                ADD       [EDI],CL
    0008:804DD06C  22E0                AND       AH,AL
    0008:804DD06E  0090C38D4900        ADD       [EAX+00498DC3],DL
    0008:804DD074  90                  NOP
    0008:804DD075  90                  NOP
    0008:804DD076  90                  NOP
    0008:804DD077  90                  NOP
    0008:804DD078  90                  NOP
    @KiFlushSingleTb
    0008:804DD079  0F013A              INVLPG    [EDX]
    0008:804DD07C  C3                  RET

    However, if you look at the disasm of the file ntoskrnl.exe, the instructions are entirely different:

    Code:
    sub_804DD054    proc near               ; CODE XREF: KeFlushEntireTb:loc_804E9DE9                  
    :804DD054                            ; DATA XREF: INIT:806B1AC8  
                   
    :804DD054 0F 20 D8                          mov     eax, cr3
    :804DD057 0F 22 D8                          mov     cr3, eax
    :804DD05A C3                                retn
    :804DD05A                   sub_804DD054    endp
    :804DD05A
    :804DD05B
    :804DD05B                   ; =============== S U B R O U T I N E =======================================
    :804DD05B
    :804DD05B
    :804DD05B                   sub_804DD05B    proc near               ; DATA XREF: INIT:806B1ACD
    :804DD05B 0F 20 E0                          mov     eax, cr4
    :804DD05E 25 7F FF FF FF                    and     eax, 0FFFFFF7Fh
    :804DD063 0F 22 E0                          mov     cr4, eax
    :804DD066 0D 80 00 00 00                    or      eax, 80h
    :804DD06B 0F 22 E0                          mov     cr4, eax
    :804DD06E
    :804DD06E                   locret_804DD06E:                        ; DATA XREF: INIT:806B1AD9
    :804DD06E C3                                retn
    :804DD06E                   sub_804DD05B    endp
    :804DD06E
    :804DD06E                   ; ---------------------------------------------------------------------------
    :804DD06F 90                                db  90h ; 
    :804DD070 C3                                retn
    :804DD070                   ; ---------------------------------------------------------------------------
    :804DD071 8D                                db  8Dh ; 
    :804DD072 49                                db  49h ; I
    :804DD073 00                                db    0
    :804DD074 90 90 90 90 90                    db 5 dup(90h)
    :804DD079
    :804DD079                   ; =============== S U B R O U T I N E =======================================
    :804DD079
    :804DD079
    :804DD079                   sub_804DD079    proc near
    :804DD079 0F 01 3A                          invlpg  byte ptr [edx]
    :804DD07C C3                                retn
    :804DD07C                   sub_804DD079    endp
    :804DD07C
    :804DD07C                   ; ---------------------------------------------------------------------------
    :804DD07D 90 90 90 90 90                    db 5 dup(90h)


    What gives? Well, if you check one of the XREFS,
    :804DD054 ; DATA XREF: INIT:806B1AC8
    you can find that during INIT, 14h bytes at 804DD054 are overwritten by the bytes at 804DD05B.

    Again using the superior symbolic name identification of Softice, we can identify that the relevant function is called _Ki386EnableGlobalPage.


    Code:
    INIT:806B1AAB _Ki386EnableGlobalPage proc near        ; DATA XREF: sub_806BE627+62
    INIT:806B1AAB
    INIT:806B1AAB arg_0           = dword ptr  4
    INIT:806B1AAB
    INIT:806B1AAB                 push    esi
    INIT:806B1AAC                 push    edi
    INIT:806B1AAD                 push    ebx
    INIT:806B1AAE                 mov     edx, [esp+0Ch+arg_0]
    INIT:806B1AB2                 pushf
    INIT:806B1AB3                 cli
    INIT:806B1AB4                 lock dec dword ptr [edx]
    INIT:806B1AB7
    INIT:806B1AB7 loc_806B1AB7:                           ; CODE XREF: _Ki386EnableGlobalPage+11
    INIT:806B1AB7                 pause
    INIT:806B1AB9                 cmp     dword ptr [edx], 0
    INIT:806B1ABC                 jnz     short loc_806B1AB7
    INIT:806B1ABE                 cmp     large byte ptr fs:51h, 0
    INIT:806B1AC6                 jnz     short loc_806B1AE0
    INIT:806B1AC8                 mov     edi, offset sub_804DD054
    INIT:806B1ACD                 mov     esi, offset sub_804DD05B
    INIT:806B1AD2                 mov     ecx, 14h
    INIT:806B1AD7                 rep movsb
    INIT:806B1AD9                 mov     byte ptr ds:locret_804DD06E, 0
    INIT:806B1AE0
    INIT:806B1AE0 loc_806B1AE0:                           ; CODE XREF: _Ki386EnableGlobalPage+1B
    INIT:806B1AE0                                         ; _Ki386EnableGlobalPage+3C
    INIT:806B1AE0                 cmp     byte ptr ds:locret_804DD06E, 0
    INIT:806B1AE7                 jnz     short loc_806B1AE0
    INIT:806B1AE9                 mov     eax, cr4
    INIT:806B1AEC                 and     eax, 0FFFFFF7Fh
    INIT:806B1AF1                 mov     ecx, cr3
    INIT:806B1AF4                 mov     cr4, eax
    INIT:806B1AF7                 mov     cr3, ecx
    INIT:806B1AFA                 or      eax, 80h
    INIT:806B1AFF                 mov     cr4, eax
    INIT:806B1B02                 popf
    INIT:806B1B03                 pop     ebx
    INIT:806B1B04                 pop     edi
    INIT:806B1B05                 pop     esi
    INIT:806B1B06                 retn    4
    INIT:806B1B06 _Ki386EnableGlobalPage endp

    Doing a search for Ki386EnableGlobalPage we find a nice explanation, as there often is, in ReactOS.


    00034 /* Now check if this is the Boot CPU */
    00035 if (!KeGetPcr()->Number)
    00036 {
    00037 /* It is.FIXME: Patch KeFlushCurrentTb */
    00038 }


    KeGetPcr()->Number is equivalent to fs:0x51
    kd> dt -r _KPCR 0xffdff000
    +0x051 Number : 0 ''



    http://www.reactos.org/generated/doxygen/de/de0/patpge_8c-source.html

    Code:
    00001 /*
    00002 * PROJECT:         ReactOS Kernel
    00003 * LICENSE:         GPL - See COPYING in the top level directory
    00004 * FILE:            ntoskrnl/ke/i386/patpge.c
    00005 * PURPOSE:         Support for PAT and PGE (Large Pages)
    00006 * PROGRAMMERS:     Alex Ionescu (alex.ionescu@reactos.org)
    00007 */
    00008 
    00009 /* INCLUDES ******************************************************************/
    00010 
    00011 #include <ntoskrnl.h>
    00012 #define NDEBUG
    00013 #include <debug.h>
    00014 
    00015 /* GLOBALS *******************************************************************/
    00016 
    00017 ULONG Ke386GlobalPagesEnabled;
    00018 
    00019 /* FUNCTIONS *****************************************************************/
    00020 
    00021 ULONG_PTR
    00022 NTAPI
    00023 Ki386EnableGlobalPage(IN volatile ULONG_PTR Context)
    00024 {
    00025     volatile PLONG Count = (PLONG)Context;
    00026     ULONG Cr4, Cr3;
    00027 
    00028     /* Disable interrupts */
    00029     _disable();
    00030 
    00031     /* Decrease CPU Count and loop until it's reached 0 */
    00032     do {InterlockedDecrement(Count);} while (!*Count);
    00033 
    00034     /* Now check if this is the Boot CPU */
    00035     if (!KeGetPcr()->Number)
    00036     {
    00037         /* It is.FIXME: Patch KeFlushCurrentTb */
    00038     }
    00039 
    00040     /* Now get CR4 and make sure PGE is masked out */
    00041     Cr4 = __readcr4();
    00042     __writecr4(Cr4 & ~CR4_PGE);
    00043 
    00044     /* Flush the TLB */
    00045     Cr3 = __readcr3();
    00046     __writecr3(Cr3);
    00047 
    00048     /* Now enable PGE */
    00049     __writecr4(Cr4 | CR4_PGE);
    00050     Ke386GlobalPagesEnabled = TRUE;
    00051 
    00052     /* Restore interrupts */
    00053     _enable();
    00054     return 0;

    I think that pretty much explains why RKU identified an ntoskrnl patch, even if it's not quite aware of what's going on.

    All that remains is hitting the Intel docs for a refresher course to understand the details of the KeFlushCurrentTb patch.


    Also, Joanna Rutkowska's System Virginity Verifier seems to identify the KeFlushCurrentTb() patch by name:
    http://kareldjag.over-blog.com/article-1232492.html



    Btw, I hope you're aware of the Canada Revenue Agency Phishing Web Site. Be safe - don't do *any* financial transactions online.

    http://securitylabs.websense.com/content/Alerts/3282.aspx

  14. #14
    Quote Originally Posted by blabberer View Post
    oh well then there are lots of simpletricks to avoid the shit keyloggers from stealing your password
    thanks for the tips, blabberer. Food for thought. I read your links and each method still seems to have its downfalls, especially if the logger is using window capture for each mouse/keystroke. Although many of them may not be up to that sophistication yet, I'm sure they soon will be.

    I am focusing on the proxy defense right now. Apparently you can d/l a free proxy (eg. fiddler at http://www.fiddlertool.com/Fiddler2/version.asp ), that sits in between your browser and the net. It can apparently be programmed to decipher your keyboard data from background nonsense typed in at random. Don't know how it works yet. Method is described here:

    http://www.acsac.org/2006/papers/56.pdf

    I need to learn more about the method of interception by the keylogger. One article refers to user32.dll and describes how the keyboard data is logged there. One concern I have, although it may be premature, is that typing a password interspersed with chaff (junk keystrokes) could be detected by examining spaces between entries. For example, when the focus is changed from the desired password entry window to the main banking window page, so that junk can be typed in, can the logger detect that a change in focus has taken place? Would that show up in the logged keystrokes somehow, or associated with them?

    If a logger is hooking user32, you'd think RKU would reveal that. I am assuming the logger would have to hook user32, or something further down the line.

  15. #15
    Quote Originally Posted by Kayaker View Post
    You should crack open Sice or Livekd and check it out.
    I think you forgot to attach a smiley. I get a bit of a laugh out of what you consider easy. I'm a mere mortal who has difficulty even following your excellent explanations. BTW...thanks for the explanation.

    More later...I've got a real virus, with accompanying chills and headache. I'm off to watch an episode of House to see if I can get any tips.

Similar Threads

  1. Amr Thabet: Reversing Stuxnet's Rootkit (MRxNet) Into C++
    By Silkut in forum Malware Analysis and Unpacking Forum
    Replies: 4
    Last Post: February 6th, 2011, 08:19
  2. The Perfect Rootkit
    By Snatch in forum Advanced Reversing and Programming
    Replies: 18
    Last Post: June 19th, 2009, 03:48
  3. Rootkit Analytics
    By Kayaker in forum Advanced Reversing and Programming
    Replies: 0
    Last Post: March 19th, 2009, 12:02
  4. Rootkit.Win32.TDSS.eyj Another custom packer/cryptor
    By Cthulhu in forum Malware Analysis and Unpacking Forum
    Replies: 3
    Last Post: February 6th, 2009, 17:25
  5. Rootkit Revealer
    By Silver in forum Tools of Our Trade (TOT) Messageboard
    Replies: 6
    Last Post: March 23rd, 2005, 18:55

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •