USB drivers for Win 7 on 8th generation Intel chipset

[WaxfordSqueers]

Setting a safety BP on GetProcAddress for example with a conditional IF PID=<your process> should help if you're trying to make the step from K32 to the beginning of your code.

Thanks. That brings back some memories. Or, after landing at _baseprocessstart, I may be able to F5 (is that Go?) till I hit a BP at GetProcessAddress pointing to my app's address near 0x0400000. I notice on a similar call to advapi.dll that advapi showed up as a symbol in a PUSH just before GetProcessAddress.

I need the start of code because there's a check for the Window's version that is throwing up an error window between SOC and Winmain. I have traced almost to it and have the address noted so if I get into the app context I can set the addr and save myself a lot of tracing.

This will be driving Blabberer crazy so i want to assure him I am definitely working on setting up Windbg and learning it this time. I have already thought of setting _baseprocessstart as a BP in Windbg to access start of code, and I am looking forward to it, believe it or not.

It's the rust, I tell you, the rust!!!

[WaxfordSqueers]

Kayaker...the reason I suggested not running disk drives off unpowered hubs is the insensitivity of hard drives to power fluctuations or inadequate power. If a hard drive is writing, and the power goes down, or gets too low, it could be interrupted during a write and write garbage in the wrong places.

Another problem is that the power may be lost while the write head is extended. Some drives I have seen used a capacitor with enough charge to get the get back to the parked position during a power fail. The spindle motor drives the disk platter fast enough to blow the heads off it and keep them airborne. If the power fails suddenly, the heads could drop onto the platter surface and score it. That's why a drive should never be moved while it's under power unless extremely carefully. If the drive gets dropped and the heads hit the surface, it's usually an unusable drive.

Trying to pull the heads apart with fingernails proves to be quite a task. They hands are under quite a bit of pressure. It goes to show how much air pressure the platters supply at 7200 RPM to allow the heads to 'fly' above the disk.

Electronic devices these days have good regulators in them and they can deal with fluctuations in power well but you never know when an unpowered hub might suddenly fail to supply adequate current. Last night, I noted that the power plug to my powered regulator had come out and the hub was running off straight USB power from the mobo. Some modern USB hubs are designed to deliver quite a bit of power but you can never tell what an unpowered hub is delivering.

[Kayaker]

That would be a good precaution.

Interestingly, I've had TraceView monitoring usbhub3.sys activity and I've come back a couple of times with a window full of WPP debug logging output. It looks like the driver occasionally reenumerates all the usb ports under its control. My non-powered hub initially returns a status of PORT_LINK_STATE_INACTIVE, though I'm not quite sure of the significance of that yet.

[WaxfordSqueers]

re PORT_LINK_STATE_INACTIVE

In communications lingo, a link is a connection between devices. Not as much the physical cable as the data stream The protocol for describing data communications is the OSI model which has seven abstract layers which are manifested by things like physical pins and cables, data streams, packets of information, etc.

https://en.wikipedia.org/wiki/OSI_model.

I imagine PORT_LINK_STATE_INACTIVE refers to one of the data links from one port being inactive. With USB, it likely means there is no cable inserted with a device attached. Or it might means there is a cable and a device but no life is detected on the device end since it is not powered on.

I do know that when you connect a USB device via a cable, the hub queries the device to get its info, like vendor and hardware device ID, and passes that on to the Plug 'n Play Manager.. Apparently PnP then talks with setupapi which figures out the drivers required.

You might want to set a BP on setupapi to see if anything interesting is going on.

[WaxfordSqueers]

Which gives me an idea. Even though my W7 ports don't work, maybe they are still being monitored by the physical hub. After all, the physical hub can't turn it's nose up at a device being plugged in. There are no software controlled gates that I know of like the tri-state devices they use to isolate the busses from the processor.

Normally, in the old days, when a device was connected, it set off an IRQ to interrupt the processor and request service. Microsoft changed all that by isolating the hardware from the software. At one time, you could send data straight to a port but now you have to go through HAL and all the rest.

[WaxfordSqueers]

Kayaker....don't know if this is if interest. It's a USB header file from Github that seems to come from the WINDDK:

https://github.com/tpn/winddk-8.1/blob/master/Include/shared/usbspec.h

