Foreword:
Recently, I was solving a wifi bug. Andriod R, based on the Qualcomm platform, encountered some problems.
Problem phenomenon:
After entering the wifi setting, turn on the wifi button switch, and the surrounding aps cannot be scanned, which results in the inability to connect to wifi.
Simple troubleshooting, sorting out the process
1: First, I first checked whether the wifi module was compiled, and after confirming that ko was compiled, I found it under the device:
kona:/vendor/lib/modules # ls
audio_mbhc.ko audio_wcd938x_slave.ko qca_cld3_qca6390.ko
audio_native.ko audio_wcd9xxx.ko qca_cld3_qca6490.ko
I just list some ko files here, what I need is qca_cld3_qca6390.ko , which means it has been compiled.
2: Afterwards, it may be that ko did not load, and I did active load here: the insmod command is used to load the module.
/vendor/lib/modules # insmod qca_cld3_qca6390.ko
insmod: failed to load qca_cld3_qca6390.ko: Required key not available
Saying that the required key is not available or does not match, this involves signing.
Note: If the following information appears during execution:
kona:/vendor/lib/modules # insmod qca_cld3_qca6390.ko
insmod: failed to load qca_cld3_qca6390.ko: File exists
It means that the module driver has been loaded, if it has been loaded, but the ap is still not scanned, then look for other problems.
3: Solve the problem of wifi scanning
1) Bypass the wifi signature detection and make this function temporarily available:
directly block the signature detection of the module:
#CONFIG_MODULE_SIG=y
#CONFIG_MODULE_SIG_FORCE=y
Explain: The
kernel configuration item
CONFIG_MODULE_SIG=y
indicates that the signature mechanism is turned on, but at this time, the module signature or unsigned can be used.
CONFIG_MODULE_SIG_FORCE=y
If the above configuration items are enabled, the module must have the correct signature before it can be used normally.
Of course, there are other configuration files with this:
CONFIG_MODULE_SIG_ALL=y When the
kernel is compiled, it will not actively sign the module unless you turn on the above configuration items.
Anyway, there is no configuration file for my brother. I only found it on the Internet.
After compiling and verifying on the computer, the wifi can scan to the ap.
2) Change the signature to make the signature consistent and solve the problem
. Pull out the module ko in the device and use the command to see:
optiplex-7070:~$ adb pull /vendor/lib/modules/qca_cld3_qca6390.ko ~/桌面/
/vendor/lib/modules/qca_cld3_qca6390.ko: 1 file pulled. 23.6 MB/s (15031278 bytes in 0.607s)
First, let's take a look at the difference between normal signed and unsigned:
ko's signature information: Module signature appended. As can be seen from the figure, qca_cld3_qca6390.ko does not see the signature information.
Note: If you already have a signature when you check the signature, it's okay, you can also sign him again on the basis of his signature!
Directly add manual signature:
Since ko has been pulled out, on the basis of inconsistent signatures, and at the same time, in order to be consistent with kenel's signature, we have to separately use the tools and secret keys and digital certificates in these two paths in the code. Take it out (you don’t need to take it out, I’m just here for convenience):
/kernel/ship_prebuilt/primary_kernel/scripts下的工具：sign-file
/kernel/ship_prebuilt/primary_kernel/certs下的密钥和数字签名：signing_key.pem与signing_key.x509
Some students have to ask again, the key and digital signature in my code do not match mine. It may be: I saw that the Internet uses signing_key.priv and signing_key.x509, so you can change signing_key. Think of priv as my signing_key.pem.
Everything is ready, directly change the signature:
Let me first look at the signature of ko from the pull:
use the command:
$:hexdump -C qca_cld3_qca6390.ko |tail
The display is as follows:
00e55e40 4d 43 c7 47 39 ba 0a b7 c9 12 b2 d8 cd 3e 45 7c |MC.G9........>E||
00e55e50 aa 07 c0 c5 09 68 ce 5e 3f b2 c0 83 77 0c 97 2e |.....h.^?...w...|
00e55e60 6e 99 78 be 45 1b 6f 9a b4 05 df f4 e5 17 1e 10 |n.x.E.o.........|
00e55e70 5e ed 05 93 46 c1 22 2d 9d 06 fc 22 25 8e c4 20 |^...F."-..."%.. |
00e55e80 87 1f 4b 2d 8b ca 9e 3a 1a 63 1f ab 75 b2 12 2f |..K-...:.c..u../|
00e55e90 e2 45 53 dc c5 3b 89 81 31 37 eb 9e 9b b5 47 46 |.ES..;..17....GF|
00e55ea0 cb 11 00 00 02 00 00 00 00 00 00 00 02 a9 7e 4d |..............~M|
00e55eb0 6f 64 75 6c 65 20 73 69 67 6e 61 74 75 72 65 20 |odule signature |
00e55ec0 61 70 70 65 6e 64 65 64 7e 0a |appended~.|
00e55eca
It means that the signature is already there, but it is not correct, it is a signature of another version, so I signed him again:
Use the command:
$ ./sign-file sha512 signing_key.pem signing_key.x509 ../qca_cld3_qca6390.ko
Check the signature again:
$ hexdump -C qca_cld3_qca6390.ko |tail
content:
00e55e30 a6 7c cf 04 d4 0c 34 50 e5 16 2c 23 4b 67 23 0e |.|....4P..,#Kg#.|
00e55e40 5b e2 d7 a0 ff 03 b0 98 5c 0f c3 6c 5f 64 d7 c1 |[.......\..l_d..|
00e55e50 46 67 b6 11 53 99 01 6a 40 41 33 bb c9 e6 92 a5 |Fg..S..j@A3.....|
00e55e60 de 51 02 ae 63 15 4e a8 48 ea d7 4c 59 b6 e9 63 |.Q..c.N.H..LY..c|
00e55e70 c0 83 b4 6d b3 2f 42 90 d1 26 a9 a4 da ba 9d 8c |...m./B..&......|
00e55e80 a8 72 94 5f 7d fe 84 3f 3f 3c 08 b2 50 3e 5d bb |.r._}..??<..P>].|
00e55e90 cb f8 cf a2 d8 09 6f 00 00 02 00 00 00 00 00 00 |......o.........|
00e55ea0 00 02 a9 7e 4d 6f 64 75 6c 65 20 73 69 67 6e 61 |...~Module signa|
00e55eb0 74 75 72 65 20 61 70 70 65 6e 64 65 64 7e 0a |ture appended~.|
00e55ebf
After signing, we delete the ko under the device. Because of the signature problem, the driver cannot be loaded, so there is no need to uninstall the driver.
After a series of adb, after the device content can be changed, we push in our changed ko:
$ adb push qca_cld3_qca6390.ko /vendor/lib/modules
qca_cld3_qca6390.ko: 1 file pushed. 26.2 MB/s (15031999 bytes in 0.547s)
Enter the device, check if we push in, if ok, we can actively load the driver:
kona:/vendor/lib/modules # insmod qca_cld3_qca6390.ko
There is no error, ok, turn on the wifi again, the wifi scan to the ap, the problem is solved.
Brief summary : If you only brush boot.img, use the tool of your code to sign, that is, under the kernel. This is the core. It does not matter who compiled the ko, but your ko must match your boot.img .
Description of the error situation: (the pits you walked through, don’t imitate)
Because I am not particularly clear about the code framework, I seem to be very mechanical with regard to the issue of signatures. At the beginning I used (note that it is the out directory):
- Digital signature and key: signing_key.pem and signing_key.x509 under /out/target/product/kona/obj/kernel/msm-4.19/certs$
/out/target/product/kona/obj/kernel/msm-4.19/certs$ ls
built-in.a signing_key.pem system_keyring.o
modules.builtin signing_key.x509 x509_certificate_list
modules.order system_certificates.o x509.genkey
- Signature tool used: sign-file under /out/target/product/kona/obj/kernel/msm-4.19/scripts$
/out/target/product/kona/obj/kernel/msm-4.19/scripts$ ls
asn1_compiler conmakehash genksyms mod recordmcount sortextable
basic dtc kallsyms modules.order selinux unifdef
bin2c extract-cert kconfig pnmtologo sign-file
After many attempts, it has been failed, and the machine crashed directly! At first glance, the signature is incorrect! I searched the above tools and secret keys globally, and found a similar file under the kernel, which is the solution to the above problem.
Without loading the driver, the reality of the app layer:
