View Full Version : USB drivers for Win 7 on 8th generation Intel chipset
WaxfordSqueers
February 14th, 2019, 19:22
Hi...have not done much reversing as of late, especially since RCE closed down. Taking an interest in tracing the usbxhci.sys driver for W10 to see if I can adapt it for use on Win 7 on an 8th generation Intel chipset.
The chipset is an Intel B360 and it seems Intel no longer makes drivers for their own chipsets, having deferred to Micro$oft.
Bit of history, then questions. I have loaded Win 10 on an Asus B360M-C mobo which uses an i5 - 8200 8th generation processor. I wanted to load an installed win 7 OS which I had on a hard drive. Surprisingly, it booted straight to the logon screen, graphics and all, using stock SP1 drivers. I had to rig USB to PS/2 adapters to get my mouse and keyboard working (another USB keyboard in a USB port to get past the boot screen) but after that I could log in and got straight to the desktop.
Most of the stock W7 drivers seemed to be working fine....all but the USB drivers which require a USB 3/3.1 driver. Of course, m$oft has crippled W7 by not supplying the USB drivers. They claim to be protecting W7 users due to a lack of updates, but if that's the case, why are they detecting W7 on 7th and 8th gen chipsets and blocking those users from updates? And why do generic drivers work on this mobo for W10 and not W7?
Questions:
1)What is currently the best dissassembler/debugger? I have never learned Olly and did get started on Windbg. IDA, of course, is still there and I notice Ilfak has released a free version of IDA 7.
2)If I start Olly what is the best platform? Does it work on win 7 and 10? The original seems pretty dated but Olly 2 does not seem to be popular for some reason.
3)If kayaker is still out there, how's the paddling? Fixed ice yet to run on W7?
4)If blabberer is still out there I could use your help getting going on windbg....again!!!
blabberer
February 15th, 2019, 23:20
Hi Waxford its been a very long time yeah i am still here
shoot the bangs let me see if i can dot them
WaxfordSqueers
February 17th, 2019, 00:05
Quote:
| [Originally Posted by blabberer;97579]Hi Waxford its been a very long time yeah i am still here shoot the bangs let me see if i can dot them |
Yeah...I have missed you guys. I regard you and kayaker as old friends, not to mention Woody and some of the other guys. I just saw 'disavowed' mentioned in another thread and believe it or not, a piece from +gthorne. Saw Delta's nym as well.
Hope you are doing well.
I have actually made some ground since I made the post a few days ago. Windbg does not seem as intimidating as I last remembered it.
I am working on finding a way to d/l symbols. Apparently msoft has changed the way it used to allow bulk downloads.
I am also wondering about the best platform. I have W10 running on an 8th generation board but it won't allow W7 to load USB drivers. I am looking into that as well, primarily to see if it's due to the hardware requirement or whether msoft has just gotten ornery and are forcing people to upgrade to W10.
I have just been advised by a local supplier that he can get me a really good USB - serial interface. I was hoping I might be able to connect my laptop to windbg on my desktop via the interface and use remote debugging.
I am running VMWare player ver 15 on W10 but right now I am running version 12 on Win7 with both softice and windbg loaded.
I was able to run Windbg on the VM (with an XP Pro VM I had available), as far as loading an app and setting a BP to break on Winmain. Then the menu bar disappeared and I had to quit. That's my fault. There is an error windows displayed between start of code and winmain and I guess something got out of whack. It's claiming the OS is wrong...no kidding...but I am just trying to get it to dump its files so I can check to see what drivers it has.
I am trying to remember our previous discussion on Windbg. Did you claim it was possible to trace right through ring 0 code?
Also, we had discussion with kayaker about contexts as applied to softice. You have to ensure you are in the proper context before setting a BP.
Does that apply to windbg as well? Can I simply set a BP at Kernel!_baseprocessstart, after loading an app, as in softice, and break in k32 near the code entry point? Then trace from there?
In many ways, it seems that windbg may be quite similar to softice in that respect only far more sophisticated.
Kayaker
February 17th, 2019, 01:00
Hey Waxford, great to see you around!
Sorry, no modern Softice port yet, I'm still trying to figure out how to get it to display in a large enough readable size font in an XP image in VMWare Player on a 4K monitor on Win10. Funny enough it's not High DPI aware, imagine that. I'm keeping my old Win 7 box for that kind of emergency old school reversing
Just a couple of comments for background, I had a quick look at the Asus site for that B360 MB and there's a comment in the FAQ about usb drivers and Win7, something about setting XHCI Hand-off to Enabled in the BIOS, perhaps you're aware of that or it's already set. You're right it seems, searching for "B360" at the Intel driver site doesn't pick up any updated usb drivers, is there any possibility that the Intel® Driver & Support Assistant might detect any updates for your system?
Oh, I started writing this before reading your last reply. I was going to mention that I'm interested in how you set things up to trace the driver and if you might use VMWare and remote debugging. I was also wondering if you can get USB 3 support with your Win7 image on VMWare Player itself running on that MB. I seem to remember having to get VMWare to update for that when I set it up on my new Win10 system.
I used to use VirtualKD for remote Windbg debugging, would that be useful? It seems to still be actively developed.
http://virtualkd.sysprogs.org/
As a side note, the reason I'm interested in this is that I was just starting to think about researching/reversing to find out which driver(s) trigger the "USB Disconnect" sound you get when you unplug a usb device. For the past few months I've been getting that sound randomly when nothing is happening, sometimes several times a day, sometimes never. I've tried setting up a logging action with EventGhost but that didn't give enough information. I've also tried Procmon to trigger when the .wav file (that I changed to a custom sound file) is accessed. That only showed that Explorer opened the file and played it internally with winmm/PlaySoundW, but not what triggered Explorer to even open.
It could be a lot of things causing it, but one possibility is an intermittent usb disconnect/reconnect, perhaps related to a wake-on device setting, something related to that was actually a Win7 hotfix at one point. I could simply ignore it or disable the sound, but what's the fun in that?
Yeah, I was just commenting to blabberer and the others a short time ago about missing all the great discussions we had here. But hey, that doesn't mean we can't still have them! Cheers.
WaxfordSqueers
February 17th, 2019, 02:23
Quote:
| [Originally Posted by Kayaker;97581]Hey Waxford, great to see you around! |
Yeah...great to hear from you and I hope you are keeping well. I have visited site a few times but did not see much in the way of posts.
Quote:
| [Originally Posted by Kayaker;97581]Sorry, no modern Softice port yet, I'm still trying to figure out how to get it to display in a large enough readable size font in an XP image in VMWare Player on a 4K monitor on Win10. Funny enough it's not High DPI aware, imagine that. I'm keeping my old Win 7 box for that kind of emergency old school reversing |
I changed width to 160 and lines to 100. I am working on a 22" monitor and i could have gone to 120 lines. Even at that I have to squint bit.
I have done considerable tracing tonight, however, and with my face close enough to the screen it has not be difficult to see. Had to get some rust out re table command and addr but got an app to break no problem at _baseprocessstart. It's running through ring 0 like nobody's business and very stable.
Just noticed that my nms files are badly outdated. Go figure, I'm using the XP kernel, etc., and I don't recall msoft updating XP.
Quote:
| [Originally Posted by Kayaker;97581] Just a couple of comments for background, I had a quick look at the Asus site for that B360 MB and there's a comment in the FAQ about usb drivers and Win7, something about setting XHCI Hand-off to Enabled in the BIOS, perhaps you're aware of that or it's already set. You're right it seems, searching for "B360" at the Intel driver site doesn't pick up any updated usb drivers, is there any possibility that the Intel® Driver & Support Assistant might detect any updates for your system? |
I'm pretty sure I have XHCI handoff enable. Tonight I learned how to turn off Secure Boot in the AMI BIOS and in the boot menu area, an F8 takes you to the Safe Mode menu where there is an item at bottom of list to disable driver certification. Apparently you can turn it off permanently using 'bcdedit.exe /set nointegritychecks on'. I can direct you to a page on that if you like as well as one about certifying your own drivers (Linux-based but from what I've read it could likely be easy to do in Windows).
Tried the Intel driver support app but no go. I am not claiming Intel is in cahoots with msoft because they were good enough to release W7 drivers for early 300 series chipsets (generation 8 and some 9). However, they have announced that as of Nov 2018 they are no longer issuing driver updates. They are handing off to msoft. I understand they have stopped making mobos as well.
I tried to load the drivers they supplied for 300 series but mine must be too new. I don't see why they would not work on W7, even with the newer chipset. I have a peripheral card from Vantec, model UGT-PC341 working fine for W7 in and a PCIe slot.
Quote:
| [Originally Posted by Kayaker;97581] I was going to mention that I'm interested in how you set things up to trace the driver and if you might use VMWare and remote debugging. I was also wondering if you can get USB 3 support with your Win7 image on VMWare Player itself running on that MB. I seem to remember having to get VMWare to update for that when I set it up on my new Win10 system. |
Have not tried tracing the driver yet on Win 10. I have been trying to exhaust some driver loading issues first. As I said in my reply, I am onto a USB-Serial Port adapter that may work for remote debugging between my laptop and the desktop. Also, I have been setting up Windbg with symbols, etc.
The thing that makes me suspicious is that I had W7 loaded on its own drive. When I plugged it into a SATA port on my new mobo, it fired up fine to the logon screen. Of course, I had no keyboard or mouse since they are both USB. Got past that because luckily my new mobo has PS/2 ports which worked find for logging on. However, to get there I had to get past a boot screen to select W7. I could have disabled it but I had another USB keyboard which I plugged into the new mobos USB port. It worked fine during boot, then the PS/2 setup, using two USB-PS/2 adapters got me the rest of the way.
In Device Manager, there were hardly any drivers flagged. The video was working on a stock VGA driver which was already loaded and I got 1920 x 1080 resolution no problem. I did change a few drivers but the only outstanding drivera are the USB drivers, which were all missing. They would not simply disappear on their own, somebody had to remove them. I think we know who that someone might be.
Msoft simply does not want anyone running W7 on newer mobos and processor. The reason seems apparent, W7 is equal to or better than W10 for performance, especially on a newer mobo with a 6 core processor.
Quote:
[Originally Posted by Kayaker;97581]I used to use VirtualKD for remote Windbg debugging, would that be useful? It seems to still be actively developed.
http://virtualkd.sysprogs.org/ |
Worth checking out, thanks for link. Was that known as LiveKD as well?
Quote:
| [Originally Posted by Kayaker;97581]As a side note, the reason I'm interested in this is that I was just starting to think about researching/reversing to find out which driver(s) trigger the "USB Disconnect" sound you get when you unplug a usb device. |
Possible solution:
https://www.maketecheasier.com/stop-random-usb-connect-noises-windows/
Quote:
| [Originally Posted by Kayaker;97581]Yeah, I was just commenting to blabberer and the others a short time ago about missing all the great discussions we had here. But hey, that doesn't mean we can't still have them! Cheers. |
I agree.
WaxfordSqueers
February 17th, 2019, 20:35
Quote:
| [Originally Posted by Kayaker;97581]I was also wondering if you can get USB 3 support with your Win7 image on VMWare Player itself running on that MB. I seem to remember having to get VMWare to update for that when I set it up on my new Win10 system. |
Sorry, kayaker, I meant to comment on this.
That's an interesting question but first about another question regarding XHCI Handoff. I am looking at it now in BIOS (AMI Aptio [2018] Version 2.19.1269) and it is enable, along with legacy USB support. Also, CSM is enabled, which deals with legacy devices.
One thing concerning me is that BIOS also lists:
USB Controllers: 2 XHCI
USB Devices: 2 keyboards, 1 Mouse, 3 Hubs.
I have 2 x XHCI controllers, one for the peripheral card and one I loaded somehow through device installation. However, the only hub showing in Device Manager is for the peripheral USB 3 device.
I'll have to dig through the registry and sort this out before I go further. I may have a conflict. Also, I am not so sure that two USB hubs can exist together let alone three.
With regard to VMWare Player, it did not occur to me they may be using their own W7 USB3 drivers. I'll look into that, thanks.
Kayaker
February 17th, 2019, 23:49
Actually I was going to thank you Waxford. I had seen that article you listed, I think, but somehow missed the Nirsoft USBDeview app they recommended. Instead I was using Nirsoft USBLogView which wasn't as useful. I believe that USBDeview gave me the clue I needed. None of the other usb monitoring I tried with EventGhost or USBLogView picked up that intermittent disconnect, but I think USBDeview did. The usb port it pointed to that might be giving me the problem is a downstream usb connection on the back of my monitor that I've got a cheap 4-port usb hub attached to. With more testing I might be able to figure out if the monitor usb port is at fault or hopefully just the cheap 4-port usb hub attached to it.
Just for fun you could try USBDeview to see if it gives more information on your ports than Device Manager.
WaxfordSqueers
February 18th, 2019, 05:29
Quote:
| [Originally Posted by Kayaker;97584]Just for fun you could try USBDeview to see if it gives more information on your ports than Device Manager. |
I was past the Nirsoft site only a few days ago and d/l'd some very interesting stuff. Have not had the chance to look it over yet. Maybe the USB app is in what I d/l'd.
There is a half decent USB app in the Microsoft Debugging Tools for Windows directory. It's in the same directory as Windbg. I think it used to be part of the Sysinternals package. Here's a link to the app and the source code:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/usbview ("https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/usbview")
WaxfordSqueers
February 18th, 2019, 19:11
Quote:
| [Originally Posted by Kayaker;97584]The usb port it pointed to that might be giving me the problem is a downstream usb connection on the back of my monitor that I've got a cheap 4-port usb hub attached to. With more testing I might be able to figure out if the monitor usb port is at fault or hopefully just the cheap 4-port usb hub attached to it. |
Not quite following. Do you mean you are feeding a USB hub from your motherboard USB connector then feeding the monitor from the hub?
If so, it could be a power issue. The USB hubs on the mobo can typically supply 500 milliamps to peripheral devices. However, some peripheral hubs draw power from one USB port and distribute it to their outputs. If you have a low current devices like a mouse, or a unifying receiver attached they won't draw much current but something like a monitor might.
I have a USB hub but it has it's own power supply. It can deliver 500 ma from each of its ports. The other day, I had the power bar feeding the USB hub its power turned off and even the unifying receiver for the mouse was acting crazy. When I turned on the power bar, the device started working normally.
Speaking of that, I think I know where my 3rd hub is coming from as reported by my BIOS. It's the peripheral USB hub. I have the onboard peripheral hub, the external hub just mentioned, and the hub built into my mobo. However, my mobo hub shows no drivers in Device manager.
Looks like I am....like it or not....going to have to investigate USB down to the driver level. Working in the dark does not work well, as you know.
One problem is Intel. They have always supplied excellent technical manuals for their mobos and chipsets. I can't find anything on my current B360 Intel chipset.
Also, as you know, there have been excellent books put out on the Windows subsystem but I don't recall mention of USB drivers and how USB interacts with the mobo. I am sure it has parallels with the serial port.
There have been several recent protocols issued for USB recently. Prior to XHCI there was OHCI, UHCI, and EHCI. They are all backward compatible so a USB2 device, for example, can run of a USB 3 or 3.1 device.
The only real difference between 3.0 and 3.1 is the speed, where 3.1 has double the speed of 3.0. (5 Gbps compared to 10 Gbps). So, I don't see why W7 is not capable of running 3.0 or 3.1 provided it has the proper drivers.
My peripheral USB 3.0 card runs on W7 fine but they use a VIA VL 805 or VL 800 chip onboard to run the USB 3.0 from my mobos PCIe bus. On W10, all the mobo's native USB 3 ports work as well as the peripheral card's USB 3 ports.
In essence, this is the problem. What is the difference between the W7 OS and the W8 and 10 OS's? You have far more experience with drivers than me, what do you think? Could it be as simple as a driver or is there maybe something in modules like K32, Win32, NTOSKRNL, or maybe HAL that has changed?
Kayaker
February 18th, 2019, 21:38
My Dell monitor has an auxiliary usb port (4 of them actually) on the back. I simply have a non-powered Orico usb hub plugged into one of them to make it more convenient to plug in external hard drives, printers etc. It's the connection to the Orico that seems to drop occasionally. You're right, it's quite possible the fact that the hub is non-powered could be the issue.
I think you said that you tried an 8th gen usb3 driver for a C300 chipset, but that didn't work with your newer C360, is that right? Do you think that driver might be the one you would start reversing to try to modify to work with your system, seems like it might be the closest "fit" you have.
As for trying to glean more information on usb internals, I noticed that some usb drivers like USBHUB3.sys and USBXHCI.sys import WppRecorder.sys. I started looking into that and found out that you can capture usb debug traces. I'm still working on the procedure, but I was able to get a trace of sorts on usbhub3.sys. Not that the results make much sense to me, but the procedure seems to work for getting at least some internal information. There are some examples of TraceView output that might give you an indication of whether the info would be of any use to you.
https://channel9.msdn.com/Blogs/WinHEC/Video-Accessing-Driver-Logs-without-a-Debugger
https://blogs.msdn.microsoft.com/usbcoreblog/2014/09/02/capturing-usb-debug-traces/
https://techcommunity.microsoft.com/t5/Microsoft-USB-Blog/How-to-include-and-view-WPP-trace-messages-in-a-driver-8217-s/ba-p/270778
I started with the steps in the first link to get an .etl file for usbhub3 and viewed that with an old copy of TraceView. I need to get the new version from the WDK as some of the log output didn't seem to be fully interpreted. That procedure seemed to give more of a "static" WPP output. I think the other links are geared towards a live tracing which might be of more use.
WaxfordSqueers
February 19th, 2019, 00:03
Quote:
| [Originally Posted by Kayaker;97587]You're right, it's quite possible the fact that the hub is non-powered could be the issue. |
Personally, I would not try to run a hard drive through an unpowered USB hub. Could be your problem.
Quote:
| [Originally Posted by Kayaker;97587]I think you said that you tried an 8th gen usb3 driver for a C300 chipset, but that didn't work with your newer C360, is that right? Do you think that driver might be the one you would start reversing to try to modify to work with your system, seems like it might be the closest "fit" you have. |
As of yet, I am still confused about the meanings of the 8th generation labels I don't think my B360 chipset is listed as C2xx, it is a C3xx if anything.
However, here's a link to the Intel driver release for the C220/C610 series chipsets which Intel lists as 7th, 8th, and 9th generation. I plan to compare those drivers first in IDA with the W10 drivers for HUB and XHCI. I could send you a copy of my W10 drivers for comparison, if you're curious. Don't know if PM still works.
https://downloadcenter.intel.com/download/22824 ("https://downloadcenter.intel.com/download/22824")
Quote:
| [Originally Posted by Kayaker;97587]As for trying to glean more information on usb internals, I noticed that some usb drivers like USBHUB3.sys and USBXHCI.sys import WppRecorder.sys. |
Thanks for heads up. At this stage, my head is a bit scrambled as to which way to go. I've been having fun with my VM version of ice tracing through an installer setup file to see if it will dump some stock files. Obviously, I need to get Windbg going with a remote monitor on Win 10. Or maybe run it from W7 and observe W10.
At the moment, W7 is running USB 3 fine with the peripheral card. As you said, it's more fun peeking under the hood, spelunking as Matt Pietrek called it.
Kayaker
February 19th, 2019, 00:30
Just an update on using TraceView to log internal messages put out by usbhub3.sys when connecting a usb stick as an example.
Code:
HUBHTX_Get20PortChangeEvent: PORT_STATUS_ERROR / HubHwVerifierPortDeviceDisconnected event: PortConnectChange & CCS=0; portNum 1, prevPS 0x0101, curPS 0x0100, curPC 0x0001
HUBHTX_Get20PortChangeEvent: Called HubHwVerifierPortDeviceDisconnected
Device Context 0xFFFFD00E5F713110 - USB\VID_0951&PID_1646&REV_0100 - Port Path 1:4:1:0:0:0
DeviceHackFlags:0x8
Nothing earth shattering, but it does at least lead to a function in usbhub3.sys code in IDA when you also load the PDB from MS:
Code:
.text:00000001C0004218 HUBHTX_Get20PortChangeEvent proc near ; CODE XREF: HUBPSM20_EnablingInterruptsAndGettingPortEvent+14
.text:00000001C0004218 ; HUBPSM20_GettingPortChangeEventInSuspended+B
.text:00000001C0004218
....
.text:00000001C0004218 4C 8B DC mov r11, rsp
.text:00000001C000421B 49 89 5B 08 mov [r11+8], rbx
I'm using TraceView from an older WDK version but it seems to work OK. If you don't have it and don't want to install the full WDK, you can extract it from the iso (620MB) from here - GRMWDK_EN_7600_1\WDK\tracingtool_x64fre_cab001.cab
https://www.microsoft.com/en-ca/download/details.aspx?id=11800
...
I was going to ask you about the C220/C610 driver and wondered how it differed from the one you had. What defines "chipset support" when the general function of these drivers must be fairly similar?
WaxfordSqueers
February 19th, 2019, 00:40
Kayaker...there are times when I break on _baseprocessstart then take a couple of steps and I'm into the start of code for my app. Other times, I can't get there. I have to go through countless steps of code in the system and never seem to come out the other end.
Is that maybe because another proc is using _bpss? Have you found a way out of the code, maybe a BP further along the way, like GetProcessAddress or GetModuleHandle?
Or is it maybe the VM?
WaxfordSqueers
February 19th, 2019, 01:06
Quote:
| [Originally Posted by Kayaker;97589]I was going to ask you about the C220/C610 driver and wondered how it differed from the one you had. What defines "chipset support" when the general function of these drivers must be fairly similar? |
Thanks for info on tracer. I will check it out.
That's got me too, about the chipset's supported. I managed to download an Intel INF install for the B360 and it installed a lot of drivers for the chipset on W7. All but the USB drivers.
I just noticed a log file from an earlier attempt to load the USB 3 driver for which I supplied a link above. It claims there are sections in its own INF that are missing. And the Dev_numbers listed do not include my device, which is DEV_A36D. It lists up till DEV_A2AF.
Here's a typical error message from the install for Iusb3hub.inf:
"Section <PackageInfo> Key <Sequence> not found in INF.
It gives a ClassGUID, which is for the general class 'Universal Serial Bus Controller' then immediately below it tells you the Package.info.Name = iusb3hub, as in the title of the INF file. Then it gives PackageInfo.Sequence = 0. Then it says: "Error locating a device section, Skipping inf.
That's why my hub is not getting loaded.
Sorry to burden with all this, just thinking out loud.
Kayaker
February 19th, 2019, 13:59
Quote:
[Originally Posted by WaxfordSqueers;97590]Kayaker...there are times when I break on _baseprocessstart then take a couple of steps and I'm into the start of code for my app. Other times, I can't get there. I have to go through countless steps of code in the system and never seem to come out the other end.
Is that maybe because another proc is using _bpss? Have you found a way out of the code, maybe a BP further along the way, like GetProcessAddress or GetModuleHandle?
Or is it maybe the VM? |
I recall that sort of thing happening when tracing in VMWare, F8 through an API call and it may give control back to the VM thread dispatcher. 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.
WaxfordSqueers
February 19th, 2019, 18:38
Quote:
| [Originally Posted by Kayaker;97592]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
February 20th, 2019, 00:43
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
February 20th, 2019, 02:42
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
February 20th, 2019, 06:34
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 ("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
February 20th, 2019, 06:41
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
February 20th, 2019, 20:53
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 ("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
February 20th, 2019, 22:55
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
February 20th, 2019, 23:41
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
February 21st, 2019, 00:46
Quote:
| [Originally Posted by Kayaker;97600]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
February 21st, 2019, 04:23
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
February 23rd, 2019, 23:18
@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
February 24th, 2019, 20:36
@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 ("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
February 25th, 2019, 00:10
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
February 25th, 2019, 02:24
Quote:
| [Originally Posted by Kayaker;97605]I believe Alt-F2 closes the program |
I believe you're right, found out the hard way.
Quote:
| [Originally Posted by Kayaker;97605]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>.
Quote:
| [Originally Posted by Kayaker;97605]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.
Quote:
| [Originally Posted by Kayaker;97605]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
February 25th, 2019, 13:05
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)
3036
ollydbg has a watch window use ALT+V or view Watches add watches as needed
tile windows to keep watch window visible and trace
3037
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
Code:
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
Code:
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
Code:
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
Code:
ntdll!LdrpDoDebuggerBreak+0x2c:
774105a6 cc int 3
0:000>
WaxfordSqueers
February 28th, 2019, 05:13
Quote:
| [Originally Posted by blabberer;97607]1) ollydbg v2 does not have a command-line interface natively (third party plugins are available which provide the functionality) |
Hey blabbs, thanks for detailed explanation. Much appreciated. Need time to digest it all.
Maybe I am using the wrong term by referring to it as a command line. I saw a window in Olly that allowed the entry of expressions and even a simple one like BPX <address>.
Can an expression be used in Olly like BMSG <hwnd> <msg>
There are situations where I need to break on a mouse click so I can trace into an app that cannot be captured from start of code or winmain().
Kayaker
February 28th, 2019, 15:08
Oh yeah you're right, there was a cmdline.dll plugin that came with Olly 1 that can be used for setting breakpoints. Look at the help file for details on syntax. Also look at the help file in Olly 2 for setting bp's on WM_ messages using PeekMessageA and (esp+4) as an example. Not sure if there's a more direct way for global BMSG as in Sice.
3038
.
.
And I guess you could use this for Olly 2
Gigapede's Command Bar 3.20.110
https://tuts4you.com/download/3405/
WaxfordSqueers
March 1st, 2019, 01:07
Quote:
[Originally Posted by Kayaker;97609]And I guess you could use this for Olly 2
Gigapede's Command Bar 3.20.110 |
Already tried that but it froze Olly 2.1. I got an hour glass that wouldn't go away. Had to close Olly using task manager. Don't know enough yet about plug-ins to fix it, if it can be fixed.
I also d/l'd the Vic plugin 2.06 for Olly 2.xx. It loaded fine but I have not seen a command line as in those you suggested above. I thought there was one in there.
http://viclab.biz/ ("http://viclab.biz/")
Right now I have myself immersed in running a W7 install repair after uninstalling all updates back to SP1. I was going to unload SP1 but it won't let me.
There's a method to my madness. I want to eliminate any updates since SP1 and reload Win 7 with my install disk slip-streamed with SP1 and a few updates till about 2016. I want to see if W7 will load its native USB drivers on my new mobo. Also, I have injected Intel USB3 drivers as suggested by Intel for earlier generations. Hopefully it doesn't blow up my board.
Also, got my USB to serial adapter today so I can try it on Windbg with a remote monitor. This is more an educational thing. I'd like to try tracing the USB drivers right through the system from the mouse on W10 then compare the W10 driver to the W7 driver for earlier generations.
You asked me how I planned to investigate the w10 USB driver and I had to think about it a bit using Windbg or a debugger that will allow me to do that. I was hoping to get some advice from you and blabberer on that.
Don't know if you remember Silver's DX crackme. He setup a DX image of a spinning cube and if you managed to solve the crackme you'd get the spinning cube with a message.
I solved it by more of a brute force method. The Windows mouse cursor is not the same mouse cursor you see in a DX app, they use their own cursor. I reasoned the only way to get at the DX cursor, and code, was to put a BP on the Windows cursor and trace it through the system to the DX code.
Wasn't quite that easy, Silver threw in some anti-debugging checks like CRC and blowfish. The CRC was not straight CRC either, he used an encryption routine. I traced through the entire encryption routine to see how they worked.
I am thinking of using a similar approach for the USB mouse input. However, I don't know which driver is which for breakpoints. I'd like to BP on a mouse click as close to the USB port as possible then trace it through the driver to see what the driver does with it.
What about that USB app you linked to, or the one from Debugging Tools? It has to be connected to the USB ports and either would provide a means of trapping the mouse.
If there is a hardware difference between chipset generations, I am screwed. I am reasoning, however, that the same Intel drivers for both USB 3.0 and 3.1 were issued for early versions of generation 6, 7, 8, and 9. Since the difference between 3.0 and 3.1 seem to be only differences in speed, the hardware may be different to generate the higher speed. I don't know if that would entail a drastic difference in drivers, however.
When I did Silver's crackme, I also traced the code from OEP to see what was going on. I was trying to see how DX interfaced with the Windows system. It was quite interesting. I traced to Winmain() then watched the Windows windows being formed. In the middle of the Windows procedures, just before ShowWindow, Silver set one of his encryption routines.
Just after Show Window, the DX code began. The initial code is mainly about DX structures which are populated partly from the Windows formation structures, like 640 x 480. I was able to trace through it, having to stop and figure out the DX structures they use. That was an experience in itself. However, when I tried to change the data in a structure to put the DX screen into a window (hint from Silver), it blew up due to a later CRC check.
After fixing that, I ended up in the message loop and spent looking for access to the DX routines which actually create the DX windows and cursor. It was the time I spent near the message loop, gathering addresses and such that helped me immensely later while tracing the mouse through the mouse driver i8402prt.sys and into the system.
When you reach the DX code, however, you are still not seeing the DX mouse cursor or the DX images on the screen. That came later and I found the code by following the mouse trail, so to speak through the Windows mouse driver.
After tracing through the mouse driver code, I came to a dead-end in a waitforsingleobject loop and it occurred to me to change the context in ice to the code around the message loop. Then I set a a BP on one of those address and bingo, I was in the DX code straight from the windows mouse.
I'd like to do something like that so I could trap the USB mouse in the code for LButtonDown. However, for some reason, W7 is not even loading it's legacy drivers on my new board and I am reasoning that with a repair-install, the installation software of 2016 should not know about newer generation mobo chipsets and what to do with them.
We'll see. First I have to replace a wonky CD/DVD drive.
WaxfordSqueers
March 1st, 2019, 04:47
Kayaker....while waiting for my repair install to finish...or not....I got into some Powershell stuff involving the wmic command. For example in a Powershell window, entering the string of commands:
wmic qfe list
will generate a list of all updates on your machine. You can modify it to get more information such as the date each one was installed.
That got me interested in WMI itself which I have largely ignored. Seems to be a data base of all devices, and more, on the system. That lead to this page about USB devices:
https://devblogs.microsoft.com/powershell/displaying-usb-devices-using-wmi/
The guy offers a simple script that lists USB devices:
ps> gwmi Win32_USBControllerDevice |fl Antecedent,Dependent
Don't know if that's an f1 or fl...I did a copy/paste.
Further down the page is a script which can be entered into a text editor and saved as
'usbscript.vbs. In order to run it you have to give Powershell permission by using the instructions:
Set-ExecutionPolicy RemoteSigned
Then enter .\USBScript.vbs
The .\ is required before the script name.
I don't know why the author displayed each USB entry with a separate window but I'm sure it can be made into a list instead.
The script formatting is getting lost. I'll try to attach script as file, change txt to vbs.
WaxfordSqueers
March 1st, 2019, 06:02
Just found out that .\ in ps before a vbs file or a script with a .ps1 extension means the script is in the current directory.
You likely know all this stuff. I found out the hard way that if you just enter script.vbs at the ps prompt it claims it is an unknown cmdlet. Duh!!!! It's like being at the C:\DOS prompt and trying to enter a command for a file in another directory. Been there, done that.
Ergo, as in DOS, if you want to execute a ps script you have to specify it's directory, or use .\ before the script if it's in the current directory.
Don't know what this has to do with the thread other than me ruminating about ways to use Powershell to check out my USB drivers.
ps. enter Get-Alias at the ps> prompt to get a list of aliases for commands, some of which translate to DOS and Unix.
blabberer
March 2nd, 2019, 01:22
powershell is highly discoverable all you need in most cases is the tab key and you can tab tab tab through the whole $51T10@d
gwmi is iirc deprecated
use get-cimclass and friends which supersedes gwmi
Code:
PS C:\> Get-Command *cim*
CommandType Name ModuleName
----------- ---- ----------
Alias gcim -> Get-CimInstance
Alias icim -> Invoke-CimMethod
Alias ncim -> New-CimInstance
Alias rcim -> Remove-CimInstance
Alias scim -> Set-CimInstance
Cmdlet Get-CimAssociatedInstance CimCmdlets
Cmdlet Get-CimClass CimCmdlets
Cmdlet Get-CimInstance CimCmdlets
Cmdlet Get-CimSession CimCmdlets
Cmdlet Invoke-CimMethod CimCmdlets
Cmdlet New-CimInstance CimCmdlets
Cmdlet New-CimSession CimCmdlets
Cmdlet New-CimSessionOption CimCmdlets
Cmdlet Register-CimIndicationEvent CimCmdlets
Cmdlet Remove-CimInstance CimCmdlets
Cmdlet Remove-CimSession CimCmdlets
Cmdlet Set-CimInstance CimCmdlets
Application Register-CimProvider.exe
PS C:\>
the fl is short form for format-list command and the asterisk is wildcard to indicate format every thing
the default output is single line cut short by ... (ellipsis to indicate more data is available)
in a win7 32 bit vm i can count 1053 classes that are query-able
and around 8 usb relative classes that you can check
Code:
C:\>powershell -c "get-cimclass" | wc -l
1051
C:\>powershell -c "get-cimclass" | grep -i "usb"
CIM_USBDevice {SetPowerState, R... {Caption, Description, InstallDate, Name...}
CIM_USBHub {SetPowerState, R... {Caption, Description, InstallDate, Name...}
Win32_USBHub {SetPowerState, R... {Caption, Description, InstallDate, Name...}
CIM_USBController {SetPowerState, R... {Caption, Description, InstallDate, Name...}
Win32_USBController {SetPowerState, R... {Caption, Description, InstallDate, Name...}
Win32_USBControllerDevice {} {Antecedent, Dependent, NegotiatedDataWidth, NegotiatedSpeed...}
CIM_USBControllerHasHub {} {Antecedent, Dependent, NegotiatedDataWidth, NegotiatedSpeed...}
Win32_PerfFormattedData_usbhub_USB {} {Caption, Description, Name, Frequency_Object...}
Win32_PerfRawData_usbhub_USB {} {Caption, Description, Name, Frequency_Object...}
C:\>
btw use the dedicated powershell_ise.exe executable
it gives you the help for each class instances and how to use it and
comes with an inbuilt terminal , script editor and an inbuilt debugger
shakingsphere i think said better thee screenshots than thou wisecracks
so here it is
3040
Kayaker
March 2nd, 2019, 05:54
I've never used PowerShell-ISE other than to give it a brief look. Worth exploring, there must be some practical uses for it. I've really only used PS to uninstall the Win10 bloatware.
Waxford, here's a crazy idea which might not be of any use, but you never know. I'm not exactly sure what your situation is. OK, it seems you don't have USB 3 drivers for Win7 that support your Gen 8 CPU, but I'm not sure if that means your usb3 ports are functionally dead because there are no drivers installed, or if they are still recognized but will only function at usb2 speeds, or something else. No matter.
I was using Wireshark, or more specifically USBPcap that now comes installed with it, to see if I could capture keyboard and mouse activity. I found a couple of RE-ish articles which described exactly that. I was able to duplicate the results and capture (and interpret) keystrokes as well as mouse up/down clicks and x/y position.
The point is that USBPcap is a filter driver that installs itself as an additional driver for each of the USB controllers on your system (Root Hub, eXtensible Host Controller, Generic USB Hub, etc.) If you look at Driver Details for the USB Controllers in Device Manager you'll see it installed under each of them.
My thought here is that if one of your controllers is completely "missing" a driver of any sort, USBPcap might install itself as a proxy of sorts that might provide some communication. Being a filter driver, it will pass the IRP (in this case with a IOCTL_INTERNAL_USB_SUBMIT_URB request containing a USB request block (URB)) down to the next lower level driver when done with it. If there is ultimately a bus driver supporting your usb controller (even without a higher level device driver), it should get the I/O request. Whether it would handle it properly I don't know, but that's another matter.
Here is some relevant source code and info on USBPcap:
https://github.com/desowin/usbpcap/blob/master/USBPcapDriver/USBPcapDeviceControl.c
https://desowin.org/usbpcap/
And if interested in using Wireshark as a key/mouse logger:
https://medium.com/@ali.bawazeeer/kaizen-ctf-2018-reverse-engineer-usb-keystrok-from-pcap-file-2412351679f4
https://medium.com/@forwardsecrecy/hackmethod-july-2017-challenges-write-up-1303f414c8d6
WaxfordSqueers
March 4th, 2019, 06:44
Quote:
| [Originally Posted by Kayaker;97614] I'm not exactly sure what your situation is. OK, it seems you don't have USB 3 drivers for Win7 that support your Gen 8 CPU, but I'm not sure if that means your usb3 ports are functionally dead because there are no drivers installed, or if they are still recognized but will only function at usb2 speeds, or something else. No matter. |
Kayaker...thanks for the research.
My problem is that the 22 USB ports I have available on the 8th gen mobo (12 physical) don't even show in the USB tool. I d/l'd this 'adaptation' of the Debugging Toolkit USBview and it shows a fantastic amount of detail for each mobo USB port in Windows 10. In Windows 7, it shows my VIA USB 3 peripheral card ports in detail but only a basic header for my USB XHCI controller and USB 3 HUB.
It shows no ports whatsoever for the mobo USB ports.
https://www.uwe-sieber.de/usbtreeview_e.html
I suspect that msoft has somehow disabled W7 but I don't want to succumb to paranoia. There may be a perfectly good explanation but why is msoft not supplying USB drivers for W7 when Intel was supplying them right up to generation 9 in an earlier revision?
That's right, they had drivers for W7 that would run 300 series chipsets and according to the Intel hardware data manual, the B360 is as much a 300-series chipset as the rest. Intel has suddenly stopped producing drivers as well, explaining that of October 2018, they will leave the supply of drivers to msoft.
Something smells fishy.
Using USBTreeview and investigating by hand by checking the properties of USB devices in Device Manager for both W7 and W10, I have discovered a few interesting facts.
1)Intel has issued a very detailed hardware layout for recent chipsets in which my chipset, the B360 is listed. All the device driver codes match up with the device description in Device Manager and the XHCI USB controller driver is listed as A36D as a common device in several related chipsets.
Other Intel chipsets in the same class are: H370, H310, Q370 and Z390. Those chipsets and the B360 all use a minor bus on the PCI main bus to run USB3 and they need a specific USB driver. However, companies like VIA can use the same PCI bus with their own driver to drive their own USB 3 chips. It seems Asus is doing the same with some of their Intel boards, using an Asmedia USB controller.
2)Win 10 has drivers that run the B360 chipset fine. It appears that Intel and M$oft may be in cahoots. With your knowledge of drivers, do you think it's likely that W7 cannot run USB 3 off a driver? There can't be that much difference in the two OSes if every other part of W7 is running fine on my 300 series board.
I mean, if you wanted to cripple W7 for newer mobos, what would be the best way to do it? Cripple the USB mouse and keyboard input, right? Along with the other USB devices used for backups, etc.
But wait!! My B360 has PS/2 hardware inputs for a mouse and keyboard that will allow W7 to run without USB. What's the point?
It's a little too crazy not to be done by design.
WaxfordSqueers
March 4th, 2019, 07:25
BTW...I knew W7 had a feature for XP mode but had not looked at it till now. I have downloaded the XP mode app from Microsoft and apparently it allows XP to run like a VM in W7 or in VM Player. I already have it running in a VM with our favourite tool but I am curious as to whether the XP Mode app would allow the tool to run in XP mode and debug apps in W7.
Just a thought, maybe I'm hallucinating after all the time I have spent with this USB stuff.
I have no idea to what extent msoft built in abilities to XP Mode to communicate with W7 that are not available in a VM.
WaxfordSqueers
March 7th, 2019, 22:59
@blabberer @kayaker
A bit premature but it's something I have been thinking about re windbg. I have never really grasped its capabilities and I know I need to use it to find that out. I have the impression that it's not possible to step through code visually with windbg, or it's two debugging counterparts in Debugging Tools, the way I could step through code visually using Ollydbg.
When I have used windbg, unless I set a BP, I was presented with one line of code at a time with a whole lot of information per line. Maybe I need to get used to that. I guess there is no way to set it up like Ollydbg so I can see everything at a glance, is there?
Naw....Microsoft would never do anything that simple, or convenient. They have not evolved File Explorer to a point where you can have dual panes to see both directories between which you are transferring files. They have not even evolved it to the point where it stops jumping around every time you open a directory.
The hold up right now is setting up windbg on two computers. I had not realized USB is now a possibility for a connection between machines so I bought a serial to USB converter.
While this thought rings through my mind, I was using a free app called Putty to test my serial connection. It advises setting the transfer mode to RTS/CTS, also known as hardware control. I don't know if windbg has the means of entering that or if it presumes it.
I forgot that RS-232 required a null modem cable between machines. I should have known better since hardware is my specialty. I am currently in the process of converting a pin to pin cable on a 9-pin DB connector to a null modem cable.
For anyone reading this and mystified about the difference, here's some down and dirty theory. This explanation is very simplistic because RS-232 is an old standard which references hardware that is not in use any more. Besides, I have just plain forgotten....it's the rust, I tell you!!!
The central device in an RS-232 connection is called the DTE (Data Terminal Equipment). Terminal in this case would be a computer serial port or a controller serial port. The equipment on the other end, maybe a modem, is a DCE (Data Communication Equipment).
If you want to connect a DTE to a DCE, a serial cable with pin to pin connections is adequate. However, if you want to connect a DTE to a DTE, like two computers to each other, you need a null modem cable in which certain pairs are crossed over between devices.
There are three basic modes in which serial cables can operate in the RS-232 serial communication standard: simplex, half-duplex and full duplex. If you have a sensor, say a water level detector, sending data to a central computer, with a simple detector, which may only indicate an on/off condition. there is no reason to send data to the sensor. Therefore a 'simplex' connection is adequate wherein data flow is only in one direction, from sensor to computer.
The next step up is half-duplex, a data transfer arrangement in which data can only be sent in one direction at a time. An example, is a communication device like a walkie-talkie where a button has to be depressed in order to talk. While it is pressed, incoming signals are cut off.
The next step up is full duplex, where the button is replaced by control circuitry which can adjust the channels each way to allow two-way data transfer, not bidirectional in real time, but one direction each way. That requires multiple conductors. Two of them are the standard transmit/receive pair which are always pins 2 and 3 on a standard DB-9 serial connector. The D refers to a D-shell, a reference to the shape of the connector pin-wise where the pins are surrounded by a D-shaped shell.
There are 5 pins on the larger side of the shell and 4 pins on the other. With the D facing you, wide side to the right, the pins are number 1 to 5 from top to bottom. On the narrow side of the D they are number 6 to 9 from top to bottom. Therefore 6 is across from 1 and 2 and in-between.
The other conductors in the 9-pin arrangement are control signals which tell the equipment on either end how to send/receive data on the transmit/receive pair. It's called a handshake arrangement because either end advises the other end as to it's condition and whether it's OK to send data.
With a straight-through pin-to-pin cable, it's plain to see the transmit conductor would be connected to the transmit conductor on the other end. Good if you have a DCE on the other end, like a modem. not good if there is a DTE on the other end like a computer.
The null modem cable crosses the data pairs over between DTE's so the transmit on one end connects to the receive on the other end, and vice-versa. So pin 2 (Rx) on one machine is wired to pin 3 (Tx) on the other end and pin 2 (Rx) on the other end is connected to pin 3 (Tx) on the near end.
There are two basic pairs of control signals: one pair (DTR/DSR) controls the readiness of each machine to receive or transmit data and the other pair (RTS/CTS) control the actual data flow.
There are two applications, maybe more, here as well. One for a DTE - DCE and another for a DTE - DTE.
For example, DTR, 'data terminal ready' and the other DSR 'data set ready' cannot be connected DSR-DSR and CTS-CTS beyween DTE's. The 'terminal' refers to the computer end (DTE) and the 'set' refers to the remote device (DCE). Each one is transmitting it's readiness to receive and transmit data.
Think of the DTE's as intelligent devices that can receive and transmit control data and the DCE as a 'dumb' terminal that can only receive control signals and react to them. With intelligent devices, they can become confused (ha, ha) via one to one cabling if they receive too much conflicting control info. So, they talk to each other directly, whereas a dumb terminal lacks that capability.
Another pair is RTS (ready to send) and the other is CTS (clear to send). If the computer needs to send data, it changes the status on its RTS line alerting the remote device on it's CTS line. When the remote device receives this alert it assesses it's condition and changes the status on its DSR line that it's ready. Not too sure how that works between DTE's but I have provided a good link below which addresses that.
In a null modem cable, pin 4 (DTR) on the terminal end is connected to Pin 6 (DSR) on the set end, and vice-versa from Pin 6 on the set end to Pin 4 on the terminal end.
Pins 7 and 8 on the cables must be crossed over for RTS/CTS as well . ie. Pin 7 computer end to pin 8 remote end and vice versa.
Pin 5 is ground and it can connect to pin 5 directly on the remote machine. A common ground is very important with RS-232 devices and if you ever have trouble with them, a good starting point is to ensure a good ground between devices
There may also be a shield ground, which is a bare copper wire in contact with a foil shield around the conductors to suppress EMI interference and transmission. The shield conductors are connected together, but not to the pin 5 ground connector..
Pin 9 is not used and Pin 1 is the carrier-detect (CD) line which finds an application with modems that send a carrier signal. I don't know if it's required between computers but I am wiring it to Pin 6 on both ends based on a diagram from Microsoft in which they show such a connection for their serial ports.
This site has a lot of good info on RS-232:
https://www.lammertbies.nl/comm/info/RS-232_null_modem.html
Here's microsoft on serial debugging, with a null model cable (crossover cable) layout:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-null-modem-cable-connection
blabberer
March 8th, 2019, 02:32
I am Not Sure if You Have to Run Through So many Hoops
if your target is windows 10 you can simply use net debugging
no one recommends usb debugging in real world it is regarded as finnicky
at the best obviously no words can describe the frustration when it is worst
and if you are not hitting the raw iron using a virtual machine is the best option
it is simply 2 3 clicks to set it up
create a vm with your favourite os version
create a pipe in the vm \\.\pipe\dbgpipe
set /debug on settings using bcdedit in the target under vm (either for the {current} boot or for a copied {current} so that you have two boot options)
open a windbg instance in physical machine which is running the vm
file -> kernel debug -> com -> check pipe , check reconnect , leaves resets at 0 , leave baudrate at 115200
provide the pipe that you set up \\.\pipe\dbgpipe
hit ctrl+break or alt+delete a few times and you should be ready to go
as to seeing everything like ollydbg
yes you can see everything
you need to set up a workspace
open a blank windbg instance
hit alt+7 to open a blank disasssmbly window
hit alt+6 to open a blank call stack window and dock the window where you want it
do the same for registers and memory dump and command pane
you should have 5 windows docked
now save the workspace file->save->workspaces and close the windbg
next time onwards windbg will open as you saved it
WaxfordSqueers
March 8th, 2019, 20:53
Quote:
[Originally Posted by blabberer;97618]I am Not Sure if You Have to Run Through So many Hoops
|
Thanks for review of debugging via VM. I have done it in the past and even got a connection between host and guest. I am not averse to it and will use it again. One of my VMs is setup for it but it's an XP VM.
I plan to use this for W7 as well, primarily to follow the driver loading process to see if I can spot where the problem lies. With the USB controller, iusbxhci.sys, I actually saw it loaded in memory the other day but when I checked last night it was not there. I was using a driver viewer from Nirsoft. It appeared to be loaded in a 64K section only and I don't know what that means wrt to drivers.
Just to be clear, I just mentioned USB as an aside. I am setting up serial port communication, not USB, although I may check that out to see how far TCP has advanced with W10. I realize how finicky it can be, I recall the early pre-Net days with BBS's, x-modem, z-modem, and the blazing 9600 baud rate [/sarc off]. Prior to that there was the 300 baud rate days, then 1200. When the baud rate increased to 28K then 56K the transfer rate for files shot right up.
I don't regard this as any less finicky than setting up a home network. It drives me batty at times setting up IP addresses, DNS servers, etc., only to have windoze flag the connection as bad. Or tell you the host and remote are using the same IP address. Then, when you resort to their troubleshooting dummy (aka Wizard) it checks the situation and comes back telling you it could not find anything wrong.
Although I have not done much in the way of serial, I've had to set up serial printers in the field and I am schooled in the hardware end of serial. I understand the RS-232 protocol at the hardware level with pins 2 & 3 being indelibly inscribed in my brain as receive/transmit. I am actually finding this project to be interesting. Who knows, I may finally learn how to use Telnet properly.
The advantage I see with serial is that you can theoretically sit at one machine and observe the results in real time on the other machine. With the VM, if anything happens with the app you are debugging, you'd have to switch from guest to host to see any results. Furthermore, Msoft describes the process in detail, right down to the pinouts for the null modem cable. Of course, they also describe debugging via TCP as well.
With softice, if something of import occurred on the debuggee, ice would disappear behind the debugee screen. You could see a message box open, for example, or an input window for text. Then you'd F4 back into ice, or have a BP set to capture input to a text box. With the right BP, you could enter text and have it break upon 'OK' on the text box.
Maybe I'm all wet and talking through my hat with regard to a serial setup with windbg.
WaxfordSqueers
March 8th, 2019, 21:33
Quote:
[Originally Posted by blabberer;97618]as to seeing everything like ollydbg
yes you can see everything
you need to set up a workspace |
Thanks for that blabbs. Good to know.
blabberer
March 9th, 2019, 09:22
1) windows 10 as target supports net debugging properly not xp or 7
2) host can be windows 7 that is windbg can run in a machine that runs win 7
so if you have a physical machine that runs windows 7
and if your physical machine is of recent make (intel vtx , long mode , blah blah that is required to create a win-x vm)
then you can create a winx vm
enable net debugging copy the hash that is created after enabling net debugging to host and connect windbg using that hash
if your host is windows 10 pro using hypervisor is more even better
as to your query of seeing everything windbg already have provided you some themes
try double clicking this first before going the hard way i described earlier
%windbg_installation_folder%\Arch\Themes\*theme*.wew
3041
WaxfordSqueers
March 9th, 2019, 22:48
Quote:
[Originally Posted by blabberer;97621]1) windows 10 as target supports net debugging properly not xp or 7
2) host can be windows 7 that is windbg can run in a machine that runs win 7
so if you have a physical machine that runs windows 7
and if your physical machine is of recent make (intel vtx , long mode , blah blah that is required to create a win-x vm) |
I am looking forward to getting into this so thanks for the info. It's interesting to see all the windows setup in Windbg so thanks again for that insight.
My mobo has vtx and hypervisor but I have an issue with the latter. While trying to set up my serial port I selected COM1 initially. I got an error somewhere that hypervisor is using COM 1. Is that possible, or did I read it wrong?
I have changed to COM2 but I don't know if my mobo serial ports are hardwired to 1 and 3 and 2 and 4. I am getting no serial connection right now. It's a hassle getting at the serial ports on the mobo to change the connector. With Windbg setup on either computer, each one indicates a connection to COM2 but both freeze, allowing no input, while displaying something like 'waiting to reconnect'.
I will be using W10 for part of my investigation so there's no problem setting it up as host. I want to see how W10 handles the USBXHCI controller and hub drivers in W10 then compare that to W7 to see why the drivers won't start.
I have already looked at the drivers in IDA 7 but plan to set IDA up on each of my computers and compare the W10 driver to the W7 drivers supplied by Intel.
Meantime, I am furiously reading on the USB architecture and how it communicates with the system.
blabberer
March 10th, 2019, 05:35
Quote:
With Windbg setup on either computer, each one indicates a connection to COM2 but both freeze, allowing no input, while displaying something like 'waiting to reconnect'. |
what do you mean by this ?
you do not think that windbg on host will be talking to windbg in guest(target) ? do you ??
it is one way traffic the guest talks to the windbg running in host about all the events that happen in the guest(target) machine
the windbg in host listens and breaks when appropriate for the human on the host to interpret and handle the event
stop take a breath throw away all the wires and create a vm first get your first break take few baby steps in and out of the code
force forget sice it is and old extinct dinosaur get your feet wet first no point talking 10 things and not doing even one
WaxfordSqueers
March 10th, 2019, 10:07
Quote:
[Originally Posted by blabberer;97623]what do you mean by this ?
you do not think that windbg on host will be talking to windbg in guest(target) ? do you ?? |
I have read and researched till I am blue in the face and there are no answers as to why both the host and the guest just sit there displaying the message 'waiting to restart'. While those messages are there no entry is possible on either window.
Quote:
[Originally Posted by blabberer;97623]stop take a breath throw away all the wires and create a vm first get your first break take few baby steps in and out of the code
force forget sice it is and old extinct dinosaur get your feet wet first no point talking 10 things and not doing even one |
I was hoping to learn by applying Windbg to a real-time project. I have one and I am currently trying to set it up to run on a serial connection. With a VM, I can't very well debug a driver in Windows while it is running on a VM. In fact, that why I want to run a remote session using a serial connection, so I can watch a driver being installed and started. I want to see why it's not starting.
To accomplish that, I need to understand the basics of USB drivers and the USB driver stack, hence the 10 different things at once. I am gaining ground. My initial concern was that W7 had something lacking that could not be overcome. Remember, my problem is getting USB running with W7 on a newer generation motherboard. No one has done it yet with the B360 Intel chipset as far as I know.
Thus far, I have learned that the Windows kernel communicates with USB devices through various levels of drivers. The hub driver is connected right to the hardware and detects it when it is inserted. It queries the device for it's Vendor ID and Hardware ID, in conjunction with the USB Host Controller Driver that sits right above it on the USB stack, then advises the kernel of the new device.
The kernel then instructs the hub to power the device and send it the device info so the kernel can enumerate it via the controller and the hub. I am getting no power to the mobo USB ports under W7 so the hub is not being turned on. In fact, it's currently not loaded. I have seen the USB Host Controller loaded but not turned on. That suggests to me the driver above it is not communicating with the Host Controller or the drivers have code that is not synchronized because calls to certain drivers are reaching the wrong code.
There is a system level driver sitting between the kernel and the USB host controller that may be the problem. I can't get W7 to load any of its USB drivers, even for USB 2 devices.
With the new USB3 controllers, USB 2 and 3 run in parallel but why are all the USB 2 drivers not showing up in Device Manager? They are loaded but not showing up. USBD.SYS is loaded and it's a system level driver that interfaces the kernel to the other USB drivers.
Do you think I can examine all that using a VM? I am not being facetious, I am asking a straight question.
Windows 10 runs USB 3 on my mobo's chipset no problem and Intel released driver in 2018 that allowed W7 to run USB 3. My chipset is a 300-series and the release allowed an earlier revision of my 300-series chipset to run. That suggests to me that it's not W7 causing the problem.
Of course, I read a lot of negative comment about why someone would want to run W7 when it's over 10 years old. One good reason...Windows 10. It's an over-bloated spying device that is so laden down with garbage that it's a surprise it even runs. Have you opened task manager and taken a look at the bloatware processes running? It's astounding.
Last time I tried tracing at the kernel level, I kept running into VM code. Also, after spending hours trying to learn the basic Windbg functions, I got nowhere fast. I learned softice by applying it to actual problems, finding ways to deal with peculiarities in softice. One of the hardest parts was actually setting it up to run properly, as I am currently doing with Windbg.
I realize softice is now severely limited but it's no dinosaur. It's still a very powerful debugger for 32 bit apps if they can be run in an XP environment. I used it very recently and very successfully in a VM. I would like to see it ported to a win7 environment with 64-bit capabilities but I realize that's highly unlikely, so I am making an attempt to move on.
WaxfordSqueers
March 10th, 2019, 10:10
ps...blabberer, what does Kdsrv do?
blabberer
March 10th, 2019, 13:11
Quote:
| I can't very well debug a driver in Windows while it is running on a VM |
i do not understand the reservation here can you explain why you cannot ??
here is a sample session breaking on usbuhci.sys loading and stepping right through DriverEntry
i broke on usbuhci.sys using sxe ld:usuhci.sys
this breaks when the system maps the driver
once broken here you can set a bp on this driver's DriverEntry() function and continue
i have broken here because of sxe ld:usbuhci.sys
Code:
kd> .lastevent
Last event: Load module usbuhci.sys at 887d0000
debugger time: Sun Mar 10 23:12:36.333 2019
stack trace when broken
Code:
kd> kb
# ChildEBP RetAddr Args to Child
00 8bb476fc 818a4308 8bb47714 8bb476ec ffffffff nt!DbgLoadImageSymbols+0x41
01 8bb4771c 81ad0815 0000004a 8d4c11a8 00000000 nt!DbgLoadImageSymbolsUnicode+0x24
02 8bb47758 81acc296 8bb478f8 8bb477c8 8bb477ac nt!MiDriverLoadSucceeded+0x13b
03 8bb47840 81a60809 00000000 00000000 8bb478e4 nt!MmLoadSystemImageEx+0x39c
04 8bb47858 81a63744 8bb478f8 00000000 00000000 nt!MmLoadSystemImage+0x25
05 8bb47958 81b34a32 00000000 8bb47988 00000005 nt!IopLoadDriver+0x1f6
06 8bb4799c 81a6785b 00000003 00000000 00000002 nt!PipCallDriverAddDeviceQueryRoutine+0x16c
07 8bb479c8 81a68739 00000005 8c1e1f08 800000ac nt!PnpCallDriverQueryServiceHelper+0x6f
08 8bb47ab0 81a67d0c 00000000 8d4aa378 8d4aa378 nt!PipCallDriverAddDevice+0x293
09 8bb47c9c 81b7c522 8bb47cc0 00000000 00000000 nt!PipProcessDevNodeTree+0x13c
0a 8bb47cc8 818da9b7 81a06320 8c1b1040 818da6ce nt!PiProcessStartSystemDevices+0x44
0b 8bb47d28 8187b1bc 00000000 00000000 8c1b1040 nt!PnpDeviceActionWorker+0x2e9
0c 8bb47d78 818a8516 81a2f1e0 c46e4180 00000000 nt!ExpWorkerThread+0xc0
0d 8bb47db0 81923ad5 8187b0fc 81a2f1e0 00000000 nt!PspSystemThreadStartup+0x4a
0e 8bb47dbc 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x15
the driver that is being loaded
Code:
kd> ds /c 100 8bb47714
8d4ca680 "\Windows\System32\drivers\usbuhci.sys"
setting an breakpoint on DriverEntry and Continuing
Code:
kd> bp usbuhci!DriverEntry
kd> g
our breakpoint got hit
Code:
Breakpoint 0 hit
usbuhci!DriverEntry:
887d1000 8bff mov edi,edi
stack trace on this breakpoint
Code:
kd> kb
# ChildEBP RetAddr Args to Child
00 8bb47860 887d8015 8bb47958 81a639a3 8d4d1510 usbuhci!DriverEntry
01 8bb47868 81a639a3 8d4d1510 8d4d5000 8bb47a3c usbuhci!GsDriverEntry+0x15
02 8bb47958 81b34a32 00000000 8bb47988 00000005 nt!IopLoadDriver+0x455
03 8bb4799c 81a6785b 00000003 00000000 00000002 nt!PipCallDriverAddDeviceQueryRoutine+0x16c
04 8bb479c8 81a68739 00000005 8c1e1f08 800000ac nt!PnpCallDriverQueryServiceHelper+0x6f
05 8bb47ab0 81a67d0c 00000000 8d4aa378 8d4aa378 nt!PipCallDriverAddDevice+0x293
06 8bb47c9c 81b7c522 8bb47cc0 00000000 00000000 nt!PipProcessDevNodeTree+0x13c
07 8bb47cc8 818da9b7 81a06320 8c1b1040 818da6ce nt!PiProcessStartSystemDevices+0x44
08 8bb47d28 8187b1bc 00000000 00000000 8c1b1040 nt!PnpDeviceActionWorker+0x2e9
09 8bb47d78 818a8516 81a2f1e0 c46e4180 00000000 nt!ExpWorkerThread+0xc0
0a 8bb47db0 81923ad5 8187b0fc 81a2f1e0 00000000 nt!PspSystemThreadStartup+0x4a
0b 8bb47dbc 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x15
the disassembly of DriverEntry For usbuhci.sys
target is (win 10 15063 x86 32 bit vm running in some old 32 bit (now discontinued vmware player )
host is running 32 bit win 7 x86 15 year old celeron processor
Code:
kd> uf .
usbuhci!DriverEntry:
887d1000 8bff mov edi,edi
887d1002 55 push ebp
887d1003 8bec mov ebp,esp
887d1005 81ec18010000 sub esp,118h
887d100b a100707d88 mov eax,dword ptr [usbuhci!__security_cookie (887d7000)]
887d1010 33c5 xor eax,ebp
887d1012 8945fc mov dword ptr [ebp-4],eax
887d1015 56 push esi
887d1016 57 push edi
887d1017 8d85e8feffff lea eax,[ebp-118h]
887d101d c785e8feffff14010000 mov dword ptr [ebp-118h],114h
887d1027 50 push eax
887d1028 8bf2 mov esi,edx
887d102a 8bf9 mov edi,ecx
887d102c ff15c4607d88 call dword ptr [usbuhci!_imp__RtlGetVersion (887d60c4)]
887d1032 83255c717d8800 and dword ptr [usbuhci!RegistrationPacket+0x13c (887d715c)],0
887d1039 56 push esi
887d103a 6820707d88 push offset usbuhci!RegistrationPacket (887d7020)
887d103f 68f4010000 push 1F4h
887d1044 c70530707d8898010000 mov dword ptr [usbuhci!RegistrationPacket+0x10 (887d7030)],198h
887d104e c70534707d8898000000 mov dword ptr [usbuhci!RegistrationPacket+0x14 (887d7034)],98h
887d1058 c70538707d8824000000 mov dword ptr [usbuhci!RegistrationPacket+0x18 (887d7038)],24h
887d1062 c70544707d88c0220000 mov dword ptr [usbuhci!RegistrationPacket+0x24 (887d7044)],22C0h
887d106c c70544727d8816187d88 mov dword ptr [usbuhci!RegistrationPacket+0x224 (887d7244)],offset usbuhci!UhciPreStartController (887d1816)
887d1076 c70558707d881e187d88 mov dword ptr [usbuhci!RegistrationPacket+0x38 (887d7058)],offset usbuhci!UhciStartController (887d181e)
887d1080 c7055c707d88f4167d88 mov dword ptr [usbuhci!RegistrationPacket+0x3c (887d705c)],offset usbuhci!UhciStopController (887d16f4)
887d108a c70594707d88285a7d88 mov dword ptr [usbuhci!RegistrationPacket+0x74 (887d7094)],offset usbuhci!UhciEnableInterrupts (887d5a28)
887d1094 c70598707d886e597d88 mov dword ptr [usbuhci!RegistrationPacket+0x78 (887d7098)],offset usbuhci!UhciDisableInterrupts (887d596e)
887d109e c70568707d88a4567d88 mov dword ptr [usbuhci!RegistrationPacket+0x48 (887d7068)],offset usbuhci!UhciInterruptService (887d56a4)
887d10a8 c7056c707d8868597d88 mov dword ptr [usbuhci!RegistrationPacket+0x4c (887d706c)],offset usbuhci!UhciInterruptDpc (887d5968)
887d10b2 c70560707d88222a7d88 mov dword ptr [usbuhci!RegistrationPacket+0x40 (887d7060)],offset usbuhci!UhciSuspendController (887d2a22)
887d10bc c70564707d88a02b7d88 mov dword ptr [usbuhci!RegistrationPacket+0x44 (887d7064)],offset usbuhci!UhciResumeController (887d2ba0)
887d10c6 c705f0707d88aa5a7d88 mov dword ptr [usbuhci!RegistrationPacket+0xd0 (887d70f0)],offset usbuhci!UhciRHDisableIrq (887d5aaa)
887d10d0 c705f4707d88aa5a7d88 mov dword ptr [usbuhci!RegistrationPacket+0xd4 (887d70f4)],offset usbuhci!UhciRHDisableIrq (887d5aaa)
887d10da c705b0707d88a82e7d88 mov dword ptr [usbuhci!RegistrationPacket+0x90 (887d70b0)],offset usbuhci!UhciRHGetRootHubData (887d2ea8)
887d10e4 c705b4707d88022f7d88 mov dword ptr [usbuhci!RegistrationPacket+0x94 (887d70b4)],offset usbuhci!UhciRHGetStatus (887d2f02)
887d10ee c705bc707d88162f7d88 mov dword ptr [usbuhci!RegistrationPacket+0x9c (887d70bc)],offset usbuhci!UhciRHGetHubStatus (887d2f16)
887d10f8 c705b8707d88ba2f7d88 mov dword ptr [usbuhci!RegistrationPacket+0x98 (887d70b8)],offset usbuhci!UhciRHGetPortStatus (887d2fba)
887d1102 c705c0707d8852347d88 mov dword ptr [usbuhci!RegistrationPacket+0xa0 (887d70c0)],offset usbuhci!UhciRHSetFeaturePortReset (887d3452)
887d110c c705c8707d889e2f7d88 mov dword ptr [usbuhci!RegistrationPacket+0xa8 (887d70c8)],offset usbuhci!UhciRHSetFeaturePortEnable (887d2f9e)
887d1116 c705c4707d88b42f7d88 mov dword ptr [usbuhci!RegistrationPacket+0xa4 (887d70c4)],offset usbuhci!UhciRHClearFeaturePortPower (887d2fb4)
887d1120 c705cc707d88ee357d88 mov dword ptr [usbuhci!RegistrationPacket+0xac (887d70cc)],offset usbuhci!UhciRHSetFeaturePortSuspend (887d35ee)
887d112a c705d8707d8830377d88 mov dword ptr [usbuhci!RegistrationPacket+0xb8 (887d70d8)],offset usbuhci!UhciRHClearFeaturePortSuspend (887d3730)
887d1134 c705d0707d88882f7d88 mov dword ptr [usbuhci!RegistrationPacket+0xb0 (887d70d0)],offset usbuhci!UhciRHClearFeaturePortEnable (887d2f88)
887d113e c705d4707d88b42f7d88 mov dword ptr [usbuhci!RegistrationPacket+0xb4 (887d70d4)],offset usbuhci!UhciRHClearFeaturePortPower (887d2fb4)
887d1148 c705e0707d8832387d88 mov dword ptr [usbuhci!RegistrationPacket+0xc0 (887d70e0)],offset usbuhci!UhciRHClearFeaturePortConnectChange (887d3832)
887d1152 c705e4707d88f2387d88 mov dword ptr [usbuhci!RegistrationPacket+0xc4 (887d70e4)],offset usbuhci!UhciRHClearFeaturePortResetChange (887d38f2)
887d115c c705dc707d889c387d88 mov dword ptr [usbuhci!RegistrationPacket+0xbc (887d70dc)],offset usbuhci!UhciRHClearFeaturePortEnableChange (887d389c)
887d1166 c705e8707d880e397d88 mov dword ptr [usbuhci!RegistrationPacket+0xc8 (887d70e8)],offset usbuhci!UhciRHClearFeaturePortSuspendChange (887d390e)
887d1170 c705ec707d882a397d88 mov dword ptr [usbuhci!RegistrationPacket+0xcc (887d70ec)],offset usbuhci!UhciRHClearFeaturePortOvercurrentChange (887d392a)
887d117a c705a8707d8816207d88 mov dword ptr [usbuhci!RegistrationPacket+0x88 (887d70a8)],offset usbuhci!UhciSetEndpointStatus (887d2016)
887d1184 c705a4707d8896207d88 mov dword ptr [usbuhci!RegistrationPacket+0x84 (887d70a4)],offset usbuhci!UhciGetEndpointStatus (887d2096)
887d118e c705a0707d883e247d88 mov dword ptr [usbuhci!RegistrationPacket+0x80 (887d70a0)],offset usbuhci!UhciSetEndpointDataToggle (887d243e)
887d1198 c70548707d88161a7d88 mov dword ptr [usbuhci!RegistrationPacket+0x28 (887d7048)],offset usbuhci!UhciOpenEndpoint (887d1a16)
887d11a2 c7054c707d88981c7d88 mov dword ptr [usbuhci!RegistrationPacket+0x2c (887d704c)],offset usbuhci!UhciPokeEndpoint (887d1c98)
887d11ac c70550707d88f41d7d88 mov dword ptr [usbuhci!RegistrationPacket+0x30 (887d7050)],offset usbuhci!UhciQueryEndpointRequirements (887d1df4)
887d11b6 c70554707d883e1c7d88 mov dword ptr [usbuhci!RegistrationPacket+0x34 (887d7054)],offset usbuhci!UhciCloseEndpoint (887d1c3e)
887d11c0 c70584707d88ca1e7d88 mov dword ptr [usbuhci!RegistrationPacket+0x64 (887d7084)],offset usbuhci!UhciPollEndpoint (887d1eca)
887d11ca c70580707d8804217d88 mov dword ptr [usbuhci!RegistrationPacket+0x60 (887d7080)],offset usbuhci!UhciSetEndpointState (887d2104)
887d11d4 c7057c707d8870217d88 mov dword ptr [usbuhci!RegistrationPacket+0x5c (887d707c)],offset usbuhci!UhciGetEndpointState (887d2170)
887d11de c7058c707d88c2217d88 mov dword ptr [usbuhci!RegistrationPacket+0x6c (887d708c)],offset usbuhci!UhciGet32BitFrameNumber (887d21c2)
887d11e8 c7059c707d8850227d88 mov dword ptr [usbuhci!RegistrationPacket+0x7c (887d709c)],offset usbuhci!UhciPollController (887d2250)
887d11f2 c70588707d88602e7d88 mov dword ptr [usbuhci!RegistrationPacket+0x68 (887d7088)],offset usbuhci!UhciCheckController (887d2e60)
887d11fc c70590707d88ae5a7d88 mov dword ptr [usbuhci!RegistrationPacket+0x70 (887d7090)],offset usbuhci!UhciInterruptNextSOF (887d5aae)
887d1206 c70570707d88d0227d88 mov dword ptr [usbuhci!RegistrationPacket+0x50 (887d7070)],offset usbuhci!UhciSubmitTransfer (887d22d0)
887d1210 c70574707d88584d7d88 mov dword ptr [usbuhci!RegistrationPacket+0x54 (887d7074)],offset usbuhci!UhciIsochTransfer (887d4d58)
887d121a c70578707d8864237d88 mov dword ptr [usbuhci!RegistrationPacket+0x58 (887d7078)],offset usbuhci!UhciAbortTransfer (887d2364)
887d1224 c705f8707d889e247d88 mov dword ptr [usbuhci!RegistrationPacket+0xd8 (887d70f8)],offset usbuhci!UhciStartSendOnePacket (887d249e)
887d122e c705fc707d883c277d88 mov dword ptr [usbuhci!RegistrationPacket+0xdc (887d70fc)],offset usbuhci!UhciEndSendOnePacket (887d273c)
887d1238 c70500717d8808247d88 mov dword ptr [usbuhci!RegistrationPacket+0xe0 (887d7100)],offset usbuhci!UhciPassThru (887d2408)
887d1242 c70548717d88f2597d88 mov dword ptr [usbuhci!RegistrationPacket+0x128 (887d7148)],offset usbuhci!UhciFlushInterrupts (887d59f2)
887d124c c70598717d880e587d88 mov dword ptr [usbuhci!RegistrationPacket+0x178 (887d7198)],offset usbuhci!UhciInterruptDpcEx (887d580e)
887d1256 c705f8717d88c6167d88 mov dword ptr [usbuhci!RegistrationPacket+0x1d8 (887d71f8)],offset usbuhci!UhciHaltController (887d16c6)
887d1260 c705ec717d88541c7d88 mov dword ptr [usbuhci!RegistrationPacket+0x1cc (887d71ec)],offset usbuhci!UhciDbgFreeEndpointEndpoint (887d1c54)
887d126a c70524707d88c3020000 mov dword ptr [usbuhci!RegistrationPacket+0x4 (887d7024)],2C3h
887d1274 c70520707d8802000000 mov dword ptr [usbuhci!RegistrationPacket (887d7020)],2
887d127e c70528707d88e02e0000 mov dword ptr [usbuhci!RegistrationPacket+0x8 (887d7028)],2EE0h
887d1288 83673400 and dword ptr [edi+34h],0
887d128c 57 push edi
887d128d ff15b8607d88 call dword ptr [usbuhci!_imp__USBPORT_RegisterUSBPortDriver (887d60b8)]
887d1293 8b4dfc mov ecx,dword ptr [ebp-4]
887d1296 5f pop edi
887d1297 33cd xor ecx,ebp
887d1299 5e pop esi
887d129a e8f7480000 call usbuhci!__security_check_cookie (887d5b96)
887d129f 8be5 mov esp,ebp
887d12a1 5d pop ebp
887d12a2 c3 ret
kdsrv is a server application you run that on target
you can connect to it using any debugger (windbg , kd , cdb , from a client machine )
WaxfordSqueers
March 10th, 2019, 22:53
Quote:
| [Originally Posted by blabberer;97626]i do not understand the reservation here can you explain why you cannot ?? |
First of all I want to express my appreciation for all the work you do in order to give these examples. It's really appreciated.
The reason I cannot is because I am trying to load USB 3 drivers for W7 on an 8th generation 300-series Intel chipset (B360) and neither Microsoft nor Intel have provided W7 drivers for my particular USB Vendor/Device revision. If I try to load the required drivers in a VM, they are not being loaded using my particular chipset. And I doubt that a current VM can virtualize my particular chipset.
It might be interesting to see what would happen if I tried to force a USB 3 driver install on W7 VM to see where the problem arises.
Here's a link to drivers from Intel for W7 on my generation chipset. See if you can load them on a normal W7 installation. I don't think you can but I am interested in what goes wrong during the installation. Is it an address conflict due to a call to code that has changed?
If you use the Intel setup.exe it will produce an error message claiming something is wrong. If you use the Device Manager new hardware Wizard you can point it at the INF files under drivers.
https://downloadcenter.intel.com/download/22824/Intel-USB-3-0-eXtensible-Host-Controller-Driver-for-Intel-8-9-100-Series-and-Intel-C220-C610-Chipset-Family?product=65855
usbuhci.sys is a miniport driver associated with USB 2. So, if you have a fully functioning USB 2 system working, there should be no problem loading drivers. However, I have no USB operating natively in W7 at the moment on my B360 chipset mobo. There are no W7 native drivers showing up in Device Manager even for USB 2 drivers. The moment I plugged my W7 installation into the new mobo, all USB drivers disappeared.
I do have a VIA USB 3 peripheral card running on W7 but it uses it's own USB chipset and drivers. Those drivers show up in DM.
Intel did supply drivers for an earlier revision of the 300-series chipset but for some reason the drivers fail to load, giving an error 10. Even if I could load the USBXHCI.SYS USB Host Controller driver using your method, what good does it do me if the driver is not speaking to to the kernel or to the hub below it?
Seems to me, and I stand to be corrected, I have to approach this through the loading process from Device Manager. If you have the time and interest could you open Device Manager in a W7 installation, select a driver category, then open the 'Action' menu. Select "Add Legacy Hardware'. See if you can trap the process used to load drivers from the Wizard that opens.
You mentioned doing 10 different things. I could quite easily make it 20, there are so many different approaches here.
I have no idea what I'm dealing with. Did Intel release a revision with hardware removed? Don't think so because the board works fine with W10 drivers on my current chipset revision. It would likely work fine with W8 drivers.
My task is to discover what it is about the relationship between my current B360 chipset and the USB 3 drivers that will not allow the drivers to load. If there are drivers that allow W10 to load USB 3 drivers and work fine on the B360, what is it with W7? Till very recently, Intel released the W7 drivers at the link above that work on the 300-series chipset and my B360 is a 300-series chipset.
Kayaker
March 11th, 2019, 01:44
Quote:
| [Originally Posted by WaxfordSqueers;97627]If you use the Intel setup.exe it will produce an error message claiming something is wrong. |
You mean this error message?
3042
The string is from the Lang/en-US/Setup.exe.mui resource-only file. The name indicates the message is generated from the main 32-bit Setup.exe file itself. While I haven't tried it, breaking at (MessageBoxIndirectW) would seem like the first step? Maybe you can interpret what feature the code is looking for.
Nice stuff Blabbs. On a side note, have you ever found a good replacement for OSR IrpTracker?
There's this, but the driver is not digitally signed:
https://github.com/MartinDrab/IRPMon/releases
WaxfordSqueers
March 11th, 2019, 06:43
Quote:
[Originally Posted by blabberer;97618]open a windbg instance in physical machine which is running the vm file -> kernel debug -> com -> check pipe , check reconnect , leaves resets at 0 , leave baudrate at 115200 provide the pipe that you set up \\.\pipe\dbgpipe
hit ctrl+break or alt+delete a few times and you should be ready to go |
I will get to the VM but I wanted to establish a serial connection just for the heck of it. I am now good to go, had some issues in the null modem cable.
I used Putty, a free app that can check serial ports, and I can now send text messages via com2 at 115200 baud rate. So there is a com 2 connection and I am wired in the cable exactly as Msoft suggested.
Therefore, I should, in theory, have the same situation you describe above, except I have a direct serial connection.
Maybe I am doing this wrong. I opened Windbg in the host and selected kernel debug. Set up the serial port as you describe. Opened another Windbg session in the guest but it's not clear whether I have to open a kernel debug session on that end, or maybe use 'connect to a remote session'.
I tried kernel debug but both windows sit there claiming 'debuggee not connected' and 'waiting to reconnect'. Both machines indicate they have opened \\.\com2.
Sorry for the dumb questions.
WaxfordSqueers
March 11th, 2019, 06:54
Quote:
[Originally Posted by Kayaker;97628]You mean this error message?
3042
The string is from the Lang/en-US/Setup.exe.mui resource-only file. The name indicates the message is generated from the main 32-bit Setup.exe file itself. While I haven't tried it, breaking at (MessageBoxIndirectW) would seem like the first step? Maybe you can interpret what feature the code is looking for. |
Yep, that's the message. It's not clear what it means since my chipset exceeds the minimum requirements. I think when those drivers were issued, the B360 chipset was not yet released.
I have already traced quite a ways into that setup.exe using Olly 2 and saw a reference to not loading drivers beyond the Skylake chipset version, which is a bit older than mine. I am going to try it again later. Unfortunately Olly 2 choked on it along the way.
If you have a moment, try loading it in sice. It's a 32 bit app but it would not break on _baseprocessaddress. I noted a TLS entry in IDA and I had wondered if something is diverting it during the loading process.
As a disclaimer, I have absolutely no intention of reverse engineering the app, I am only looking for information as to why the drivers cannot be loaded. I believe Matt Pietrek called it 'spelunking'. Maybe we should contact Matt and see if he'll revive sice.
blabberer
March 11th, 2019, 07:07
that was what i was asking two threads earlier
you are not supposed to open two windbg and expect both of them to talk to each other
you are supposed to boot into debugmode and windbg that is listening on the host will connect to the boot
in target open cmd.exe
in the command prompt use bcdedit to create another boot menu
so when you press the power button on
you get two bootable options
one plain
one debug enabled
and a 30 seconds timeout to choose one of the option
here you choose the second debug enabled boot and windbg will come to life in the host
WaxfordSqueers
March 11th, 2019, 07:37
@blabberer....reading more on this.
Seems I first have to declare the debugging machine as a server using the .server command. Then I have to go on the client machine and open a remote session using
com
ort=COMPort,baud=BaudRate,channel=COMChannel[,password=Password]
It tried but it's getting late and I am bleary eyed.
I opened Notepad in my desktop and got to a prompt. I entered .server and got a message specifying the format.
I entered '.server npipe: Pipe=Com2' and it opened a server connection using my user name on the desktop. I got:
0: <debugger> -remote npipe: Pipe=Com2, Server=<my user name>
Maybe a pipe is not what I want.
I have been unable as yet to connect the laptop, even though I know COM2 is working fine at 115200 baud.
I have just as much trouble trying to open a VM connection.
WaxfordSqueers
March 11th, 2019, 07:54
Quote:
| [Originally Posted by blabberer;97631]you are supposed to boot into debugmode and windbg that is listening on the host will connect to the boot |
I already have the desktop in debug mode. If I set Windbg into kernel debug mode and boot the desktop into debug mode, nothing happens. It indicates it has opened //./com2 but is waiting to reconnect.
It's too late I'll work on this tomorrow.
Thanks for your patience and time.
Kayaker
March 11th, 2019, 19:04
Unless you are bound and determined to debug through a COM port for some reason, you might want to start with a basic VM setup, as Blabberer suggested, and see how far along you get with driver debugging or the setup file, if that's what your goal is. Maybe revisit the cable connection later.
FWIW, I just set up a Win10 host -> Win7x64 guest VM using VirtualKD and followed along with Blabs usbuhci.sys debugging example. Took all of oh 5 minutes, no fuss no muss.
I think I understand why you want to debug through a serial connection, Win7 booting with your MB under a VM isn't *exactly* the same as Win7 booting with your MB on your computer, maybe especially when it comes to USB connections. VirtualKD might even solve that problem, where the host is your laptop and your computer is the guest. Since the whole purpose of VirtualKD is to make it easier (and faster communication) for remote debugging, it really might be worth trying it.
WaxfordSqueers
March 11th, 2019, 22:23
Quote:
| [Originally Posted by Kayaker;97634]Unless you are bound and determined to debug through a COM port for some reason, you might want to start with a basic VM setup, as Blabberer suggested, and see how far along you get with driver debugging or the setup file, if that's what your goal is. Maybe revisit the cable connection later. |
I am not bound to any approach in particular and I am heeding the advice of Blabbs and yourself closely. I regard you and Blabbs highly, regarding both of you as being among the elite in reversing, especially at a normal level where your interests are more academic.
My current interest in the com port has more to do with my hardware background. I have expertise in that area and I 'should' be able to get this connection going. It interests me as to why it was not going before and it turned out to be a bad assumption about null modem cables.
***this can be skipped...technical diarrhea****
FYI, when you look at a straight-through, typical female to female serial cable it does not matter how the internal wires are coloured as long as they are run from 'equivalent' pins to equivalent pins. Once you cut that cable to route the conductors in different ways, to make a null modem cable, you have to be very careful with regard to the D-shell orientation.
When D-shells plug into each other they do as as a mirror image of each other. If you pull them apart and rotate them through 180 degrees, and view them, they form a mirror image with the short end of the D adjacent and the longer ends on opposite sides. If you now locate pin 1 on the longer pin side, which should be indicated on the terminal connector or in it's literature, pin 1 on the longer female connector is directly opposite it on the outside.
If you don't pay close attention to that alignment, right along the chain, when you have the cable unplugged, you can quite easily get pins 1 and 5 reversed by having the plug upside down. To make matters worse, the adapter connecting to the mobo serial port, which bring it out to the back panel, is a ribbon cable.
On the mobo end the connector is numbered across the connector so that odd numbered pin counts are 1,3,5,7,9 along one side and 2,4,6,8 along the other. However, the D-shell pinout is number 1,2,3,4,5 along the wide side of the D and 6,7,8,9 along the short side with the 6 opposite and between the 1,2 pins.
When you transition from a keyed mobo connector, through a flat ribbon cable, through two D-shell connectors, through a serial cable, through another two D-shells and into a USB to serial adapter D-shell, the mind can become rather boggled trying to keep everything aligned while one makes a drawing.
When you cut the cable, there are 9 different coloured conductors inside but you can't see where they connect to the connector because the connectors are molded plastic. So you have to ring them out with an ohmmeter. Some of the conductors in the cable follow the resistor colour code as R,O,Y,G,B,V,S (red orange, yellow, green, blue, violet, slate).
What I forgot is that some manufactures start at black on pin 1 and brown on pin 2, then pin 3 is R, 4 is O, etc.
What threw me was the black, which is normally ground. It was connected to the end pin on the long side of the D and ground in a serial connector is 5, so I presumed black was pin 5. Wrong!!! I was holding the D-shell backwards and that was actually pin 1. Turned out ground was yellow.
See how easy it is to blow up a motherboard? Thankfully, serial does not expose voltages directly to the bus. They are exposed through pull up and pull down arrangements where the serial chip is exposed via resistors of sufficient size to limit the current.
Motherboard normally also implement current limiting in case some idiot, like me, reverses the wrong connections.
*********************
Quote:
| [Originally Posted by Kayaker;97634]I think I understand why you want to debug through a serial connection, Win7 booting with your MB under a VM isn't *exactly* the same as Win7 booting with your MB on your computer, maybe especially when it comes to USB connections. VirtualKD might even solve that problem, where the host is your laptop and your computer is the guest. Since the whole purpose of VirtualKD is to make it easier (and faster communication) for remote debugging, it really might be worth trying it. |
Thanks for the insight. Blabbs is a good guy and a good teacher and I'm sure he regards me as being somewhat obtuse in this regard. I think his message is quit messing with irrelevant detail and get on a VM so you can learn Windbg. His point is well taken and he'll receive no argument from me.
As I pointed out to him, I have had similar issues setting up a virtual COM port on a VM and I would really like to see this serial configuration work.
You mentioned Wireshark in a previous post and I am going to try that or some other app that will allow me to most definitely verify communications between computers.
Putty is showing a COM2 connection, I can type messages between the Putty terminals on either machine. Telnet complains about port 23 being blocked and that sounds like a Firewall issue.
I will d/l VirtualKD and check it out. Thanks for suggestion.
WaxfordSqueers
March 13th, 2019, 02:52
@ Kayaker @blabberer
I have a serial port monitor on a laptop and Windbg on a desktop. Windbg is open as a kernel debugger and it's sending an IRP_MJ_READ to the laptop via COM2 through a cable. Those are the sets of iiiiis I talked about. They are related to the IRP.
I have been told to reboot the laptop and that the desktop Windbg should detect the reboot in debug mode and perform some kind of action.
Question: If Wdbg is sending out an IRP_MJ_READ it is trying to read something. What the heck can it read? I find that to be utterly confusing. I have tried sending a ctrl-break and an alt-del, plus several other keys. It just sits there with the message:
opened \\.\com2
Waiting to reconnect
It acknowledges being connected to com2 and it is getting an IRP through to the laptop's com2, where it is being monitored by a serial port tool.
I have tried it both ways and verified on both machines using bcdedit that both machines are in debug mode and both on COM2 at 115200 baud.
I have experienced the same problem in VMs, not exactly the same issue, but the failure to connect.
The problem is, I have no idea what to expect on the other end. Blabbs laid it out very simply about hitting ctrl-break or alt-del but there is no response from wdbg.
What the heck is Windbg trying to connect to? If it is coming in through a serial port how would it know what to look for? I could see it with telnet via a network with a telnet client on the other end. I can do it with Putty with a Putty client open in the other machine. But what the heck would wdbg be looking for if it does not have another version of itself open?
Telnet fails due to the utter insanity introduced by msoft re security. It requires users on another computer to be part of the TelnetClient group. Guess what. When you try to add a user on another computer it tells you it can't find that user.
Well, duh!!!! Of course not, I am trying to tell you about it you dumb-ass Wizard. It's as bad as the security in Windows. How many times have I tried to change security permissions on a file or registry key in windoze, as Administrator, only to be told I don't have the level of security required to access the file or key.
Oh, I have a perfect fix for that garbage. I go into the mft and change the permissions at the root. And I mean ROOT. You can do anything you want to permissions in the mft if you know where to find it.
If I get a connection, what am I looking for....a window with a cursor? Or do I get access to Explorer so I can load a file or a DRIVER?
There is very little info on this. Even msoft, who write volumes on it, are seriously terse about what to expect when a connection is established.
The same problem about 'waiting to reconnect' is prevalent on the Net and I have not read a satisfactory solution. It may be related to particular mobos and/or versions of OSs.
WaxfordSqueers
March 14th, 2019, 06:13
@blabberer @kayaker
Spent a lot of time going over what you guys have told me and doing further research.
Thus far, I have confirmed I am getting communication between windbg either way, between my desktop and laptop via a serial cable.
I have begun to notice issue with the symbol server, much of which I have corrected. However, a nagging problem persists. Windbg is completely ignoring the environment variables where I have set _NT_SYMBOL_PATH as:
srv*c:\syms*https://msdl.microsoft.com/download/symbols
Where c:\syms is my symbol store.
If I fire up windbg and load notepad, it will populate my store with ntdll.pdb. After running notepad it populated the store further with deferred pdb files.
When I restart windbg, my symbol path is gone, replace with just srv*. Then wdbg complains about not being able to find symbol files.
It's this sort of crap that I am sure turns people off from using windbg. It's typical Microsoft bs...convoluted, abstracted nonsense that has no logical basis other than to Microsoft weenies.
Furthermore, I cannot find a way to d/l core system files like ntoskrnl, win32, hal, or anything other than ntdll, kernel32, gdi32, and user32.
I have read that my current issue may be related to wdbg being unable to find required symbol files when it watches for the debuggee. [/whine off].
Kayaker
March 14th, 2019, 23:02
So you got it connected? Know what the problem was?
I've only ever used Windbg remotely for driver debugging, but I'm finding using it for remote user-mode debugging a real PITA. I followed the advice of some guy here
https://stackoverflow.com/questions/31295295/how-to-break-on-the-entry-point-of-a-program-when-debug-in-kernel-mode-with-wind
and found that setting _NT_SYMBOL_PATH in the guest VM to a shared folder (mapped to Z:\) helped when using ntsd in the target. You may need to set up a shared symbol folder as well if you haven't already.
To be honest, I don't really "get" how to use ntsd - d calc.exe in the remote target to debug it through Windbg in the host. The remote VM is locked up after breaking on $exentry, naturally, but there's no disassembly window in Windbg, or F8/F10, etc. to use. I don't want to debug ON the remote target through ntsd, I want to work through the Windbg interface on the host.
Going the other route, strictly through the kernel debugger with
!gflag +ksl
sxe ld calc.exe
works, in a way, but I can't seem to make it behave in a normal user-mode way after the initial exception, such as breaking on $exentry to single step.
More RTFMing I suppose...
blabberer
March 15th, 2019, 01:15
ntsd -d is for using a present existing kernel debugger connection for debugging a user mode application running in the target
you run calc.exe in inside the vm using ntsd -d calc
this breaks in the kernel debugger at exactly the same place where you will break if you open it in a windbg instance inside vm
you can do everything you can as if you are physically debugging the app in target with a user mode debugger running inside the target
you need a symbol path that is relative to ntsd running inside target that is you need a symbol path that is inside target for this
you dont want to download gigbytes of craps for each of the vm you have
so you right click the mycomputer and map a network drive
ie net use * \\blah\foo
now the target is happy it got a path that is relative to itself
host is happy because it found the symbols
and host can happily download the symbol to one central place viz srv*drive:\folder*httpsXXXXX\msdlXXXXX.com
you can run n thousand vms with n^n thousand os versions and you have all the symbols for all the versions in one single place
Code:
E:\SYMBOLS>dir /s /b *ntdll*
E:\SYMBOLS\ntdll.dll
E:\SYMBOLS\ntdll.pdb
E:\SYMBOLS\wntdll.pdb
E:\SYMBOLS\ntdll.dll\4802A12Caf000\ntdll.dll
E:\SYMBOLS\ntdll.dll\49901D48b2000\ntdll.dll
E:\SYMBOLS\ntdll.dll\4CE7B96E13c000\ntdll.dll
E:\SYMBOLS\ntdll.dll\521EA91C13c000\ntdll.dll
E:\SYMBOLS\ntdll.dll\56A84B3317b000\ntdll.dll
E:\SYMBOLS\ntdll.dll\FAC1B31418d000\ntdll.dll
E:\SYMBOLS\ntdll.pdb\120028FA453F4CD5A6A404EC37396A582\ntdll.pdb
E:\SYMBOLS\ntdll.pdb\1751003260CA42598C0FB326585000ED2\ntdll.pdb
E:\SYMBOLS\ntdll.pdb\6992F4DAF4B144068D78669D6CB5D2072\ntdll.pdb
E:\SYMBOLS\ntdll.pdb\8670B02D0AAB58B6417C99F75EC9F6181\ntdll.pdb
E:\SYMBOLS\ntdll.pdb\ABF1BB59358045878B4834C02650F1AA1\ntdll.pdb
E:\SYMBOLS\ntdll.pdb\CD4062A231154A17A18DAE7D1A0FBACC2\ntdll.pdb
E:\SYMBOLS\ntdll.pdb\CD4062A231154A17A18DAE7D1A0FBACC2\oldntdll.pdb
E:\SYMBOLS\wntdll.pdb\F42E56BB23DF4C2A9CAA683DA90E032F1\wntdll.pdb
E:\SYMBOLS>dir /s /b *ntkr*
E:\SYMBOLS\ntkrnlmp.exe
E:\SYMBOLS\ntkrnlmp.pdb
E:\SYMBOLS\ntkrnlpa.exe
E:\SYMBOLS\Ntkrpamp.exe
E:\SYMBOLS\ntkrpamp.pdb
E:\SYMBOLS\ntkrnlmp.exe\4CE78A06404000\ntkrnlmp.exe
E:\SYMBOLS\ntkrnlmp.pdb\00625D7D36754CBEBA4533BA9A0F3FE22\ntkrnlmp.pdb
E:\SYMBOLS\ntkrnlpa.exe\521E9CB6413000\ntkrnlpa.exe
E:\SYMBOLS\Ntkrpamp.exe\4CE78A09412000\ntkrpamp.exe
E:\SYMBOLS\ntkrpamp.pdb\684DA42A30CC450F81C535B4D18944B12\ntkrpamp.pdb
E:\SYMBOLS\ntkrpamp.pdb\68D8223983D9498BA98FCDE6FE21A6F01\ntkrpamp.pdb
E:\SYMBOLS\ntkrpamp.pdb\8D19793666974C2381B49539536AC9EE1\ntkrpamp.pdb
E:\SYMBOLS\ntkrpamp.pdb\E4AF624F009A4D99A4F85690E0164DBC2\ntkrpamp.pdb
E:\SYMBOLS>set _NT
_NT_SYMBOL_PATH=srv*E:\symbols*http://msdl.microsoft.com/download/symbols;
3043
Kayaker
March 15th, 2019, 04:19
Yeah I can break on $exentry, with symbols, but I was stuck as where to go from there. I was hoping most of the Windbg functions would be available, including the Disassembly window and F8/F10 keys, but I realize now it's mostly limited to ntsd/cdb commands inputted on the command line. "t" = F8, "p"=F10, "u ." to try to figure out where the hell you are in the code, blah, blah.
Hmm, ntsd is useful for some purposes I'm sure, but doesn't look like a lot of fun. Maybe I'll try x64dbg or Windbg for user-mode debugging within VM's and leave the remote Windbg stuff strictly for kernel mode.
Thanks for the help.
blabberer
March 15th, 2019, 12:51
yeah ntsd is useful for exotic situations not for normal debugging of calc.exe
ntsd is useful if you are debugging a nonui session 1 process under ui session2 process (IMAGINE NETWORK_SERVICES )
it can sit there headless and just serve as command interpreter
i think you will never be able to ( x64dbg or ollydbg or radare2 or even windbg usermode) a winlogon.exe or csrss.exe right from start
well it is exotic and is to be used for exotic purposes
there is absolutely no joy debugging calc.exe
it is just an exercise in masochistic sadism
WaxfordSqueers
March 15th, 2019, 21:09
Quote:
| [Originally Posted by Kayaker;97638]So you got it connected? Know what the problem was? |
The initial connection problem was in the null modem cable. As I explained in my rambling blurb, it's easy to invert the D-shell serial connector and reverse pins 1 and 5. As far as the 'waiting to reconnect', that is still unresolved.
The problem may be in the USB-Serial interface I am using. Microsoft is finicky with their demands. With network connections for Windbg, they only allow certain models of network cards. Maybe they are using the RS-232 interface in a non-standard manner. However, their explanation of a serial connection requires a null modem format and that's exactly how I have wired my null model cable, to Msoft specifications.
Getting closer through. I found an excellent book on Windows debugging which covers that very question. The book seems to think it's in the connection parameters but I am beginning to suspect more.
I am wondering about the possibility of debugging windbg using windbg?
Realizing I know nothing about how the debugger interacts with the OS, or the facts behind host/guest or local/remote/target, I have rolled up the sleeves and decided to understanding it all from the bottom up.
I have already covered a lot of it in books like Windows Internals and this book begins with a good explanation of the OS architecture from user mode through ntdll, ntoskrnl and Hal to the hardware level. The author uses that to explain user mode debugging versus kernel mode debugging.
I have skimmed some of it to see what they are getting at and the author explains a remote session versus a remote stub. So, it seems more involved than simply connecting two machines together, you have to decide whether the debugger will be on the target machine or the local machine and as Blabbs said, you have to decide where to put the symbols.
There is also the question of what debug mode does to connect itself to windbg on the other computer. That is all explained in the book but I have yet to digest it.
Amazingly, you can actually setup debug mode in msconfig under the boot tab. You can turn debug on/off and set the com port and the baud rate. You can even make it permanent.
To compound the issue, this author is talking about a straight, pin to pin serial cable and does not mention a null modem cable. I can almost get that provided the communication is from one machine to the other with no data required in the opposite direction.
More research required.
WaxfordSqueers
March 15th, 2019, 22:51
Quote:
[Originally Posted by blabberer;97639]so you right click the mycomputer and map a network drive
ie net use * \\blah\foo |
Thanks for tip. I might add that on my system I had to give permission on the shared folder before the network share could be implemented. I just right/clicked the shared folder, selected 'Share' then selected 'Everyone' under the Share button.
There is also an Advanced button where you can do more intricate permissions.
WaxfordSqueers
March 18th, 2019, 04:14
One major issue with using a USB - serial converter is the availability of the port when the target machine is booted.
Answering my own question, when I set up wdbg on a host machine and set it in kernel mode, then reboot the target in debug mode, the target OS loads a file called kdcom.dll during boot for a serial port connection on the target end. kdcom looks for s REAL serial port with wdbg on the other end and my mickey mouse USB - serial converter driver has not yet been loaded. Therefore, no serial port is seen.
One problem solved.
But wait... a light just went on. Suppose I reverse the connection so wdbg is on the laptop with the serial port working, then reboot the desktop with the real serial port? Hmmmm. Gotta check and see if my desktop version of W7 has a kdcom.dll in sys32.
I do have a Firewire port on my laptop but no Firewire capabilities on my Asus B360 mobo. Don't know if a converter is available between Firewire and a serial port, or USB port.
If there was such an animal it would likely work because the Firewire port on my laptop is an actual port. It would be available at boot time in debug mode and the other end should not matter since wdbg already has it open.
Apparently a network connection is not available on W7.
Sigh!!!
I do have a modem port (RJ-11 connector) on my laptop and it is driven by a removable module. The modem 'should' be connected to an internal serial port but I have no idea what is available on it.
I was wondering why my BIOS lists a serial port and no external physical port can be seen.
I never really understood what Bluetooth was about till the other day. Apparently it is a wifi version of RS-232. My Bluetooth devices on my laptop are marked COM5 and COM7, which are serial ports but I'd likely run into the same issues where those Bluetooth were not available early enough to connect with kdcom.dll.
The research never ends.
I know, blabbs, I know....use a friggin VM and get on with it. What if I ran a W7 VM as host, could I use it to debug the physical machine?
blabberer
March 18th, 2019, 10:21
Quote:
I was wondering why my BIOS lists a serial port and no external physical port can be seen.
|
i have been told or i have read somewhere that a mother board can have headers that you can reach at if you are in factory
but not physically exposed
especially usb headers are supplied by many vendors for extensing usb ports to front panel
here is a b360 motherboard snapshot (not sure if it is your b360 it is google's first hit b360)
PRIME-B360-PLUS/ ("https://www.asus.com/in/Motherboards/PRIME-B360-PLUS/")
see if you can locate a serial header in there
3044
and here is a link to some soldersoldier's attempt to put some x cable to y pinouts to give birth to a exposed z
soldersoldier/ ("https://embedjournal.com/pc-serial-port-not-dead/")
can i use w7 vm as host ??
why not try it out ?
actually vmware has two options to declare which end is what
but from my feeble understanding of vm's i think a virtual machine can work on top of one physical machine only
i havent tried to connect a vm that is running on top a physical machine to another remote physical machine connected by a cable
if that is what you are referring to
WaxfordSqueers
March 19th, 2019, 00:46
Quote:
[Originally Posted by blabberer;97646]i have been told or i have read somewhere that a mother board can have headers that you can reach at if you are in factory
but not physically exposed |
Yeah....I have seen that done before. RS-232 is still a common communication protocol and some electronic equipment is tested via a serial port then the port is abandoned.
That's what I was talking about with my laptop which has a modem output via an RJ-11 jack, a common telephone jack. The jack has a cable running to it and is coupled to the mobo via a coupler that I presume converts the serial output on the mobo to a modem-compatible 2-wire circuit. If I'm lucky, the port where the coupler connects may be an RS-232 port. Or, as you point out, there may be header traces on the mobo for an abandoned RS-232 i/f.
It may not be full RS-232, however. The simplex form only uses a transmit and receive terminal with a ground. I'd be lucky if it had the full compliment of handshake signals as required by Microsoft in their specifications for connecting two computers with a serial null modem cable.
I would have looked at it by now but it's not a trivial device to reach. It requires dismantling a good deal of the laptop and I have not had time as of yet. Another option may be the Bluetooth module. It may connect to an RS-232 port where the module acts as a converter from RS-232 to wireless RS-232. I need to research that more.
At the link you provide, the guy was lucky not to have damaged his mobo. I presumed the mobo serial pin configuration was the same as on the DB-9 connector but it was not. Luckily Asus supplied the pinout.
BTW...in the article at the link he claims DB-9 is not the correct terminology. DB-9 has been regarded as the correct terminology throughout the industry as long as I can recall.
Quote:
| [Originally Posted by blabberer;97646]here is a b360 motherboard snapshot (not sure if it is your b360 it is google's first hit b360) |
Close but it's the Asus Prime B360 Plus and mine is a B360M-C. The one in your photo has three full sized PCI slots grouped together and mine only has one.
If you look at the bottom left side of the board in your photo you'll see two serial ports. They are rectangular in shape with a slot in the bottom edge.
Quote:
[Originally Posted by blabberer;97646]i havent tried to connect a vm that is running on top a physical machine to another remote physical machine connected by a cable
if that is what you are referring to |
No. I was talking about setting up a pipe between the VM and the host mobo so I could debug the USB driver stack in W10 on that particular B360 mobo. I want to then compare that to the W7 stack to see where it differs.
There are W7 drivers supplied by Intel (I posted a link earlier) for a slightly earlier version of the 300-series mobo of which my B360 is a part. However, those drivers refuse to start under W7 on my mobo and I think it's because the driver above them, supplied by msoft, to interface those drivers to the kernel, is too old to deal with USB 3 drivers. If I can figure out how it works in W10, maybe I can find a driver in W8 or so that will do the job.
What I want to do, in W10, is trace the action of a USB device as it is plugged into a USB port. I want to trace through the USB driver stack (not the call stack) which consists of several drivers between the kernel and the physical USB device. They communicate via IRPs.
I asked you this a while back. Can Wdbg trace as low as HAL and right to the device? From what I am reading now it can only be done via a remote connection using kernel debugging. However, it's still not clear whether I can use wdbg to trace right through ring 0 code to the device level.
I seem to recall you saying it can be done.
Kayaker
March 20th, 2019, 01:31
Waxford, just to let you know, I mentioned earlier about IRPMon
https://github.com/MartinDrab/IRPMon
I was able to run it on a VM after selecting "Disable driver signature enforcement" from the boot menu and monitor USB IRP's. You'll have to read the docs and play around with which usb drivers to hook, but I did get some results such as DriverObject and IRP Addresses. Since you can combine that monitoring with a Windbg kernel session at the same time, it might help your cause.
For example, here is the output of !irp from an IRP address captured by IRPMon when I had a usb stick plugged in:
Code:
kd> !irp fffffa8002186ca0
Irp is active with 7 stacks 7 is current (= 0xfffffa8002186f20)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace. Pending has been returned
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[IRP_MJ_INTERNAL_DEVICE_CONTROL(f), N/A(0)]
0 0 fffffa8002ce9050 00000000 fffff880032361b4-00000000
\Driver\usbehci USBSTOR!USBSTOR_CswCompletion
Args: 00000000 00000000 0x0 00000000
[IRP_MJ_INTERNAL_DEVICE_CONTROL(f), N/A(0)]
0 0 fffffa8002fdab60 00000000 fffff8800199dd40-fffffa8002bbda88
\Driver\USBSTOR CLASSPNP!ClasspMediaChangeDetectionCompletion
Args: fffffa8002bbda88 00000000 0x0 00000000
>[IRP_MJ_CREATE(0), N/A(0)]
2 0 fffffa8002191790 00000000 00000000-00000000
\Driver\Disk
Args: 00000000 00000000 00000000 00000000
and the results from IRPMon for that capture:
Code:
ID = 1424
Time = 3/20/2019 5:40:37 AM
Type = IRPComp
Device object = 0xFFFFFA80021D5440
Device name =
Driver object = 0xFFFFFA80025EB460
Driver name = \Driver\usbhub
Result = STATUS_MORE_PROCESSING_REQUIRED (0xC0000016)
IRP address = 0xFFFFFA8002186CA0
Thread ID = 0
Process ID = 0
IRQL = Dispatch
IOSB.Status = STATUS_SUCCESS (0x0)
IOSB.Information = 0x0000000000000000
On a side note, I've been able to break on the start of any usermode process while running Windbg in kernelmode on the host,
without requiring the use of ntsd/cdb on the guest VM. In other words, the full Windbg gui is available, including the disassembly window, so all the benefits of Olly + Softice. The procedure steps through bp's on nt!NtMapViewOfSection and ntdll!RtlUserThreadStart then calculating the OEP of the target. A simple script can automate most of the sequence, which I can outline later.
blabberer
March 20th, 2019, 04:13
ah you asked me earlier about irpmon equivalent with signed drivers
no i havent found one
btw youdont have to calculate the oep when on RtlUserThreadStart they are already available in registers
check the post i made for ollydbg here http://www.woodmann.com/forum/showthread.php?15764-USB-drivers-for-Win-7-on-8th-generation-Intel-chipset&p=97607&viewfull=1#post97607
btw @kayaker
keep in mind that !gflag +ksl ; sxe:ld will work only once per boot
you may need to do some jugglery to catch it again check this thread
https://community.osr.com/discussion/comment/233214/
Kayaker
March 20th, 2019, 07:28
Nice trick picking up the OEP from the register. Not sure how that would work in 64 bit though. Here's the start of RtlUserThreadStart after the break. I have to step into the RAX call, to get to the next bit of code where RDX holds the call to the program (in this case Autoruns64).
3049
3050
EDIT: Actually, looking at the code, it might be in RCX, I'll check next time.
EDIT: Yes it is.
I've been using this script snippet, called as
$$>a< C:\..\script.wds <image name>
where <image name> is interpreted as the base address
Code:
.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"
}
Oh, and $exentry only works on programs with symbols it seems, else it always points to nt!KiSystemStartup for some reason.
Most times I've been able to Break or .restart after letting the app run and repeat without too much problem, I think usually, but yeah sometimes it seems to wipe out !gflag and sxe.
WaxfordSqueers
March 21st, 2019, 22:40
Quote:
| [Originally Posted by Kayaker;97648]I was able to run it [IRPmon] on a VM after selecting "Disable driver signature enforcement" from the boot menu and monitor USB IRP's. You'll have to read the docs and play around with which usb drivers to hook, but I did get some results such as DriverObject and IRP Addresses. Since you can combine that monitoring with a Windbg kernel session at the same time, it might help your cause. |
Thanks, Kayaker. I find this intrusiveness by Msoft to be irritating. When I installed IPRmon, I got a nasty message telling me the driver is not signed therefore I should uninstall the app. I mean, after purchasing Windows, does it belong to me to use as I like, or do they still hold the right to dictate what I should and should not load?
On my desktop, I have put the OS in test mode so I can load what I want and I have defeated file checker so I can test different versions of drivers and dlls so it won't erase what I install.
I'll try IRPmon out soon. At the moment I am deliberately isolating everything I can think of that might interfere with wdbg on a host seeing the target. I came across some permission issues and I am thinking of turning off DEP in BIOS. Ran takeown and icacls on my c:\ drive to restore permissions but forgot about reparse points/junctions. I would think icacls and takeown would be familiar with the reparse points since it is issued by msoft. It's not. Seems I have to run them directory by directory to avoid those directories with junction points.
I have noticed in the W7 registry, under HKLM in enumeration, there are sub-hives called Properties. They are strongly defended by access denied warnings. I am going to run an app to reset permissions in the registry but I'd like to reset Properties as well so I can see what's in there.
I fear the DEP is likely running shotgun on serial port communications early in the boot process, either that or one of those new fangled boot code monitors is at work.
I am also checking out my Comodo firewall. It has a means of enabling or disabling ports but I'm trying to figure out if the 0x2F8 - 0x2FF addresses associated with COM2 are actual port addresses that I can enter in Comodo to ensure those ports are enabled. To complicated further, the ports in Comodo are in decimal, not hex.
Quote:
| [Originally Posted by Kayaker;97648]On a side note, I've been able to break on the start of any usermode process while running Windbg in kernelmode on the host |
Not sure what you mean, more out of my ignorance of wdbg than anything. I have run notepad right from the wdbg GUI, under File/Open Executable, and it is stopped in ntdll by design. Is that considered k-mode wrt wdbg? I was not aware you could run it in different modes, I thought it was the KD cmd line debugger with a GUI.
I have been able to set a BP to trap a File/Open in notepad while it is running just as I would have done with sice. Did not try tracing into K32, or ntdll to see if it would hit a sysenter and carry on into the kernel.
blabberer
March 22nd, 2019, 05:35
Quote:
I have run notepad right from the wdbg GUI, under File/Open Executable, and it is stopped in ntdll by design. Is that considered k-mode wrt wdbg?
|
no absolutely not if you open notepad.exe on the same computer running windbg and if it breaks on ntdll!Kixxxstartyyy you are doing plain usermode debugging as if you are debugging it in ollydbg / x64dbg / whatever debug including visual-studio f5
now if you run notepad.exe in the target computer and if it breaks in the windbg running in host
you are debugging the notepad under kernel debugger in this case you can view the notepads complete virtual space ie on a 32 bit computer
you can see the target notepad.exe's virtual address space from 0x00000000 to 0xffffffff or their physical pages
like i said earlier get your feet wet instead of editing ntfs mft root acls billions of computers are running doze and probably billions went through windbg / kd and yes hal also needs debugging so you can step through hal function oh by the way you can disassemble bios amli code with windbg
and debug acpi tables will that qualify your requirement you posted few threads ago ?
calc.exe stopped in kernelmode when Section is mapped
3051
WaxfordSqueers
March 22nd, 2019, 20:09
re turning of DEP in BIOS, I can do it on my HP laptop but not on my B360 BIOS.
I recall being advised with sice while setting up windoze to start in debug mode to use a switch like /opt out to stop DEP. Does anyone know if something similar can be added to the W7 debug string in debug mode to stop DEP loading in debug mode?
Closest I have seen is adding a line with bcdedit as:
bcdedit.exe /set nx AlwaysOff
I don't know if that can be entered verbatim or if the 'x' in 'nx' is a variable.
ps. I have a whole lot of grief with file/folder permissions. Ran chkdsk and it stalled at 0%. Remembered that I had applied a drive letter to the system partition so I could read it. Turning that off got chkdsk to 70% where it has stalled overnight checking security descriptors.
I have lost bcdedit. The system complains it's folder is missing. Under HKLM there is usually a bcdedit entry titled BCD000000.... It's gone.
Good Grief!!!! .....Charley Brown.
WaxfordSqueers
March 22nd, 2019, 20:20
Quote:
| [Originally Posted by blabberer;97652]no absolutely not if you open notepad.exe on the same computer running windbg and if it breaks on ntdll!Kixxxstartyyy you are doing plain usermode debugging as if you are debugging it in ollydbg / x64dbg / whatever debug including visual-studio f5 |
Thanks blabbs, I did get my feet wet, somewhat. I traced from the ntdll point where notepad stops well into ntdll and k32. I realize that is still user mode code.
What would happen if I hit an entry point from ntdll into the kernel? Would it just stall, or kick me back to ntdll code after the kernel processes completed?
Along the way, I experimented with the windows you suggested, changing the colours and fonts to suit. I had the code window setup with custom colours and the register window open.
Takes a bit of getting used to with the 64-bit registers. I wondered if the leading zeros can be dumped when not in use.
Could not find a flags register for imminent jumps. Have not looked hard yet.
I wish the register windows could be arranged more horizontally than vertically. Maybe there's a way. Anyway, I began to feel quite comfortable stepping through the code with F8 and F10.
Kayaker
March 22nd, 2019, 22:39
Quote:
| [Originally Posted by WaxfordSqueers;97654]Takes a bit of getting used to with the 64-bit registers. I wondered if the leading zeros can be dumped when not in use. |
Blabberer probably has all kinds of interesting tricks, which is why I enjoy discussing this, I always learn something. I noticed that the Registers window is blank for me and gives the error message "Registers are not yet known". If you google that, it's a known problem in some situations and there's even an extension to address it:
https://github.com/mbikovitsky/WingDbg
Maybe you haven't come across that problem yet. Instead I use the Watch window and add the registers manually - @rip, @rax, @rbx, etc. If you use the 32 bit equivalents - @eip, @eax, etc. you'll get them as such without the higher order portion of the 64 bit address if you don't want to look at it. But I think that just adds to confusion because it's not immediately apparent if you're looking at a 64 bit address or a dword value.
blabberer
March 23rd, 2019, 03:03
sure register windows can be docked horizontally play with workspaces dock it to your taste and save the workspace layout
register display can be customised to suit what one wants
I don't use gui much I like kd and I prefer hitting r rather than lifting mouse
but if and when I use gui I simply put eax below rax ebx below rbx and so on
3052
WaxfordSqueers
March 23rd, 2019, 20:37
Quote:
| [Originally Posted by Kayaker;97655]I noticed that the Registers window is blank for me and gives the error message "Registers are not yet known". If you google that, it's a known problem in some situations and there's even an extension to address it: |
Thanks for tip. Have not yet encountered that one but I have downloaded the earlier version of wdbg as suggested at a link on the site. It claims the earlier version will run on W10 just fine and does not give the register problem with earlier versions of windoze.
WaxfordSqueers
March 23rd, 2019, 20:41
Quote:
[Originally Posted by blabberer;97656]sure register windows can be docked horizontally.....
I don't use gui much I like kd and I prefer hitting r rather than lifting mouse |
I wasn't referring to docking, I meant laying out the registers horizontally rather than having to use a scroll bar to access those ones off the bottom.
What kind of mouse do you have to lift?
You don't mean a moose do you, as my Scottish ancestors would pronounce it?
I just push mine around. It squeaks when I do and I have to offer it a bit of cheese to keep it quiet.
blabberer
March 24th, 2019, 02:03
f8 and f10 can print three registers per line
gui layout isn't configurable
by default register printing is disabled in kernel mode
to enable printing when broken or during stepping
just do
.prompt_allow +reg
with that if you f8 or f10 or stop on an event you will get a display like this (both host and target are winx64 1809
Code:
kd> t
rax=0000000000000001 rbx=fffff8025aa56180 rcx=0000000000000001
rdx=0000000000000000 rsi=000000000000014b rdi=ffffb28157e6a040
rip=fffff8025b7baca1 rsp=fffff8025df35b78 rbp=0000000000000002
r8=00000000000000c5 r9=0000000000000000 r10=0000000000000101
r11=0000000003234a75 r12=000000156c094a00 r13=0000000000000000
r14=fffff78000000300 r15=0000000000000001
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000202
nt!DbgBreakPointWithStatus+0x1:
fffff802`5b7baca1 c3 ret
kd> t
rax=0000000000000001 rbx=fffff8025aa56180 rcx=0000000000000001
rdx=0000000000000000 rsi=000000000000014b rdi=ffffb28157e6a040
rip=fffff8025b7cfac6 rsp=fffff8025df35b80 rbp=0000000000000002
r8=00000000000000c5 r9=0000000000000000 r10=0000000000000101
r11=0000000003234a75 r12=000000156c094a00 r13=0000000000000000
r14=fffff78000000300 r15=0000000000000001
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000202
nt!KdCheckForDebugBreak+0x8eb6e:
fffff802`5b7cfac6 90 nop
kd> p
rax=0000000000000001 rbx=fffff8025aa56180 rcx=0000000000000001
rdx=0000000000000000 rsi=000000000000014b rdi=ffffb28157e6a040
rip=fffff8025b7cfac7 rsp=fffff8025df35b80 rbp=0000000000000002
r8=00000000000000c5 r9=0000000000000000 r10=0000000000000101
r11=0000000003234a75 r12=000000156c094a00 r13=0000000000000000
r14=fffff78000000300 r15=0000000000000001
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000202
nt!KdCheckForDebugBreak+0x8eb6f:
fffff802`5b7cfac7 e9aa14f7ff jmp nt!KdCheckForDebugBreak+0x1e (fffff802`5b740f76)
kd> p
rax=0000000000000001 rbx=fffff8025aa56180 rcx=0000000000000001
rdx=0000000000000000 rsi=000000000000014b rdi=ffffb28157e6a040
rip=fffff8025b740f76 rsp=fffff8025df35b80 rbp=0000000000000002
r8=00000000000000c5 r9=0000000000000000 r10=0000000000000101
r11=0000000003234a75 r12=000000156c094a00 r13=0000000000000000
r14=fffff78000000300 r15=0000000000000001
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000202
nt!KdCheckForDebugBreak+0x1e:
fffff802`5b740f76 4883c428 add rsp,28h
WaxfordSqueers
March 24th, 2019, 05:37
Quote:
[Originally Posted by blabberer;97659]f8 and f10 can print three registers per line
gui layout isn't configurable] |
Thanks for on-going info blabbs.
Had a break-through tonight re serial communication. Not what I wanted but something unexpected.
Decided to try KD instead of wdbg. I just started it as KD but it knew to start a remote debug session and came up with the customary:
Opened \\.\COM2
Waiting to reconnect...
Scratched my head for a bit and opened a KD session on target to try some commands. Verified that comm settings on that end were good but added one I had not known about
KD /set dbgtransport kdcom.dll
kdcom.dll is the dll on the target end with which windoze in debug mode loads early in the process. I looked at it quickly in IDA and it's full of communication jargon.
BTW...I typed .server into the host KD window but nothing seemed to happen. I don't know if that helped but later, during a KD session, it opened a window of help functions. I noted a few of them for key combos like:
<Ctrl-V><Enter> Toggle Verbose Mode
<Ctrl-\><Enter> Debug Current Debugger
One difference with KD is that I have a cursor, whereas with wdbg it is frozen. So I turned verbose mode to on in the host KD and when I used the Ctrl-\, Enter, it spawned a cdb.exe session with a verbose window. It told me in the verbosity to use...
"-remote npipe:icfenable,pipe=cdb_pipe,server='my user ID'
I presumed that meant to enter that line on KD in the target machine so I opened a cmd prompt in the target KD directory and added the above line to KD as a command line option. Lo and behold, KD on the target machine and CDB on the host started talking to each other. At least, commands entered in cdb on the host immediately show up in the KD target window over the serial port.
I am stumped here because I have no idea what to enter. I'll have to study up on cdb and see what commands I can use. I tried <ctrl-W><Enter> from the KD instructions which is 'Print version information' in cdb and KD and cdb on both the target and the host spat out a lot of stuff about the machines.
Then both left me a prompt as: 0.002>
It's amazing that I have cdb on the host talking to KD on the target but I can't get either wdbg or KD past the 'waiting to reconnect' message. KD has responded to the <cntl> key functions but it's still not connected to the target.
Ah, well, tomorrow is another debugging day. At least i feel better getting that action.
blabberer
March 24th, 2019, 08:32
ctrl+\ is shortcut key for debugging the debugger
another command for it is doing .dbgdbg in the command window
0.002> is an usermode prompt
i am not sure what you have done
kd as far as i know doesn't take a switch set do you mean bcdedit /set ??
if you are using a serial pipe windbg should say
Opened \\.\pipe\dbpipe
Waiting to reconnect...
you say \\.\com so you have an actual serial com port open
and you say your target opened a pipe ??
i cannot decipher it as either heads or tails
here is an overview of how kdcom works by sending packets (from the kdvmware fast debug protocol driver author)
http://articles.sysprogs.org/kdvmware/kdcom/
WaxfordSqueers
March 25th, 2019, 05:51
Quote:
[Originally Posted by blabberer;97661]i am not sure what you have done
kd as far as i know doesn't take a switch set do you mean bcdedit /set ?? |
You have no idea what I've done???...I don't have a clue.
Quote:
[Originally Posted by blabberer;97661]you say \\.\com so you have an actual serial com port open
and you say your target opened a pipe ?? |
I am using a serial cable and bcdedit has set it up as COM2. It was also bcdedit in which I used the /set command.
I seem to have succeeded in opening a .server connection from host as server to target as client.
I started by opening KD in host and got:
Code:
C:\Program Files\Debugging Tools for Windows (x64)>kd
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Opened \\.\COM2
Waiting to reconnect...
Then I entered:
.server
^\
And received:
Code:
Debugger spawned, connect with
"-remote npipe:icfenable,pipe=cdb_pipe,server=xxxx-PC"
xxxx-PC is my user name replace with x's.
***********
It also opened a cdb session as:
Code:
Server started with 'npipe:icfenable,pipe=cdb_pipe'
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
*** wait with pending attach
Symbol search path is: srv*c:\syms*https://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00000001`3f3c0000 00000001`3f443000 C:\Program Files\Debugging Tools
for Windows (x64)\kd.exe
ModLoad: 00000000`776a0000 00000000`7783f000 C:\Windows\SYSTEM32\ntdll.dll
ModLoad: 00000000`77580000 00000000`7769f000 C:\Windows\system32\kernel32.dll
ModLoad: 000007fe`fd300000 000007fe`fd36a000 C:\Windows\system32\KERNELBASE.dl
l
ModLoad: 000007fe`ff250000 000007fe`ff2ef000 C:\Windows\system32\msvcrt.dll
ModLoad: 00000000`739b0000 00000000`73e35000 C:\Program Files\Debugging Tools
for Windows (x64)\dbgeng.dll
ModLoad: 00000000`73810000 00000000`739a6000 C:\Program Files\Debugging Tools
for Windows (x64)\dbghelp.dll
ModLoad: 000007fe`fc310000 000007fe`fc31c000 C:\Windows\system32\VERSION.dll
ModLoad: 000007fe`fd600000 000007fe`fd6db000 C:\Windows\system32\ADVAPI32.dll
ModLoad: 000007fe`ff8d0000 000007fe`ff8ef000 C:\Windows\SYSTEM32\sechost.dll
ModLoad: 000007fe`fe110000 000007fe`fe23d000 C:\Windows\system32\RPCRT4.dll
ModLoad: 00000001`80000000 00000001`8005e000 C:\Windows\system32\guard64.dll
ModLoad: 00000000`77480000 00000000`7757a000 C:\Windows\system32\USER32.dll
ModLoad: 000007fe`fd8c0000 000007fe`fd927000 C:\Windows\system32\GDI32.dll
ModLoad: 000007fe`ff320000 000007fe`ff32e000 C:\Windows\system32\LPK.dll
ModLoad: 000007fe`ff350000 000007fe`ff41b000 C:\Windows\system32\USP10.dll
ModLoad: 000007fe`ff2f0000 000007fe`ff31e000 C:\Windows\system32\IMM32.DLL
ModLoad: 000007fe`fe000000 000007fe`fe109000 C:\Windows\system32\MSCTF.dll
ModLoad: 000007fe`fd1a0000 000007fe`fd1a9000 C:\Windows\system32\fltlib.dll
ModLoad: 000007fe`fd030000 000007fe`fd087000 C:\Windows\system32\apphelp.dll
(9f0.ed0): Break instruction exception - code 80000003 (first chance)
ntdll!DbgBreakPoint:
00000000`7770b1d0 cc int 3
0:002>
****************
In the target, I opened a kd session with kd -kl. I had not noticed that the -kl parameters open kd locally. I had, however, rebooted the target and I don't know if that made a difference.
*******************
Note the first line in the cdb session:
"Server started with 'npipe:icfenable,pipe=cdb_pipe'"
And at the end of the kd session:
"Debugger spawned, connect with
"-remote npipe:icfenable,pipe=cdb_pipe,server=xxxx-PC""
**************
As I said in last post, I took that to mean I should enter that line in target kd session, which I did.
kd target responded with:
Code:
C:\Program Files\Debugging Tools for Windows (x64)>kd -remote npipe:icfenable,pipe=cdb_pipe,server=YOGI-PC
Connected to server with 'npipe:icfenable,pipe=cdb_pipe,server=xxxx-PC'
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
*** wait with pending attach
Symbol search path is: srv*c:\syms*https://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00000001`3f3c0000 00000001`3f443000 C:\Program Files\Debugging Tools for Windows (x64)\kd.exe
ModLoad: 00000000`776a0000 00000000`7783f000 C:\Windows\SYSTEM32\ntdll.dll
ModLoad: 00000000`77580000 00000000`7769f000 C:\Windows\system32\kernel32.dll
ModLoad: 000007fe`fd300000 000007fe`fd36a000 C:\Windows\system32\KERNELBASE.dll
ModLoad: 000007fe`ff250000 000007fe`ff2ef000 C:\Windows\system32\msvcrt.dll
ModLoad: 00000000`739b0000 00000000`73e35000 C:\Program Files\Debugging Tools for Windows (x64)\dbgeng.dll
ModLoad: 00000000`73810000 00000000`739a6000 C:\Program Files\Debugging Tools for Windows (x64)\dbghelp.dll
ModLoad: 000007fe`fc310000 000007fe`fc31c000 C:\Windows\system32\VERSION.dll
ModLoad: 000007fe`fd600000 000007fe`fd6db000 C:\Windows\system32\ADVAPI32.dll
ModLoad: 000007fe`ff8d0000 000007fe`ff8ef000 C:\Windows\SYSTEM32\sechost.dll
ModLoad: 000007fe`fe110000 000007fe`fe23d000 C:\Windows\system32\RPCRT4.dll
ModLoad: 00000001`80000000 00000001`8005e000 C:\Windows\system32\guard64.dll
ModLoad: 00000000`77480000 00000000`7757a000 C:\Windows\system32\USER32.dll
ModLoad: 000007fe`fd8c0000 000007fe`fd927000 C:\Windows\system32\GDI32.dll
ModLoad: 000007fe`ff320000 000007fe`ff32e000 C:\Windows\system32\LPK.dll
ModLoad: 000007fe`ff350000 000007fe`ff41b000 C:\Windows\system32\USP10.dll
ModLoad: 000007fe`ff2f0000 000007fe`ff31e000 C:\Windows\system32\IMM32.DLL
ModLoad: 000007fe`fe000000 000007fe`fe109000 C:\Windows\system32\MSCTF.dll
ModLoad: 000007fe`fd1a0000 000007fe`fd1a9000 C:\Windows\system32\fltlib.dll
ModLoad: 000007fe`fd030000 000007fe`fd087000 C:\Windows\system32\apphelp.dll
(9f0.ed0): Break instruction exception - code 80000003 (first chance)
ntdll!DbgBreakPoint:
00000000`7770b1d0 cc int 3
Live user mode: <Local>
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
command line: 'cdb.exe -server npipe:icfenable,pipe=cdb_pipe -p 2544' Debugger Process 0x166C
dbgeng: image 6.12.0002.633, built Mon Feb 01 12:15:54 2010
[path: C:\Program Files\Debugging Tools for Windows (x64)\dbgeng.dll]
dbghelp: image 6.12.0002.633, built Mon Feb 01 12:15:44 2010
[path: C:\Program Files\Debugging Tools for Windows (x64)\dbghelp.dll]
DIA version: 20921
Extension DLL search Path:
C:\Program Files\Debugging Tools for Windows.....(edited for brevity).
Extension DLL chain:
dbghelp: image 6.12.0002.633, API 6.1.6, built Mon Feb 01 12:15:44 2010
[path: C:\Program Files\Debugging Tools for Windows (x64)\dbghelp.dll]
ext: image 6.12.0002.633, API 1.0.0, built Mon Feb 01 12:15:46 2010
[path: C:\Program Files\Debugging Tools for Windows (x64)\winext\ext.dll]
exts: image 6.12.0002.633, API 1.0.0, built Mon Feb 01 12:15:38 2010
[path: C:\Program Files\Debugging Tools for Windows (x64)\WINXP\exts.dll]
uext: image 6.12.0002.633, API 1.0.0, built Mon Feb 01 12:15:36 2010
[path: C:\Program Files\Debugging Tools for Windows (x64)\winext\uext.dll]
ntsdexts: image 6.1.7650.0, API 1.0.0, built Mon Feb 01 12:15:18 2010
[path: C:\Program Files\Debugging Tools for Windows (x64)\WINXP\ntsdexts.dll]
0:002>
If I go into the cdb window and enter a command, it is echoed in the target KD console.
I don't see much use for that at the moment but it demonstrates I have a serial connection which I may be able to use to figure out why wdbg and kd on the host cannot connect to target.
blabberer
March 25th, 2019, 09:20
there are inconsistencies but ill just note them but not dwell on them
1) when a debugger is waiting to reconnect you cannot enter any commands only shortcut keys work
so i don't know how you managed to enter .server
i can acknowledge being able to type ctrl+\ (or ctrl+alt+\ in newer windbg) which will spawn a parent debugger debugging the current debugger
from which it was spawned
this parent debugger can connect to multiple targets all at once and provides a pipe to do so
you opened a kd -remote this connected to the cdb_pipe (it is a named pipe it is not connecting via com port that is exclusively opened for kd )
the actual comport which has been opened for exclusive access will be banged out in device manager
here is a threeway snapshot just look at titles
3053
or here is a snap shot of full blown session where i detach the first target but leave the pipe communicating
3054
WaxfordSqueers
March 26th, 2019, 06:33
Quote:
| [Originally Posted by blabberer;97663]1) when a debugger is waiting to reconnect you cannot enter any commands only shortcut keys work so i don't know how you managed to enter .server |
I was messing with it, nothing structured but based loosely on the following:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/activating-a-debugging-server
My understanding of a pipe is that it's a software connection but I had previously associated it with a VM. According to this article it can be used if a debugger is opened with an elevated command prompt.
With regard to USB, I read that the kernel connects to the driver stack via a pipe which terminates in an endpoint, which is a buffer in a device. Obviously with two computers there has to be a medium for connecting them and it is likely via the network. I'm not so sure that could not happen via the serial port but I'll pull the network cable to verify that.
I wonder if kdcom.dll can establish a pipe? It's done in a VM, why not over a real serial connection? KD definitely has control of the serial port but it was opened with an elevated cmd prompt and once I entered '.server', then ctrl-\ enter, why could KD not use the serial port, since it is connected to it?
I'll get back to you with more on your reply and thanks again for your patience and effort to explain.
blabberer
March 26th, 2019, 08:13
i cant answer the why i don't understand theory or i rather wouldn't want to
try this and understand for yourself or ask a new question
start->run (win+r) -> cmd.exe -> cd %windbginstallationpath% -> cdb/windbg anybinary -> .cls -> .server npipe: pipe=waxford,icfenable
this will start a server that any clients can connect to with -remote syntax
open another cmd prompt
Code:
type net view and hit enter
get the name of servers running in the network like \\foo-pc
query the debugging server running with
cdb -QR \\name you got from net view
it willl reply
server \\ pipe=pipename (here pipename will be waxford fyi)
connect to the server with
cdb -remote npipe: pipe=waxford ,server="foo-pc"
now you can send any command and it will be executed and the results will be transferred to your screen (cmd.exe console screen)
download
pipelist from sysinternals and run it it will show the waxford pipe's details
Code:
C:\>pipelist | find "wax"
waxford 3 -1
download tcpview from sysinternals and look at epmap port (445)
Code:
process pid proto locadd locport remaddr remport state spkt sbytes rpkt rbytes
System 4 TCPV6 [ipv6addr] 50351 [ipv6addr] 445 ESTABLISHED 23 3,003 24 2,285
or open powershell and query
Code:
C:\>powershell -c "[system.Io.directory]::getfiles('\\.\\pipe\\')" | grep -i wax
\\.\\pipe\\waxford
WaxfordSqueers
March 30th, 2019, 21:05
Quote:
[Originally Posted by blabberer;97666]try this and understand for yourself or ask a new question
|
Sorry I haven't got back, Blabbs, I am embroiled in permission issues on my desktop. Tried to run takeown and icacls on my C: drive and received access denied in Program Files and Windows directories.
Meantime I have tried some of what you suggested in this post with success but not to the extent I need to do it.
With regard to my physical connection, I have set up a serial port debugger on either end
of my serial ports and I am getting good communication both ways. Wdbg is having serious problems and I don't think Microsoft has put much effort into clarifying the problem. I have read extensively on it, even in Microsoft tutorials, and they fail to adequately address the problem.
No one on the Net I have come across has any more than a cursory understanding of this problem. I think that's because no one understands exactly how debugging mode works and there's no way to debug it during boot. At least, there's no way I have read about.
My serial debugger is seeing wndg sending out it's message, which is basically Ascii iiii followed by <ACK> followed by a series of <NULL> bytes. It's waiting for a reply from the debugger but it's receiving nothing. If microsoft were not such a load of twits, they'd have acknowledged receipt of the host wdbg transmission or at least posted an error message to say what is wrong. However, I have yet to encounter an msoft error message that means anything in particular at any time. I have seen them on BSODS and they generally mean very little.
The clue here, I think, is that wdbg becomes frozen while awaiting a reply. There is no way to enter commands. At least with KD, you can enter some commands. I entered '.server' for example followed by <ctrl-\> and got cdb to pop up.
An <ACK> means acknowledge. The iiii in Ascii is 69,69,69,69, which means something in serial control language, but is the <ACK> a request to acknowledge or does it mean it acknowledges something it received? I think it's the former.
Where do these 69s disappear on the other end? I have three different serial apps that see them but not windows debugger.
I recall a method in older Windows OS's, which may still be available, where you could step into windows driver by driver, to see which ones were failing. That's what is required with debug mode, a forced step by step procedure so a person can see what is going on.
I am beginning to think there are issues with Bluetooth drivers, which HP have installed on my laptop. They use COM5 and COM7 but for some reason the drivers are involved with a USB port. I may remove the Bluetooth module.
I wanted to use COM10, well out of the way, and I can enter COM10 on my real serial port and on my USB-Serial converter. Guess what, Wdbg only allows COM1 to COM4. I have tried to force COM10 in wdbg at the command prompt and it has accepted it, but I have not been able to test it yet since I have become embroiled in the permissions issue.
Microsoft networking is actually a horror show dreamed up by a sadistic idiot. They have a group policy client which runs just before logon but there's no way to access it since the group policy editor is not available unless you download a package from Microsoft. If you do, it tells you a domain is required and that means setting up a central computer to deal with the users and related permissions.
I am not talking about gpedit.msc, which is a local policy editor. The group policy client is taking far too long to load and I am thinking maybe windows debugger is timing out due to the delay. I have tried to fix the problem but that requires gpmc.msc, which is the related group policy management console.
The damnable thing is that you can enter gpresult in a cmd shell and it will give you errors in the group policy which can slow down boot time considerably, but you need gpmc.msc to deal with it. When you load gpmc, after downloading the package, it won't let you access local group policy to fix the errors, because you need to be on a domain running active desktop.
Whoever designed this system are raving idiots. They have completely missed the mark, confusing the needs of a home user with the needs of a business with servers, domains and networks.
I tried a network connection with wdbg, following the instruction in a Microsoft tutorial, only to be met with the error message that the debuggee cannot be found. They require only that you select a port in wdbg, suggesting an address above 50,000. I randomly selected 55555. No go. I did everything by the book, entering the requires commands in a cmd shell and received a long key. No debuggee can be found.
A casual home user should not have such issues. It should be dead, stupid simple yet Microsoft have turned it into an IT-weenie horror show. I can't even connect two computers with Telnet due to the anal requirements of Windows permissions over a network.
Unix should have been abandoned 30 years ago but Microsoft is only now beginning to implement Unix openly. That's where all this crap about permissions comes from plus the rocket-science of omitting file extensions that make it immediately clear what kind of file you are examining. In DOS life it is foo.exe, foo.txt. foo.bin, foo.jpg, etc. In Unix it is foo, foo, foo foo, etc., and they are OK with that because they are all weenies.
At this point, you are likely pulling your hair out wondering why I am messing with physical connections. I am doing it basically because hardware is my game and such connections are 'supposed' to be logical. They are far from logical due to intervening issues that Microsoft does not address like firewall issues and their anal, idiotic system of permissions that manage at times to issue 'access denied' error windows requiring administrative rights when I am the administrator.
blabberer
April 4th, 2019, 14:29
sure take your time
go round over one less than thousand times
WaxfordSqueers
April 4th, 2019, 18:36
Quote:
| [Originally Posted by blabberer;97675]sure take your time go round over one less than thousand times |
Question...is there a way for me to set up a debugging session on the target so I can find out why it is not responding to the host?
Learned a trick of which you may be aware. Don't go away it applies to debugging, which I go into after.
You can use the 'Ease of Access' icon at the logon screen as a link to cmd.exe. Therefore, you can start a command window at the logon screen. I have already done that to load drivers.
The Ease of access app is utilman.exe, found in Windows/system32. It is referenced in the registry under HKLM/Software/Microsoft/WindowsNT/CurrentVersion/Image File Execution Options. Under Utilman you find 'Debugger'. It's a matter of changing the Debugger value to cmd.exe, and voila, the Ease of Access icon opens up a command window.
I just tested that by double-clicking Utilman in sys32 and it opened a command window.
I see no evidence that the command window opens with elevated privileges but there is a command line to do that. Thus far, I've had no need for it but this command line should give cmd.exe permanent administrative privileges. Don't know if that is good or bad.
cmd.exe /c takeown /f "%1" && icacls "%1" /grant administrators:F
I just applied that via the Run command and now cmd.exe opens as: Administrator: Command Prompt.
To the question:
Could I run KD from the logon screen using such a cmd window? I tried it at the logon window by pressing 'Ease of Access' icon and KD opens fine in the command window. I used the KD -kl option however.
If I use just KD it gives me error 0n2..."The system cannot find the file specified". That's because I don't know what file I am looking for.
I can play with this, and I will, but you'll know whether or not I'm wasting my time.
I was also able to open windbg at the logon screen. I launched 'Attach to a Process' to see if I could find a process related to debug. I am currently making a list of them and identifying each one with debug off and debug on. Hopefully I can find a process that might get me into the debugging process on the target.
BTW...all this is taking place on the target machine.
blabberer
April 5th, 2019, 02:06
sorry to be a prick but I will outline things once again ( I understand you like hard wares )
download VMware player (free and x64)
download 90 days evaluation version of windows 10 enterprise (1809)
install VMware (all default settings using NAT for network (apipa range local domain and dhcp for internet no serial crap absolutely none)
install windows 10 inside it
create a shared folder in the host and enable shared folder access in VMware (easy way)
copy kdnet.exe / kdmanifestxxxx.xml to the shared folder
copy both of them from shared folder to desktop of VMware
run kdnet from a command prompt it will say if your nic is ok for kd or not
if it is ok
ping 192.168.xxxx
if you get a response from host ( do ipconfig on host and find what the ip is if there are several ping all of them and note which one responds)
do kdnet 192.168.xxxxx 50000 (this will enable the only bootable partition to be debug enabled and set dbgsettings to net debugging)
it will provide you a key
copy it to foo.txt and dump it in shared folder so that access the key in host
open a command prompt in host
c:\xxxxx\windbg.exe -k net
ort=50000 , key=yyyyyyyzzzzzzaaaaaa
it will open a windbg with waiting to reconnect
go to target and in the command prompt that you did kdnet
type
shutdown -r -t 0
when the target restarts your windbg that is waiting for connection will connect to the os and you are ready for kernel debugging
once you do this you can take all the cables screwdrivers nuts and bolts and bang them till they connect with hammers
and I reread the question
no kd -kl is NOT KERNEL DEBUGGING
loosely said it creates dump of the current machine and debugs that dump
it is kind of viewing snapshot of the entire system in a debugger
it is ONCE AGAIN NOT KERNEL DEBUGGING
WaxfordSqueers
April 5th, 2019, 03:34
[Originally Posted by blabberer;97677]sorry to be a prick but I will outline things once again ( I understand you like hard wares )
Oh, be a prick if you want.
I've known you long enough to know your a good guy under it all. I don't blame you, as I said it must be exasperating for you to explain things with a VM and have me persist with the hardware.
Furthermore I remember how you used to carry on about softice, even though Kayaker and I tried to edjumacate you as to the superiority of ice.
I am close to using the VM but this damned hardware should work and I am finding it a major challenge to find out why it does not. I mean, serial ports are dead, stupid simple in the real world and I don't think it's the hardware. I think the problem is Microsoft and their damned permission paranoia.
Why is it no one on the Net understands what's going on? I contacted a guy on a blog who gave me a hint. He told me to try CTL+ALT+D on Windbg and it would give a bit more info, which it did. I actually have Wdbg on the host talking to KD a little bit on the target. I don't think they know they are talking to each other but they are responding to commands like .restart over the serial port.
[Originally Posted by blabberer;97677]kd -kl is NOT KERNEL DEBUGGING
I knew that!!!
I have been entering KD by itself on the target and it sits there after opening \\.\COM2 and whine's the same as wdbg on the host that it's waiting to reconnect. I have also used KD -t, and KD -k comm:Port=COM2, Baud=115200.
However, while in one of the instances with KD on the target I entered .restart and it sent a message to wdbg on the host. The host was spitting out the 'wait for type 7 packet' and 'timeout' when suddenly the target sent back the message about packet 6 and the host acknowledged it.
It seems to have received a reset.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
PacketType=6, ByteCount=0, PacketId=0,
READ: Recieved KD_RESET packetThrottle 0x10 write to 0x1
, send KD_RESET ACK packet
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
[QUOTE][Originally Posted by blabberer;97677]download VMware player (free and x64)
download 90 days evaluation version of windows 10 enterprise (1809)[/CODE]
I already have VMWare Player 15 running on both W7 and W10 on the desktop and W7 on the laptop. I have my own version of W10 from when they were giving it away free.
In fact, I have a copy running on a separate drive but I'm not sure if I could clone it onto a VM disk.
I have already done much of the setup you describe on my real computer and got the key. I'll try it with the VM. I'm not that far away from using the VM.
WaxfordSqueers
April 6th, 2019, 01:52
@blabberer....found a good use for kd -kl
The -kl command line works only when the computer is in debug mode. Makes sense, if you are debugging locally you should be in debug mode.
With kd open under -kl, you can use debugger extensions to examine various aspects of the machine. The extension usb3kd.dll allows you to examine aspects of USB. The extensions are in the winext dir of the address below in x64 directory.
You are probably aware of that already.
I wonder if an extension is available for the serial port?
WaxfordSqueers
April 6th, 2019, 03:38
@blabbs
Question. Is there a way to control the output of the screen to one page at a time in kd?
For example, if I enter !process 0 0 there is so much data scrolling by that by the time it stops I have lost much of the starting procs. I tried adjusting the buffer size for history in the cmd window but no go.
It just occurred to me that powershell might work better.
**************
Answering my own question, yes it does. Powershell lists them all.
blabberer
April 6th, 2019, 14:48
-kl switch is applicable to windbg also and it has a much much bigger screen buffer
use windbg -kl with all your windows in full glory
if you dont want to enable debug swich in bcdedit download livekd from sysinternals and use livekd -k pathtowindbg.exe
this will be equivalent to kd -kl but without debug switch in bcdedit
edit
you can start the session with logging enabled -logo
or start logging to a file all you do in an open session with .logopen command
this will dump everything to a file that is if you have a marathon 40 hour session you can have all the crap logged to a file that you can refer to
right from the first minute
WaxfordSqueers
April 6th, 2019, 20:31
Quote:
| [Originally Posted by blabberer;97681]-kl switch is applicable to windbg also and it has a much much bigger screen buffer use windbg -kl with all your windows in full glory |
Thanks for info. I have no particular interest in the -kl switch but I came across an article by Microsoft on local kernel debugging in which they explained that the -kl switch worked only in debug mode.
I found it interesting that I could start wdbg with the -kl switch and get an immediate command prompt where I could enter commands like !process 0 0. Till then, the only way I knew of doing that was to load an app like notepad.
I discovered the -kl usage with windbg just after sending the past couple of messages and the !process 0 0 puts out a humungous amount of process and thread information. I was looking for a reference to the debugging mode session, especially for reference to kdcom.dll, which is apparently reliant on debugging extensions.
I can see how this will be very useful when applied to my USB driver stack problem between W10 and W7, using the USB extensions to locate breakpoints and so on.
I am curious as to whether kdcom.dll is an actual extension like those used in the debugger directory under winext. I'd like to have a serial extension like the USB extension I discovered that can spit out information about the USB stack.
My current interest is in using my serial problem to learn more about windbg and how it works. I would really like to dig into the debug target engine to see what is going on, while learning how to use windbg and kd effectively.
I read in an article that it is possible to set breakpoints in Windows drivers as it is booting and cut into the boot process. I can't imagine what kind of setup would allow that.
I was just reading about switching contexts in kd/wdbg. I recall with sice that you had to switch into the K32 context to set BPs but you could list the loaded modules using the 'table' command. Is there a similar command in kd/wdbg?
!process lists process and their threads but I'm looking to find the likes of ntoskrnl and its threads.
blabberer
April 8th, 2019, 14:44
kdcom.dll is not an extension as in windbg extension it is a native mode dll and is part of Operating System your os will not boot if it misses kdcom.dll
it imports from ntos and hal and exports debugging related functions like sending and receiving packets
you proabablyu have some misconceptions
you will never be able to find ntoskrnl and its threads ntoskrnl is not a process it is a part of os nothing will exist if there is no ntoskrnl
ntos does not /will not / cannot / have any threads
it is THE kernel module that implements all major functionality of Operating System
yes windbg can debug boot stage
you need to enable boot debugging
here is a break using sxe ibp this happens before any of the process has been started yet
not even system process has been started yet
it is at a place where BOOT OPTIONS are being checked and you can see kdcom
has been loaded this early along with ntos and hal
Code:
kd> r
eax=00000001 ebx=00000000 ecx=8080a188 edx=8293badc esi=8080a198 edi=00000029
eip=82bb15c8 esp=8293bb00 ebp=8293bca4 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00200202
nt!InitBootProcessor+0x3d0: <<<<<<
82bb15c8 8a4174 mov al,byte ptr [ecx+74h] ds:0023:8080a1fc=00
kd> dx ( nt!_LOADER_PARAMETER_BLOCK *) @ecx
( nt!_LOADER_PARAMETER_BLOCK *) @ecx : 0x8080a188 [Type: _LOADER_PARAMETER_BLOCK *]
[+0x000] OsMajorVersion : 0x6 [Type: unsigned long]
[+0x004] OsMinorVersion : 0x1 [Type: unsigned long]
[+0x008] Size : 0x88 [Type: unsigned long]
[+0x00c] Reserved : 0x0 [Type: unsigned long]
[+0x010] LoadOrderListHead [Type: _LIST_ENTRY]
[+0x018] MemoryDescriptorListHead [Type: _LIST_ENTRY]
[+0x020] BootDriverListHead [Type: _LIST_ENTRY]
[+0x028] KernelStack : 0x8293c000 [Type: unsigned long]
[+0x02c] Prcb : 0x0 [Type: unsigned long]
[+0x030] Process : 0x0 [Type: unsigned long]
[+0x034] Thread : 0x82948340 [Type: unsigned long]
[+0x038] RegistryLength : 0x8c0000 [Type: unsigned long]
[+0x03c] RegistryBase : 0x81c05000 [Type: void *]
[+0x040] ConfigurationRoot : 0x8080a2b0 [Type: _CONFIGURATION_COMPONENT_DATA *]
[+0x044] ArcBootDeviceName : 0x80831380 : "multi(0)disk(0)rdisk(0)partition(2)" [Type: char *]
[+0x048] ArcHalDeviceName : 0x808311c8 : "multi(0)disk(0)rdisk(0)partition(1)" [Type: char *]
[+0x04c] NtBootPathName : 0x80827e70 : "\Windows\" [Type: char *]
[+0x050] NtHalPathName : 0x80814c98 : "\" [Type: char *]
[+0x054] LoadOptions : 0x80813080 : " BOOTDEBUG NOEXECUTE=OPTOUT DEBUGPORT=COM1 BAUDRATE=115200 DEBUG" [Type: char *]
[+0x058] NlsData : 0x808d33e0 [Type: _NLS_DATA_BLOCK *]
[+0x05c] ArcDiskInformation : 0x808180e8 [Type: _ARC_DISK_INFORMATION *]
[+0x060] OemFontFile : 0x838e41d0 [Type: void *]
[+0x064] Extension : 0x808313b8 [Type: _LOADER_PARAMETER_EXTENSION *]
[+0x068] u [Type: <unnamed-tag>]
[+0x074] FirmwareInformation [Type: _FIRMWARE_INFORMATION_LOADER_BLOCK]
kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
NULL value in PsActiveProcess List
kd> lm
start end module name
80b9c000 80ba4000 kdcom (deferred)
8281c000 82c20000 nt (pdb symbols) e:\symbols\ntkrnlmp.pdb\00625D7D36754CBEBA4533BA9A0F3FE22\ntkrnlmp.pdb
82c20000 82c48000 hal (deferred)
WaxfordSqueers
April 8th, 2019, 20:24
Quote:
[Originally Posted by blabberer;97684]kdcom.dll is not an extension as in windbg extension it is a native mode dll and is part of Operating System your os will not boot if it misses kdcom.dll
it imports from ntos and hal and exports debugging related functions like sending and receiving packets
you proabablyu have some misconceptions |
It's safe to say that I have a whole lot of misconceptions.
My understanding from reading Microsoft is that kdcom.dll is part of a trio. For a serial connection, kdcom is the man. For a firewire connection, kd1392.dll is the man and for a USB connection, kdusb.dll is the man.
They said nothing about kdcom doubling as a serial comm dll and a general packet go-between. However, since serial comm predated 1392 and USB by a significant degree, maybe it has been there all along with 1392 and usb being new kids on the block.
I have spent the last day or so studying the Intel Management system. Both my mobos, host and target, are Intel based and I can have both engines talking to each other. I had not realized till recently that the Intel engine is chip based, it's like a parallel processing system and a feature of interest is SOL, serial over LAN.
Apparently, the management engine can run without an OS loaded, which is interesting. That should mean serial comm is available before Windows loads, and hopefully during the boot phase.
However, while dabbling with such systems, the best laid plans of men and mice, aft gang aglay. While trying to get SOL going in Win10, I get an error message that it cannot start due to a lack of system resources.
WHAT!!!! Win10 with a lack of system resources!!!????. Apparently the rocket scientists at msoft have failed to address the issue of serial comm being traditionally on IRQ 3 and 4 only. Both my serial ports are already using those IRQs and although the INF file on my W7 allows for SOL allows for a wide range of IRQs, including 'any'. W10 has omitted that section from the INF file for SOL.
I never thought I'd see the day again where I had to juggle hardware IRQs and address ranges.
Quote:
[Originally Posted by blabberer;97684]here is a break using sxe ibp this happens before any of the process has been started yet
not even system process has been started yet
it is at a place where BOOT OPTIONS are being checked and you can see kdcom
has been loaded this early along with ntos and hal |
That's interesting. Where are you running wdbg/kd from? I told you about my cmd prompt running off an ease of access icon at logon but I wonder if there is a way to load wdbg/kd from a breakpoint in kdcom, maybe when it loads after ntoskrnl.
WaxfordSqueers
April 10th, 2019, 02:02
@blabberer
Success!!!
Established a net connection with wdbg between W7 laptop as host and W10 as target.
Did not expect it to break so early in the target boot. It broke before the boot screen where I select W10 or W7.
Practiced a few commands. Listed the modules and loaded symbols for modules like usbxhci, usbhub3, etc., that were deferred.
At the moment, don't really know where to go from here. When it first broke, there were only 3 modules loaded. I did not catch their names. By the time the target ran to the boot select window where I select W10, most of the modules were loaded.
Too late tonight, tomorrow is another day.
blabberer
April 11th, 2019, 03:55
congratulations
welcome to the club
as they say it is never late for old dogs to learn new tricks
WaxfordSqueers
April 11th, 2019, 21:25
Quote:
[Originally Posted by blabberer;97687]congratulations welcome to the club
as they say it is never late for old dogs to learn new tricks |
Arf!! Arf!!
Took a couple of days off. Wore myself out with the number of hour (weeks???) of futility encountered trying to establish a connection.
The Net connection was far from easy to solve. The host was indicating no debuggee present but I had a good Net connection between computers over which I could transfer files in either direction. On my system, my laptop is the host and connects to the router via wifi, running W7 SP1. The Target machine is a desktop running a dual booted system of W7 and W10. They are connected via a LAN CAT5 cable using RJ-45 connectors. Currently, I am using W10 as the debuggee (target).
When windbg was put into kernel debugging mode on the host, I could not get a connection.
Ran ipconfig /all on each machine and noted the IP4 address, marked 'preferred' on each Ethernet adapter section. I could not ping either of them from either machine. The command is ping -4 <address>, where <address> is the 192.168.xxx.xxx address noted for IP4 in the ipconfig listing of the machine you wish to ping. The -4 tells ping to look for an IP4 network connection.
Used 'arp -a' command to list networks available and their MAC address. The MAC address will identify the physical device connected, if you can find the MAC address. Some physical units have it marked on a label on the device. Could not see the IP4 address of either machine when arping from one to the other, even though I could transfer files fine under windows explorer under the Network folder.
Turns out that on my W10 network end the IP4 connection had reverted to the default connection, which gets it's IP address from the DHCP server. So, I went into Networks and Sharing under the 'change adapter settings' on each machine. On the host, it's ok to allow the IP4 connection to get it's IP address from the DHCP server since the server is at the router.
The router address on mine is 192.168.0.1 and that is also the default gateway. On the target, however, it can't use that default address if it is connecting to the Net over the the host wireless connection as on mine.
It's a two hat job. You have to put on your wireless hat when dealing with the wifi connection to the router, then onward to the Internet provider. When you deal with the network (LAN) you have to change hats and put on your LAN hat. On my host, there is a 'bridge' connection under 'change adapter settings' and it bridges the LAN connection from the target computer to the wifi on the host. Using that bridge, I get an Internet wifi connection on my target machine.
OK. I don't need a wifi connection on the target, I just need a LAN connection between host and target and over a certain port, which I chose as 55555. Microsoft recommends 50000 or so, but my addresses looked busy around there as revealed by my firewall activity manager. To establish the LAN connection I need the target to have it's own unique network address. If I let it set itself up to get addresses from the DHCP server, it will often use an address in the 169.xxx.xxx.xxx range which comes from outside.
It appears at one time that I had selected an address in range of my default gateway at 192.168.0.1 In ipconfig it was listed as 192.168.0.1XX. So I went into Network and Sharing/change adapter settings/Local Area Connection x, where x is the number of the LAN connection in use.
BTW...two other excellent network troubleshooting commands for a command window are 'netstat', which lists all IPs on a machine and the ports used by each, and 'route'. The latter is a complex command to use but you can use it to rebuild your entire network on a machine if it ever gets corrupted.
On the target, I right-clicked on the connection under 'change adapter settings', and found the IP4 entry in the lower table. I highlighted the IP4 connection and selected 'properties'. The IP4 connection was configured to 'obtain an IP address automatically', and that was the problem.
I clicked the radio button below to select 'Use the following IP address'. Then I entered my old 'static' IP4 address from ipconfig /all. If it is listed as a 169.xxx.xxx.xxx IP address it won't do, it has to start with 192.168.xxx.xxx. The 169.xxx.xxx.xxx IP address comes from a DHCP server via the router. DCHP addresses are dynamic, they change all the time. You want a static address which is fixed for the target machine and it will be configured as 192.168.xxx.xxx.
You can pretty well select any IP address between 192.168.0.1 to 192.168.0.255 as long as it does not conflict with the default gateway IP or other LAN IPs in that range. Some routers don't use 192.168.0.1 as a default gateway, so it's necessary to find out what a particular router is using. Sometimes it's written on a label on the router, or in the manual.
Anyway, I entered 192.168.0.xxx from my ipconfig /all listing and Windows complained it was for an old device and may cause a conflict. I knew that device was no longer there so I told it to accept that address. The moment it did, I was able to ping the IP4 address listed on either machine from either machine. And running arp -a on either machine listed those addresses as now being part of the network.
After that, windbg was happy. I might add that when setting up the 'Use this IP address' in the IP4 properties, that the config window shows an entry for 'subnet mask' and 'default gateway'. The subnet mask is configured by the system the moment you hit 'Enter' for the chosen static IP address. It will be something like 255.255.255.0. For the default gateway I chose the base IP address for my router, which is 192.168.0.1
Below that, in another window, are the DNS entries. You can leave that stock but I use 8.8.8.8 and 8.8.4.4, which I think is the Google DNS server. A DNS server changes an address like www.google.com to an numerical IP address like xxx.xxx.xxx.xxx.
Below the NS window is an Advanced button. It opens in a Window with three tabs, one of them marked 'WINS'. At the bottom of the WINS window are setting for Netbios. They advise you to use the middle one for static IPs, 'Enable Netbios over TCP/IP. I use that one.
BTW...Microsoft advises not to leave a machine in debug mode. I have no choice. With W10 in debug mode as target, it takes forever to load. I have heard that is normal with kernel debugging. I had to go into a cmd window and set bcdedit /debug off to get W10 back to a normal boot speed.
WaxfordSqueers
April 17th, 2019, 22:36
Quote:
[Originally Posted by WaxfordSqueers;97686]@blabberer
Success!!! |
More success
Established a serial connection from W7 laptop as host to W7 target. I could have gone the VM route and I am going to explore it, but I could not use the physical net (LAN) connection because W8 and higher is required. The VM debugging technique will allow me to examine the W7 USB driver stack but it won't allow me to do that with my motherboard running the target OS. I may need that ability to see why my B360 chipset is not running W7 with USB 3 support.
The problem seemed to lie in my dual-boot configuration. I have W7 dual booted with W10 but had been using the W7 boot loader. I had not used W10 for a while but I noticed when I did use it W10 imposed it's own bootloader.
Decided to try my serial connection again and I setup W7 in debug mode with W10 debug off. When I rebooted the target, however, it ran into the W10 boot loader screen and on a whim I selected the Advanced options and forced debug mode from there. I also selected W7 as the default OS.
When I rebooted, it ran to the W10 logon screen at first (of course it would...I'd just selected debug mode for W10), which annoyed me, but the host wdbg indicated the debuggee running. I rebooted from W10 logon screen and when it started it was back in the old W7 boot loader with W7 marked in debug mode. So I selected W7 and it happily ran through logon to the desktop, whence I hit ctrl-break in the host and it broke on W7.
Seems there is something related to the W10 boot loader that enables serial debugging mode whereas the W7 boot loader route does not. In the future, I may have to boot with the W10 boot loader and repeat the process.
Here's the initial startup dialog. You can see the break where the host indicated it was shutting down. It started indicating W10 then after the shutdown it indicated W7.
Quote:
Microsoft (R) Windows Debugger Version 10.0.17763.132 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Opened \\.\com2
Waiting to reconnect...
Connected to Windows 10 17763 x64 target at (Wed Apr 17 19:31:17.449 2019 (UTC - 7:00)), ptr64 TRUE
Kernel Debugger connection established.
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*c:\syms*http://msdl.microsoft.com/download/symbols
Deferred srv*c:\syms*https://msdl.microsoft.com/download/symbols
Symbol search path is: srv*c:\syms*http://msdl.microsoft.com/download/symbols;srv*c:\syms*https://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 10 Kernel Version 17763 MP (1 procs) Free x64
Built by: 17763.1.amd64fre.rs5_release.180914-1434
Machine Name:
Kernel base = 0xfffff804`096af000 PsLoadedModuleList = 0xfffff804`09aca790
System Uptime: 0 days 0:00:00.000
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
* *
* You are seeing this message because you pressed either *
* CTRL+C (if you run console kernel debugger) or, *
* CTRL+BREAK (if you run GUI kernel debugger), *
* on your debugger machine's keyboard. *
* *
* THIS IS NOT A BUG OR A SYSTEM CRASH *
* *
* If you did not intend to break into the debugger, press the "g" key, then *
* press the "Enter" key now. This message might immediately reappear. If it *
* does, press "g" and "Enter" again. *
* *
*******************************************************************************
nt!DbgBreakPointWithStatus:
fffff804`0986a390 cc int 3
kd> g
KDTARGET: Refreshing KD connection
nvLDDMkm: Driver Registry Path = '\REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\nvlddmkm'
nvAdapter: Device Registry Path = '\REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000'
nvAdapter:
nvAdapter: ***** CNvLAdapter* ffff9e8efe9c4000 -> DriverModel is 0x2300 ******
nvAdapter:
Shutdown occurred at (Wed Apr 17 19:37:04.035 2019 (UTC - 7:00))...unloading all symbol tables.
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*c:\syms*http://msdl.microsoft.com/download/symbols
Deferred srv*c:\syms*https://msdl.microsoft.com/download/symbols
Waiting to reconnect...
Connected to Windows 7 7601 x64 target at (Wed Apr 17 19:37:33.784 2019 (UTC - 7:00)), ptr64 TRUE
Kernel Debugger connection established.
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*c:\syms*http://msdl.microsoft.com/download/symbols
Deferred srv*c:\syms*https://msdl.microsoft.com/download/symbols
Symbol search path is: srv*c:\syms*http://msdl.microsoft.com/download/symbols;srv*c:\syms*https://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 MP (1 procs) Free x64
Built by: 7601.24387.amd64fre.win7sp1
Machine Name:
Kernel base = 0xfffff800`03e4e000 PsLoadedModuleList = 0xfffff800`04087c90
System Uptime: not available
nvLDDMkm: Driver Registry Path = '\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\nvlddmkm'
KDTARGET: Refreshing KD connection
nvAdapter: Device Registry Path = '\REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\CLASS\{4D36E968-E325-11CE-BFC1-08002BE10318}\0001'
nvAdapter:
nvAdapter: ***** CNvLAdapter* fffffa800df31000 -> DriverModel is 0x1100 ******
nvAdapter:
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
* *
* You are seeing this message because you pressed either *
* CTRL+C (if you run console kernel debugger) or, *
* CTRL+BREAK (if you run GUI kernel debugger), *
* on your debugger machine's keyboard. *
* *
* THIS IS NOT A BUG OR A SYSTEM CRASH *
* *
* If you did not intend to break into the debugger, press the "g" key, then *
* press the "Enter" key now. This message might immediately reappear. If it *
* does, press "g" and "Enter" again. *
* *
*******************************************************************************
nt!DbgBreakPointWithStatus:
fffff800`03ee8400 cc int 3
0: kd>
|
WaxfordSqueers
April 24th, 2019, 20:12
I have been busy checking out the various modes of windbg. Feeling more comfortable with it now that I am getting onto customizing the workspace.
Stumbled across this interesting means of getting from the wdbg bp for an app just loaded through the load executable menu. wdbg stops the app in system code and entering
U $exentry
lists the OEP of app being loaded. In my case, I bp'd on the address supplied and when I hit G, it stopped right at the app entry point.
One issue I have yet to solve is how to quickly determine the context of the code in which I am tracing. In my current setup, I can tell I am in the current thread only by the address and call addresses supplied by wdbg with the app name prepended. However, when a system call is made, it's not always obvious which part is being called.
I have figured out how to open memory windows for esi, edi and eax (in 32 bit mode).
Right now I am examining a setup file for loading USB drivers. It's interesting how often it uses CPUID and I am getting an education in identifying processors by the CPUID return values. I am just using the 32 bit wdbg version since the setup file is 32 bit. At one point it compares values returned in eax to hard coded values representing different processors. I have identified the codes against certain processors and it is a bit-wise code with each bit or set of bits representing processor features.
I know ultimately the app is checking for 6th generation Intel processors but as yet I don't know if it is rejecting newer processors. I have to determine the reason for using several different cmp instructions with jumps to different areas of the code.
Worked out the USB 2 and 3 stacks basically as to the theory. Next I need to examine the structures in wdbg to get a deeper meaning of how the drivers/devices interact.
I do know this, My usbxhci driver for the host controller has not been supplied a PDO by the PCI bus driver. It has been enumerated and loaded in memory but without the PDO it cannot load the hub driver in the USB stack. If the hub driver doesn't load, the USB ports can't be connected to the hub.
WaxfordSqueers
April 25th, 2019, 03:44
Is there no way to attach to an application on the target, or start it remotely, with full kernel debugging power, from a host computer?
If I run !process 0 0, I can see the target app but it seems I cannot attach to it remotely.
Am I missing something or is that not allowed with remote kernel debugging?
blabberer
April 25th, 2019, 14:39
host
sxe ld foo.exe
g
target double click foo.exe
windbg will break on loading the exe
reload symbols
set process specific breaks as reqd bp /p {eproc } [module!symbol]
btw keep in mind sxe ld will work only once per boot for one specific binary
WaxfordSqueers
April 25th, 2019, 21:45
Quote:
| [Originally Posted by blabberer;97694]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.
WaxfordSqueers
April 26th, 2019, 20:23
Quote:
[Originally Posted by blabberer;97694]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> .
Quote:
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. |
Kayaker
April 26th, 2019, 23:22
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
WaxfordSqueers
April 27th, 2019, 01:13
Quote:
| [Originally Posted by Kayaker;97697]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.
Kayaker
April 28th, 2019, 22:18
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."
WaxfordSqueers
April 29th, 2019, 00:57
Quote:
| [Originally Posted by Kayaker;97699]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;97699]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.
WaxfordSqueers
April 29th, 2019, 22:16
@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.
Quote:
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. |
Kayaker
April 30th, 2019, 15:58
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.
WaxfordSqueers
April 30th, 2019, 19:23
Quote:
[Originally Posted by Kayaker;97702]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.
WaxfordSqueers
May 7th, 2019, 20:09
@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.
Quote:
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 |
Kayaker
May 8th, 2019, 00:10
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.)
WaxfordSqueers
May 9th, 2019, 05:08
@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:
Quote:
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:
Quote:
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.
Kayaker
May 10th, 2019, 21:13
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)
WaxfordSqueers
May 11th, 2019, 01:41
Quote:
| [Originally Posted by Kayaker;97707]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.
Kayaker
May 11th, 2019, 14:51
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.
WaxfordSqueers
May 11th, 2019, 23:16
Quote:
| [Originally Posted by Kayaker;97709]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. |
Heh!!!
No trick of mine it all comes down to the code snippet to break on a message box OK button.
Quote:
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
|
I could not get the extension sdbgext to work in w64 therefore could not employ the !hwnd poi(poi(esp+4)). However, the bp user32!GetMessageW "pt;gc" got me right into the message loop for windows and it was retrieving messages from Device Manager (I presume devmgr.dll).
I know the message loop processes all messages from user apps but when I was there it was processing only device manager windows messages. Many of them we 0xf messages for wm_paint.
I guess because I was in the context for Device Manager when I activated the OK button, windows must have retrieved the message. It was a 32770 dialog box.
https://docs.microsoft.com/en-us/windows/desktop/winmsg/about-window-classes
I may be all wet but it is my understanding that the window's message loop uses getmessagew and that it is a system thing. It processes any windows message and passes it on to the calling application.
Looked it up:
https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-getmessagew
Quote:
GetMessageW function
Retrieves a message from the calling thread's message queue. The function dispatches incoming sent messages until a posted message is available for retrieval. |
Kayaker
May 12th, 2019, 00:26
I guess you found a message loop at some level, a system wide message queue? I didn't think that breakpoint would work if the API wasn't called as an import in what seemed to be the main code processes. The stack might clear up exactly what code you're sitting in.
I believe breakpoints should be process specific with this format.
r $proc
.process
bp /p @$proc user32!GetMessageW
WaxfordSqueers
May 12th, 2019, 01:47
kayaker...here's how to reproduce:
-control panel\device manager
-in devmgr go to top of tree at user name, right click and select Install Legacy Hardware.
-hit 'next' and on next window choose to install manually.
-next window is Add Hardware window. I go down to USB and select an Intel USB 3 host controller driver.
-select driver then 'Have Disk'. Find driver in that set of Intel drivers to which I linked earlier.
-a 32770 dialog box opens with OK button.
-open windbg as Administrator.
-select 'Attach to Process'
-look down list for mmc then select it.
-windbg opens mmc.
-break (not really sure if I used break)
-I run .reload force /f
-trick here is to arrange windows so that the mouse can be placed over the OK button on dev manager 32770 box. Once you set bp user32!getmessagew it will break on even a mouse movement.
-enter bp user32!getmessagew in wdbg and hit 'enter'
-very carefully go to mouse and do a left click. Dev manager window should break up and wdbg should break at 77539e54 push rebx
-a few lines below there is an official call to user32!getmessagew+0x1b
Tracing a few steps reveals hwnd of "Device Manager" MMCMainFrame in rsi.
Tracing blindly a lot further there is a call to mmc!CSubclassManager::SubClasProc
The call is at 77539bb6 in user32!UserCallWinProcCheckWow+0x1ad and the mmcfunc is at ff4f2474. IDA shows the func at .text:01009DAF.
stack:
Quote:
# Child-SP RetAddr Call Site
00 00000000`0018cc18 000007fe`fb955925 USER32!GetMessageW
01 00000000`0018cc20 000007fe`fb955cfd Comctl32!_RealPropertySheet+0x309
02 00000000`0018ccf0 000007fe`e61a8b15 Comctl32!_PropertySheet+0x55
03 00000000`0018cd30 000007fe`e61a2204 hdwwiz!PropertySheetW+0x55
04 00000000`0018cd60 000007fe`ee213a94 hdwwiz!AddHardwareWizard+0x130
05 00000000`0018d8f0 000007fe`ee2131d7 devmgr!CResultView::MenuCommand+0x2e0
06 00000000`0018d950 000007fe`ee20fb2a devmgr!CFolder::MenuCommand+0xab
07 00000000`0018d980 000007fe`e4b71a33 devmgr!CComponent::Command+0x92
08 00000000`0018d9e0 000007fe`e4abbc6f mmcndmgr!IExtendContextMenuWrapper::Command+0xeb
09 00000000`0018db20 000007fe`e4a9d260 mmcndmgr!CMenuItem::ScExecute+0x367
0a 00000000`0018dbe0 000007fe`e4a9ca90 mmcndmgr!CContextMenu::ExecuteMenuItem+0xd4
0b 00000000`0018dc50 000007fe`e4a9c840 mmcndmgr!CContextMenu::ShowContextMenuEx+0x244
0c 00000000`0018dd40 000007fe`e4a98e20 mmcndmgr!CContextMenu::ShowContextMenu+0x20
0d 00000000`0018dd90 000007fe`e4b7e023 mmcndmgr!CNodeInitObject::ShowContextMenu+0x128
0e 00000000`0018de10 000007fe`ee214dfb mmcndmgr!NodeInitObjectWrapper::IContextMenuProviderWrapper::ShowContextMenu+0xbf
0f 00000000`0018df30 000007fe`ee20b4aa devmgr!CResultView:oContextMenu+0x1c7
10 00000000`0018dfd0 000007fe`ee20880a devmgr!CResultView::tvNotify+0xdd
11 00000000`0018e000 000007fe`ee208134 devmgr!CFolder::tvNotify+0x26
12 00000000`0018e040 000007fe`e6503dfe devmgr!CComponent::tvNotify+0x58
13 00000000`0018e080 000007fe`e5f90c4a dmocx!CTVCtrl::OnContextMenu+0x82 |
Code:
Code:
USER32!GetMessageW:
00000000`77539e54 fff3 push rbx
00000000`77539e56 4883ec20 sub rsp,20h
00000000`77539e5a 418bc0 mov eax,r8d
00000000`77539e5d 488bd9 mov rbx,rcx
00000000`77539e60 b90000feff mov ecx,0FFFE0000h
00000000`77539e65 410bc1 or eax,r9d
00000000`77539e68 458bd1 mov r10d,r9d
00000000`77539e6b 85c1 test ecx,eax
00000000`77539e6d 0f85678d0100 jne USER32!GetMessageW+0x1b (00000000`77552bda)
00000000`77539e73 458bca mov r9d,r10d
00000000`77539e76 488bcb mov rcx,rbx
00000000`77539e79 e8c2ffffff call USER32!NtUserGetMessage (00000000`77539e40)
00000000`77539e7e 817b0802010000 cmp dword ptr [rbx+8],102h
00000000`77539e85 448bd0 mov r10d,eax
00000000`77539e88 0f844e480000 je USER32!GetMessageW+0x49 (00000000`7753e6dc)
00000000`77539e8e 817b08cc000000 cmp dword ptr [rbx+8],0CCh
00000000`77539e95 0f8441480000 je USER32!GetMessageW+0x49 (00000000`7753e6dc)
00000000`77539e9b 418bc2 mov eax,r10d
00000000`77539e9e 4883c420 add rsp,20h
00000000`77539ea2 5b pop rbx
00000000`77539ea3 c3 ret
WaxfordSqueers
May 12th, 2019, 22:18
kayaker....there is a reply just before this one.
Trying to repeat my last process in wdbg u-mode in remote kernel debugging. No success thus far. Below is a list of U-mode processes from my host. You can see mmc.exe listed along with devmgr.dll and hdwwiz, a reference to the Hardware Wizard window. Although they show symbols as being deferred, I have managed to load symbols for all of them using the ld command.
There seems to be no communication whatsoever between host and any u-mode apps. Whereas that may be by design, if it is the case, it pretty well renders wdbg useless as a debugger other than for drivers.
My overall impression is that wdbg gives loads of information about windows features but it's not even half the debugger of softice. I could go anywhere in ring 0 with sice but I have yet to get beyond ntdll with wdbg. There was no need for remote debugging with sice, it could all be done on the same computer, and powerfully.
Hope I am wrong.
Quote:
0: kd> lm u
start end module name
00000000`022c0000 00000000`022c4000 api_ms_win_downlevel_shlwapi_l1_1_0 (deferred)
00000000`02620000 00000000`02acc000 WININET (deferred)
00000000`052f0000 00000000`0532b000 WINTRUST (deferred)
00000000`73c60000 00000000`73c98000 odbcint (deferred)
00000000`77420000 00000000`7751a000 USER32 (pdb symbols) c:\websymbols\user32.pdb\9A43D3FD584F4A9698B7AB8D28BC8C502\user32.pdb
00000000`77520000 00000000`7763f000 kernel32 (deferred)
00000000`77640000 00000000`777df000 ntdll (pdb symbols) c:\websymbols\ntdll.pdb\15FC8206E55A4725A768F3033BB4C9201\ntdll.pdb
00000000`777e0000 00000000`777e3000 normaliz (deferred)
00000000`777f0000 00000000`777f7000 PSAPI (deferred)
00000000`ffc20000 00000000`ffe30000 mmc (deferred)
000007fe`e3a00000 000007fe`e3d14000 mmcndmgr (deferred)
000007fe`e42c0000 000007fe`e4397000 SearchFolder (deferred)
000007fe`e4650000 000007fe`e47a0000 MFC42u (deferred)
000007fe`e47c0000 000007fe`e47fb000 mlang (deferred)
000007fe`e4800000 000007fe`e4883000 devmgr (deferred)
000007fe`e4890000 000007fe`e48ea000 mmcbase (deferred)
000007fe`e4b90000 000007fe`e4baf000 thumbcache (deferred)
000007fe`e4bb0000 000007fe`e4c2b000 StructuredQuery (deferred)
000007fe`e6de0000 000007fe`e6df1000 dmocx (deferred)
000007fe`e7180000 000007fe`e71bf000 hdwwiz (deferred)
000007fe`e71c0000 000007fe`e7211000 newdev (deferred)
000007fe`e7610000 000007fe`e76ca000 ieproxy (deferred)
000007fe`e7920000 000007fe`e7924000 api_ms_win_downlevel_shlwapi_l2_1_0 (deferred)
000007fe`e8e80000 000007fe`e8f31000 ODBC32 (deferred)
000007fe`e91e0000 000007fe`ea07a000 ieframe (deferred)
000007fe`ea150000 000007fe`ea154000 api_ms_win_downlevel_shell32_l1_1_0 (deferred)
000007fe`ea180000 000007fe`ea355000 msxml3 (deferred)
000007fe`eeff0000 000007fe`ef024000 SHDOCVW (deferred)
000007fe`ef330000 000007fe`ef41e000 actxprxy (deferred)
000007fe`f6e10000 000007fe`f6e74000 webio (deferred)
000007fe`f6e80000 000007fe`f6ef1000 WINHTTP (deferred)
000007fe`f7610000 000007fe`f7614000 api_ms_win_downlevel_advapi32_l2_1_0 (deferred)
000007fe`f7710000 000007fe`f7718000 IconCodecService (deferred)
000007fe`f7720000 000007fe`f77a0000 ntshrui (deferred)
000007fe`f77a0000 000007fe`f77af000 CSCAPI (deferred)
000007fe`f77b0000 000007fe`f77bc000 CSCDLL (deferred)
000007fe`f77c0000 000007fe`f783e000 cscui (deferred)
000007fe`f7840000 000007fe`f7875000 EhStorShell (deferred)
000007fe`f8160000 000007fe`f816b000 slc (deferred)
000007fe`f8c60000 000007fe`f8dc1000 WindowsCodecs (deferred)
000007fe`f91d0000 000007fe`f91e8000 dwmapi (deferred)
000007fe`fa2f0000 000007fe`fa333000 DUser (deferred)
000007fe`fa340000 000007fe`fa432000 DUI70 (deferred)
000007fe`fa660000 000007fe`fa6b6000 UxTheme (deferred)
000007fe`fab50000 000007fe`fac7c000 propsys (deferred)
000007fe`faf50000 000007fe`faf77000 cryptnet (deferred)
000007fe`fb250000 000007fe`fb2f0000 COMCTL32_7fefb250000 (deferred)
000007fe`fb610000 000007fe`fb645000 xmllite (deferred)
000007fe`fbb40000 000007fe`fbb6d000 ntmarta (deferred)
000007fe`fbfa0000 000007fe`fbfbb000 GPAPI (deferred)
000007fe`fbfc0000 000007fe`fbfd2000 devrtl (deferred)
000007fe`fbfe0000 000007fe`fbfff000 SPINF (deferred)
000007fe`fc190000 000007fe`fc1d7000 rsaenh (deferred)
000007fe`fc490000 000007fe`fc4a8000 CRYPTSP (deferred)
000007fe`fc5a0000 000007fe`fc5ec000 bcryptprimitives (deferred)
000007fe`fc650000 000007fe`fc672000 bcrypt (deferred)
000007fe`fc680000 000007fe`fc6a3000 srvcli (deferred)
000007fe`fc6b0000 000007fe`fc700000 ncrypt (deferred)
000007fe`fc910000 000007fe`fc91b000 Secur32 (deferred)
000007fe`fcab0000 000007fe`fcab9000 fltlib (deferred)
000007fe`fcac0000 000007fe`fcacc000 version (deferred)
000007fe`fcb10000 000007fe`fcbfa000 guard64 (deferred)
000007fe`fcc30000 000007fe`fcc84000 oleacc (deferred)
000007fe`fcc90000 000007fe`fce85000 Comctl32 (deferred)
000007fe`fcf10000 000007fe`fcf35000 SSPICLI (deferred)
000007fe`fcf40000 000007fe`fcf97000 apphelp (deferred)
000007fe`fcfa0000 000007fe`fcfaf000 CRYPTBASE (deferred)
000007fe`fcfb0000 000007fe`fd041000 SXS (deferred)
000007fe`fd050000 000007fe`fd064000 RpcRtRemote (deferred)
000007fe`fd070000 000007fe`fd073000 api_ms_win_core_synch_l1_2_0 (deferred)
000007fe`fd080000 000007fe`fd0eb000 cssguard64 (deferred)
000007fe`fd190000 000007fe`fd19f000 profapi (deferred)
000007fe`fd1a0000 000007fe`fd1af000 MSASN1 (deferred)
000007fe`fd1b0000 000007fe`fd1b4000 api_ms_win_downlevel_version_l1_1_0 (deferred)
000007fe`fd1c0000 000007fe`fd32d000 CRYPT32 (deferred)
000007fe`fd330000 000007fe`fd334000 api_ms_win_downlevel_ole32_l1_1_0 (deferred)
000007fe`fd340000 000007fe`fd344000 api_ms_win_downlevel_user32_l1_1_0 (deferred)
000007fe`fd350000 000007fe`fd3ba000 KERNELBASE (deferred)
000007fe`fd410000 000007fe`fd413000 api_ms_win_downlevel_normaliz_l1_1_0 (deferred)
000007fe`fd4c0000 000007fe`fd4c5000 api_ms_win_downlevel_advapi32_l1_1_0 (deferred)
000007fe`fd4d0000 000007fe`fd506000 CFGMGR32 (deferred)
000007fe`fd510000 000007fe`fd52e000 USERENV (deferred)
000007fe`fd530000 000007fe`fd54a000 DEVOBJ (deferred)
000007fe`fd550000 000007fe`fd5a2000 WLDAP32 (deferred)
000007fe`fd5b0000 000007fe`fd67b000 USP10 (deferred)
000007fe`fd680000 000007fe`fd717000 COMDLG32 (deferred)
000007fe`fdbd0000 000007fe`fdc37000 GDI32 (deferred)
000007fe`fdc40000 000007fe`fdcdf000 msvcrt (deferred)
000007fe`fdce0000 000007fe`fdd51000 SHLWAPI (deferred)
000007fe`fdd70000 000007fe`fdf6f000 ole32 (deferred)
000007fe`fdf70000 000007fe`fe079000 MSCTF (deferred)
000007fe`fe120000 000007fe`fe12e000 LPK (deferred)
000007fe`fe130000 000007fe`fe2b8000 urlmon (deferred)
000007fe`fe310000 000007fe`ff09a000 SHELL32 (deferred)
000007fe`ff0a0000 000007fe`ff17b000 ADVAPI32 (deferred)
000007fe`ff180000 000007fe`ff2ac000 RPCRT4 (deferred)
000007fe`ff2b0000 000007fe`ff38a000 OLEAUT32 (deferred)
000007fe`ff390000 000007fe`ff3be000 IMM32 (deferred)
000007fe`ff3c0000 000007fe`ff3df000 sechost (deferred)
000007fe`ff3e0000 000007fe`ff479000 CLBCatQ (deferred)
000007fe`ff480000 000007fe`ff74a000 iertutil (deferred)
000007fe`ff750000 000007fe`ff927000 SETUPAPI (deferred)
|
WaxfordSqueers
May 12th, 2019, 22:45
kayaker...spoke too soon...as usual.
Now blabbs will be mad at me.
Found a way but won't have a chance to test it right now.
I described the process before but here it is briefly. Need to get into the context of mmc.exe.
!process 0 0 mmc
Take the process address of mmc from above and add it to...
.process /i <address>.
wdbg instructs you to hit g and let target run. It claims when target breaks you will be in context of above.
Did that but got the following:
Quote:
0: kd> .process /i fffffa8011f311e0
You need to continue execution (press 'g' <enter> for the context
to be switched. When the debugger breaks in again, you will be in
the new process context.
0: kd> g
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPointWithStatus:
fffff800`03ea2400 cc int 3
5: kd> gh
Breakpoint 1 hit
mmc!CSubclassManager::SubclassProc:
0033:00000000`ffc22474 fff7 push rdi |
Note the 'Break instruction exception - code 80000003'
Gave me an idea and I hit 'Go Handled Exception' (hence the gh at kd> prompt). Following that the target broke at:
Quote:
mmc!CSubclassManager::SubclassProc:
0033:00000000`ffc22474 fff7 push rdi |
I am now in mmc code at a point I got to last night by setting the user32!getwindowsmesagew bp.
I had 3 bps set:
Quote:
5: kd> bl
0 e 00000000`77439e54 0001 (0001) USER32!GetMessageW
1 e 00000000`ffc22474 0001 (0001) mmc!CSubclassManager::SubclassProc
2 e 00000000`77539bb6 0001 (0001) kernel32!BasepCreateActCtx+0xa17 |
The last one was an address I picked up somewhere.
Oddly enough, it did not break in user32. Maybe I have to set the context to U32 to have it hit but I can't seem to set the U32 context as I can the mmc context.
WaxfordSqueers
May 14th, 2019, 18:16
@kayaker...just noticed something I should have noticed before. In the particular implementation of Device Manager I am using, for manual hardware installation, the central app is setupapi. I had been looking for devmgr.dll but I am now thinking it may not even be called while installing hardware. Maybe deeper into the DM tree where drivers can be updated, devmgr may be implemented.
Thus far, I have gotten into the middle of setupapi from the host using kernel debugging and it is parsing the command line where I have my iusb3xhc USB3 driver.
The main problem I am having is extremely slow single stepping. It's the same problem with Windbg in user mode on the same machine so it does not seem to be the serial connection. It may be my antivirus since I noticed one of its components in the stack along with setupapi functions. I'll disable it next time but I wonder if disabling is enough since the driver remains loaded.
Here's an excerpt from setupapi where it is copying the command line as it checks for the disk source of the driver. Got here by manipulating the stack addresses and using them as bp's.
Quote:
SETUPAPI!SetupPromptForDisk+0x70d:
0033:000007fe`ff7780fb 3bc2 cmp eax,edx
5: kd> t
SETUPAPI!SetupPromptForDisk+0x70f:
0033:000007fe`ff7780fd 0f87f16d0200 ja SETUPAPI!SetupPromptForDisk+0x711 (000007fe`ff79eef4)
5: kd> t
SETUPAPI!SetupPromptForDisk+0x718:
0033:000007fe`ff778103 4c8b842480000000 mov r8,qword ptr [rsp+80h]
5: kd> t
SETUPAPI!SetupPromptForDisk+0x720:
0033:000007fe`ff77810b e854a0fdff call SETUPAPI!StringCchCopyW (000007fe`ff752164)
5: kd> p
SETUPAPI!SetupPromptForDisk+0x725:
0033:000007fe`ff778110 85c0 test eax,eax
5: kd> t
SETUPAPI!SetupPromptForDisk+0x727:
0033:000007fe`ff778112 0f88e66d0200 js SETUPAPI!SetupPromptForDisk+0x729 (000007fe`ff79eefe)
5: kd> t |
Kayaker
May 14th, 2019, 21:33
Yeah, I think that's zeroing in on it. I reached the same point by using Strings64 to scan the mui files in /system32/en-US for the error message when using the hardware wizard to try to install the usb driver, which pointed to setupapi.dll.mui.
The string resource Id is found with Resource Hacker, and a search in IDA showed exactly where the message dialog is created. I figure that function would be a place to start digging. Stepping back references an exported function called initially by devmgr.dll
Code:
File Name : setupapi.dll
.text:000007FF79A83F84 SelectOEMDriver proc near ; CODE XREF: SetupDiSelectOEMDrv+6E
.text:000007FF79A83F84 ; HandleSelectOEM+110
.text:000007FF79A84580 mov r8d, 0EA78h ; 0x0000EA78,
.text:000007FF79A84580 ; "The folder you specified doesn't contain a compatible software driver for your device.
.text:000007FF79A84580 ; If the folder contains a driver, make sure it is
.text:000007FF79A84580 ; designed to work with %1.\r\n"
.text:000007FF79A84586 mov rdx, [rsp+208h+var_150]
.text:000007FF79A8458E mov rcx, cs:MyDllModuleHandle
.text:000007FF79A84595 call FormatMessageBox
WaxfordSqueers
May 14th, 2019, 22:10
Quote:
| [Originally Posted by Kayaker;97716]Stepping back references an exported function called initially by devmgr.dll |
That's interesting and a whole lot easier than forcing my way through the deep code woods by tracing. Mind you, I have developed a few tricks over the years for managing immense amounts of code while tracing.
The check for the OEM driver is about where I am now.
I am not sure if this will accomplish anything but it's giving me practice with Windbg and allowing me to see how Windoze handles the installation of drivers. And what criteria it uses to determine whether the current driver is good enough, as it often claims. I am sure that comes down to reading the INF file, which as you pointed out, can be garnered from the Intel log file.
I am hoping to find out why it will install the driver under certain conditions yet not activate it. The Intel drivers to which I have posted a link were good for my type of mobo on W7 till very recently. Something may have changed in the B360 chipset model, which is not even listed in the INF file. It's reference is VEN_8080&DEV_A36D, the A36D referring to the B360 chipset USB 3 host controller.
The setup file checks for chipsets newer than Skylake (mine is Coffee Lake), which it references in the software as SKY+. I don't know if msoft has a similar check. It does know that I am using a newer chipset and processor and has cut me off from updates for W7. I regarded that as pretty mean-spirited.
I do know that Microsoft rates drivers and their acceptability using a scale. I have also noted that both Intel and Msoft have changed the dates on their drivers, Intel going back to 1969, the date of the formation of Intel. That seems to have something to do with the rating of drivers as well.
WaxfordSqueers
May 16th, 2019, 17:18
Kayaker...don't know if you have the answer for this or if blabberer might.
Windbg seems to lack the ability to trace into a system call. Typically, a system call begins with a 'syscall' and I expect the code to follow into the system itself. However, windbg seems to bypass system calls and that can result in undesirable effects when tracing code.
I reached a function in U32 called U32!_fnDWORD. From what I recall it is related to a callback from a system routine in U-mode.
Within that function there is another function:
0000000076F467FA call [User32!_imp_NtCallbackReturn]
It leads to the following code:
Ntdll!ZwCallbackReturn
33:00000000771B98D0 mov R10, RCX
......................................mov eax, 2
......................................syscall
......................................ret
If my target has a dialog box open with an OK button already activate but frozen, when I activate 'sysenter', the target executes to completion.
It would not do that in softice. I would have been able to trace right into the system call and through it, sometimes back into user mode code.
Is this a limitation of wdbg? Or is there a way to influence wdbg to trace into the system call? If that problem cannot be overcome, it's not much use to me as a ring 0 debugger. As youknow, there are many times that calls are made into the system and the system calls back into U-mode. That's what I expected to happen in this case but the debugger seems to have lost control and allowed the target to run to completion.
Kayaker
May 16th, 2019, 21:41
Couple random ideas.
Depending on what you're trying to do, you might have a look at nt!KeUserModeCallback / ntdll!KiUserCallbackDispatcher, see if you can get an address of the callback and any kernel buffer pointer.
The PEB might help.
No point in trying to trace into syscalls directly.
WaxfordSqueers
May 16th, 2019, 23:21
Quote:
| [Originally Posted by Kayaker;97719]Depending on what you're trying to do |
Thanks k. I'll check out what you suggest.
What I am trying to do ultimately is find where the OK button leads. I am trying to load a driver and I am watching how Windoze processes the load. I would actually like to set a conditional break where I could check the left button click which is 0x201.
I have several dialog windows open related to Add Hardware in Device Manager. The code I am stepping through is related to those windows. The call into the system is likely related to win32k.sys since it is the system side that deals with graphics.
Normally, I would not care about system calls but on several occasions I have seen a call to the system, call back into a user program or a user system library before returning.
With sice I would often jump over a syscall and find there was something vital in the sys call where I had to trace through system code to the app on which I was working.
That's twice now that I have hit a system callback and had windbg lose control of the tracing process. It should do its business and return, if it is not going to allow tracing through sys code.
WaxfordSqueers
May 18th, 2019, 21:32
I have been reading in-depth stuff about reversing and the Windows kernel-user systems. Part review, part new. I had one of those Homer Simpson Doh!!! moments while reading on the syscall command.
Why not set a bp on the address of the ret command after the syscall?
Doh!!! Don't have time right now but I am interested to see if something happens inside the routine called by syscall or whether the OK dialog box will still be there if it breaks immediately after the syscall.
I got so strung out on what I used to do with softice and where I could set a bp to stop the app going to completion that the totally obvious solution was overlooked.
Meantime, during my reading, I covered some theoretical ground related to your last post about callbacks. Got some ideas on how to place a bp, if required, to investigate further.
Besides, I am rusty as all git out.
+Ork will be smiling at my doh!!! gaffe since he emphasized looking for the obvious.
WaxfordSqueers
May 18th, 2019, 21:37
ps. I have noticed that many people have viewed this thread yet no one but kayaker and blabberer has commented. Please don't feel shy about hyjacking the thread, every comment is welcome. I would like to hear from some of the old RCE crew if for nothing more than to say hello.
Covered something on canonical addressing. I have noticed on occasion that when I try to set a bp in windbg, it gets entered as 0xfffff7fe'xxxxxxxx rather than 0x000007fe'xxxxxxxx. In the former case, the bp is not applied in the right place.
From what I understand, the 64 bit canonical address must have all the same values before the 64 bit msb address, otherwise it changes things. If I have an address listed as 0x0000007fe'xxxxxxxx it can be sub-divided as 0x0000-07fe'xxxxxxxx. The 07fe part of the msb side is an actual 4 byte address. Somehow, wdbg is interpreting it as f7fe and adding ffff in front of it.
WaxfordSqueers
May 20th, 2019, 20:14
Kayaker...wasted an inordinate amount of time on a wild goose (Canadian variety) chase. The OK button issue is a non-entity. It leads to a search for the 'Have Disk' part of the 'Add Hardware' to the required INF file. Once that has been located and OK is hit a new screen appears stating something like 'To start installing your new hardware, hit next'.
I should have been starting from that Next button. That's where the actual driver installation begins. Doh!!!
I had been searching for that string in associated mui files with no luck until I noticed there are two versions of hdwwiz, the add hardware wizard. There is one with an exe extension and one with a cpl extension. The mui for the cpl extension has the string at ordinal 1056 (0x420). I have found that in the Window procedure in IDA @ 0BE03DF0 but they are just putting the dialog box together at that point.
I am trying to recall, but once ShowWindow is executed, the dialog box window with the Next button should appear and wait for input. I don't know if the code below Show Window is related.
I'd really like to find a bp after the Next button to bp on. I have seen reference to:
_imp_SetupDiRegisterDeviceInfo@24 a bit below but have no has time to pursue it.
blabberer
May 22nd, 2019, 15:26
Quote:
| Kayaker...don't know if you have the answer for this or if blabberer might. |
the dis is from w7 32 but concepts are same (w10 32/64 whatever)
the instruction syscall / sysenter / int 2e / int2b etc are executed from usermode
but the actual work is done in kernel mode
so you may need to wait on the other side with proper breakpoints to catch the action
your fndword
Code:
kd> x user32!*fndword*
761301a6 USER32!__fnDWORDOPTINLPMSG (<no parameter info>
76114f59 USER32!__fnDWORD (<no parameter info>
kd> uf /c USER32!__fnDWORD
USER32!__fnDWORD (76114f59)
USER32!__fnDWORD+0x21 (76114f7a):
unresolvable call: call dword ptr [eax+14h]
USER32!__fnDWORD+0x2f (76114f88):
call to USER32!XyCallbackReturn (76116214)
kd> uf /c USER32!XyCallbackReturn
USER32!XyCallbackReturn (76116214)
no calls found
kd> uf USER32!XyCallbackReturn
USER32!XyCallbackReturn:
76116214 8b442404 mov eax,dword ptr [esp+4]
76116218 cd2b int 2Bh
7611621a c20400 ret 4
kd> $$ it calls an interrupt int 2b
kd> lets see whats in the idt of 2b
^ Syntax error in 'lets see whats in the idt of 2b'
kd> !idt 2b
Dumping IDT: 80b95400
552bb9f90000002b: 82e52e90 nt!KiCallbackReturn
kd> $$ so a proper bp /p $proc nt!KiCallbackReturn should get you the action
nt!Kicallbackreturn calls nt!NtCallbackReturn
Code:
kd> uf /c nt!KiCallbackReturn
Flow analysis was incomplete, some code may be missing
nt!KiCallbackReturn (82e52e90)
nt!KiSystemServicePostCall+0x8 (82e528ce):
call to hal!KeGetCurrentIrql (8322d6ee)
nt!KiServiceExit+0x1c (82e52938):
call to nt!KiCopyCounters (82ef80e7)
nt!KiServiceExit+0x52 (82e5296e):
call to hal!KfRaiseIrql (8322d844)
nt!KiServiceExit+0x5f (82e5297b):
call to nt!KiDeliverApc (82ec5975)
nt!KiServiceExit+0x65 (82e52981):
call to hal!KfLowerIrql (8322db48)
nt!KiServiceExit2+0x159 (82e52c24):
call to nt!KeBugCheck2 (82ef41c3)
nt!KiServiceExit2+0x173 (82e52c3e):
call to nt!KeBugCheck2 (82ef41c3)
nt!KiServiceExit2+0x188 (82e52c53):
call to nt!PerfInfoLogSysCallExit (82f26d6d)
nt!KiCallbackReturn+0x88 (82e52f18):
call to nt!NtCallbackReturn (82e93f60)
kd> uf /c /D 0x82e93f60
nt!NtCallbackReturn (82e93f60)
nt!NtCallbackReturn+0x47 (82e93fa7):
call to nt!KxTransferNpxState (82e93c9c)
nt!NtCallbackReturn+0xa9 (82e94009):
call to nt!MmDeleteKernelStack (82eab569)
WaxfordSqueers
May 24th, 2019, 17:58
Quote:
| [Originally Posted by Kayaker;97725]This thread should be split at some point if it goes off topic. |
Do whatever you think is best, kayaker.
I started the thread as a general query into USB 3 drivers for W7 on a newer generation mobo. Microsoft never has supplied drivers on W7 for USB3.
I needed to find a debugger to do that and the discussion lead off into 64 bit debuggers. I needed to learn Windbg properly while finding a way to study W7 and W10 USB trees with the hope of finding a clue as to why current Intel USB 3 drivers won't load on my B360 chipset.
Currently I am trying to follow the loading sequence used in Device Manager to see if I can find a clue as to why the drivers won't activate. However, I plan to attack it at a deeper level once I get a feel for what is involved. It's a steep learning curve.
Break the current thread into two or more threads as you see fit.
WaxfordSqueers
May 24th, 2019, 18:06
Quote:
[Originally Posted by blabberer;97724]the instruction syscall / sysenter / int 2e / int2b etc are executed from usermode but the actual work is done in kernel mode
so you may need to wait on the other side with proper breakpoints to catch the action
|
Thanks for info, Blabbs and good to hear from you.
There is good info here for me to study in windbg. Thanks for taking the time to put it together.
I went back to the syscall command and set a bp on the ret address. It never broke, the code entered by syscall must have called back into the user app and likely won't return till further processes is done.
As it stands, as I indicated in an earlier post, I was barking up the wrong tree. The syscall was in code leading to an INF file and was related to an open dialog box with an OK button. I needed to activate that button and reach the next stage where the driver is loaded.
WaxfordSqueers
June 15th, 2019, 04:31
Just noted threads have been split. I have been posting to wrong thread.
Have not given up on this thread, I have just been busy on an unrelated project. I'll be back.
Elenil
June 23rd, 2019, 08:10
Quote:
[Originally Posted by WaxfordSqueers;97742]Just noted threads have been split. I have been posting to wrong thread.
Have not given up on this thread, I have just been busy on an unrelated project. I'll be back. |
waxfordsqueers i might got the problem fixed you where talking in page 1
i tryed to fix the problems for this old tool
i made a beta you might try it out ?
(removed see woodmann downloads for download)
i will delete the link later its kinda off tropic since i cant send a private msg
WaxfordSqueers
June 23rd, 2019, 22:32
Quote:
| [Originally Posted by Elenil;97743]i will delete the post later its kinda off tropic since i cant send a private msg |
Thanks, elenil. It's not off-topic to me. You are welcome to leave the link on this thread if you like. Kayaker might want to do something with it, however.
Kayaker
June 24th, 2019, 00:08
Of course, updates to IceStealth is always welcome.
WaxfordSqueers
June 27th, 2019, 17:26
Quote:
| [Originally Posted by Kayaker;97745]Of course, updates to IceStealth is always welcome. |
Kayaker...noted that your join date was in 2000. Your 20th anniversary will be coming up soon.
Planning a party?
Powered by vBulletin® Version 4.2.2 Copyright © 2019 vBulletin Solutions, Inc. All rights reserved.