Connection with Username/Password/Authentication Settings

[studioiyagi001]

Hello!

Thanks for great work!
It seems the script is working well but I have an issue that my sim card requires additional APN setting like id, password, cert type (CHAP), APN protocol, APN type.

Can I give those settings in .ini and run the script?

Thanks!

[samweisgamdschie]

Although I haven't got a running WWAN card yet, I will have the same things to configure. An ini file or commandline arguments would be great for those settings.

[tgxn]

Yeah, currently there's no interface to configure these settings AFAIK. We'd need to figure out how these actually get set.

[sibradzic]

Any clues where to start looking how to set the password? I want to invest some time checking this one...

[tgxn]

I'm really not too sure! There's a reversing repo which is what this driver was originally written against I think,

If it's possible to set these under windows, then it's probably going to be an undocumented RPC call.

There's some discussion in #63 about the reversing repo too. Maybe setting these settings might be possible via AT also? 👀

[sibradzic]

It seems to me that all APN settings are supposed to be set with UtaMsCallPsAttachApnConfigReq, it is probably just a matter of figuring out which part of args are used for storing password and other APN data.
Where does the info about the types originally coming from?

[sibradzic]

Who originally figured out where to place apn_string inside the args? Was this somehow "captured" on windows driver?

I believe I can figure out where the APN auth options are, if only I could see what data is windows driver passing with auth options configured, when executing UtaMsCallPsAttachApnConfigReq. But I have no clue how to "capture" this on Windows...

[zhuyifei1999]

Who originally figured out where to place apn_string inside the args?

Given the commit logs, almost definitely @abrasive.

Was this somehow "captured" on windows driver?

No idea if this was captured, but it was definitely reversed. (https://github.com/xmm7360/reversing).

If you want to have a try at reversing xmm7360/reversing#3 this PR has all the XML & IDC dumps of abrasive's IDBs which you can import into IDA or Ghidra

[sibradzic]

I loaded the IDB dumps in Ghidra, but this thing is overwhelming, and I can barely understand what am I doing...
If someone can "guide" me on how this disassembler reversing actually helped to locate where apn_string actually resides in the data passed to UtaMsCallPsAttachApnConfigReq, perhaps I can try to emulate that process, otherwise I'm pretty lost 🤷‍♂️

[zhuyifei1999]

I loaded the IDB dumps in Ghidra, but this thing is overwhelming, and I can barely understand what am I doing...

Tbh I feel the same (no ARM reversing experience here). I was preempted by other projects; might try again in the coming weeks.

[tgxn]

This is kinda why I've taken a bit of a back seat on this stuff :)

Happy for people with experience with this to play around but I wasn't able to get the dumps loaded either. :/

[abrasive]

I did all the reversing based on logs from the Windows driver. I ran a windows VM under a patched qemu - see the relevant stuff in the reversing repo.

On the reversing front, look in the function RPCUnpackUtaMsCallPsAttachApnConfigReq. From memory, the general pattern of the RPCUnpack... functions is that they call a series of other functions to unpack arguments one by one (eg. "unpack an int", "unpack a string" sort of thing). You should be able to line them up against the known arguments and work out what's what.

[sibradzic]

@abrasive I've built patched qemu, it installs and runs, but I can't get to the point that I have functioning XMM7360 PCI device in Windoze. I've tried a loads of stuff; non-patched qemu, 3 different kernels, 3 different T14 BIOS revisions, 3 different Win10 releases, it won't budge :| The best thing I could get in Windoze is this in the Device Manager:

Intel(R) XMM7360-P WWAN
The device cannot start. (Code 10)
{Operation Failed}The requested operation was unsuccessful.
C0000001

Service: UDE
Problem: 0xA
Problem Status: C0000001

On the kernel(s) side I see this being logged, so I guess that's not the issue::

[  108.970589] vfio-pci 0000:05:00.0: enabling device (0000 -> 0002)
[  110.004122] vfio-pci 0000:05:00.0: vfio_ecap_init: hiding ecap 0x1e@0x150

I've tried vfio-ing other PCI devices from the T14, such as Ethernet ports, and that works just fine, but XMM7360 just won't budge, damn it!

@abrasive, in your README, I don't see any actual vfio-pci directive in the qemu command... Can you please share more details on how exactly did you plugged the XMM7360 into the Windoze VM? Which particular kernel and T14 (or some other machine) BIOS have you been using when trying it out?

[abrasive]

@sibradzic I'm sorry, it looks like I posted the wrong run script. This is the one I have on disk. It has a bunch of stuff (eg. license passthrough) that is unlikely to be useful to you, but it does have the device passthrough with all of the magic flags I'd forgotten it needs. My apologies for the incorrect doucmentation.

exec /var/tmp/portage/app-emulation/qemu-4.0.0-r50/work/qemu-4.0.0/softmmu-build/x86_64-softmmu/qemu-system-x86_64 --enable-kvm -cpu host,hv_time,kvm=off,hv_vendor_id=1234567890ab,hv_vapic,hv_relaxed,hv_spinlocks=0x1fff \
  -nodefaults \
    -machine pc-q35-3.0,accel=kvm,kernel_irqchip=on \
  -device ioh3420,bus=pcie.0,multifunction=on,port=1,chassis=1,id=root.1 \
    -drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/OVMF_CODE.fd \
    -drive if=pflash,format=raw,file=OVMF_VARS.fd \
    -device virtio-scsi-pci,id=scsi0 \
        -blockdev driver=raw,node-name=root,cache.direct=on,discard=unmap,file.driver=host_device,file.aio=native,file.filename=/dev/zvol/seg/enc/vm/windows \
        -device scsi-hd,bus=scsi0.0,drive=root \
    -drive file=Win10_1903.iso,if=ide,media=cdrom \
    -drive file=virtio-win-0.1.164.iso,if=ide,media=cdrom \
    -netdev user,id=net0,smb=/home/jhl,hostfwd=tcp::3389-:3389,hostfwd=tcp::23946-:23946, -device virtio-net-pci,netdev=net0 \
    -device virtio-tablet-pci -device virtio-keyboard-pci \
    -m 10G \
    -smp 4 \
    -monitor stdio \
    -vga none -nographic \
    -rtc base=localtime \
    -acpitable file=license/MSDM -acpitable file=license/SLIC \
    -smbios file=segnomin_smbios.bin \
    -global ICH9-LPC.disable_s3=1 \
    -global ICH9-LPC.disable_s4=1 \
    -spice disable-ticketing,port=9984 \
    -device vfio-pci,bus=root.1,host=3b:00.0,x-no-mmap,x-no-kvm-msi,x-no-kvm-ioeventfd \
    -device virtio-serial -chardev spicevmc,id=vdagent,debug=0,name=vdagent \
        -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
    -device ivshmem-plain,memdev=ivshmem \
    -object memory-backend-file,id=ivshmem,share=on,mem-path=/dev/shm/looking-glass,size=32M \
    -trace events=trace \
    $*
    # -trace events=trace,file=log \
    #-acpitable /home/jhl/sync/thinkpad/acpi_vbios/optimus-vfio-docs/asl/ssdt1.aml \
    -serial tcp:127.0.0.1:4445 -parallel none \
    #-fw_cfg genroms/vbios,file=vbios_N2IET74W \

[sibradzic]

Can I assume that -acpitable /home/jhl/sync/thinkpad/acpi_vbios/optimus-vfio-docs/asl/ssdt1.aml refers to the https://github.com/jscinoz/optimus-vfio-docs/blob/master/asl/ssdt1.asl? (Ahh never mind, I see that's commented out...)

And license/MSDM & license/SLIC are extracts from your own ThinkPad BIOS?
What is segnomin_smbios.bin?

[sibradzic]

@abrasive Thanks for the info. I tried the vfio flags you suggest in -device vfio-pci,bus=root.1,host=3b:00.0,x-no-mmap,x-no-kvm-msi,x-no-kvm-ioeventfd as well as all possible flags I see in qemu-system-x86_64 -device vfio-pci,?, but to no avail, the windows driver is still suck in Code 10... Maybe there is some weird crap going on in my AMD T14 IOMMU or something, I simply can't pass-through the modem (other PCI devices seems to work).

Do you still have your snooping setup available? If you do, I believe we could easily get the APN credentials from what resembles a r2 ls 2 sre: 2f84e4000 13e5 0 0 ; message in https://github.com/xmm7360/reversing/blob/master/windows_snooping/example_queue_1. If you could set up some dummy username & password, and set auth to "PAP or CHAP" in the windows VM and just attempt a cellular connection, the placement of credentials and PAP/CHAP enablement flags should be identifiable in the snoop...

[tgxn]

Reading through the AT command guide from Fibrocom, there seems to be a way to set PAP, CHAP and authentication using an AT command

AT+XGAUTH=?
AT+XGAUTH=0,1,"GSM","1234"

This proprietary command allows to enter the type of authentication for a user-name(using a password)
for the specified PDP context.

Set command allows to enter the type of authentication for a user-name (using a password) for the specified PDP context.

[tuxor1337]

I tried to dig into this issue again. I installed Win10 as a qemu (v8.2.2) guest with direct access to the modem device (via vfio-pci). The device is recognized by the Windows (Lenovo) driver and it shows the firmware version and carrier. When Windows boots, there is some activity on the RPC channel (mostly related to FCC unlocking). However, first thing after login, the driver tries to flash a firmware update. After a while, it says "Firmware update failed" and will stop interacting with the modem device. So, no way for me to continue using the device and snooping RPC commands.

@abrasive Do you remember facing similar problems when you did the PCI snooping? I tried all versions of the Windows driver that have been released since early 2019 and all of them tried to flash a firmware update, then failed and stopped doing anything afterwards.

[abrasive]

@tuxor1337 they have a somewhat weird design where it insists on flashing the modem depending on the SIM card provider. I think I let it run in native Windows before I got started.

It should be possible to pass through the device in FW update mode, but might be fiddly. Does it flip into USB mode and enumerate on the host that way? Or does it come up as a PCI device with different ID, which would presumably need a rescan on the host? Possibly with a remove beforehand?

[tuxor1337]

@abrasive Thanks for the quick response! Unfortunately, I currently don't have a native Windows for testing. Maybe I will install Win10 to some external drive and boot from there. Unfortunately, I don't have spare external media, currently :)

