Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
Hello Bjørn, hi all, fascinating ;-) I made some limited progress with analysing the binary's code. There are plenty of conditions for different firmware versions (some of which I have never seen in the wild). The most recent version computes some data from the IMEI, but I don't really understand (using static analysis only) what is actually sent to the modem. Regards, Thilo Viele Grüße aus Hamburg Thilo Ginkel -- Thilo-Alexander Ginkel · Isestr. 6 · D-20144 Hamburg · Germany E-Mail/Jabber: th...@ginkel.com · @thiloginkel Phone: +49 (0)40 68895028 · Mobile/Signal: +49 (0)177 8033300 On Tue, May 10, 2022 at 11:00 AM Bjørn Mork wrote: > > More interesting stuff from that binary. The resource section contains > 3 zip-files among other stuff. Two of these contain DPR_Table.txt files > per device-id(?) and some binary blobs I don't recognise. Names might > indicate NV entries? > > > bjorn@miraculix:/tmp$ unzip -l resources/101.bin > Archive: resources/101.bin > Length DateTimeName > - -- - > 0 2020-05-04 16:27 TuneCode/ > 0 2020-05-04 16:27 TuneCode/tunecode_876D/ > 3752 2019-12-24 15:18 TuneCode/tunecode_876D/DPR_Table.txt > - --- > 3752 3 files > bjorn@miraculix:/tmp$ unzip -l resources/102.bin > Archive: resources/102.bin > Length DateTimeName > - -- - > 0 2021-03-08 17:14 TuneCode/ > 0 2021-03-08 17:15 TuneCode/tunecode_093D/ > 7462 2021-03-15 13:40 TuneCode/tunecode_093D/DPR_Table.txt > 0 2021-03-08 17:16 TuneCode/tunecode_098C/ > 7462 2021-03-15 13:40 TuneCode/tunecode_098C/DPR_Table.txt > 0 2020-05-29 19:02 TuneCode/tunecode_09C6/ > 36067 2020-04-22 16:11 TuneCode/tunecode_09C6/00029653 > 510 2020-04-30 10:40 TuneCode/tunecode_09C6/00029654 > 7403 2020-05-29 18:57 TuneCode/tunecode_09C6/DPR_Table.txt > 0 2020-10-07 14:00 TuneCode/tunecode_0A3F/ > 40314 2020-10-12 18:38 TuneCode/tunecode_0A3F/00029653 > 510 2020-10-12 18:40 TuneCode/tunecode_0A3F/00029654 > 7443 2020-10-07 13:35 TuneCode/tunecode_0A3F/DPR_Table.txt > 0 2021-02-04 10:22 TuneCode/tunecode_0A5B/ > 48254 2021-01-25 12:41 TuneCode/tunecode_0A5B/00029653 > 510 2021-01-25 12:36 TuneCode/tunecode_0A5B/00029654 > 7208 2021-02-26 15:46 TuneCode/tunecode_0A5B/DPR_Table.txt > 0 2021-03-08 14:41 TuneCode/tunecode_0A69/ > 39619 2021-03-08 14:37 TuneCode/tunecode_0A69/00029653 > 510 2021-03-08 14:37 TuneCode/tunecode_0A69/00029654 > 0 2021-03-08 14:42 TuneCode/tunecode_0A6A/ > 39619 2021-03-08 14:37 TuneCode/tunecode_0A6A/00029653 > 510 2021-03-08 14:37 TuneCode/tunecode_0A6A/00029654 > - --- >243401 23 files > > > The DPR_table files contains lines with different system+band > conbinations followed by 8 numbers which looks like they could be dB or > dBm values. Sample data: > > LTE B39 24 24 24 24 24 24 24 24 > LTE B40 24 24 24 24 24 24 23 23 > LTE B41 27 27 27 24 27 27 22.5 22.5 > LTE B42 24 24 24 24 24 22.5 24 22.5 > LTE B48 22 22 22 22 21 20.5 22 20.5 > LTE B66 24 24 24 24 24 24 18 18 > SA N1 24 24 24 24 24 24 24 24 > SA N2 24 24 24 24 24 18 24 18 > SA N3 24 24 24 24 24 24 24 24 > SA N5 24 24 24 24 24 24 19.5 19.5 > SA N7 24 24 24 24 21.5 15 24 15 > SA N8 24 24 24 24 24 24 24 24 > SA N12 24 24 24 24 24 24 19 19 > SA N20 24 24 24 24 24 24 24 24 > SA N28 24 24 24 24 24 24 24 24 > SA N38 24 24 24 24 24 14 24 14 > SA N41 27 27 27 27 21.5 15 27 15 > SA N66 24 24 24 24 24 18 24 18 > SA N77 27 27 27 27 27 18.5 27 18.5 > SA N78 27 27 27 27 27 20.5 27 20.5 > SA N79 27 27 27 27 27 16 27 16 > ENDC B5 N2 24.5 24.5 24.5 24.5 24.5 24.5 18.5 18.5 > NSA N2 B5 24 24 24 24 24 18 24 18 > ENDC B12 N2 24.5 24.5 24.5 24.5 24.5 24.5 19.5 19.5 > NSA N2 B12 24 24 24 24 24 18 24 18 > ENDC B13 N2 24.5 24.5 24.5 24.5 24.5 24.5 21.5 21.5 > NSA N2 B13 24 24 24 24 24 18 24 18 > ENDC B7 N5 24 24 24 24 21.5 14 24 14 > NSA N5 B7 24 24 24 24 24 24 18.5 18.5 > ENDC B48 N5 22 22 22 22 21 19.5 22 19.5 > NSA N5 B48 24 24 24 24 24 24 18.5 18.5 > > > The last zip contains rtsar_config_fcc and rtsar_config_row data for a > number of other(?) devices. Some of them in 2dB and 0dB variants. > Interestingly enough, this seems to be made for another Foxconn customer > and not intended for Lenovo devices at all. Doesn't look like there are > similar resources for any Lenovo modem/PC. Talk about mess. > > > bjorn@miraculix:/tmp$ unzip -l resources/106.bin > Archive: resources/106.bin > Length DateTimeName > - -- - > 0 2020-12-30 10:51 MipiTable_HP_TALISKER/ > 0 2020-12-30 10:55 MipiTable_HP_TALISKER/86F9/ > 0 2020-12-30 10:55 MipiTable_HP_TALISKER/86F9/2dB/ > 1612
Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
More interesting stuff from that binary. The resource section contains 3 zip-files among other stuff. Two of these contain DPR_Table.txt files per device-id(?) and some binary blobs I don't recognise. Names might indicate NV entries? bjorn@miraculix:/tmp$ unzip -l resources/101.bin Archive: resources/101.bin Length DateTimeName - -- - 0 2020-05-04 16:27 TuneCode/ 0 2020-05-04 16:27 TuneCode/tunecode_876D/ 3752 2019-12-24 15:18 TuneCode/tunecode_876D/DPR_Table.txt - --- 3752 3 files bjorn@miraculix:/tmp$ unzip -l resources/102.bin Archive: resources/102.bin Length DateTimeName - -- - 0 2021-03-08 17:14 TuneCode/ 0 2021-03-08 17:15 TuneCode/tunecode_093D/ 7462 2021-03-15 13:40 TuneCode/tunecode_093D/DPR_Table.txt 0 2021-03-08 17:16 TuneCode/tunecode_098C/ 7462 2021-03-15 13:40 TuneCode/tunecode_098C/DPR_Table.txt 0 2020-05-29 19:02 TuneCode/tunecode_09C6/ 36067 2020-04-22 16:11 TuneCode/tunecode_09C6/00029653 510 2020-04-30 10:40 TuneCode/tunecode_09C6/00029654 7403 2020-05-29 18:57 TuneCode/tunecode_09C6/DPR_Table.txt 0 2020-10-07 14:00 TuneCode/tunecode_0A3F/ 40314 2020-10-12 18:38 TuneCode/tunecode_0A3F/00029653 510 2020-10-12 18:40 TuneCode/tunecode_0A3F/00029654 7443 2020-10-07 13:35 TuneCode/tunecode_0A3F/DPR_Table.txt 0 2021-02-04 10:22 TuneCode/tunecode_0A5B/ 48254 2021-01-25 12:41 TuneCode/tunecode_0A5B/00029653 510 2021-01-25 12:36 TuneCode/tunecode_0A5B/00029654 7208 2021-02-26 15:46 TuneCode/tunecode_0A5B/DPR_Table.txt 0 2021-03-08 14:41 TuneCode/tunecode_0A69/ 39619 2021-03-08 14:37 TuneCode/tunecode_0A69/00029653 510 2021-03-08 14:37 TuneCode/tunecode_0A69/00029654 0 2021-03-08 14:42 TuneCode/tunecode_0A6A/ 39619 2021-03-08 14:37 TuneCode/tunecode_0A6A/00029653 510 2021-03-08 14:37 TuneCode/tunecode_0A6A/00029654 - --- 243401 23 files The DPR_table files contains lines with different system+band conbinations followed by 8 numbers which looks like they could be dB or dBm values. Sample data: LTE B39 24 24 24 24 24 24 24 24 LTE B40 24 24 24 24 24 24 23 23 LTE B41 27 27 27 24 27 27 22.5 22.5 LTE B42 24 24 24 24 24 22.5 24 22.5 LTE B48 22 22 22 22 21 20.5 22 20.5 LTE B66 24 24 24 24 24 24 18 18 SA N1 24 24 24 24 24 24 24 24 SA N2 24 24 24 24 24 18 24 18 SA N3 24 24 24 24 24 24 24 24 SA N5 24 24 24 24 24 24 19.5 19.5 SA N7 24 24 24 24 21.5 15 24 15 SA N8 24 24 24 24 24 24 24 24 SA N12 24 24 24 24 24 24 19 19 SA N20 24 24 24 24 24 24 24 24 SA N28 24 24 24 24 24 24 24 24 SA N38 24 24 24 24 24 14 24 14 SA N41 27 27 27 27 21.5 15 27 15 SA N66 24 24 24 24 24 18 24 18 SA N77 27 27 27 27 27 18.5 27 18.5 SA N78 27 27 27 27 27 20.5 27 20.5 SA N79 27 27 27 27 27 16 27 16 ENDC B5 N2 24.5 24.5 24.5 24.5 24.5 24.5 18.5 18.5 NSA N2 B5 24 24 24 24 24 18 24 18 ENDC B12 N2 24.5 24.5 24.5 24.5 24.5 24.5 19.5 19.5 NSA N2 B12 24 24 24 24 24 18 24 18 ENDC B13 N2 24.5 24.5 24.5 24.5 24.5 24.5 21.5 21.5 NSA N2 B13 24 24 24 24 24 18 24 18 ENDC B7 N5 24 24 24 24 21.5 14 24 14 NSA N5 B7 24 24 24 24 24 24 18.5 18.5 ENDC B48 N5 22 22 22 22 21 19.5 22 19.5 NSA N5 B48 24 24 24 24 24 24 18.5 18.5 The last zip contains rtsar_config_fcc and rtsar_config_row data for a number of other(?) devices. Some of them in 2dB and 0dB variants. Interestingly enough, this seems to be made for another Foxconn customer and not intended for Lenovo devices at all. Doesn't look like there are similar resources for any Lenovo modem/PC. Talk about mess. bjorn@miraculix:/tmp$ unzip -l resources/106.bin Archive: resources/106.bin Length DateTimeName - -- - 0 2020-12-30 10:51 MipiTable_HP_TALISKER/ 0 2020-12-30 10:55 MipiTable_HP_TALISKER/86F9/ 0 2020-12-30 10:55 MipiTable_HP_TALISKER/86F9/2dB/ 1612 2020-10-07 09:07 MipiTable_HP_TALISKER/86F9/2dB/rtsar_config_fcc 32 2020-10-07 09:08 MipiTable_HP_TALISKER/86F9/2dB/rtsar_config_fcc_md5.txt 1584 2020-10-07 09:07 MipiTable_HP_TALISKER/86F9/2dB/rtsar_config_row 32 2020-10-07 09:08 MipiTable_HP_TALISKER/86F9/2dB/rtsar_config_row_md5.txt 0 2020-12-30 10:55 MipiTable_HP_TALISKER/86FA/ 0 2020-12-30 10:55 MipiTable_HP_TALISKER/86FA/2dB/ 1612 2020-10-07 09:07 MipiTable_HP_TALISKER/86FA/2dB/rtsar_config_fcc 32 2020-10-07 09:08 MipiTable_HP_TALISKER/86FA/2dB/rtsar_config_fcc_md5.txt 1584 2020-10-07 09:07 MipiTable_HP_TALISKER/86FA/2dB/rtsar_config_row 32 2020-10-07 09:08 MipiTable_HP_TALISKER/86FA/2dB/rtsar_config_row_md5.txt 0 2020-12-30 10:55 MipiTable_HP_TALISKER/8709/ 0
Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
Thilo-Alexander Ginkel writes:
> Hello again,
>
> quick update if anyone wants to have a look before I find time to do so:
> The unlock is most probably in SIMService.exe, which contains the magic
> string "KHOIHGIUCCHHII" that is checked for in DMI and also used by the
> unlocking Snap...
I believe you're right. Tried to compare the 4 versions I found
available for the X1 Nano, and note that the 3 most recent ones have a
GobiDLL::SetRadioFlagNew reference:
bjorn@miraculix:/tmp$ strings
/home/bjorn/.wine/fake_windows/DRIVERS/WIN/QCSDX55/20220905.22073777/Src/QUD_GNSS/SIMService/SIMService.exe|grep
SetRadioFlag
Get mpFnDMSSetRadioFlag API address fail.
GobiDLL::SetRadioFlag
%s, %d: mpFnDMSSetRadioFlag success.
%s, %d: mpFnDMSSetRadioFlag fail.Error:%d
GobiDLL::SetRadioFlagNew
Which does not exist in the oldest version:
bjorn@miraculix:/tmp$ strings
/home/bjorn/.wine/fake_windows/DRIVERS/WIN/QCSDX55/20211105.10364130/Src/QUD_GNSS/SIMService/SIMService.exe|grep
SetRadioFlag
Get mpFnDMSSetRadioFlag API address fail.
GobiDLL::SetRadioFlag
%s, %d: mpFnDMSSetRadioFlag success.
%s, %d: mpFnDMSSetRadioFlag fail.Error:%d
So maybe look into that function?
There also seems to be a lot of SAR related magic there. Won't affect
the CE declaration of conformity AFAIK.
There are also references to a number of low level QMI requests. Some
of these look quite interesting for other purposes as well. Like the
DMS{S,G}etEFSNVValue - I guess that's generally useful.
UIMEventRegistration
UIMGetCardStatus
UIMReadTransparent
DMSSetPCPlatformSystemID
DMSGetFWVersion
DMSGetDeviceRevision
DMSGetFWSwitchingLock
DMSSetFWSwitchingLock
ChangeDeviceDownLoadMode
DMSSetEFSNVValue
DMSGetEFSNVValue
DMSSetBiosFlag
DMSGetOperatingMode
DMSSetOperatingMode
WDSModifyProfileaa
WDSGetProfileSettings
WDSModifyProfile
NASGetSystemInfo
NASSetRegistrationEventReport
NASGetSystemSelectionPref
NASSetSystemSelectionPref
DMSGetDeviceSerialNumbers
DMSSetDPRInfo
DMSGetDPRInfo
DMSGetFastWriteDPR
DMSSetFastWriteDPR
Bjørn
Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
I sincerely hope you succeed. If I'll see any way I can help out, I'll try my best to do it. Enrico On Mon, 9 May 2022, Thilo-Alexander Ginkel wrote: Date: Mon, 9 May 2022 20:13:43 From: Thilo-Alexander Ginkel To: Bjørn Mork Cc: "ModemManager (development)" , Aleksander Morgado Subject: Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock Hi Bjørn, thanks for your reply! I don't think that the lenovo-wwan-dpr snap implements the OTP unlocking mechanism. Lenovo also just posted in their forum [1] that the new firmware deliberately broke the unlock used by ModemManager. So that was probably my last Lenovo laptop... With regards to reversing the OTP mechanism: I made some first attempts at decompiling / diffing the Windows driver using Ghidra, but have to admit that I am not very experienced doing so and am somewhat lost as to which driver file actually implements the unlocking. Thanks, Thilo [1] https://forums.lenovo.com/t5/Other-Linux-Discussions/Finally-X55-5G-modem-works-under-linux/m-p/5082236?page=11#5639046 On Sun, May 1, 2022 at 6:31 PM Bjørn Mork wrote: Bjørn Mork writes: Wrt the implementation: Any protocol depending on closed binaries is broken by design, without exception. It doesn't matter whether you use a "secret" algorithm or just store keys inside the binary. Anything that was compiled can be decompiled. Sure it can be obfuscated to make that harder. We all love a challenge :-) And just let me prove that fact without even modifying one byte of the code: root@miraculix:/tmp# cat /sys/class/dmi/id/product_family ThinkPad X1 Carbon 4th root@miraculix:/tmp# echo ThinkEdge > /tmp/product_family root@miraculix:/tmp# mount --bind /tmp/product_family /sys/class/dmi/id/product_family root@miraculix:/tmp# cat /sys/class/dmi/id/product_family ThinkEdge And what do you think? There goes the machine check May 1 18:24:59 miraculix DPR_Fcc_unlock_service: main(): FCC unlock app started May 1 18:24:59 miraculix DPR_Fcc_unlock_service: get_product(): DT May 1 18:24:59 miraculix DPR_Fcc_unlock_service: MACHINE = [4] --- THINKEDGE_SE30 = [4] May 1 18:24:59 miraculix DPR_Fcc_unlock_service: main(): FCC unlock app exited This doesn't work for me of course, only having the original EM7455 modem. But I do note that the log output changed from -1 to 4, whatever that means. Previously: May 1 18:21:01 miraculix DPR_Fcc_unlock_service: MACHINE = [-1] --- THINKEDGE_SE30 = [4] Something to try out on your X1E4, maybe? Bjørn
Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
Hello again, quick update if anyone wants to have a look before I find time to do so: The unlock is most probably in SIMService.exe, which contains the magic string "KHOIHGIUCCHHII" that is checked for in DMI and also used by the unlocking Snap... Regards, Thilo On Mon, May 9, 2022 at 8:13 PM Thilo-Alexander Ginkel wrote: > Hi Bjørn, > > thanks for your reply! I don't think that the lenovo-wwan-dpr snap > implements the OTP unlocking mechanism. > > Lenovo also just posted in their forum [1] that the new firmware > deliberately broke the unlock used by ModemManager. So that was > probably my last Lenovo laptop... > > With regards to reversing the OTP mechanism: I made some first > attempts at decompiling / diffing the Windows driver using Ghidra, but > have to admit that I am not very experienced doing so and am somewhat > lost as to which driver file actually implements the unlocking. > > Thanks, > Thilo > > [1] > https://forums.lenovo.com/t5/Other-Linux-Discussions/Finally-X55-5G-modem-works-under-linux/m-p/5082236?page=11#5639046 > > > On Sun, May 1, 2022 at 6:31 PM Bjørn Mork wrote: > > > > Bjørn Mork writes: > > > > > Wrt the implementation: Any protocol depending on closed binaries is > > > broken by design, without exception. It doesn't matter whether you use > > > a "secret" algorithm or just store keys inside the binary. Anything > that > > > was compiled can be decompiled. Sure it can be obfuscated to make that > > > harder. We all love a challenge :-) > > > > And just let me prove that fact without even modifying one byte of the > > code: > > > > root@miraculix:/tmp# cat /sys/class/dmi/id/product_family > > ThinkPad X1 Carbon 4th > > root@miraculix:/tmp# echo ThinkEdge > /tmp/product_family > > root@miraculix:/tmp# mount --bind /tmp/product_family > /sys/class/dmi/id/product_family > > root@miraculix:/tmp# cat /sys/class/dmi/id/product_family > > ThinkEdge > > > > And what do you think? There goes the machine check > > > > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: main(): FCC unlock > app started > > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: get_product(): DT > > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: MACHINE = [4] --- > THINKEDGE_SE30 = [4] > > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: main(): FCC unlock > app exited > > > > This doesn't work for me of course, only having the original EM7455 > > modem. But I do note that the log output changed from -1 to 4, whatever > > that means. Previously: > > > > May 1 18:21:01 miraculix DPR_Fcc_unlock_service: MACHINE = [-1] --- > THINKEDGE_SE30 = [4] > > > > Something to try out on your X1E4, maybe? > > > > > > Bjørn >
Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
Hi Bjørn, thanks for your reply! I don't think that the lenovo-wwan-dpr snap implements the OTP unlocking mechanism. Lenovo also just posted in their forum [1] that the new firmware deliberately broke the unlock used by ModemManager. So that was probably my last Lenovo laptop... With regards to reversing the OTP mechanism: I made some first attempts at decompiling / diffing the Windows driver using Ghidra, but have to admit that I am not very experienced doing so and am somewhat lost as to which driver file actually implements the unlocking. Thanks, Thilo [1] https://forums.lenovo.com/t5/Other-Linux-Discussions/Finally-X55-5G-modem-works-under-linux/m-p/5082236?page=11#5639046 On Sun, May 1, 2022 at 6:31 PM Bjørn Mork wrote: > > Bjørn Mork writes: > > > Wrt the implementation: Any protocol depending on closed binaries is > > broken by design, without exception. It doesn't matter whether you use > > a "secret" algorithm or just store keys inside the binary. Anything that > > was compiled can be decompiled. Sure it can be obfuscated to make that > > harder. We all love a challenge :-) > > And just let me prove that fact without even modifying one byte of the > code: > > root@miraculix:/tmp# cat /sys/class/dmi/id/product_family > ThinkPad X1 Carbon 4th > root@miraculix:/tmp# echo ThinkEdge > /tmp/product_family > root@miraculix:/tmp# mount --bind /tmp/product_family > /sys/class/dmi/id/product_family > root@miraculix:/tmp# cat /sys/class/dmi/id/product_family > ThinkEdge > > And what do you think? There goes the machine check > > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: main(): FCC unlock app > started > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: get_product(): DT > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: MACHINE = [4] --- > THINKEDGE_SE30 = [4] > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: main(): FCC unlock app > exited > > This doesn't work for me of course, only having the original EM7455 > modem. But I do note that the log output changed from -1 to 4, whatever > that means. Previously: > > May 1 18:21:01 miraculix DPR_Fcc_unlock_service: MACHINE = [-1] --- > THINKEDGE_SE30 = [4] > > Something to try out on your X1E4, maybe? > > > Bjørn
Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
Bjørn Mork writes: > Wrt the implementation: Any protocol depending on closed binaries is > broken by design, without exception. It doesn't matter whether you use > a "secret" algorithm or just store keys inside the binary. Anything that > was compiled can be decompiled. Sure it can be obfuscated to make that > harder. We all love a challenge :-) And just let me prove that fact without even modifying one byte of the code: root@miraculix:/tmp# cat /sys/class/dmi/id/product_family ThinkPad X1 Carbon 4th root@miraculix:/tmp# echo ThinkEdge > /tmp/product_family root@miraculix:/tmp# mount --bind /tmp/product_family /sys/class/dmi/id/product_family root@miraculix:/tmp# cat /sys/class/dmi/id/product_family ThinkEdge And what do you think? There goes the machine check May 1 18:24:59 miraculix DPR_Fcc_unlock_service: main(): FCC unlock app started May 1 18:24:59 miraculix DPR_Fcc_unlock_service: get_product(): DT May 1 18:24:59 miraculix DPR_Fcc_unlock_service: MACHINE = [4] --- THINKEDGE_SE30 = [4] May 1 18:24:59 miraculix DPR_Fcc_unlock_service: main(): FCC unlock app exited This doesn't work for me of course, only having the original EM7455 modem. But I do note that the log output changed from -1 to 4, whatever that means. Previously: May 1 18:21:01 miraculix DPR_Fcc_unlock_service: MACHINE = [-1] --- THINKEDGE_SE30 = [4] Something to try out on your X1E4, maybe? Bjørn
Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
Thilo-Alexander Ginkel writes: > IIRC the snap does not support the modem running in an X1E4 that I own > and Iam not sure wthere it implements the old or the new FCC unlock. I believe this proves the experiment failed. I am sure Mark and others in Lenovo have tried. I do not doubt their good intentions. But changing policies involving legal matters inside a big company is extremely hard. I'm not surprised that it failed. In my opinion, the vendor binary lock support in MM is a complete waste of time and resources unless there are any vendors who provide such binaries in a timely manner for all their systems with locked modems. To me, "timely manner" means that the enabling Linux binaries must be available when I buy a laptop requiring it. Not months later, for a select subset of models. That's worthless. It's like jumping half-way over the ditch. The state of the current Lenovo FCC unlock support is that there is no way for me to figure out if I ever can use the integrated modem in a Thinkpad I buy today. And worse: Even if it works today, there is no way to know that it will continue to work after upgrading firmware. Not that great selling points, really... Anyway, it looks like we're back to decompiling, reverse engineering, and documenting all these mumbo-jumbo US quirks as open source. Too bad. But if we have to, then I'm sure we can. FWIW, I consider the "FCC unlock" thing another brilliant idea from the same lawyers who brought us RP-SMA. It's a techincal solution to a non-technical problem. This has never lead to anything good. Wrt the implementation: Any protocol depending on closed binaries is broken by design, without exception. It doesn't matter whether you use a "secret" algorithm or just store keys inside the binary. Anything that was compiled can be decompiled. Sure it can be obfuscated to make that harder. We all love a challenge :-) Actually, if Lenovo wanted to create a *working* FCC lock, then they could have designed an open interface between system and modem firmware to securely validate the platform. This isn't hard. You could e.g use the TPM, or some other of the many hardware security solutions out there, to store secret(s) used by an open protocol. As for the state of the current Lenovo FCC unlock binary, I downloaded the lenovo-wwan-dpr snap and found that it was last updated in September 2021. It doesn't seem to support any Thinkpad or current modem firmware at all. I'm not even sure why we discuss it. Is there anyone here who have been able to use this as-is? bjorn@miraculix:/tmp/_lenovo-wwan-dpr_4.snap.extracted/squashfs-root$ cat snapcraft.yaml name: lenovo-wwan-dpr version: "1.0.2-wwan-dpr" summary: This APP is used for FCC unlock and DPR of WWAN feature for Lenovo. description: | In this version only FCC unlock App is implemented for DT SE30 product. confinement: strict base: core20 grade: stable parts: dpr-wwan: plugin: dump source: . stage-packages: - pciutils - libmbim-glib-dev apps: wwan-dpr: daemon: oneshot plugs: - hardware-observe - modem-manager command: bin/DPR_wwan dpr-fcc-unlock: command: bin/DPR_Fcc_unlock_service plugs: - hardware-observe - modem-manager layout: /usr/lib/mbim2sar.so: bind-file: $SNAP/usr/lib/mbim2sar.so /usr/lib/libdpr.so: bind-file: $SNAP/usr/lib/libdpr.so Bjjørn (who still haven't replaced the good old X1 Carbon gen4 - so I'm safe until the 4G network shuts down :)
Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
Hi, On Wed, Apr 27, 2022 at 1:50 PM Aleksander Morgado wrote: > > I can boot up Windows and downgrade the firmware, but would be > > interested in a more permanent fix. > > > > What would be needed to figure out the new unlock procedure? Any hints > > are much appreciated! > > Lenovo published already their own FCC unlock tool here > https://snapcraft.io/lenovo-wwan-dpr > Haven't tried it yet here though, I'm still using the old SDX55 firmware. > > If you don't want to use that closed source tool and If you're > interested in reverse engineering the process, looking at what that > tool does would be useful I guess. IIRC the snap does not support the modem running in an X1E4 that I own and Iam not sure wthere it implements the old or the new FCC unlock. I decompiled them some time last year and will have another look later today. A first look at the Windows drivers using Ghidra didn't reveal any FCC unlocking functionality, but frankly I am somewhat lost where to start searching (the Windows drivers are a somewhat bloated set of .sys files / DLLs). Thanks, Thilo
Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
Hey! > Lenovo just published a new firmware for the T99W175 / Foxconn SDX55 > 5G modem on LVFS [1] that effectively soft-bricks the modem under > Linux as the FCC unlock no longer works. > Thanks for the heads up! I personally will keep my module with the old firmware. > I can boot up Windows and downgrade the firmware, but would be > interested in a more permanent fix. > > What would be needed to figure out the new unlock procedure? Any hints > are much appreciated! > Lenovo published already their own FCC unlock tool here https://snapcraft.io/lenovo-wwan-dpr Haven't tried it yet here though, I'm still using the old SDX55 firmware. If you don't want to use that closed source tool and If you're interested in reverse engineering the process, looking at what that tool does would be useful I guess. -- Aleksander https://aleksander.es
