Jump to content

Mov AX, 0xDEAD

Members
  • Posts

    28
  • Joined

  • Last visited

Posts posted by Mov AX, 0xDEAD

  1. 6 hours ago, pappyN4 said:

    catching up on TRIM in the deleted thread...

    Is there a backport win8 storport?  Or is it just the storpor8.sys that was being discussed?  NTOSKRNL_Emu has missing dependencies with win8 storport.

    storpor8.sys is emulator of some new functions for win7's storport.sys

    I have experimental ported win8.0 storport.sys, it has many manual injected calls to PoStartNextPowerIrp(), perfectly works with win8's storahci

    Me and Daniel chose win7's storport.sys as base for ported storage drivers because it was last version who stills call PoStartNextPowerIrp() at proper places

  2. On 1/19/2022 at 4:31 PM, infuscomus said:

    is IDA absolutely necessary? I don't have it installed, can I use windbg?

    If IDA is necessary, can you help me setup windows 8.0 pre-install environment for debugging?

    IDA debugger has same GUI, as standalone Disassembler

    i dont have pre-install environment experience, debug config stored in BCD

  3. 1 hour ago, infuscomus said:

    I got very close to booting XP textmode setup with the server 2008 kernel and HAL - I got up to "Setup is Starting Windows" - no crash, but it stops there.

    You are very far to booting XP texmode."Setup is Starting Windows" means all drivers loaded as files to ram. Next stage is code execution, but it stops there (surprise)...

  4. On 12/21/2021 at 1:34 AM, George King said:

    Anybody tried this to boot XP in UEFI?

    https://github.com/maharmstone/quibble

    Question is - how many people using WinXP x64 on UEFI x64 with original ACPI 1.0 driver on modern PC?

    Answer - about zero, only few new motherboards has special acpi1.0 legacy support for WinXP.

    Of couse you can make heavy patch of your DSDT to isolate all acpi2.0 syntax and run with ACPI 1.0 driver. Or use acpi x64 driver from longhorn 5048 beta

  5. 23 hours ago, infuscomus said:

    @Mov AX, 0xDEAD

    I'd like to try and use the function PoSetPowerState to set the powerstate of the 149c controller to D3 - then wait 1-2ms - then go back to D0.

    1) You cannot PoSetPowerState without device_object, device_object will be created usb3 driver to present usb3 controller abstraction to Windows

    2) PoSetPowerState used to inform windows about current power state, what you do next after windows marked device as D0 ?

    3) Better reverse ms usb3 8.0 driver(use win10 usb3 sources as base), find place where controller is resetted, change wait time or inject your additional code

    4) Think about why are some additional delays/power states - solution to the problem ?  I have repeatedly written that the driver will reset the controller, you will reset it second time(or you - first, driver - second), and what will it give ?

  6. 1 hour ago, infuscomus said:

    @Mov AX, 0xDEAD

    Can you show me in C code how to check if the system has just been booted, and if so, tell the xhci controller to reset itself?

    Do it yourself, reseting controller is complicated task, first you need take ownership from bios(for on-board controller). hal source show how to get ownership. Also explore leaked windows10 usb3 driver to see how to reset controller. And again, MS USB3 driver do these jobs itself.

    "system has just been booted" - i dont know what you mean, running ntldr(DOS-part) or running win32k.sys from user-mode process is same "windows are booting". Emu_Extender run when windows load any first driver linked with ntoskrn8.sys, it can be usb3 or storage driver, so DllInitialize will be runed before main win8 usb3 controller code (USBXHCI.SYS) in any case

     

     

  7. 34 minutes ago, infuscomus said:

    @Mov AX, 0xDEAD

    I was looking through the XP HAL source code and saw there are USB related chipset hacks included called HalpStopohciInterrupt HalpStopUhciInterrupt etc..

    I looked into the Windows 8.0 HAL and saw there is now a HalpStopXhciInterrupt included too, I know I'm just guessing here but this might be what is needed to fix problematic USB controllers.

    Let see what hack do:

    Quote

    HalpStopOhciInterrupt(
    Routine Description:
        This routine shuts off the interrupt from an OHCI
        USB controller.  This may be necessary because
        a BIOS may enable the PCI interrupt from a USB controller
        in order to do "legacy USB support" where it translates
        USB keyboard and mouse traffic into something that DOS
        can use.  (Our loader and all of Win9x approximate DOS.)

    HalpStopOhciInterrupt check who is current owner of usb controller: 1) if BIOS, hal request changing ownership from bios to hal 2) if controller has no owner, no actions with ownership. At end HalpStopOhciInterrupt disable interrupts by writing to controller.

    Why HAL need this hack ? i guess to avoid unexpected interrupts when no driver loaded for some device. But we have proper usb3 driver and usb controller cannot works without interrupts, so usb3 driver will enable interrupts anyway(maybe with other pci routing, i dont know), also MS USB3 driver recheck ownership of controller and gain it if controller is under BIOS control

    Quote

    Do you think you could try and implement this function into the XP HAL source code?

    I think these hacks are useless because usb3 driver do opposing job.

    Can you remind me, what is wrong with amd controller and MS USB3 8.0 driver ?

  8. 14 minutes ago, infuscomus said:

    I have an OEM SP3 XP ISO where I swapped out the kernel with my compiled version if you want to try it out? This version installs in a VM at least.

    We already have compiled sp3 kernel from MS, so No. If you have custom kernel, you need all related files compiled from same source - hal, acpi, win32k(?), pci(?) ...

  9. 21 minutes ago, infuscomus said:

    @Mov AX, 0xDEAD

    So do you think the 149C controller is failing because of a missing function in our patched acpi.sys that the windows 8.0 acpi.sys has?

    I dont know, MS usb3 driver is very complex due "usb stack", maybe it require specific acpi functionality. Or maybe bios uses specific registers of amd usb controller to reprogram it to custom mode so DSDT is only way to control this "custom" mode.

  10. 3 minutes ago, infuscomus said:

    @Mov AX, 0xDEAD

    First 0xDEADBEEF which I bypassed, but now I get BSOD 50 and 8E

    any help to get your extender working with this?

    I can explain only 0xDEADBEEF bsod, because this is extender's internal assertion checks

    0xDEADBEEF, 0x3 - bug in PsSetCreateProcessNotifyRoutineEx_k8, overflowed list or some similar

    0xDEADBEEF, 0x5 - not found signature of existing but not exported functions in ntoskrnl.exe,  just comment KeBugCheckEx()

    50 or 8E - can't help with this, when you mix parts of different OS - you get mess

  11. 33 minutes ago, canonkong said:

    I already porting the usb driver from win8.1 and win10 1511, but they will code 10 error on win7.  What I need to do with the inf file?

    Code 10 is common error -  unsupported hardware, unsupported OS, failed internal driver checks, etc...

    Driver code starts, but windows receive some error from driver, you can't fix it with patching .inf

    And don't forget to remove initial security cookie check, this check, will fail on pre-Win8 OSes

     

  12. 3 hours ago, infuscomus said:

    The windows 8.0 ACPI driver maybe? - vanilla versions gives A5 BSOD, but after patching it boots and the 149C controller works there properly at boot time..

    OK, original 8.0 usb3 driver works with 0x149c controller under Win8.0 environment (+ patched acpi), so problem is deeper and 8.1 driver in different OS may have same issue.

    The first thing that comes to mind - DSDT, but on Linux open source usb3 driver (by Intel) uses acpi functions only in two cases - workaround for fewer Intel chipsets (Skylake and other), linux driver call special DSM methods to power up something in hardware, see xhci_pme_acpi_rtd3_enable()
    second is powering ports(?) usb_acpi_set_power_state(), many subcalls.
    
    
×
×
  • Create New...