I found that, when in USB mode, the device will show up under a particular xhci controller on the host. Fortunately, I don't really need that xhci controller (apart from the modem in flash mode, it controls my webcam and fingerprint reader). So, I use vfio to pass through the whole xhci controller AND the modem in PCI mode. That means that my qemu host is really completely agnostic of the modem device the whole time while qemu is running, and everything is directly accessible from the Win10 guest. Still, for some reason, the firmware update fails.

[abrasive]

@tuxor1337 you might have to use sysfs to remove the PCI device and then rescan the bus while the Windows side is waiting for the device to come back in FW update mode?

Alternatively, not sure if you can get away with this, but you might be able to pass the parent bus of the card through to Windows and have the hotplugging handling run on the Windows side. Figure out which root port is handling it with lspci -t and pass that over instead?

[tuxor1337]

@abrasive Removing the PCI device through sysfs (while qemu is running with vfio-pci) permanently removes the device for the Win10 guest - even after rescanning the bus and after vfio-pci binds to it again.

For the alternative: Unfortunately, vfio-pci cannot bind to PCI root ports. I can unbind the pcieport kernel module from the card's parent port. But then, vfio-pci will still produce error -22 (device in use). Similarly, virt-manager says that "non-endpoint" PCI devices cannot be passed over to the guest.

[abrasive]

@tuxor1337 I suspect removing and re-adding to the guest would involve using the qemu console, but I guess I'm more curious about what Windows needs to see for it to know it's in FW update mode. When you rescan, does it come up with the same PCI ID & subsystem ID when it's in FW update mode?

[tuxor1337]

@abrasive The output of lspci -knnv remains completely unchanged when it's in FW update mode. Only in lshw and in lsusb, an additional USB device pops up. This USB device always shows up under the same xhci_hcd controller, and with the identical physical ID (1-7). Only the kernel device ID under /dev/bus/usb/001/00X is incremented by one each time (see diff below).

That's why I am using vfio-pci to pass over the xhci_hcd controller. That way, the Win10 guest can directly detect the new USB device. I don't need to remove/rescan the PCI card on the host to bring up the FW update mode. The FW update driver under the Win10 guest is capable of resetting the card and triggering the FW update mode so that the card shows up as a new USB device under Windows. Then the FW update driver interacts with the card in FW update mode and keeps it there for ~30 seconds before the driver decides that the FW update failed. Without interaction, the card will only stay in FW update mode for ~5 seconds.

diff -su normal/lspci.txt fwupd/lspci.txt
Files normal/lspci.txt and fwupd/lspci.txt are identical

diff -su normal/lshw.txt fwupd/lshw.txt
--- normal/lshw.txt	2024-07-04 08:48:40.448839530 +0200
+++ fwupd/lshw.txt	2024-07-04 08:50:24.383382277 +0200
@@ -178,7 +178,15 @@
                    version: 1.08
                    capabilities: usb-2.01 usb
                    configuration: driver=usbhid maxpower=96mA speed=12Mbit/s
