Problem and Solution of https Request Failure of Android Mobile Wechat 7.0.4 Debugging Widget

Keywords: Android Mobile SSL OpenSSL

Note: To read this article, you need an Android phone that already has root!

Explain

System: MacOS 10.13.6
 Mobile phone: millet 6 (already root)
Pack Grabbing Tool: Charles
 Wechat Version: 7.0.4

phenomenon

Android phones can't grab https requests through Charles proxy. I used 7.0.3 the day before yesterday (April 16, 2019). I don't know why I caught it. Yesterday, the handicap was updated to 7.0.4. And iOS (the iPhone 5S 12.1.4) has no problem.

Searching for relevant information, it is said that the upgrade of Wechat to Version 7 restricts user certificate credentials. According to the more recommendation schemes on the Internet, it is suggested that the certificate be placed in the system certificate storage directory, which requires Root mobile phone, if not, the following content is not suitable for reading.

Next, I tried to put the certificate generated by Charles in the system certificate of the mobile phone, which was not so smooth and failed! Let me explain it slowly.

step

Generate Charles certificates

We need to generate an identifiable certificate that can be stored in the system certificate directory.

After the mobile agent is set up, the mobile phone accesses: <chls.pro/ssl> and downloads the certificate. The name is charles-proxy-ssl-proxying-certificate.pem. (If you get this file on the computer, assume that the certificate has the path of the computer: ~/charles-proxy-ssl-proxying-certificate.pem).

This command generates a hash value at your computer terminal:

openssl x509 -subject_hash_old -in ~/charles-proxy-ssl-proxying-certificate.pem

You can see that the output is similar to the following

P750TM:webs whidy$ openssl x509 -subject_hash_old -in ~/certificate.pem 
07e87b3d
-----BEGIN CERTIFICATE-----
MIIFYjCCBEqgAwIBAgIGAWeQpfWHMA...
....
77JclxPc0UdJHi5rOf7w+LU8YZFPdMTLa/c2JjMlspt08UeQVDE=
-----END CERTIFICATE-----

Rename certificate 07e87b3d.0 Note the suffix!

Next, you can copy the file to the mobile phone's / system/etc/security/cacerts / directory by any means. If it succeeds, you can try to grab the package again. If it fails, please continue reading.

Super Terminal Operation

If you don't mind the trouble, you can do the following at the super terminal (self-downloaded tool) on Android mobile phone, but I don't. I've enabled adb connection to operate the mobile phone in MacOS X. If you want to, please follow my way.

Computer terminals execute the following commands (brew is not introduced here, self-learning is not understood)

brew cask install android-platform-tools

Once installed, the data line is connected to the mobile phone and tested.

adb devices

No errors were reported, and the following information is normal:

List of devices attached
* daemon not running; starting now at tcp:5037
* daemon started successfully
fa8a05fd    device

Then get root permission and try to copy the file 07e87b3d.0 to / system/etc/security/cacerts/

adb root

After obtaining permission, directly execute the following command to place the certificate in the system directory.

push ~/07e87b3d.0 /system/etc/security/cacerts/

If successful, please try to grab the bag. If the prompt fails, such as inadequate permissions and read-only, the error message may be as follows:

P750TM:/ whidy$ adb push ~/07e87b3d.0 /system/etc/security/cacerts/
adb: error: failed to copy '/Users/whidy/07e87b3d.0' to '/system/etc/security/cacerts/07e87b3d.0': remote couldn't create file: Read-only file system
/Users/whidy/07e87b3d.0: 0 files pushed. 0.0 MB/s (1947 bytes in 0.119s)

Then we should continue to toss and turn. The chmod 777 copied online is useless at present. To solve this problem, mount operations are needed.

Load the writable system directory

Look at where mount is currently mounted in the system directory, and you can get the following general information:

rootfs on / type rootfs (ro,seclabel,size=2828452k,nr_inodes=707113)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,size=2912600k,nr_inodes=728150,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime,gid=3009,hidepid=2)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
/dev/block/dm-0 on /system type ext4 (ro,seclabel,relatime,discard,data=ordered)
debugfs on /sys/kernel/debug type debugfs (rw,seclabel,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
none on /dev/stune type cgroup (rw,relatime,schedtune)
tmpfs on /mnt type tmpfs (rw,seclabel,relatime,size=2912600k,nr_inodes=728150,mode=755,gid=1000)
none on /config type configfs (rw,relatime)
none on /dev/memcg type cgroup (rw,relatime,memory)

Notice the line / dev/block/dm-0 on /system type ext4 (ro,seclabel,relatime,discard,data=ordered), followed by a RO in parentheses, representing readonly!

Next, try to modify the writable (rw) state:

mount -o rw,remount /dev/block/dm-0 /system

If it succeeds, try copying the file in and fail. For example,'/dev/block/dm-0'is read-only. Please continue reading.

Reference here Android O, failed to mount /system, /dev/block/dm-0 is read only One operation! Here I am:

adb disable-verity
adb reboot

Turn off validation to restart the device. After the restart, continue:

adb root
adb remount
adb shell

Executing mount finds that the result is not the same as it was just now. Find the line with system and find it like this.

/dev/block/sde43 on /system type ext4 (rw,seclabel,relatime,discard,data=ordered)

It's ready to write. I'll try to copy it in. Execute ADB push ~/07e87b3d.0/system/etc/security/cacerts/, and the following results occur:

P750TM:/ whidy$ adb push ~/07e87b3d.0 /system/etc/security/cacerts/
/Users/whidy/07e87b3d.0: 1 file pushed. 0.1 MB/s (1947 bytes in 0.022s)

It should be done. Then go to the settings in my millet 6 mobile phone > more Settings > System Security > encryption and credentials > credentials of trust > system to see, roll to the bottom, ok, certificate import success. Go grab your bag again.~

This article is written and recorded. Now you can see that the https request is Ok.~

Last

I recommend that disable-verity be restored at last, so that it can be operated on as follows:

adb root
adb enable-verity
adb reboot

That's about all.

Write texts with references to relevant articles:

Posted by bluntster on Wed, 15 May 2019 23:57:03 -0700