Page 8 of 10 FirstFirst 12345678910 LastLast
Results 106 to 120 of 141

Thread: USB drivers for Win 7 on 8th generation Intel chipset

  1. #106
    Quote Originally Posted by blabberer View Post
    host sxe ld foo.exe g target double click foo.exe windbg will break on loading the exe reload symbols
    Thanks blabbs.

    I got a bit reckless with my experimentation and inserted an 0xCC at the OEP of the target app. It worked, but an exception was thrown and things became unglued a bit. My registers windows would not show the registers, claiming they were not known.

    I could single step find, and even BP, but without the registers windows it got tough.

    Someone mentioned that I'd have to move EIP back a step but it was at the right address. I opened a memory window, which was already pointing at the EIP and changed the CC back to EB.

    On sice you could turn off the exceptions if I recall correctly. Is there a way to do that in wdbg so the app will simply freeze when it encounters the CC?

    [EDIT]...just noticed that SXE does what I want. Thanks again.
    Last edited by WaxfordSqueers; April 25th, 2019 at 21:57.

  2. #107
    Quote Originally Posted by blabberer View Post
    host
    sxe ld foo.exe g
    target double click foo.exe
    Blabbs...If I don't insert a CC at foo.exe's OEP Windbg does not stop the app as it usually does when loaded by Windbg directly.

    There may be TLS issues as I indicated earlier in this thread. If I load foo.exe straight from windbg running on the target, it does not open as foo.exe. It has another name. Examining the properties of the file under the new name, it indicates foo.exe is its old name.

    The OEP is the same code as foo.exe but it is not renamed to foo.exe till later in the process.

    BTW...I had to drop my Windbg version back to 6.12.0002.633 to get a registry window with registers. The Windbg ver 10 apparently has a bug in which the register windows shows no data during remote debugging. Don't know if that could be an issue.

    I am thinking that even with the CC inserted at OEP, Windbg should still stop the app at the usual place before OEP, but it does not with the remote connection.

    If I load it using the CC inserted at OEP, it is called foo.exe. Using the sxe ld command, it runs in a far more stable manner albeit much slower. BPs operate quickly but single stepping has a noticeable lag. That's even after a .reload /f.

    I should also mention that after loading foo.exe using a CC at OEP, the host wdbg prompt changes from 0:00:kd> to 32:5:kd:x86> .

    0: kd> sxe ld setup.exe
    0: kd> g
    The context is partially valid. Only x86 user-mode context is available.
    WOW64 breakpoint - code 4000001f (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    00000000`010791e7 cc int 3

    after Go Handled Exceptions command:

    32.4: kd:x86> gh
    The context is partially valid. Only x86 user-mode context is available.
    The context is partially valid. Only x86 user-mode context is available.
    Last edited by WaxfordSqueers; April 26th, 2019 at 20:38.

  3. #108
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,079
    Blog Entries
    5
    If you're talking about the usb Setup.exe file, one thing I noticed is that you have to open it as Admin, else Windbg will stop at the Consent.exe process instead, which is the dialog where you give permission. From there you'd have to break on a second loading of Setup.exe, if I remember correctly. Perhaps that isn't pertinent to your issue, but best to start it privileged so you've only got one OEP to aim for.

    Not sure why you're not breaking, here's a general procedure I follow to remotely debug a usermode target, pieced together from here and there. From initial break:

    Code:
    !gflag +ksl
    sxe ld Autoruns64.exe
    g
    
    START target program in VM
    
    r $proc
    .process
    
    bp /p @$proc nt!NtMapViewOfSection
    g
    
    x ntdll!RtlUser*
    .reload /user
    
    bp0 /p @$proc ntdll!RtlUserThreadStart
    g
    At this point you need to find the OEP. $exentry will not work without symbols so you need to find it another way when not directly opening the process in Windbg. From an earlier post here, Blabberer mentioned getting it from EAX at RtlUserThreadStart for 32bit. For x64 it's in RCX, but I wouldn't trust getting it from the registers, depending on the calling convention (/optimization I believe), registers aren't used for stack variables in the same way in x64.

    One way is to parse the PE file headers to get base address and address of entry point

    Code:
    lm
    start             end                 module name
    00000001`3f350000 00000001`3f426000   Autoruns64   (deferred)             
    
    kd> !dh 00000001`3f350000
    
    File Type: EXECUTABLE IMAGE
    
    OPTIONAL HEADER VALUES
    ...
       5EB04 address of entry point
        1000 base of code
        
    u 00000001`3f350000+5EB04    
    kd> u 00000001`3f350000+5EB04
    *** ERROR: Module load completed but symbols could not be loaded for Autoruns64.exe
    Autoruns64+0x5eb04:
    00000001`3f3aeb04 ??              ???
                                ^ Memory access error in 'u 00000001`3f350000+5EB04'
    
    
    bp0 00000001`3f3aeb04
    breakpoint 0 exists, redefining
    kd> bl
         0 e Disable Clear  00000001`3f3aeb04     0001 (0001) Autoruns64+0x5eb04
    
    kd> g
    Breakpoint 0 hit
    Autoruns64+0x5eb04:
    0033:00000001`3f3aeb04 4883ec28        sub     rsp,28h
    I like to use a script for the whole thing

    Code:
    $$ Command1.wds - WinDbg script to break on start of a usermode program while running WinDbg as a kernel debugger
    $$ 
    
    $$ $$>a<C:\temp\command1.wds autoruns64
    
    .block {
        .printf "Hello World!\n"
    }
    
    .block{
        r $proc
        .process
    }
    
    .block{
        bp /p @$proc nt!NtMapViewOfSection
        g
    }
    
    .block{
        .reload /user
        bp0 /p @$proc ntdll!RtlUserThreadStart
        g
    }
    
    .block{
        r $t0 = ${$arg1}+dwo(${$arg1}+dwo(${$arg1}+3c)+28)
        .printf "BaseAddress = %p OEP = %p \n", ${$arg1}, @$t0
        bp0 /p @$proc @$t0
        g
        .printf "Welcome to OEP \n"    
    }
    Kayaker

  4. #109
    Quote Originally Posted by Kayaker View Post
    If you're talking about the usb Setup.exe file, one thing I noticed is that you have to open it as Admin...
    Thanks Kayaker...tried that, as admin, no go. Remember that message box we talked about earlier where it tells you the system does not meet requirements? It runs straight to that message box.

    BTW...cannot see that messagebox listed as 'messagebox'. Just before I hit it, I noticed a reference to Find Resource. I am used to opening the stack to see where the messagebox was called from then progressively work back from it via the stack. Can't do that here since the stack addresses don't pertain to a call from the app. Either that or I am not using wdng correctly, which is likely.

    I am using a remote connection with a serial port. Has been working fine, much better than anticipated.

    I already know where the OEP is located, got it from IDA.

    BTW...there used to be a plugin for IDA from which you could create a pdb file. Don't recall details, but I think it was aimed at a sym file for sice. Wonder if that could be converted somehow to a pdb for windbg? I know a guid is required for wdbg sym files.

    Anyhoo...I just loaded the setup file in wdbg on the target and it stops fine if I load it using the File\Open Executable. However, the file is not called setup.exe at that point. If you open the setup file in wdbg you'll see it listed, but not as setup.exe.

    That's what it indicates in the ModLoad inital dialog in wdbg. The init dialog ends with:

    ntdll!LdrpDoDebuggerBreak+0x30:
    00000000'77626c50 cc int 3

    If I enter U $exentry it gives me the OEP but not as setup.exe, as the other filename.

    Thanks again, for the extra info.

  5. #110
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,079
    Blog Entries
    5
    I just wanted to mention that I've been getting consistent results breaking at the OEP of the setup file using the above procedure, *except* that it never breaks at RtlUserThreadStart for some reason, so I have to set the OEP bp after the first break of NtMapViewOfSection.

    I see why you put a foolproof CC at the OEP, this app did give some problems, but I wanted to confirm that Windbg will work correctly without having to resort to that.

    I see what you mean about it using the internal filename when opening directly in Windbg.

    In any case, here's where the MsgBox is hit for me. Of more use is probably what is written in the IntelUSB3.log file before that.

    Code:
    :004342C4                 push    offset aDidnTFindAnyInfSThatMatchActiveHar ; "Didn't find any INF's that match active"...
    :004342C9                 push    2
    :004342CB                 push    offset hObject
    :004342D0                 call    WriteIntelLog
    :004342D5                 add     esp, 0Ch
    :004342D8                 mov     edx, 80h
    :004342DD                 mov     ecx, 7DAh
    :004342E2                 push    0
    :004342E4                 push    7FBh
    :004342E9                 push    7F01h
    :004342EE                 push    1
    :004342F0                 call    ErrorMsgBox     ; to MessageBoxIndirectW
    :004342F0                                         ; Resource ID 7fb in Lang/setup.exe.mui
    :004342F0                                         ; "This computer does not meet the minimum requirements for installing the software."

  6. #111
    Quote Originally Posted by Kayaker View Post
    I see why you put a foolproof CC at the OEP, this app did give some problems, but I wanted to confirm that Windbg will work correctly without having to resort to that.
    Thanks Kayaker, I'll have to look into why it is not stopping.

    Quote Originally Posted by Kayaker View Post
    In any case, here's where the MsgBox is hit for me. Of more use is probably what is written in the IntelUSB3.log file before that.
    Thanks for the code snippet. I knew about the log file and I have forgotten to check it. It was creating issues for me during tracing and it took a long time for me to figure it out and avoid it.

    I note that the first PUSH refers to an INF file that cannot be found. That's interesting. The call to error msg also gives the name of the messagebox.

    I am forgetting my windows theory. Of course, it's not really a typical message box. It's an 'indirect' type of Window that stands on its own. That explains why I cannot trace it back on the stack. It appears the setup thread has already been terminated and the message box is part of the thread shutdown process.

    In other apps I have worked on, the messagebox is a call that must return before the thread shutdown proceeds.

    I could likely enter a conditional bp with the messagebox resource handle in [ebp-c], I think it would be. It would likely also show up in eax at some point.

    ps. thanks again for reminding me of log file. I noted things in there that offer excellent information as to one of my problems.

  7. #112
    @kayaker
    @blabberer

    Please don't bother with this stuff if it is giving you a headache.

    How much do you know about drivers in general? I got the setup.exe to run, based on the information you provided, and it loaded the drivers. However, they are still marked as 'unable to start'.

    The drivers are listed in Device Manager but have no resources assigned.

    I took this excerpt from a devnode dump, !devnode 0 1.

    PCI\VEN_8086&DEV_A36D&SUBSYS_86941043&REV_10\3&11583659&0&A0 is a reference to my xhci host controller, the first node of the USB tree at the PCU bus.

    I did not think there was a PDO but this lists one. It seems to be indicating that the PDO has been formed but not sent back to the PnP Manager.



    0: kd> !devnode fffffa800939a6e0
    DevNode 0xfffffa800939a6e0 for PDO 0xfffffa80083f8a10
    Parent 0xfffffa8009393610 Sibling 0xfffffa80083f6010 Child 0000000000
    InstancePath is "PCI\VEN_8086&DEV_A36D&SUBSYS_86941043&REV_10\3&11583659&0&A0"
    State = DeviceNodeInitialized (0x302)
    Previous State = DeviceNodeUninitialized (0x301)
    StateHistory[09] = DeviceNodeUninitialized (0x301)
    StateHistory[08] = DeviceNodeRemoved (0x312)
    StateHistory[07] = DeviceNodeStartCompletion (0x306)
    StateHistory[06] = DeviceNodeAwaitingQueuedRemoval (0x30f)
    StateHistory[05] = DeviceNodeStartCompletion (0x306)
    StateHistory[04] = DeviceNodeStartPending (0x305)
    StateHistory[03] = DeviceNodeResourcesAssigned (0x304)
    StateHistory[02] = DeviceNodeDriversAdded (0x303)
    StateHistory[01] = DeviceNodeInitialized (0x302)
    StateHistory[00] = DeviceNodeUninitialized (0x301)
    StateHistory[19] = Unknown State (0x0)
    StateHistory[18] = Unknown State (0x0)
    StateHistory[17] = Unknown State (0x0)
    StateHistory[16] = Unknown State (0x0)
    StateHistory[15] = Unknown State (0x0)
    StateHistory[14] = Unknown State (0x0)
    StateHistory[13] = Unknown State (0x0)
    StateHistory[12] = Unknown State (0x0)
    StateHistory[11] = Unknown State (0x0)
    StateHistory[10] = Unknown State (0x0)
    Flags (0x00002230) DNF_ENUMERATED, DNF_IDS_QUERIED,
    DNF_RESOURCE_REQUIREMENTS_NEED_FILTERED, DNF_HAS_PROBLEM
    CapabilityFlags (0x00002000) WakeFromD3
    Problem = CM_PROB_NOT_CONFIGURED
    Problem Status = 0x00000000

    *************

    0: kd> !devobj fffffa80083f8a10
    Device object (fffffa80083f8a10) is for:
    NTPNP_PCI0002 \Driver\pci DriverObject fffffa8009393470
    Current Irp 00000000 RefCount 0 Type 00000022 Flags 00001040
    SecurityDescriptor fffff8a0000bf250 DevExt fffffa80083f8b60 DevObjExt fffffa80083f8f90 DevNode fffffa800939a6e0
    ExtensionFlags (0x00000810) DOE_START_PENDING, DOE_DEFAULT_SD_PRESENT
    Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
    AttachedDevice (Upper) fffffa80091d45f0 \Driver\ACPI
    Device queue is not busy.
    Last edited by WaxfordSqueers; April 30th, 2019 at 01:02.

  8. #113
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,079
    Blog Entries
    5
    That seems useful, on the surface at least.

    CM_PROB_NOT_CONFIGURED - There is a device on the system for which there is no ConfigFlags registry entry. This means no driver is installed. Typically this means an INF file could not be found.

    Are the BootFlag and other settings in the Registry set and comparable to say those in a working Win10 usbxhci entry?

    I started looking at the DNF_RESOURCE_REQUIREMENTS_NEED_FILTERED error - The device's resource requirements list is a filtered list
    and what exactly this requirement list is, which apparently travels down the driver stack:
    https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/modifying-a-resource-requirements-list

    Then I started to search for Windbg commands that might give some info. The !arbiter extension shows the allocated ranges for usb drivers (usbuhci and usbehci for my Win7). Maybe your usbxhci entry is blank if Device Manager is showing no allocated resources for it?

    Still playing.

  9. #114
    Quote Originally Posted by Kayaker View Post
    That seems useful, on the surface at least.

    CM_PROB_NOT_CONFIGURED - There is a device on the system for which there is no ConfigFlags registry entry. This means no driver is installed. Typically this means an INF file could not be found.

    Are the BootFlag and other settings in the Registry set and comparable to say those in a working Win10 usbxhci entry?
    It's obvious I need to do more research, like comparing W7 to W10 more closely.

    I know it's tough for you since you don't have the actual hardware to deal with or even the drivers in the correct context. I think I have other issues related to the actual installation and I can't offer you good info yet till I look into that.

    For example, from the installation log, it tells me it cannot decipher the A36D device description. No kidding!! When the INF file was written, the A36D XHCI controller it describes did not exist. So, I have to see if I can track down what info it needs, maybe from the W10 xhci install which does know about the A36D controller.

    One problem is knowing where to look in the W10 registry. I am sure I can compare them directly in most cases. Another issue is that the USB 3 implementation seems to have changed between W7 and W10. Apparently W8 retained the USB 2 stack and implemented the USB3 stack in parallel, each with their own drivers. In W10, it seems they are implementing both USB 2 and 3 through the same stack, using only an xhci host controller for both.

    That should not really matter since Intel has released drivers for W7 that run on processors and chipsets very similar to my present processor/chipset. Intel has supplied no drivers other than the host controller, the hub driver, and a switch driver that I think serves to switch USB devices between operating modes. For example, sometimes a USB port is strictly an input port but at others it works as a server.

    Furthermore, I had W7 on a hard drive running on an ICH9 chipset which is at least 10 years older than my current chipset, and when I plugged the drive into my new mobo, everything on W7 ran fine except for the USB stack. The hard drives, display, etc., all ran fine using the old ICH9 drivers.

    I have since updated the W7 drivers to drivers better suited to the new mobo, but even at that, W7 runs happily with drivers designed for a chipset closer to mine than the ICH9.

    Furthermore, for some reason, the WOW64 node is being used. There are 32-bit apps being used by Intel, which explains part of that, but on a Russian site I saw a note that the USB3 drivers should be installed in the Windows directory in the SysWOW64 directory.

    Have not tried that yet.

  10. #115
    @kayaker @blabberer

    Scratching my head over how to test a non-working driver with limited understanding of how a driver should work.

    Recently I have been working on the driver loading process in Device Manager. I need a method to get wdbg to break on a hwnd when I press an OK button on a 32770 dialog box.

    With sice, I'd set it as bp <hwnd> <WM_COMMAND> or something like that. It seems more convoluted with wdbg.

    I have found the hwnd for the OK button using spy++ but as I recall, it was not desirable to bp on the OK button itself. I often had to bp further up the chain to get the bp to break on wm_command.

    Anyway, found the algorithm in the window below:

    The first part I can follow and the .load sdbgext now makes sense since I d/l'd the extension.

    The second bp is telling me wdbg should break if a pointer to a pointer at esp+4 is 0x202. Whaaaaa??? Could they not just have used poi(esp+8)? I know 0x202 is the wm_command code for WM_LBUTTONUP, although I have always used 0X201.

    Note....after more reading on poi, I realize it's not as simple as a pointer, it is described as 'pointer-sized data from the specified address', which is a Microsoft obfuscation for 'even we don't know what it means'. Anyway, I gather it's used because windbg was initially based on MASM which uses pointers in a different manner than C++. So you have to tell what you expect to find in the brackets like (esp+4).

    Is poi similar to the * used to indicate a variable is a pointer to an address rather than a value?

    The 2nd statement in the bp.... {!hwnd poi(poi(esp+4));gc } seems to be fetching the hwnd of the pointer to the pointer, but, again, why not just poi(esp+4)?

    The statement windbg -c "$$>a< ......\wtf.txt" calc
    Is telling wdbg to open calc.exe with the wtf text file which was created from the preceding code. I don't begin to understand the -c "$$>a< ...... part.



    bp user32!GetMessageW "pt;gc"
    g
    bc *
    .load sdbgext
    bp @eip ".if (poi(poi(esp+4)+4) == 0x202) {!hwnd poi(poi(esp+4));gc } .else {gc}"
    g

    windbg -c "$$>a< ......\wtf.txt" calc

    Window 00600438
    Name And
    Class Button
    WndProc 00000000
    Style WS_OVERLAPPED
    ExStyle WS_EX_NOPARENTNOTIFY WS_EX_LEFT WS_EX_LTRREADING WS_EX_RIGHTSCROLLBAR
    HInstance 01000000
    ParentWnd 00490534
    Id 00000056
    UserData 00000000
    Unicode TRUE
    ThreadId 00000df0
    ProcessId 00000f68
    Window 00150436
    Name Xor
    Class Button
    WndProc 00000000
    Style WS_OVERLAPPED
    Last edited by WaxfordSqueers; May 7th, 2019 at 21:38.

  11. #116
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,079
    Blog Entries
    5
    I'll have to file that script away, for breaking on a button click. No surprise the source

    That line is running the script file as the calc process opens, but could be used at any time, or as individual commands as well.

    https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/windbg-command-line-options

    Code:
    -c " command "
    Specifies the initial debugger command to run at start-up. This command  must be enclosed in quotation marks.
     Multiple commands can be separated  with semicolons. 
    (If you have a long command list, it may be easier to  put them in a script and then use the
     -c option with the $<, $><, $><, $$>< (Run Script File) command.)

  12. #117
    @kayaker....I did reply but maybe I forgot to send the message. Rust!!!

    Where's that blabberer, probably out there blabbing to someone?

    Heh. Working on attaching to a user-mode process on the target via k-mode debugging via serial port. Don't know if I'm barking up wrong tree. Have Device Manager running on target via mmc.exe console as snap-in. Have window open in Device Manager I am trying to access (OK button).

    Can't get my third party extensions running on wdbg. Keeps telling me it cannot find the file which is bs. Using the .chain command it lists one of my third party extensions then tells me it can't find it.

    Sometimes Microsoft can be really daft.

    Read this on Net:

    !process 0 0 mmc.exe returns:

    0: kd> !process 0 0 mmc.exe
    PROCESS fffffa8011ff6b00
    SessionId: 1 Cid: 1384 Peb: 7fffffd5000 ParentCid: 0618
    DirBase: 1152f9000 ObjectTable: fffff8a0038c0660 HandleCount: 403.
    Image: mmc.exe
    Then .process /r /p fffffa8011ff6b00 returns this:

    0: kd> .process /r /p fffffa8011ff6b00
    Implicit process is now fffffa80`11ff6b00
    .cache forcedecodeuser done
    Loading User Symbols
    Now I am supposed to be in context of mmc.exe. In fact, using those commands returns a whole slew of U-mode apps later with lm. Verrrry interrrrresting.

    Another method using .process /i fffffa8011ff6b00 requires me to hit g and when wdbg breaks I am supposed to be mmc.exe context. I set the bp on user32!getmessagew and it breaks on every message available except mine.

    In fact, I cannot access the target to press the OK button. It's frozen. Maybe I did not wait long enough.

    I guess getmessage is not the best bp since Windoze is a message-based system.

    Using method 1 with the /r /p commands I set a 'bp user32!getmessagew' but nothing happens when I hit the OK button.

    Last night, using wdbg in straight U-mode it broke every time. However, I could not find the hwnd I needed for OK button. I found loads of Device Manager hwnds for the various Device manager windows but not the one I needed.

    Thought I may have better luck with a remote K-mode session but no. Found myself stepping through the Windows message loop as each Window had messages processed but nothing for the OK button.

    Just thinking I may have to look closer at another hwnd for the message 0x201 being processed.

  13. #118
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,079
    Blog Entries
    5
    I've been playing with this a bit for fun, interested in how to break on a usermode Message in Windbg running remotely in kernel mode.
    You've probably made some progress in finding a suitable breakpoint, but in any case.

    I tried some things with Spy++ and found click messages, but I was noticing that devmgr.dll (+.mui / Reshacker) is the Device Manager dialog control, over the parent mmc.exe. When I took a closer look at the code there seems to be dedicated functions for important stuff Device Manager does.

    There are 4 Messaging functions that are probably the replacement for the missing GetMessage api:

    Code:
    .text:5FC81000                   ; File Name : devmgr.dll
    
    .idata:5FCC93D4                   ; LRESULT __stdcall DispatchMessageW(const MSG *lpMsg)
    .idata:5FCC93D4 ?? ?? ?? ??                       extrn __imp__DispatchMessageW@4:dword
    .idata:5FCC93D4                                                           ; CODE XREF: CMachine::Reenumerate(void)+90
    .idata:5FCC93D4                                                           ; CRemoveDevDlg::OnOk(void)+120
    .idata:5FCC93D4                                                           ; CInstallDriverDlg::OnOk(void)+119
    .idata:5FCC93D4                                                           ; CRemoveDriverDlg::OnOk(void)+130
    
    .idata:5FCC93D8                   ; BOOL __stdcall TranslateMessage(const MSG *lpMsg)
    .idata:5FCC93D8 ?? ?? ?? ??                       extrn __imp__TranslateMessage@4:dword
    .idata:5FCC93D8                                                           ; CODE XREF: CMachine::Reenumerate(void)+86
    .idata:5FCC93D8                                                           ; CRemoveDevDlg::OnOk(void)+116
    .idata:5FCC93D8                                                           ; CInstallDriverDlg::OnOk(void)+10F
    .idata:5FCC93D8                                                           ; CRemoveDriverDlg::OnOk(void)+126
    
    .idata:5FCC93DC                   ; BOOL __stdcall IsDialogMessageW(HWND hDlg, LPMSG lpMsg)
    .idata:5FCC93DC ?? ?? ?? ??                       extrn __imp__IsDialogMessageW@8:dword
    .idata:5FCC93DC                                                           ; CODE XREF: CMachine::Reenumerate(void)+78
    .idata:5FCC93DC                                                           ; CRemoveDevDlg::OnOk(void)+108
    .idata:5FCC93DC                                                           ; CInstallDriverDlg::OnOk(void)+101
    .idata:5FCC93DC                                                           ; CRemoveDriverDlg::OnOk(void)+118
    
    .idata:5FCC93E0                   ; BOOL __stdcall PeekMessageW(LPMSG lpMsg, HWND hWnd, UINT wMsgFilterMin, UINT wMsgFilterMax, UINT wRemoveMsg)
    .idata:5FCC93E0 ?? ?? ?? ??                       extrn __imp__PeekMessageW@20:dword
    .idata:5FCC93E0                                                           ; CODE XREF: CMachine::Reenumerate(void)+9E
    .idata:5FCC93E0                                                           ; CRemoveDevDlg::OnOk(void)+12F
    .idata:5FCC93E0                                                           ; CInstallDriverDlg::OnOk(void)+128
    .idata:5FCC93E0                                                           ; CRemoveDriverDlg::OnOk(void)+13F
    And a procedure that uses them:

    Code:
    .text:5FCBCACA                   ?OnOk@CInstallDriverDlg proc near
    .text:5FCBCACA                                                           ; CODE XREF: CInstallDriverDlg::OnCommand(uint,long)+21
    
    .text:5FCBCB8E 68 80 C6 CB 5F                    push    offset ?InstallDriverThreadProc@@YGKPAX@Z ; lpStartAddress
    .text:5FCBCB93 53                                push    ebx             ; dwStackSize
    .text:5FCBCB94 53                                push    ebx             ; lpThreadAttributes
    .text:5FCBCB95 FF 15 30 92 CC 5F                 call    ds:__imp__CreateThread@24 ; CreateThread(x,x,x,x,x,x)

  14. #119
    Quote Originally Posted by Kayaker View Post
    There are 4 Messaging functions that are probably the replacement for the missing GetMessage api:
    Thanks for taking the time, kayaker.

    I have actually traced through the loop you have listed using wdbg in user mode. That's when I start mmc.exe with wdbg then loaded Device Manager from the mmc shell. You look for devmgr.msc in sys32 and open it with the mmc shell. There is a loop (of course there is...getmessagew...duh!!!) and I can watch all the windows in Device Manager being processed by hwnd.

    I have even broken in user32!getmessagew by setting bp user32!getmessagew with wdbg in user mode and it gets activated when I press the OK button in device manager. I was able to trace from there into the message loop that is processing the device manager hwnds. I just couldn't find the one with the window message 0x201.

    I mentioned this before. The 0x201 message likely won't show up with the OK button hwnd, it will likely be in a window further up the window tree. Using spyxx, you can set it to check for which window is using the wm_command routine. I'll need to take a closer look. Rust!!!

    You have given me an idea I should have thought of. I should be able to take almost any address in the mmc context from my host machine. I can load mmc as a process from the host but I wonder if I could load devicemgr.dll as a process or a dll. I am thinking !dll but when I tried to list the dlls from the host it claimed it could not find something or other. I'll get the specific error message but I can't right now.

    It may be that the context for mmc.exe is not the correct context for devicemgr.dll. It also occurred to me that I should be in the context for user32 when I set the bp for user32!getmessagew. I tried to get into the user32 context from the host using
    process 0 0 user32 but nothing came up.

    One thing I have not dealt with in wdbg is identifying the context I am in. When I traced through the message loop you included, all the hwnds in device manager were being processed but I did not think to see if they were in devicemgr.dll. I should be able to see that on the stack.

  15. #120
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,079
    Blog Entries
    5
    I guess what's confusing me is I don't see GetMessageW in the list of imports in IDA in either mmc.exe or devmgr.dll. You must have a secret trick.

Similar Threads

  1. Key generation
    By rebx in forum The Newbie Forum
    Replies: 4
    Last Post: December 17th, 2011, 12:46
  2. License generation WLSCGEN
    By calvin in forum The Newbie Forum
    Replies: 0
    Last Post: March 2nd, 2010, 04:38
  3. how does certificate generation work ?
    By p_2001 in forum The Newbie Forum
    Replies: 15
    Last Post: March 17th, 2009, 11:57
  4. FlexLM license generation
    By Killer_l00p in forum Malware Analysis and Unpacking Forum
    Replies: 2
    Last Post: June 18th, 2001, 13:14
  5. FlexLM license generation
    By Killer_l00p in forum Malware Analysis and Unpacking Forum
    Replies: 0
    Last Post: June 15th, 2001, 05:30

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
  •