An excerpt (format lost):

typedef enum _USB_PORT_FEATURE_SELECTOR {
PORT_CONNECTION = 0,
PORT_ENABLE = 1,
PORT_SUSPEND = 2,
PORT_OVER_CURRENT = 3,
PORT_RESET = 4,
PORT_LINK_STATE = 5,
PORT_POWER = 8,
PORT_LOW_SPEED = 9,
C_PORT_CONNECTION = 16,
C_PORT_ENABLE = 17,
C_PORT_SUSPEND = 18,
C_PORT_OVER_CURRENT = 19,
C_PORT_RESET = 20,
PORT_TEST = 21,
PORT_INDICATOR = 22,
PORT_U1_TIMEOUT = 23,
PORT_U2_TIMEOUT = 24,
C_PORT_LINK_STATE = 25,
C_PORT_CONFIG_ERROR = 26,
PORT_REMOTE_WAKE_MASK = 27,
BH_PORT_RESET = 28,
C_BH_PORT_RESET = 29,
FORCE_LINKPM_ACCEPT = 30
} USB_PORT_FEATURE_SELECTOR, *PUSB_PORT_FEATURE_SELECTOR;

[WaxfordSqueers]

BTW....ran into a problem last night I have not encountered before. Loaded a setup.exe file in Symbol Loader and set BPX on _baseprocessstart and when I hit 'Load' in Symbol Loader, nothing happened.

I immediately syspected a TLS issue and IDA revealed a TLSCallback in the RDATA section but not related to the main code. There is a TLS section there as well in the PE header.

I noted that another BP had been set somehow, but not by me. It is k32!BaseCheckAppcompatCache. If I table it, the context is NToskrnl and if I table back to k32, my original BP is still set on K32!_baseprocessstart.

Today, starting fresh, after initiating load with Loader32 I got one line after CTRL D back into debugger. This was after running the app from the LOAD feature in Loader.

NT$$$: Load32 Start=517B0000 SIZE=7B000 KPEB=81F85560 MOD=msdia20

I know the app I am trying to load is much newer but it's a 32-bit app. I am not trying to run it to install its load I am only trying to trace to an error message it gives regarding the W7 system not having the required features. I just want to see what it's complaining about.

[Kayaker]

Just refreshing my own memory (the rust, the rust!)

ntdll!LdrpCallTlsInitializers should be the way "in" to TLS Callbacks

https://doxygen.reactos.org/d8/d55/ldrutils_8c.html#a08a1787a2f1a050432fcdbbc5f16c4d6

[WaxfordSqueers]

ntdll!LdrpCallTlsInitializers should be the way "in" to TLS Callbacks

Thanks...worth looking into.

Meantime I have an issue with Activation Contexts it seems.

Used the BP from NToskrnl...BaseCheckAppcompatCache to set a BP and the app broke there...at 7C81686E on my kernel. So it's not getting as far as _baseprocessstart before simply stopping. I am guess it has made a call to a non-existent address or something strange.

I have been tracing from there and just got through a call to __imp__RtlActivateActivationContextUnsafeFast.

Msoft calls Activation Contexts areas in memory that can redirect an app to the right dll and it also relates to the SxS directory. Not sure that XP had an SxS directory.

I am currently back in K32 at 7C8169CA but I have no idea as yet what I am doing.

[WaxfordSqueers]

Kayaker...please don't think I'm ignoring your input on USB...I do appreciate your efforts.

Right now I'm stuck trying to figure out if I'm beating my head against the wall trying to load drivers for W7. That's why I'm doing this tracing right now. I am eliminating all reasonable possibilities before plunging into tracing the problem with Windbg or one of its fellow debuggers.

I have a disk that comes with my B360 mobo and I needed to get at the driver files in there to see if they'd load. I noted an ini file which had all the Windows versions listed but commented out. I found my Win version for W7, uncommented it, and it happily loaded all the chipset drivers except for USB 3.

Now I am working on the Intel USB 3 setup file for W7, to which I linked in an earlier post. It wont install in W7 but gives no good reason why. It does not state that the version of Windows is wrong it simply says the computer does not meet the minimum requirements, which is crazy. The computer, if anything, exceeds the minimum requirements since those drivers are for a slightly earlier version than my mobo chipset.