-              *-usb:1
+              *-usb:1 UNCLAIMED
+                   description: Communication device
+                   vendor: Intel Corp. [8087]
+                   physical id: 7
+                   bus info: usb@1:7
+                   version: 0.00
+                   capabilities: usb-2.10
+                   configuration: maxpower=500mA speed=480Mbit/s
+              *-usb:2
                    description: Video
                    product: Integrated Camera [4F2:B67C]
                    vendor: Chicony Electronics Co.,Ltd. [4F2]
@@ -188,7 +196,7 @@
                    serial: 6726
                    capabilities: usb-2.01
                    configuration: driver=uvcvideo maxpower=500mA speed=480Mbit/s
-              *-usb:2 UNCLAIMED
+              *-usb:3 UNCLAIMED
                    description: Generic USB device
                    product: Prometheus MIS Touch Fingerprint Reader [6CB:BD]
                    vendor: Synaptics, Inc. [6CB]

diff -su normal/lsusb.txt fwupd/lsusb.txt
--- normal/lsusb.txt	2024-07-04 08:48:40.543839599 +0200
+++ fwupd/lsusb.txt	2024-07-04 08:50:24.462382403 +0200
@@ -4,6 +4,9 @@
     |__ Port 006: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 12M
         ID 2386:4328 Raydium Corporation Touch System
         /sys/bus/usb/devices/1-6  /dev/bus/usb/001/002
+    |__ Port 007: Dev 006, If 0, Class=CDC Data, Driver=[none], 480M
+        ID 8087:07f5 Intel Corp. 
+        /sys/bus/usb/devices/1-7  /dev/bus/usb/001/006
     |__ Port 008: Dev 003, If 0, Class=Video, Driver=uvcvideo, 480M
         ID 04f2:b67c Chicony Electronics Co., Ltd 
         /sys/bus/usb/devices/1-8  /dev/bus/usb/001/003

[tuxor1337]

I located some config and log files in C:\Windows\Firmware\FwSwitchbin:

• FlashServiceDebugLogger_DLL.log
• SwitchDebugLog.log
• fbconfig.ini
• WWANFirmwareFlashConfig.ini

From the SwitchDebugLog.log, I would deduce that, in fact, the update service is enforcing to flash a firmware that somehow matches the carrier of the current SIM card (as you suspected). I don't see an option in the config files to manipulate this behavior.

From the FlashServiceDebugLogger_DLL.log, I got the impression that the process is triggering a device reboot (which seems to be successfull) and then waits for the USB device 8087:0aca to show up - but it never shows up. The device that shows up is 8087:07f5. That's why it times out after 15 seconds or so.

[tuxor1337]

I was finally able to run the driver on a native Windows (I installed Win10 to a 32 GB USB pen drive that I got from a friend). On that native Win10 setup, the modem works very well. The modem firmware is now up to date and, in the Win10 guest under qemu, the driver will not make any attempts at updating the firmware. So far, so good.

However, the Win10 qemu-guest is not able to FCC unlock the card. This is really fascinating because I have no idea what might cause this. I snoop the RPC commands and see that it executes the well-known init sequence (as expected!):

UtaMsSmsInit
UtaMsCbsInit
UtaMsNetOpen
UtaMsCallCsInit
UtaMsCallPsInitialize
UtaMsSsInit
UtaMsSimOpenReq
CsiFccLockQueryReq

After that, the driver requests an unlock challenge (CsiFccLockGenChallengeReq) but doesn't even wait for the response before sending an unlock attempt (CsiFccLockVerChallengeReq). The modem says that FCC unlock was NOT successful, but the driver keeps sending CsiFccLockGenChallengeReq and CsiFccLockVerChallengeReq over and over again for minutes. After a very high number of attempts, it will stop. It then starts to send UtaRPCScreenControlReq in and endless loop - the modem always answers 0 to this.

How is it possible that the driver acts so weird when inside a qemu guest? I double-checked that it is the exact same version that is used in the native Win10 installation.

However: I found that permanently disabling the FCC lock with at@nvm:fix_cat_fcclock.fcclock_mode=0 (and storing in NVM) does work around this problem. I can now finally start looking into how to specify username/password etc. ... Thanks a lot for your support! I will report back asap.

[tuxor1337]

I have been able to reverse engineer where to put the information about APN cert type (none, PAP or CHAP), APN user, and APN password. It's part of my merge request for ModemManager, see here: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/1200

[abrasive]

Fantastic! Well done and thank you :)

[pswiatki]

So, does it mean I can now bring the connection up and later, when done, shut it down gracefully?

[tuxor1337]

Yes, connecting and disconnecting is now both part of the merge request.

[pswiatki]

So sweet. Thank you so much. I shall test it shortly on my DELL laptop.