Page 11 of 11 FirstFirst ... 4567891011
Results 151 to 154 of 154

Thread: NTFS MFT Internals

  1. #151
    Quote Originally Posted by Kayaker View Post
    Thanks for that Kayaker.

    I was just investigating another possible method that I got from this suggestion:

    What you need is to get the window procedure address....
    A simple solution is to retrieve it manually with Spy++. Once you have it, go to that address and put a conditional breakpoint....

    What I did was load explorer and open it to a directory in which I could install notepad. I then opened SPYXX and found the entry for explorer under "directory" ExploreWClass. Under that heading is another called SHELLDLL_DefView with the hwnd in front of it.

    Under SHELLDLL_DefView is another entry called "FolderView" SysListView32. FolderView is the window in Explorer where the folders are found.

    If you highlight that line, "FolderView" SysListView32, right-click and select Properties, you will find the Window Proc address to be 77420C9D and it is found in comctrl32.dll for version 6.0.2600.6028.

    Note: the comctrl32 version is found in Windows\winsxs, not in windows\system32.

    That winproc in comctrl32 is the beginning of a function in IDA that leads to CALL GetWindowLongW. The first push before that call is the hwnd and the previous push is the index.

    Theoretically, in my particular version of Explorer, I should be able to BP on GetWindowLongW with the hwnd found in SPYXX as a condition.

    I realize that the winproc shown in SPYXX is not the address of the call to GetWindowLongW, which comes shortly after at 77420CC5. However, the push for the hwnd is a push eax and that is loaded by a mov eax, [ebp+8] a few steps before.

    It might be possible to use the SPYXX winproc address for the "FolderView" SysListView32 explorer window with the condition that [ebp+8] = hwnd of same. ebp does not seem to change from the winproc address until GetWindowLongW is called.

    .text:77420C9D                 mov     edi, edi
    .text:77420C9F                 push    ebp
    .text:77420CA0                 mov     ebp, esp
    .text:77420CA2                 sub     esp, 148h
    .text:77420CA8                 mov     eax, dword_774623E0
    .text:77420CAD                 push    ebx
    .text:77420CAE                 mov     ebx, [ebp+10h]
    .text:77420CB1                 push    esi
    .text:77420CB2                 push    edi
    .text:77420CB3                 mov     edi, [ebp+14h]
    .text:77420CB6                 mov     [ebp-4], eax
    .text:77420CB9                 mov     eax, [ebp+8]
    .text:77420CBC                 push    0
    .text:77420CBE                 push    eax
    .text:77420CBF                 mov     [ebp-108h], eax
    .text:77420CC5                 call    ds:GetWindowLongW

  2. #152
    Super Moderator
    Join Date
    Dec 2004
    Blog Entries
    a round of applause to kayaker for revealing his secret of success.

    yes [esp] in sice == poi(@esp)
    so [[[ebp+4]]] == poi(poi(poi(@ebp+4)))

    use of @ denotes what follows is a register and not a symbol and cuts down unneeded symbol loading time poi(esp) should working equally well albeit slower than poi(@esp)

    here is a refresher course on semantics take time to practice

    foo:\>dir /b
    foo:\>type foo.cpp
    #include <stdio.h>
    int main (void)
            int var1,var2,var3,var4,var5,var6;
            var1 = 9;
            var2 = *(&var1);                //9
            var3 = *(&var2)+ *(&var1);      //9+9
            var4 = *(&var3)+ *(&var2);      //18+9
            var5 = *(&var4)+ *(&var3);      //27+18
            var6 = *(&var5)+ *(&var4);      //45+27
            printf("%d\n",var6);    //72
            return 0;
    foo:\>cl /nologo /Zi foo.cpp /link /release /debug
    foo:\>dir /b
    foo:\>cdb -c "bp foo!main;g;dv;.echo ===========;pc;dv;" foo.exe
    0:000> cdb: Reading initial command 'bp foo!main;g;dv;.echo ===========;pc;dv;'
    Breakpoint 0 hit
               var3 = 0n4228356
               var2 = 0n4228376
               var6 = 0n4208635
               var1 = 0n1310592
               var5 = 0n4205493
               var4 = 0n4208635
               var3 = 0n18
               var2 = 0n9
               var6 = 0n72
               var1 = 0n9
               var5 = 0n45
               var4 = 0n27
    lets play with expressions and get to know our poi on double square brackets

    masm expression evaluation
    0:000> ? var1
    Evaluate expression: 1310572 = 0013ff6c
    0:000> ? poi(13ff6c)
    Evaluate expression: 9 = 00000009
    c++ expression evaluation
    0:000> ?? var1
    int 0n9
    mixed expression evaluation 
    0:000> ? poi(@@c++(&var1))
    Evaluate expression: 9 = 00000009
    masm evaluation of c++ expression
    0:000> ? @@c++(*&var1 +2* (*&var2 + *&var3 + *&var4) )
    Evaluate expression: 117 = 00000075
    fscking complicated crap 
    masm operator ? evaluting a c++ expression that has got an embedded masm exprssion inside it
    0:000> ? @@c++(*&var1 +2* (*&var2 + *&var3 + @@masm(poi(@@c++(&var4)))   ) )
    Evaluate expression: 117 = 00000075
    i dont  know what this does all i know is it delivers what i ask 
    0:000> ?? @@masm( poi(@@c++(&var1)) +2* ( poi(@@c++(&var2)) + poi(13ff60) + @@masm(poi(13ff74)) ) )
    unsigned int64 0x75
    Last edited by blabberer; March 27th, 2014 at 03:00.

  3. #153
    Quote Originally Posted by blabberer View Post
    yes [esp] in sice == poi(@esp)
    so [[[ebp+4]]] == poi(poi(poi(@ebp+4)))
    Thanks for tute...mighty handy. The thing that scares me is that I can follow you, even the C++ stuff. I'll have to dust off my C++ compiler.

    I noticed the use of 'n' rather than 'X'. What's with that? eg. var3 = 0n4228356

    I'm going to do what you suggest and practice some of this but it does help a lot when someone familiar with it explains it. I have done a considerable amount of reading on windbg and I recall the explanation of masm expressions as opposed to c++ expressions and @@ versus poi.

    It still doesn't make complete sense to me. I guess I have been using the masm expressions in SI but I don't understand the need to bring c++ expressions into the equation.

    In SI, I know that 0x7717DDEE is a value and that [0x7717DDE] is a value at the address 0x7717DDEE. I even understand nested values using pointers.

    I've had that clearly in my mind for a long time and I can read code in SI quickly. Now I have to contend with c++ expressions and I am not getting why.

    I'll go back and read more on the subject but thanks for taking the time to write down all this stuff. I'm sure anyone reading it will benefit from it as well, even if just for a review.

  4. #154
    Quote Originally Posted by WaxfordSqueers View Post
    I'll go back and read more on the subject
    Answered some of the questions for myself.

    The 'n' as in 0n77171177 means decimal.

    Whenever I have used SI it has been without source code. I've had no need for evaluating C++ expressions. I can see why the debugger needs that ability.

Similar Threads

  1. NTFS reversing
    By WaxfordSqueers in forum The Newbie Forum
    Replies: 21
    Last Post: April 28th, 2013, 00:56
  2. Qt Internals & Reversing
    By Daniel Pistelli in forum Blogs Forum
    Replies: 11
    Last Post: December 5th, 2008, 04:12
  3. problem with NTFS file encryption
    By Hero in forum The Newbie Forum
    Replies: 10
    Last Post: October 22nd, 2004, 03:49
  4. New project: RSA-65 analysis on GetDataBack for NTFS
    By Lbolt99 in forum RCE Cryptographics
    Replies: 6
    Last Post: August 1st, 2002, 14:48
  5. Write to NTFS
    By tentakkel in forum Malware Analysis and Unpacking Forum
    Replies: 7
    Last Post: October 8th, 2001, 17:18


Posting Permissions

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