Page 3 of 10 FirstFirst 12345678910 LastLast
Results 31 to 45 of 142

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

  1. #31
    Quote Originally Posted by blabberer View Post
    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().

  2. #32
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Blog Entries
    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.

    Name:  OllyCmdLine2.jpg
Views: 114
Size:  70.3 KB


    And I guess you could use this for Olly 2

    Gigapede's Command Bar 3.20.110

  3. #33
    Quote Originally Posted by Kayaker View Post
    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.

    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.

  4. #34
    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:

    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.
    Attached Files Attached Files

  5. #35
    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.

  6. #36
    Super Moderator
    Join Date
    Dec 2004
    Blog Entries
    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

    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

    C:\>powershell -c "get-cimclass" | wc -l
    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...}
    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

    Name:  powershell1.gif
Views: 92
Size:  846.9 KB

  7. #37
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Blog Entries
    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:

    And if interested in using Wireshark as a key/mouse logger:

  8. #38
    Quote Originally Posted by Kayaker View Post
    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.

    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.

  9. #39
    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.

  10. #40

    Windbg setup

    @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'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:

    Here's microsoft on serial debugging, with a null model cable (crossover cable) layout:

  11. #41
    Super Moderator
    Join Date
    Dec 2004
    Blog Entries
    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

  12. #42
    Quote Originally Posted by blabberer View Post
    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.

  13. #43
    Quote Originally Posted by blabberer View Post
    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.

  14. #44
    Super Moderator
    Join Date
    Dec 2004
    Blog Entries
    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

    Name:  windtheme.gif
Views: 87
Size:  171.6 KB

  15. #45
    Quote Originally Posted by blabberer View Post
    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.

Similar Threads

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


Posting Permissions

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