Snapdragon X55 (Thinkpad X1 Nano w/5G Modem)

[Bjørn Mork]

Aleksander Morgado <aleksander at aleksander.es> writes:

> Hey,
>
>>
>> The problem we have now is that we no longer have a simple solution to snoop the trafic from windows. It was simple with USB but I have no idea how to do that with PCIe. I've never worked with PCI-drivers.
>> ---------------------
>
> There has to be a way to capture the PCI traffic in Windows, or not?

I fear there isn't, except by modifying drivers.  You can probably snoop
writes to control space.  But the advantage of PCI is the direct
access.  Unless I've misunderstood this whole PCI thing.  Which isn't
completely unlikely ;-)

Except maybe if you can hook a software IOMMU into the game, and can
"listen" in on the bounce buffers?

Yes, I agree.  Someone surely must have done that already?

Or maybe it's easier to fake a PCI device and see what the driver does
to it?

Just some random ideas waaaay out of my league..

> Here's the Lenovo driver for the SDX55, I assume that during that
> installation, the module would get FCC unlocked:
> https://support.lenovo.com/es/en/downloads/ds547596-qualcomm-snapdragon-x55-5g-modem-driver-for-windows-10-version-1809-or-later-thinkpad-x1-nano-gen-1

I downloaded this earlier to have a peek. It is nice enough to run in
Wine so you can observe it without hardware or Windows.  But getting
something useful out of it is harder.  Most of those 500MB is firmware.
Wondering if they duplicate the complete image for different operators?
For some odd reason, the firmware is distributed as FOTA/FOTA_FW_Img.dat
which I have no idea how to unwrap.  Anyway, that's besides the question

As for the rest of it, there isn't anything bloody obvious enough for me
to spot.  We have these files:

├── Install.cmd
└── Src
    ├── FOTA
    │   ├── FOTA_FW_Img.dat
    │   ├── mbfwdriver.cat
    │   ├── MBFWDriver.dll
    │   ├── MBFWDriver.inf
    │   └── MBFWDriver.pdb
    ├── MHI
    │   ├── mhihost.cat
    │   ├── MhiHost.inf
    │   ├── MhiHost.pdb
    │   └── MhiHost.sys
    ├── QUD_GNSS
    │   ├── qcgnss.cat
    │   ├── qcgnss.dll
    │   ├── qcgnss.inf
    │   ├── qcgnss.pdb
    │   ├── qcmdm.inf
    │   ├── qcqmux.pdb
    │   ├── qcqmux.sys
    │   ├── qcqmuxusb.pdb
    │   ├── qcqmuxusb.sys
    │   ├── qcser.cat
    │   ├── qcser.inf
    │   ├── qmuxmdm.cat
    │   ├── QmuxMdm.inf
    │   ├── serial
    │   │   └── amd64
    │   │       ├── qcusbser.pdb
    │   │       └── qcusbser.sys
    │   └── SIMService
    │       ├── GobiConnectionMgmt.dll
    │       ├── McfgMgmt.dll
    │       ├── MSFTCompressor.exe
    │       ├── SilentInstall.exe
    │       ├── SIMService.exe
    │       └── upgrade.exe
    ├── ThermalMdm
    │   ├── qcthermalmdm.cat
    │   ├── qcthermalmdm.inf
    │   ├── qcthermalmdm.pdb
    │   └── qcthermalmdm.sys
    └── UDE
        ├── qcude
        │   └── amd64
        │       ├── qcude.pdb
        │       ├── qcude.sys
        │       └── WdfCoinstaller01011.dll
        ├── qcude.cat
        └── qcude.inf

11 directories, 40 files


I was wondering a bit about WdfCoinstaller01011.dll=  Or maybe that
SIMService does something odd?

If it's not there, then it has to be built into one of the drivers.  But
that was how it was with the Sierra FCC request too, wasn't it?

> We only need one single good capture during the process.

Or a hint from Lenovo.   Maybe poke  Mark Pearson who gave a talk at
debconf20: https://debconf20.debconf.org/talks/67-lenovo-debian/ ?


Bjørn