I am slowly getting up to speed on Windbg et al but at this point I don't have the familiarity to keep up with you.

Made some headway tonight, the app is exiting via Loader 32 before reaching _baseprocessstart. Did not encounter any reference to TLS issues. That does not mean they are not there.

On top of that, I noticed a registry hack that allows the USB drivers to show up in the Windows 7 hardware installer. You can access the installer in W7 Device Manager by right-clicking the root of the directory tree in DM and clicking the legacy install option.

Till I adjusted the registry there were no USB drivers showing up there. Now I have them all but when I select an INF file, W7 merely returns to the menu rather than processing the drivers. Seems to me some vital software has been removed which is not very nice.

[WaxfordSqueers]

@kayaker @blabberer or anyone reading this thread.

While I am awaiting my USB-serial adapter to run Windbg on a remote monitor, I decided to try Olydbg, both versions. I am also looking at Syser which has apparently been recently upgraded for 64 bit.

Took me a while to sort out Olly, the fonts were so small on my 1920 x 1080 screen. The trick is to go into Options and rename one of the stock font sizes to your own name. I called mine Myfont. Then you can adjust the size of the fonts to a readable size, like 14 or 16 even.

Anyway, I am managing to run both versions by intuition based on softice. I wish Olly had some of the extensive features of softice, like being able to set watch windows for ESI and EDI rather than a generic dump window.

I cannot, for the life of me, figure out how to type in an address as a breakpoint. In fact, I was merrily going along using F7 and F8 to single-step and jump over when suddenly Olly 2 froze with a hardware breakpoint I did not set.

Some of the apps I have seen precede the code with CC's and maybe Olly misinterpreted such a scenario as a hardware breakpoint.

The other problem, which is an annoyance, is the base Olly uses for the app. I am used to the base being 0x0400000 and they use a different base each time. Is there a way to force it onto 0x0400000?

I am thinking since it's a user-level debugger that it cannot seize 0x040000. Maybe I could unload apps till it can.

[WaxfordSqueers]

@kayaker @blabberer

A pretty heady discussion between kayaker and blabbs circa 2012.

http://www.woodmann.com/forum/showthread.php?14904-ollydbg-2-x-plugin-OLLY_LKD

I am getting closer to resolving symbol problem on Windbg and Olly 2 thanks to such debates and other posts by Blabberer on Windbg. However, the Olly 2 command line remains mysterious.

According to Olly himself, it should be reached with an Alt-F2. On my version, 2.1 something, it doesn't work. I see no reference to a command line window in the menu either.

I want to write in a breakpoint, like BPX <address> or BPX _baseprocessstart. Olly does allow a start on a system breakpoint but where to enter it.

And, no, I'm not that dumb.

[Kayaker]

I believe Alt-F2 closes the program, which is what it does for me, see here

http://www.dc214.org/notes/rev_eng/Docs/OllyDbg%20Shortcuts.pdf

I'm not sure what command line window you're looking for, but what I usually do is right click in the CPU window and use a combination of Select Module and/or Search For to find a named target for a BP, or Go to Expression if I want to go to an address, then use F2 or the breakpoint menu to set it.

I don't think you'll find _baseprocessstart in Olly since it's not exported. Nor should you really need it, I think that was more of a Sice trick when the Loader sometimes didn't stop on WinMain.

A system breakpoint (not sure where that is offhand), TLS callback, Winmain, etc is usually set in Options beforehand you might have noticed.

As for the random loading not at base 0x400000, that would be ASLR I assume. I was reading that the Enhanced Mitigation Experience Toolkit (EMET) can be used to opt out of that for selected processes. I just d/l it for fun but haven't tried it yet.

https://www.microsoft.com/en-us/download/details.aspx?id=54264

Is this XP you're tracing in or Win7 x64 out of curiosity?

[WaxfordSqueers]

I believe Alt-F2 closes the program

I believe you're right, found out the hard way.

I'm not sure what command line window you're looking for

I saw a window on the Net in which you can enter a BP manually, like BPX <address>. I'm sure it was Alt-<something>.

I don't think you'll find _baseprocessstart in Olly since it's not exported. Nor should you really need it, I think that was more of a Sice trick when the Loader sometimes didn't stop on WinMain

.

Yes...I have checked out the various means of stopping and the system BP stops in ntdll @ 77AF0F75. I encountered another by name and it has 'base' something or other. I was interested due to the TlsCallback thing. I'd like to see how it's handled before OEP.

If you check the stack when the app stops at OEP, you can see a string where it will return following the string.

Is this XP you're tracing in or Win7 x64 out of curiosity?

It's Win7 SP1 6.1 7601. My processor is 64 bit.

I am starting to get more used to it but there may be bugs in Olly 2. I keeps claiming there is something unknown @ 36E1B0 = 4 and it stalls there. Last time I looked the EIP was pointing to something in U32 just following a call.

Anyway, Olly claims it won't work on an x64 system but it's working fine on mine for the most part. I think most setup files are still 32-bit, I could be wrong, and W7 does have the WOW section which I think can handle a fair amount of x86 activity.

[blabberer]

1) ollydbg v2 does not have a command-line interface natively (third party plugins are available which provide the functionality)
2) ollydbg has quirks running in 64 bit machine under wow layer (ollydbg is 32 bit 64 bit not released yet )
3) there is an actively developed opensource project for 64 bit called x64dbg (interface similar to ollydbg but using Qt )
you can give it a try
4) BaseProcessStart is xp for vista+ os use ntdll.RtlUserThreadStart
5) ctrl+g type RtlUserThreadStart -> follow Label -> hit f2 to set a break point -> f9

This Function Is a kernel mode call back and is invoked via NtContinue as such you will not have a stacktrace the arguments to this function are in registers Eax, Ebx in 32 bit viz AddressOfEntryPoint and PEB (Process Environment Block)




ollydbg has a watch window use ALT+V or view Watches add watches as needed
tile windows to keep watch window visible and trace



of course there is no match to windbg guis cant compete with console


you can stop even before kernel32 is loaded in the process even before peb is created


C:\>cdb -xe ld:ntdll calc

Microsoft (R) Windows Debugger Version 10.0.17763.132 X86

ModLoad: 00ba0000 00c60000   calc.exe
ModLoad: 77370000 774ac000   ntdll.dll
eax=00bb2d6c ebx=7ffd5000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000
eip=773b70d8 esp=000dfbe4 ebp=00000000 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000200
ntdll!RtlUserThreadStart:  <<<<<<<
773b70d8 89442404        mov     dword ptr [esp+4],eax ss:0023:000dfbe8=00000000

ntdll is loaded now

0:000> lm
start    end        module name
00ba0000 00c60000   calc       (deferred)
77370000 774ac000   ntdll      (pdb symbols)          e:\symbols\ntdll.pdb\CD4062A231154A17A18DAE7D1A0FBACC2\ntdll.pdb

you can catch loading of kernel32.dll if you set a break here

0:000> bp ntdll!LdrLoadDll
0:000> g
Breakpoint 0 hit
eax=000df7ec ebx=7ffd5000 ecx=773d36f6 edx=7744cd48 esi=773d7de0 edi=00000000
eip=773d22ae esp=000df738 ebp=000df8a4 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
ntdll!LdrLoadDll:
773d22ae 8bff            mov     edi,edi
0:000> kb
ChildEBP RetAddr  Args to Child
000df734 773d7d33 00000000 00000000 773d7de0 ntdll!LdrLoadDll
000df8a4 773d60a7 000df918 77370000 74445d42 ntdll!LdrpInitializeProcess+0xfe7
000df8f4 773d3659 000df918 77370000 00000000 ntdll!_LdrpInitialize+0x78
000df904 00000000 000df918 77370000 00000000 ntdll!LdrInitializeThunk+0x10
0:000> g
ModLoad: 76e00000 76ed4000   C:\Windows\system32\kernel32.dll
Breakpoint 0 hit
eax=773d22ae ebx=00000000 ecx=000df1a0 edx=00000062 esi=773c8b19 edi=000df1c0
eip=773d22ae esp=000df184 ebp=000df1ac iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!LdrLoadDll:
773d22ae 8bff            mov     edi,edi
0:000> g

system break point is so far below it will take ages to reach here if you single step

ntdll!LdrpDoDebuggerBreak+0x2c:
774105a6 cc              int     3
0:000>