收購
ng them (see Figure 5).
[…]
2 {
1: “nihaocanyoureadthis”
5: 3407918
}
3 {
1: 107
2: 10
5: 1
}
4 {
1: “1133d4c64afbf1feda85d3c497dd6164|0”
2: “wn1||0”
3: “6.0.3.44”
4: “notepad.exe”
}
[…]
Figure 5:
Excerpt of decrypted information, including what we had typed (“nihaocanyoureadthis”) and the app into which it was typed (“notepad.exe”).
A vulnerability exists in the BAIDUv3.1+AESv2 scheme that allows a network eavesdropper to decrypt the contents of these messages. Since AES is a symmetric encryption algorithm, the same key used to encrypt a message can also be used to decrypt it. Since kf is fixed, any network eavesdropper with knowledge of kf, such as from performing the same analysis of the app as we performed, can decrypt km and thus can decrypt the plaintext contents of each message encrypted in the manner described above. As we found that users’ keystrokes and the names of the applications they were using were sent in these messages, a network eavesdropper who is eavesdropping on a user’s network traffic can observe what that user is typing and into which application they are typing it by taking advantage of this vulnerability.
iFlytek
We analyzed iFlytek (also called xùnfēi from the pinyin of 讯飞) IME on Android, iOS, and Windows. We found that iFlytek IME for Android includes a vulnerability which allows network eavesdroppers to recover the plaintext of insufficiently encrypted network transmissions, revealing sensitive information including what users have typed (see Table 4 for details).
Platform
File/Package Name
Version analyzed
Secure?
Android
com.iflytek.inputmethod
12.1.10
✘✘
iOS
com.iflytek.inputime
12.1.3338
✔
Windows
iFlyIME_Setup_3.0.1734.exe
3.0.1734
✔
Table 4: The versions of Xunfei IME analyzed.
The Android version of iFlytek IME encrypts the payload of each HTTP request sent to pinyin.voicecloud.cn with the following algorithm. Let s be the current time in seconds since the Unix epoch at the time of the request. For each request, an 8-byte encryption key is then derived by first performing the following computation:
x = (s % 0x5F5E100) ^ 0x1001111
The 8-byte key k is then derived from x as the lowest 8 ASCII-encoded digits of x, left-padded with leading zeroes if necessary, in big-endian order. In Python, the above can be summarized by the following expression:
k = b’%08u’ % ((s % 0x5F5E100) ^ 0x1001111)
The payload of the request is then padded with PKCS#7 padding and then encrypted with DES using key k in ECB mode. The value s is transmitted in the HTTP request in the clear as a GET parameter named “time”.
Since DES is a symmetric encryption algorithm, the same key used to encrypt a message can also be used to decrypt it. Since k can be easily derived from s and since s is transmitted in the clear in every HTTP request encrypted by k, any network eavesdropper can easily decrypt the contents of each HTTP request encrypted in the manner described above. (Since s is simply the time in single second resolution, it also stands to reason that a network eavesdropper would have general knowledge of s in any case.)
We found that users’ keystrokes were transmitted in a protobuf serialization and encrypted in this manner (see Figure 6). Therefore, a network eavesdropper who is eavesdropping on a user’s network traffic can observe what that user is typing by taking advantage of this vulnerability.
1: 0
2: 0
3: 49
4: “xxxxx”
5: 0
7 {
1: “app_id”
2: “100IME”
}
7 {
1: “uid”
2: “230817031752396418”
}
7 {
1: “cli_ver”
2: “12.1.14983”
}
7 {
1: “net_type”
2: “wifi”
}
7 {
1: “OS”
2: “android”
}
8: 8
Figure 6:
Decrypted information revealing what we had typed (“xxxxx”).
Finally, the DES encryption algorithm is an older encryption algorithm with known weaknesses, and the ECB block cipher mode is a simplistic and problematic cipher mode. The use of each of these technologies is problematic in itself and opens the Android version of iFlytek IME’s communications to additional attacks.
收購samsung
We analyzed
收購samsung Keyboard on Android as well as the versions of Sogou IME and Baidu IME that
收購samsung bundled with our test device, an SM-T220 tablet running ROM version T220CHN4CWF4. We found that
收購samsung Keyboard for Android and
收購samsung’s bundled version Baidu IME includes a vulnerability that allows network eavesdroppers to recover the plaintext of insufficiently encrypted network transmissions, revealing sensitive information including what users have typed (see Table 5 for details).
Platform
Application name
Package name
Version analyzed
Secure?
OneUI 5.1
收購samsung Keyboard
com.
收購samsung.android.honeyboard
5.6.10.26
✘✘
OneUI 5.1
百度输入法 (Baidu IME)
com.baidu.input
8.5.20.4
✘✘
OneUI 5.1
搜狗输入法三星版 (Sogou IME
收購samsung Version)
com.sohu.inputmethod.sogou.
收購samsung
10.32.38.202307281642
✔
Table 5: The keyboards analyzed on our
收購samsung test device.
收購samsung Keyboard (com.
收購samsung.android.honeyboard)
We found that when using
收購samsung Keyboard on the Chinese edition of a
收購samsung device and when Pinyin is chosen as
收購samsung Keyboard’s input language,
收購samsung Keyboard transmits keystroke data to the following URL in the clear via HTTP POST:
http://shouji.sogou.com/web_ime/mobile_pb.php?durtot=339&h=8f2bc112-bbec-3f96-86ca-652e98316ad8&r=android_oem_
收購samsung_open&v=8.13.10038.413173&s=&e=&i=&fc=0&base=dW5rbm93biswLjArMC4w&ext_ver=0
The keystroke data is contained in the request’s HTTP payload in a protobuf serialization (see Figure 7 below).
1 {
1: “8f2bc112-bbec-3f96-86ca-652e98316ad8”
2: “android_oem_
收購samsung_open”
3: “8.13.10038.413173”
4: “999”
5: 1
7: 2
}
2 {
1: “\351\000”
2: “\372\213”
}
4: “com.tencent.mobileqq”
7: “nihaocanyoureadthis”
16: 10
17 {
3 {
1: 1
2: 5
}
5: 1
9: 1
}
18: “”
19 {
1: “0”
4: “339”
}
Figure 7:
Protobuf message transmitted after typing “nihaocanyoureadthis”.
The device on which we were testing was fully updated on the date of testing (October 7, 2023) in that it had all OS updates applied and had all updates from the
收購samsung Galaxy Store applied.
Since
收購samsung Keyboard transmits keystroke data via plain, unencrypted HTTP and since there is no encryption applied at any other layer, a network eavesdropper who is monitoring a
收購samsung Keyboard user’s network traffic can easily observe that user’s keystrokes if that user is using the Chinese edition of the ROM with the Pinyin input language selected.
When using the global edition of the ROM or when using a non-Pinyin input language, we did not observe the
收購samsung keyboard communicating with cloud servers.
百度输入法 (“Baidu IME”, com.baidu.input)
We found that the version of Baidu IME bundled with our
收購samsung test device transmitted keystroke information via UDP packets to udpolimenew.baidu.com. This version of Baidu IME used the BAIDUv3.1 protocol that we describe in the Baidu section earlier but with a different cipher and compression algorithm as indicated in each transmission’s header. In the remainder of this section we explain how a network eavesdropper can, just like with AESv2, decrypt the contents of messages encrypted using a scheme we call BAIDUv3.1+AESv1 (see Table 6).
Protocol
Scheme
Cipher
Mode
Comparison of cipher to AES
BAIDUv3.1
BAIDUv3.1+AESv1
AESv1
ECB
Additional permutations
BAIDUv3.1+AESv2
AESv2
ECB
Missing round
BAIDUv4.0
BAIDUv4.0+AESv3
AESv3
BCTR
Uses home-rolled cipher mode
Table 6: Summary of ciphers used across different Baidu protocols.
收購samsung’s bundled version of Baidu IME encrypts keystrokes using a modified version of AES which we name AESv1, as we believe it to be the predecessor to Baidu’s AESv2. When encrypting, AESv1’s key expansion is like that of standard AES, except, on each but the first subkey, the order of the subkey’s bytes are additionally permuted. Furthermore, on the encryption of each block, the bytes of the block are additionally permuted in two locations, once near the beginning of the block’s encryption immediately after the block has been XOR’d by the first subkey and again near the end of the block’s encryption immediately before S-box substitution. Aside from complicating our analysis, we are not aware of these modifications altering the security properties of AES, and we have developed an implementation of this algorithm to both encrypt and decrypt messages given a plaintext or ciphertext and a key.
收購samsung’s bundled version of Baidu IME encrypts keystrokes by applying AESv1 in electronic codebook (ECB) mode in the following manner. First, the app uses the fixed 128-bit key, kf = “\xff\x9e\xd5H\x07Z\x10\xe4\xef\x06\xc7.\xa7\xa2\xf26”, to encrypt another, generated, key, km. The fixed key kf is the same key the BAIDUv3.1 protocol uses for AESv2 (see Figure 4). The encryption of km is stored in bytes 64 until 80 of each UDP packet’s payload. The key km is then used to encrypt the remainder of a zlib-compressed message payload, which is stored at byte 80 until the end of the UDP payload. We found that the encrypted payload included, in a binary container format which we did not recognize, our typed keystrokes as well as the name of the application into which we were typing them (see Figure 8).
0: [800,
1276,
10,
0,
“92F8EE78F1DDCBE74CFEB1166F70883D%7C0”,
“a1|SM-T220-gta7litewifi|320”,
“8.5.20.4”,
“com.android.settings.intelligence”,
“1012497q”,
“”,
“2你好惨又热大腿”,
“”],
1: [0, “”, “nihaocanyoureadthis”]
Figure 8:
The decrypted and decompressed payload, revealing what we had typed (“nihaocanyoureadthis”, highlighted) and the app into which it was typed (“com.android.settings.intelligence”); on top is a hex dump of, when decrypted and decompressed, the resulting proprietary binary blob, and below it is our understanding of how to parse it.
A vulnerability exists in the BAIDUv3.1+AESv1 scheme that allows a network eavesdropper to decrypt the contents of these messages. Since AES, including AESv1, is a symmetric encryption algorithm, the same key used to encrypt a message can also be used to decrypt it. Since kf is hard-coded, any network eavesdropper with knowledge of kf can decrypt km and thus decrypt the plaintext contents of each message encrypted in the manner described above. As we found that users’ keystrokes and the names of the applications they were using were sent in these messages, a network eavesdropper who is eavesdropping on a user’s network traffic can observe what that user is typing and into which application they are typing it by taking advantage of this vulnerability.
Additionally, in the version of Baidu Input Method distributed by
收購samsung, we found that key km was not securely generated using a secure pseudorandom number generator (secure PRNG). Instead, it was seeded using a custom-designed PRNG that we believe to have poor security properties, and, instead of using a high entropy seed, the PRNG generating km was seeded using the message plaintext. However, even without these weaknesses in the generation of km, the protocol is already completely insecure to network eavesdroppers as described in the previous paragraphs.
Huawei
We analyzed the keyboards preinstalled on our Huawei Mate 50 Pro test device. We found no vulnerabilities in the manner of transmission of users’ keystrokes in the versions of Huawei’s keyboard apps that we analyzed (see Table 7 for details). Specifically, Huawei used TLS to encrypt keystrokes in each version that we analyzed.
Platform
Application name
Package Name
Version analyzed
Secure?
HarmonyOS 4.0.0
搜狗输入法 (Sogou IME)
com.sohu.inputmethod.sogou
11.31
✔
HarmonyOS 4.0.0
小艺输入法 (Celia IME)
com.huawei.ohos.inputmethod
1.0.19.333
✔
Table 7: The versions of the Huawei keyboard apps analyzed.
Xiaomi
We analyzed the keyboards preinstalled on our Xiaomi Mi 11 test device. We found that they all include vulnerabilities that allow network eavesdroppers to decrypt network transmissions from the keyboards (see Table 8 for details). This means that network eavesdroppers can obtain sensitive personal information, including what users have typed.
Platform
Application name
Package Name
Version analyzed
Secure?
MIUI 14.0.31
百度输入法小米版 (Baidu IME Xiaomi Version)
com.baidu.input_mi
10.6.120.480
✘✘
MIUI 14.0.31
搜狗输入法小米版 (Sogou IME Xiaomi Version)
com.sohu.inputmethod.sogou.xiaomi
10.32.21.202210221903
✘
MIUI 14.0.31
讯飞输入法小米版 (iFlytek IME Xiaomi Version)
com.iflytek.inputmethod.miui
8.1.8014
✘✘
Table 8: The versions of the Xiaomi keyboard apps analyzed.
In this section we detail vulnerabilities in three different keyboard apps included with MIUI 14.0.31 in which users’ keystrokes can be, if necessary, decrypted, and read by network eavesdroppers.
百度输入法小米版 (“Baidu IME Xiaomi Version”, com.baidu.input_mi)
We found that Xiaomi’s Baidu-based keyboard app encrypts keystrokes using the BAIDUv3.1+AESv2 scheme which we detailed previously. When the app’s messages are decrypted and deserialized, we found that they include our typed keystrokes as well as the name of the application into which we were typing them (see Figure 9).
[…]
2 {
1: “nihaonihaoqqwerty”
}
3 {
1: 53
2: 10
3: 1080
4: 2166
5: 5
}
4 {
1: “DC0F75E6809F0FAAB46EDE2F2D6302ED%7CVAPBN4NOH”
2: “p-a1-3-66|2211133C|720”
3: “10.6.120.480”
4: “com.miui.notes”
5: “1000228c”
6: “\346\242\205\345\267\236”
}
[…]
Figure 9:
Excerpt of decrypted information, including what we had typed (“nihaonihaoqqwerty”) and the application into which it was typed (“com.miui.notes”).
Like we explained previously, a vulnerability exists in the BAIDUv3.1+AESv2 scheme that allows a network eavesdropper to decrypt the contents of these messages. As we found that users’ keystrokes and the names of the applications they were using were sent in these messages, a network eavesdropper who is eavesdropping on a user’s network traffic can observe what that user is typing and into which application they are typing it by taking advantage of this vulnerability.
搜狗输入法小米版 (“Sogou IME Xiaomi Version”, com.sohu.inputmethod.sogou.xiaomi)
The Sogou-based keyboard app is subject to a vulnerability which we have already publicly disclosed in Sogou IME (搜狗输入法) in which a network eavesdropper can decrypt and recover users’ transmitted keystrokes. Please see the corresponding details in this report for full details. Tencent responded by securing Sogou IME transmissions using TLS, but we found that Xiaomi’s Sogou-based keyboard had not been fixed.
讯飞输入法小米版 (“iFlytek IME Xiaomi Version”, com.iflytek.inputmethod.miui)
Similar to iFlytek’s own IME for Android, we found that Xiaomi’s iFlytek keyboard app used the same faulty encryption. We found that users’ keystrokes were sent to pinyin.voicecloud.cn and encrypted in this manner.
{“p”:{“m”:53,”f”:0,”l”:0},”i”:”nihaoniba”}
Figure 10:
Excerpt of decrypted information, including what we had typed (“nihaoniba”).
Therefore, a network eavesdropper who is eavesdropping on a user’s network traffic can observe what that user is typing by taking advantage of this vulnerability (see Figure 10).
OPPO
We analyzed the keyboard apps preinstalled on our OPPO OnePlus Ace test device. We found that they all include vulnerabilities that allow network eavesdroppers to decrypt network transmissions from the keyboards (see Table 9 for details). This means that network eavesdroppers can obtain sensitive personal information, including what users have typed.
Platform
Application name
Package Name
Version analyzed
Secure?
ColorOS 13.1
百度输入法定制版 (Baidu IME Custom Version)
com.baidu.input_oppo
8.5.30.503
✘✘
ColorOS 13.1
搜狗输入法定制版 (Sogou IME Custom Version)
com.sohu.inputmethod.sogouoem
8.32.0322.2305171502
✘
Table 9: The versions of the OPPO keyboard apps analyzed.
In this section we detail vulnerabilities in two different keyboard apps included with MIUI 14.0.31 in which users’ keystrokes can be, if necessary, decrypted, and read by network eavesdroppers.
百度输入法定制版 (“Baidu IME Custom Version”, com.baidu.input_oppo)
We found that OPPO’s Baidu-based keyboard app encrypts keystrokes using the BAIDUv3.1+AESv2 scheme which we detailed previously. When the app’s messages are decrypted and deserialized, we found that they include our typed keystrokes as well as the name of the application into which we were typing them (see Figure 11).
[…]
2 {
1: “nihaonihao”
}
3 {
1: 28
2: 10
3: 1240
4: 2662
5: 5
}
4 {
1: “47148455BDAEBA8A253ACBCC1CA40B1B%7CV7JTLNPID”
2: “p-a1-5-105|PHK110|720”
3: “8.5.30.503”
4: “com.android.mms”
5: “1021078a”
}
[…]
Figure 11:
Excerpt of decrypted information, including what we had typed (“nihaonihao”) and the application into which it was typed (“com.android.mms”).
Like we explained previously, a vulnerability exists in the BAIDUv3.1+AESv2 scheme that allows a network eavesdropper to decrypt the contents of these messages. As we found that users’ keystrokes and the names of the applications they were using were sent in these messages, a network eavesdropper who is eavesdropping on a user’s network traffic can observe what that user is typing and into which application they are typing it by taking advantage of this vulnerability.
搜狗输入法定制版 (“Sogou IME Custom Version”, com.sohu.inputmethod.sogouoem)
The Sogou-based keyboard app is subject to a vulnerability which we have already publicly disclosed in Sogou IME (搜狗输入法) in which a network eavesdropper can decrypt and recover users’ transmitted keystrokes. Please see the corresponding details in this report for full details. Tencent responded by securing Sogou IME transmissions using TLS, but we found that OPPO’s Sogou-based keyboard had not been fixed.
Vivo
We analyzed the keyboard apps preinstalled on our Vivo Y78+ test device. We found that the Sogou-based one includes vulnerabilities that allow network eavesdroppers to decrypt network transmissions from the keyboards (see Table 10 for details). This means that network eavesdroppers can obtain sensitive personal information, including what users have typed.
Platform
Keyboard name
Package Name
Version analyzed
Secure?
origin OS 3
搜狗输入法定制版 (Sogou IME Custom Version)
com.sohu.inputmethod.sogou.vivo
10.32.13023.2305191843
✘
origin OS 3
Jovi输入法 (Jovi IME)
com.vivo.ai.ime
2.6.1.2305231
✔
Table 10: The versions of the Vivo keyboard apps analyzed.
The Sogou-based keyboard app is subject to a vulnerability which we have already publicly disclosed in Sogou IME (搜狗输入法) in which a network eavesdropper can decrypt and recover users’ transmitted keystrokes. Please see the corresponding details in this report for full details. Tencent responded by securing Sogou IME transmissions using TLS, but we found that Vivo’s Sogou-based keyboard had not been fixed.
Honor
We analyzed the keyboard apps preinstalled on our Honor Play7T test device. We found that the Baidu-based one includes vulnerabilities that allow network eavesdroppers to decrypt network transmissions from the keyboards (see Table 11 for details). This means that network eavesdroppers can obtain sensitive personal information, including what users have typed.
Platform
Application name
Package Name
Version analyzed
Secure?
Magic UI 6.1.0
百度输入法荣耀版 (Baidu IME Honor Version)
com.baidu.input_hihonor
8.2.501.1
✘✘
Table 11: The versions of the Honor keyboard apps analyzed.
We found that Honor’s Baidu-based keyboard app encrypts keystrokes using the BAIDUv3.1+AESv2 scheme which we detailed previously. When the app’s messages are decrypted and deserialized, we found that they include our typed keystrokes as well as the name of the application into which we were typing them (see Figure 12).
[…]
2 {
1: “nihaonihaonihaoq”
5: 6422639
}
3 {
1: 91
2: 10
3: 720
4: 1552
5: 5
}
4 {
1: “A49AD3D3789A136975C2B28201753F03%7C0”
2: “p-a1-5-115|RKY-AN10|720”
3: “8.2.501.1”
4: “com.hihonor.mms”
5: “1023233d”
7: “A00-TWGTFEV5OFZ7WZ2AFN5TCDE4BPNO7XRZ-BVEZBI4D”
}
[…]
Figure 12:
Excerpt of decrypted information, including what we had typed (“nihaonihaonihaoq”) and the application into which it was typed (“com.hihonor.mms”).
Like we explained previously, a vulnerability exists in the BAIDUv3.1+AESv2 scheme that allows a network eavesdropper to decrypt the contents of these messages. As we found that users’ keystrokes and the names of the applications they were using were sent in these messages, a network eavesdropper who is eavesdropping on a user’s network traffic can observe what that user is typing and into which application they are typing it by taking advantage of this vulnerability.
As of April 1, 2024, “Baidu IME Honor Version”, the default IME on the Honor device we tested, is still vulnerable to passive decryption. We also discovered that on our Play7T device, there was no way to update “Baidu IME Honor Version” through the device’s app store. In responding to our disclosures, Honor asked us to disclose to Baidu and that it was Baidu’s responsibility to patch this issue.
Other affected keyboard apps
Given our limited resources to analyze apps, we were not able to analyze every cloud-based keyboard app available. Nevertheless, given that these vulnerabilities appeared to affect APIs that were used by multiple apps, we wanted to approximate the total number of apps affected by these vulnerabilities.
We began by searching VirusTotal, a database of software and other files that have been uploaded for automated virus scanning, for Android apps which reference the string “get.sogou.com”, the API endpoint used by Sogou IME, as these apps may require additional investigation to determine whether they are vulnerable. Excluding apps that we analyzed above, this search yielded the following apps:
com.sohu.sohuvideo
com.tencent.docs
com.sogou.reader.free
com.sohu.inputmethod.sogou.
收購samsung
com.sogou.text
com.sogou.novel
com.sogo.appmall
com.blank_app
com.sohu.inputmethod.sogou.nubia
com.sogou.androidtool
com.sohu.inputmethod.sogou.meizu
com.sohu.inputmethod.sogou.zte
sogou.mobile.explorer.hmct
sogou.mobile.explorer
com.sogou.translatorpen
com.sec.android.inputmethod.beta
com.sohu.inputmethod.sogou.meitu
com.sec.android.inputmethod
sogou.mobile.explorer.online
com.sohu.sohuvideo.meizu
com.sohu.inputmethod.sogou.oem
com.sogou.map.android.maps
sogou.llq.online
com.sohu.inputmethod.sogou.coolpad
com.sohu.inputmethod.sogou.chuizi
com.sogou.toptennews
com.sogou.recmaster
com.meizu.flyme.input
We have not analyzed these apps and thus cannot conclude that they are necessarily vulnerable, or even keyboard apps, but we provide this list to help reveal the possible scope of the vulnerabilities that we discovered. When we disclosed this list to Tencent, Tencent requested an additional three months to fix the vulnerabilities before we publicly disclosed this list, suggesting credence to the idea that apps in this list are largely vulnerable. Similarly, after excluding apps that we had already analyzed, the following are other Android apps which reference the strings “udpolimenew.baidu.com” or “udpolimeok.baidu.com”, the API endpoints used by Baidu Input Method:
com.adamrocker.android.input.simeji
com.facemoji.lite.xiaomi.gp
com.facemoji.lite.xiaomi
com.preff.kb.xm
com.facemoji.lite.transsion
com.txthinking.brook
com.facemoji.lite.vivo
com.baidu.input_huawei
com.baidu.input_vivo
com.baidu.input_oem
com.preff.kb.op
com.txthinking.shiliew
mark.via.gp
com.qinggan.app.windlink
com.baidu.mapauto
These findings suggest that a large ecosystem of apps may be affected by the vulnerabilities that we discovered in this report.
Coordinated disclosure
We reported the vulnerabilities that we discovered to each vendor in accordance with our vulnerability disclosure policy. All companies except Baidu, Vivo, and Xiaomi responded to our disclosures. Baidu fixed the most serious issues we reported to them shortly after our disclosure, but Baidu has yet to fix all issues that we reported to them. The mobile device manufacturers whose preinstalled keyboard apps we analyzed fixed issues in their apps except for their Baidu apps, which either only had the most serious issues addressed or, in the case of Honor, did not address any issues (see Table 12 for details). Regarding QQ Pinyin, Tencent indicated that “with the exception of end-of-life products, we aim to finalize the upgrade for all active products to transmit EncryptWall requests via HTTPS by the conclusion of Q1 [2024]”, but, as of April 1, 2024, we have not seen any fixes to this product. Tencent may consider QQ Pinyin end-of-life as it has not received updates since 2020, although we note that it is still available for download. For timelines and full correspondence of our disclosures to each vendor, please see the Appendix.
Legend
✘✘
working exploit created to decrypt transmitted keystrokes for both active and passive eavesdroppers
✘
working exploit created to decrypt transmitted keystrokes for an active eavesdropper
!
weaknesses present in cryptography implementation
✔
no known issues or all known issues fixed
N/A
product not offered or not present on device analyzed
Keyboard developer
Android
iOS
Windows
Tencent†
✘
N/A
✘
Baidu
!
!
!
iFlytek
✔
✔
✔
Pre-installed keyboard developer
Device manufacturer
Own
Sogou
Baidu
iFlytek
iOS
Windows
收購samsung
✔
✔*
!
N/A
N/A
N/A
Huawei
✔*
✔
N/A
N/A
N/A
N/A
Xiaomi
N/A
✔*
!
✔
N/A
N/A
OPPO
N/A
✔
!*
N/A
N/A
N/A
Vivo
✔*
✔
N/A
N/A
N/A
N/A
Honor
N/A
N/A
✘✘*
N/A
N/A
N/A
* Default keyboard app on our test device.
† Both QQ Pinyin and Sogou IME are developed by Tencent; in this report we analyzed QQ Pinyin and found the same issues as we had in Sogou IME.
Table 12: Status of vulnerabilities after disclosure as of April 1, 2024.
To summarize, we no longer have working exploits against any products except Honor’s keyboard app and Tencent’s QQ Pinyin. Baidu’s keyboard apps on other devices continue to contain weaknesses in their cryptography which we are unable to exploit at this time to fully decrypt users’ keystrokes in transit.
Barriers to users receiving security updates
Users can receive updates to their keyboard apps on their phones’ app stores, and such updates typically install in the background without user intervention. In our testing, updating keyboard apps was typically performed without friction. However, in some cases, a user may need to also ensure that they have fully updated their operating system before they will receive the fixes to our reported vulnerabilities for their keyboard app through the app store. In the case of the Honor device we tested, there was no update mechanism for the default keyboard used by the operating system through the app store. Honor devices bundled with a vulnerable version of the keyboard will remain vulnerable to passive decryption. In the case of the
收購samsung Galaxy Store, we found that on our device a user must sign in with a
收購samsung account before receiving security updates to their keyboard app. In the case the user does not have a
收購samsung account, then they must create one. We believe that installing important security updates should be frictionless, and we recommend that
收購samsung and app stores in general not require the registration of a user account before receiving important security updates.
We also learned from communication with
收購samsung’s security team that our test device had been artificially stuck on an older version of Baidu IME (version 8.5.20.4) compared to the one in the
收購samsung Galaxy Store. This is because, although the test device was using a Chinese ROM, we were prevented from receiving updates to Baidu IME because the app was geographically unavailable in Canada, where we were testing from.
收購samsung addressed this issue by adding Baidu’s keyboard app to the global market. Generally speaking, we recommend that
收購samsung and other app stores do not geoblock security updates to apps that are already installed.
Language barriers in responsible disclosures
We suspect that a language barrier may have prevented iFlytek from responding to our initial disclosure in English. After we did not receive a response for one month, we re-sent the same disclosure e-mail, but with a subject line and one-sentence summary in simplified Chinese. iFlytek responded within three days of this second email and promptly fixed the issues we noted. All future disclosure emails to the Chinese mobile device manufacturers were then written with Chinese subject lines and a short summary in Chinese. Though obvious in hindsight, we encourage security researchers to consider if the company to which they are disclosing uses a different language than the researcher. We suggest submitting vulnerability disclosures, at the very least, with short summaries and email subject lines in the official language of the company’s jurisdiction to prevent similar delays as we may have encountered in disclosure timelines.
Limitations
In this report we detail vulnerabilities relating to the security of the transmission of users’ keystrokes in multiple keyboard apps. In this work we did not perform a full audit of any app or make any attempt to exhaustively find every security vulnerability in any software. Our report concerns analyzing keyboard apps for a class of vulnerabilities that we discovered, and the absence of our reporting of other vulnerabilities should not be considered evidence of their absence.
Discussion
In this section we discuss the impact of the vulnerabilities that we found, speculate as to the factors that gave rise to them, and conclude by introducing possible ways to systemically prevent such vulnerabilities from arising in the future.
Impact of these vulnerabilities
The scope of these severe vulnerabilities cannot be overstated: until this and our previous Sogou report, the majority of Chinese mobile users’ keystrokes were decryptable by network adversaries. The keyboards we studied comprise over 95% of the third-party IME market share, which is estimated to be over 780 million users by marketing agencies. In addition, the three phone manufacturers which pre-installed and by default used vulnerable keyboard apps comprise nearly 50% of China’s smartphone market.
The vulnerabilities that we discovered would be inevitably discovered by anyone who thinks to look for them. Furthermore, the vulnerabilities do not require technological sophistication to exploit. With the exception of the vulnerability affecting many Sogou-based keyboard apps that we previously discovered, all of the vulnerabilities that we covered in this report can be exploited entirely passively without sending any additional network traffic. This also means any existing logs of network data sent by these keyboards can be decrypted in the future. As such, we might wonder, are these vulnerabilities actively under mass exploitation?
Figure 13: Locations of XKEYSCORE servers as described in a 2008 NSA slide deck.
While many governments may possess sophisticated mass surveillance capabilities, the Snowden revelations gave us unique insight into the capabilities of the United States National Security Agency (NSA) and more broadly the Five Eyes. The revelations disclosed, among other programs, an NSA program called XKEYSCORE for collecting and searching Internet data in realtime across the globe (see Figure 13). Leaked slides describing the program specifically reveal only a few examples of XKEYSCORE plugins. However, one was a plugin that was written by a Five Eyes team to take advantage of vulnerabilities in the cryptography of Chinese-developed UC Browser to enable the Five Eyes to collect device identifiers, SIM card identifiers, and account information pertaining to UC Browser users (see Figure 14 for an illustration).
Figure 14: The dashboard of an XKEYSCORE plugin used to monitor for transmissions of sensitive data insufficiently encrypted by UC Browser as described in a 2012 Five Eyes slide deck.
The similarity of the vulnerability exploited by this XKEYSCORE plugin and the vulnerabilities described in this report are uncanny, as they are all vulnerabilities in the encryption of sensitive data transmissions in software predominantly used by Chinese users. Given the known capabilities of XKEYSCORE, we surmise that the Five Eyes would have the capability to globally surveil the keystrokes of all of the keyboard apps that we analyzed with the exception of Sogou and the apps licensing its software. This single exception exists because Sogou cannot be monitored passively and would require sending packets to Sogou servers. Such communications would be measurable at Sogou’s servers and at other vantage points, potentially revealing the Five Eyes’s target(s) of surveillance to Sogou or Chinese network operators. Therefore, targets of outdated Sogou software would be undesirable victims of mass surveillance, even if such non-passive measurements were within the known capabilities of XKEYSCORE or other Five Eyes programs.
Given the enormous intelligence value of knowing what users are typing, we can conclude that not only do the NSA and more broadly the Five Eyes have the capabilities to mass exploit the vulnerabilities we found but also the strong motivation to exploit them. If the Five Eyes’ capabilities are an accurate reflection of the capabilities and motivations of other governments, then we can assume that many other governments are also capable and motivated to mass exploit these vulnerabilities. The only remaining question is whether any government had knowledge of these vulnerabilities. If they did not have such knowledge before our original report analyzing Sogou, they may have acquired after it in the same way that our original research inspired us to look at similar keyboard apps for analogous vulnerabilities. Unfortunately, short of future government leaks, we may never know if or to what extent any state actors mass exploited these vulnerabilities.
Even though we disclosed the vulnerabilities to vendors, some vendors failed to fix the issues that we reported. Moreover, users of devices which are out of support or that otherwise no longer receive updates may continue to be vulnerable. As such, many users of these apps may continue to be under mass surveillance for the foreseeable future.
How did these vulnerabilities arise
We analyzed a broad sample of Chinese keyboard apps, finding that they are almost universally vulnerable to having their users’ keystrokes being decrypted by network eavesdroppers. Yet there is no common library or a single implementation flaw responsible for these vulnerabilities. While some of the keyboard apps did license their code from other companies, our overall findings can only be explained by a large number of developers independently making the same kind of mistake. As such, we might ask, how could such a large number of independent developers almost universally make such a critical mistake?
One attempt to answer this question is to suggest that these were not mistakes at all but deliberate backdoors introduced by the Chinese government. However, this hypothesis is rather weak. First, user keystroke data is already being sent to servers within Chinese legal jurisdiction, and so the Chinese government would have access to such data anyways. Second, the vulnerabilities that we found give the ability not just to the Chinese government to decrypt transmitted keystrokes but to any other actor as well. In an ideal backdoor, the Chinese government would want the desirable property that only they have access to the backdoor. Finally, the Chinese government has made strides to study and improve the data security of apps developed and used in China, attempting to prevent and fix the very sort of vulnerabilities which we discovered. For instance, a 2020 report from CNCERT/CC found that 60 percent of the 50 banking applications that they investigated did not encrypt any user data transmitted over the network, among a litany of other common security issues.
Were Chinese app developers skeptical of using cryptographic standards perceived as “Western”? Countries such as China and Russia have their own encryption standards and ciphers. To our knowledge none of the faulty encryption implementations that we analyzed adhered to any sort of known standard in any country, and each appeared to be home-rolled ciphers. However, it is possible that Asian developers are less inclined to use encryption standards that they fear may contain backdoors such as the potential Dual_EC_DRBG backdoor.
Perhaps Chinese app developers could be skeptical of standards such as SSL/TLS as well. The TLS ecosystem has also only become nearly-universal in the past decade. Especially before broad oversight of certificate authorities became commonplace, there were many valid criticisms of the SSL/TLS ecosystem. In 2011, digital rights organizations EFF and Access Now were both concerned about the certificate authority (CA) infrastructure underpinning SSL/TLS transport encryption. Even today, the vast majority of root certificates trusted by major OSes and browsers are operated by certificate authorities based in the Global North. We also note that all of the IMEs containing vulnerabilities were first released before 2013 and likely had a need for secure network transmission before SSL/TLS became the de-facto standard for strong transport encryption.
Still, it has been a decade since the Snowden leaks demonstrated the global, urgent, and practical need for strong encryption of data-in-transit in 2013, and the TLS ecosystem has largely stabilized, with CA root lists of many major browsers and OSes controlled by voting bodies and certificate transparency deployed. As of 2024, almost 95% of web traffic from users of Firefox in the United States is traveling over HTTPS. In addition, the speed in which both iFlytek and Sogou switched to TLS demonstrates that making the change to standard TLS is not necessarily a time or resource issue. Even if skepticism towards SSL/TLS explains the reluctance to adopt it in the early 2010s, we are not sure why there is much more inertia in the Chinese Internet ecosystem against making the switch to TLS.
Finally, mobile devices and other operating systems are still incapable of guaranteeing the security of data under transmission, despite iOS and Android having introduced restrictions into their APIs. For instance, iOS 9 implemented App Transport Security, a policy placing restrictions on the ability to transmit data without TLS. However, there are two limitations of this technology. First, an app can specify exceptions to this policy in its Info.plist resource. Second, the policy affects high level APIs and leaves communications over lower level socket-based APIs unregulated. Similar to iOS, Android 9 disables cleartext traffic using certain high level APIs by default, but an app may exclude specific domains or avoid the policy by using lower level APIs.
Can we systemically address these vulnerabilities?
Individually analyzing apps for this class of vulnerabilities and individually reporting issues discovered is limited in the scale of apps that it can fix. First, while we can attempt to manually analyze some of the most popular keyboard apps, we will never be able to analyze every app at large. Second, we might not be able to predict which apps to look at in the first place. For instance, before we analyzed Sogou and the keyboard apps featured in this report, we never would have expected that their network transmissions would be so easily vulnerable to interception. In light of the limitations of the methods that we employed in this report, in the remainder of this section we discuss possibilities for how we might systematically or wholesale address apps which transmit sensitive data over networks without sufficient encryption.
By security researchers paying more attention to the Chinese Internet
There appears to be a general failure of researchers to analyze Chinese apps and the Chinese Internet ecosystem at large, despite its size and influence. The Google Play Store and Apple App Store ecosystems, for instance, are commonly studied by privacy researchers, but many Chinese app stores are overlooked, despite that many popular Chinese apps have more users than their counterparts on the Google Play Store. While the vulnerabilities that we discovered were not all trivial to find and many took substantial analysis to attack, most would have been inevitably discovered by any researcher analyzing these apps for data security. A researcher studying network traffic from users of Chinese devices could also have identified strange, non-standard traffic.
By using app store enforcement
One might call on app stores to enforce the use of sufficient encryption to protect sensitive data in transit. App stores already have a number of rules that they enforce through a combination of automated and manual review. Calling on app stores to enforce sufficient encryption of in-transit sensitive data is tempting given the resources of the companies operating the app stores. However, failing any other innovation, the same scaling issues that apply to other researchers studying these apps will apply to those working for these companies.
By using device permission models
On Android devices, installing any keyboard, regardless of whether or how it communicates with servers over the Internet, brings up a pop-up with the following text:
This input method may be able to collect all the text you type, including personal data like passwords and credit card numbers.
The wording of these warning messages is overbroad and does not necessarily help users distinguish between keyboards that transmit keystrokes over the network, keyboards that transmit keystrokes insecurely (using something other than standard TLS) over the network, and keyboards that do not transmit any data at all.
iOS devices, on the other hand, sandbox their keyboards by default. There is a “Full Access” or “open access” permission that must be explicitly granted to keyboards before they have network access, among other privileges. Without this permission, third-party keyboards cannot transmit network data. We recommend Android also adopt a more fine-grained permission model for keyboards.
Furthermore, the vulnerable apps that we studied transmit data using low level socket APIs versus higher level APIs that require the usage of TLS or HTTPS. One might desire that separate system calls be designed for TLS or HTTPS traffic in addition to the lower level socket system calls so that devices could implement an UNSAFE_INTERNET permission that would be required for apps to use the lower level system calls while still allowing TLS-encrypted traffic for apps that do not have this permission.
While this approach may have some merit, it also has certain drawbacks. It makes sense for situations where apps are untrustworthy and the operating system is completely trustworthy, but there are common situations where the operating system could be not as or even less trustworthy than apps that it is running. One common case would be a user who is running an up-to-date app on an out of date operating system, possibly because the user’s device is no longer receiving operating system updates. In such a case, the app’s implementation of TLS is more likely to be secure than that of the operating system. Furthermore, a user’s operating system may be compromised by malware or otherwise be untrustworthy in itself. Introducing a TLS system call would centralize the encryption of all sensitive data and grant the operating system easy visibility into all unencrypted data. In any case, innovating in areas of encryption is an important right of application developers, and it may not make sense to stifle apps like Signal because of their use of end-to-end or other novel encryption by requiring them to obtain an UNSAFE_INTERNET permission.
One might alternatively desire for apps at large to not be able to access the Internet at all. Instead of an UNSAFE_INTERNET permission, what about introducing an INTERNET permission to govern all Internet socket access, similar to the “Full Access” permission which iOS already applies to keyboard apps? Android devices in fact already have such a permission that apps must request to use Internet (AF_INET) sockets, but it is not a permission that is exposed to ordinary users either in the Google Play Store or through any stock Android user interface, and it is automatically granted when installing an app. Unfortunately, given all of the interprocess communication (IPC) vehicles on modern smart devices, restricting Internet socket access may not guarantee that the app could not communicate over the Internet (e.g., through Google Play services). GrapheneOS, an open source Android-based operating system, implements a NETWORK permission. However, denying this permission can lead to surprising results where apps can still communicate with the Internet via IPC with other apps. As such, we recommend that both the developers of Android and iOS work toward a meaningful INTERNET permission that would adequately inform users of whether an app communicates over the Internet.
By international standards bodies better engaging with Chinese developers
We encourage International standards bodies like the IETF to continue to engage and outreach Chinese Internet companies and engineers in good faith to further reduce friction in cross-linguistic knowledge transfer. The presence of these similar but independent vulnerabilities demonstrate that there is a friction in the transfer and implementation of knowledge between the English-speaking cryptography community and the Chinese cryptography community. For instance, Schneier’s Law or the oft-repeated mantra “don’t roll your own crypto” may be common knowledge to cryptographers trained in English, but perhaps lost in translation. A lag across linguistic boundaries means that general information like the recent stabilization of TLS and webPKI infrastructure may travel more slowly, and updating encryption software to reflect new information may lag even further behind. One other possible example of this phenomenon is that, according to Firefox Telemetry, up until 2020, the Japanese Internet ecosystem also significantly lagged behind the global average in HTTPS adoption.
Although protocols put out by IETF and other International standards bodies can be far from bulletproof, these bodies can still help facilitate international communication about the current state-of-the-art in protocol encryption. The burden of cross-linguistic and cross-cultural exchange on technical standards falls on global standards bodies. Western media outlets and researchers tend to uniformly attribute the actions and participation of private Chinese companies within standards bodies to government actors seeking sovereignty over Internet standards. While skepticism may be warranted in certain cases, there is also research that challenges a simplistic and overbroad narrative. As a single data point, we note that we did not find these issues in Huawei’s keyboards, whose employees are often noted as especially active participants in IETF standard-setting.
By using automated static or dynamic analysis
There has been a failure of automated tools to detect insecure traffic at large. Longitudinal TLS telemetry has largely been focused on web-based perspectives (i.e., how many domains support TLS or how many web connections are encrypted by TLS?), and the mobile perspective is often overlooked, despite the increasing dominance of mobile traffic globally. Although there are some research projects that survey TLS usage in Android mobile apps at scale, there is no public longitudinal data from these projects (i.e., they are run as one-off studies), and many focus on the Google Play’s Android ecosystem, thereby excluding the Chinese mobile Internet. There is perhaps a need for public longitudinal TLS telemetry for popular mobile applications globally, via automated static or dynamic analysis at scale.
By using attestations in app stores
Another way for users to gain visibility into the security and privacy properties of their apps is through the use of developer attestations, such as the ones that appear in data safety sections in many popular app stores. Both the Apple App Store and the Google Play Store collect and display such attestations to varying extents, including attestations as to what data an app collects (if any) and with whom it is shared (if anyone). Additionally, the Play Store allows developers the opportunity to attest to performing “encryption in transit” (see Figure 15 for an example). These attestations allow users to clearly see what security and privacy properties an app’s developer claims it to have and, like privacy policies, they provide means of redress if violated.
Figure 15: An example of an attestation for Microsoft SwiftKey.
We wanted to evaluate whether the apps that we analyzed lived up to their attestations concerning their encryption in the app stores in which they are available. Among the apps that we analyzed, only Baidu IME was available in the Play Store. At the time of this writing, it does not attest to its data being encrypted in transit. Although other apps that we analyzed were available in Apple’s App Store, to our knowledge, this store does not display an attestation for whether the app encrypts data in transit. As such, across both the Google Play and the Apple App stores, attestations were insufficient for compelling the keyboard apps’ developers to implement proper encryption or in providing users any opportunity for redress.
In light of the above findings, we believe that users would benefit from the following recommendations: (1) that app store operators require developers to attest to whether or not an app encrypts data in transit, (2) that app store operators display not only when developers attest to all data being encrypted in transit but also display a warning when they fail to, and (3) that app store operators require apps in certain sensitive categories, such as keyboard apps, to either positively attest to encrypting all data in transit or to attest to not transmitting any data at all.
Since most of the apps that we found perform some type of encryption, even if it were wholly inadequate, one might wonder if attesting that data is merely “encrypted” is enough, since the data arguably did have some manner of encryption applied to it during transit. The Play Store provides some guidance on this topic. Under the question — “How should I encrypt data in transit?” — the documentation notes: “You should follow best industry standards to safely encrypt your app’s data in transit. Common encryption protocols include TLS (Transport Layer Security) and HTTPS.”
Another issue with attestations is that they provide no guarantee that an app behaves as its developers attest, as developers can, after all, make false attestations. While we wish that attestations could guarantee that an app sufficiently implements proper cryptography to the same extent that a permission system can guarantee an app does not use a microphone, false attestations provide an opportunity for redress. For instance, apps which are found to violate attestations would be subject to removal from app stores. Furthermore, apps which violate attestations could be subject to fines by regulatory bodies such as the FTC. Finally, apps which violate the attestation could be liable to civil suits.
While the apps we analyzed were predominantly available from Chinese app stores, we equally recommend that Chinese app stores adopt these recommendations in addition to the Apple App Store and the Google Play Store. Moreover, while this report focuses on the problem of poor encryption practices as it applies to Chinese apps, the problem to varying extents applies to apps of all other provenances.
Summary of recommendations
We conclude our report by summarizing our recommendations to multiple stakeholders.
Recommendations to security researchers
Researchers should analyze more apps from the East Asian app ecosystem and from other popular ecosystems which may be outside of their own locale.
Researchers should develop better static and dynamic analysis techniques to recognize the types of vulnerabilities that we discovered in this report at scale.
Researchers submitting vulnerability disclosures to a company should include short summaries and email subject lines in the official language of the company’s jurisdiction.
Recommendations to international standards bodies
International standards bodies should continue to engage with security engineers from Chinese Internet companies.
Recommendations to app store operators
App stores should not require account registration as a condition to receive security updates.
App stores should not geoblock security updates.
App stores should allow developers to attest to all data being transmitted with encryption, similar to the ability in the Google Play Store.
App stores should display not only when developers attest to all data being encrypted in transit but also display a warning when they fail to.
App stores should require apps in certain sensitive categories, such as keyboard apps, to either positively attest to encrypting all data in transit or to attest to not transmitting any data at all.
Recommendations to keyboard app developers
Use well-tested and standard encryption protocols, like TLS or QUIC.
Make every attempt to provide features on-device without requiring transmitting sensitive data to cloud servers.
Recommendations to mobile operating system developers
Android should implement sandboxing by default for keyboard apps, similar to iOS, that prevents a keyboard from transmitting network traffic among other activities until a user grants the app full access.
The developers of Android and iOS should work toward a meaningful INTERNET permission that would adequately inform users of whether any app communicates over the Internet.
Recommendations to device manufacturers
Conduct security audits of third-party keyboards that you intend to pre-install by default on your operating systems.
Recommendations to users
Users of Honor’s pre-installed keyboard or users of QQ pinyin should switch keyboards immediately.
Users of any Sogou, Baidu, or iFlytek keyboard, including the versions that are bundled or pre-installed on operating systems, should ensure their keyboards and operating systems are up-to-date.
Users of any Baidu IME keyboard should consider switching to a different keyboard or disabling the “cloud-based” feature.
Users with privacy concerns should not enable “cloud-based” features on their keyboards or IMEs or should switch to a keyboard that does not offer “cloud-based” prediction.
iOS users with privacy concerns should not enable “Full Access” for their keyboards or IMEs.
Acknowledgments
We would like to thank Jedidiah Crandall, Jakub Dalek, Pellaeon Lin, and Sarah Scheffler for their guidance and review of this report. Research for this project was supervised by Ron Deibert.
Appendix
Known affected software
We recommend that all users keep their operating systems and apps, including keyboard apps, up to date. If you use any of the following software, we especially recommend you update to the most recent version of your OS and application. As of April 1, 2024, the following software has fixes available:
Separately installed, third-party keyboards
Sogou IME / 搜狗输入法 for Android and Windows
Baidu IME / 百度输入法 for Windows (this software has only been partially fixed, see below)
iFlytek IME / 讯飞输入法 for Android
Pre-installed on
收購samsung devices with Chinese edition ROM
收購samsung Keyboard
Baidu IME / 百度输入法
Pre-installed on Xiaomi devices with Chinese edition ROM
Sogou IME Xiaomi Version / 搜狗输入法小米版
iFlytek IME Xiaomi Version / 讯飞输入法小米版
Pre-installed on OPPO devices with Chinese edition ROM
Sogou IME Custom Version / 搜狗输入法定制版
Pre-installed on Vivo devices with Chinese edition ROM
Sogou IME Custom Version / 搜狗输入法定制版
The following software does not use TLS and may still contain weaknesses:
Separately installed, third-party keyboards
Baidu IME / 百度输入法 for Android, Windows, and iOS
Pre-installed on Xiaomi devices with Chinese edition ROM
Baidu IME Xiaomi Version / 百度输入法小米版
Pre-installed on OPPO devices with Chinese edition ROM
Baidu IME Custom Version / 百度输入法定制版
The following software has not been fixed and is easily exploitable, and we suggest that users switch to another keyboard entirely:
Separately installed, third-party keyboards
QQ Pinyin IME / QQ拼音输入法 for Android and Windows
Pre-installed on Honor devices with Chinese edition ROM
Baidu IME Honor Version / 百度输入法荣耀版
Disclosure timelines
Baidu
The Citizen Lab to Baidu — October 3, 2023
We sent the following via email:
To: [email protected], [email protected]
Subject: Security issue in Baidu Input Method
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed Baidu Input Method as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found that Baidu Input Method for Windows includes a vulnerability which allows network eavesdroppers to decrypt network transmissions. This means third parties can obtain sensitive personal information including what users have typed. We also found privacy and security weaknesses in the encryption used by the Android and iOS versions of Baidu Input Method. To address these issues, we suggest using HTTPS or TLS rather than custom-designed network protocols. For further details, please see the attached document.
Background
The Citizen Lab is committed to research transparency and will publish details regarding the security vulnerabilities it discovers in the context of its research activities, absent exceptional circumstances, on its website: https://citizenlab.ca/.
If no response is received to this disclosure, the Citizen Lab will publish details regarding the security vulnerability on its website after 15 calendar days from the date of this communication. In other words, where there is no response from you, Citizen Lab will publish details regarding the vulnerability after October 18 2023.
If a substantive response is received (which excludes, for example, an auto reply) to this disclosure within 15 calendar days from the date of this communication, the Citizen Lab will provide you with 45 calendar days from the date of this communication to fix (whether in whole or in part) the vulnerability before publicly disclosing the issue. In other words, where we do receive a substantive response from you, the Citizen Lab will publish details regarding the vulnerability after November 17 2023.
We reserve the right to publish details regarding the vulnerability to the general public before the expiry of the 45 calendar days set out above in the following situations: (1) you have disclosed the vulnerability to the general public, (2) you have patched the vulnerability, (3) you have taken the position that there is no security vulnerability, or (4) the Citizen Lab observes the vulnerability is under active exploitation.
All communications associated with this disclosure may be included in the Citizen Lab’s public disclosure of this vulnerability.
Next steps
Please communicate what steps you will take to address the vulnerability that we have described, and please provide the timeline you decide upon for the implementation of fixes.
Finally, upon implementation of any fixes, we ask that you communicate the full extent of the vulnerability to the Citizen Lab.
Should you have any questions about our findings please let us know. We can be reached at this email address: [email protected].
Sincerely,
The Citizen Lab
The Citizen Lab to Baidu — November 22, 2023
We sent the following via email:
To: [email protected], [email protected]
Subject: Security issues in Baidu Input Method / 百度输入法高危漏洞
多伦多大学的研究人员发现许多手机预装的百度输入法存在高危漏洞，让网络攻击者可以直接看到用户输入的内容。同时也发现百度输入法的安卓版、iOS版、和Windows版存在另外与安全相关的问题，建议切换到TLS。本文用英文解释了研究人员发现漏洞的细节。
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed Baidu Input Method as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found multiple third-party apps using the Baidu Input Method API include a vulnerability which allows network eavesdroppers to decrypt network transmissions. This means third parties can obtain sensitive personal information including what users have typed. We also found privacy and security weaknesses in the encryption used by the Windows, Android, and iOS versions of Baidu Input Method. To address these issues, we suggest using HTTPS or TLS rather than custom-designed network protocols. For further details, please see the attached document.
Background
The Citizen Lab is committed to research transparency and will publish details regarding the security vulnerabilities it discovers in the context of its research activities, absent exceptional circumstances, on its website: https://citizenlab.ca/.
If no response is received to this disclosure, the Citizen Lab will publish details regarding the security vulnerability on its website after 15 calendar days from the date of this communication. In other words, where there is no response from you, Citizen Lab will publish details regarding the vulnerability after December 7 2023.
If a substantive response is received (which excludes, for example, an auto reply) to this disclosure within 15 calendar days from the date of this communication, the Citizen Lab will provide you with 45 calendar days from the date of this communication to fix (whether in whole or in part) the vulnerability before publicly disclosing the issue. In other words, where we do receive a substantive response from you, the Citizen Lab will publish details regarding the vulnerability after January 6 2024.
We reserve the right to publish details regarding the vulnerability to the general public before the expiry of the 45 calendar days set out above in the following situations: (1) you have disclosed the vulnerability to the general public, (2) you have patched the vulnerability, (3) you have taken the position that there is no security vulnerability, or (4) the Citizen Lab observes the vulnerability is under active exploitation.
All communications associated with this disclosure may be included in the Citizen Lab’s public disclosure of this vulnerability.
Next steps
Please communicate what steps you will take to address the vulnerability that we have described, and please provide the timeline you decide upon for the implementation of fixes.
Finally, upon implementation of any fixes, we ask that you communicate the full extent of the vulnerability to the Citizen Lab.
Should you have any questions about our findings please let us know. We can be reached at this email address: [email protected].
Sincerely,
The Citizen Lab
Honor
The Citizen Lab to Honor — November 22, 2023
We sent the following via email:
To: [email protected]
Subject: Security issues in Honor keyboard / 荣耀百度输入法高危漏洞
总结：多伦多大学的研究人员发现荣耀预装的百度输入法使用的加密协议有高危漏洞，让网路攻击者可以直接看到用户输入的内容。本文用英文解释了研究人员发现高危漏洞的细节。
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed Honor pre-installed keyboard apps as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found that the Baidu-based one includes vulnerabilities that allow network eavesdroppers to decrypt network transmissions. This means third parties can obtain sensitive personal information including what users have typed. To address these issues, we suggest using HTTPS or TLS rather than custom-designed network protocols. For further details, please see the attached document.
Background
The Citizen Lab is committed to research transparency and will publish details regarding the security vulnerabilities it discovers in the context of its research activities, absent exceptional circumstances, on its website: https://citizenlab.ca/.
If no response is received to this disclosure, the Citizen Lab will publish details regarding the security vulnerability on its website after 15 calendar days from the date of this communication. In other words, where there is no response from you, Citizen Lab will publish details regarding the vulnerability after December 7 2023
If a substantive response is received (which excludes, for example, an auto reply) to this disclosure within 15 calendar days from the date of this communication, the Citizen Lab will provide you with 45 calendar days from the date of this communication to fix (whether in whole or in part) the vulnerability before publicly disclosing the issue. In other words, where we do receive a substantive response from you, the Citizen Lab will publish details regarding the vulnerability after January 6 2024
We reserve the right to publish details regarding the vulnerability to the general public before the expiry of the 45 calendar days set out above in the following situations: (1) you have disclosed the vulnerability to the general public, (2) you have patched the vulnerability, (3) you have taken the position that there is no security vulnerability, or (4) the Citizen Lab observes the vulnerability is under active exploitation.
All communications associated with this disclosure may be included in the Citizen Lab’s public disclosure of this vulnerability.
Next steps
Please communicate what steps you will take to address the vulnerability that we have described, and please provide the timeline you decide upon for the implementation of fixes.
Finally, upon implementation of any fixes, we ask that you communicate the full extent of the vulnerability to the Citizen Lab.
Should you have any questions about our findings please let us know. We can be reached at this email address: [email protected].
Sincerely,
The Citizen Lab
Honor to The Citizen Lab — November 23, 2023
We received the following email:
From: security
Subject: 答复: Security issues in Honor keyboard / 荣耀百度输入法高危漏洞
DEAR Citizen Lab
Thank you very much for your concern about the security of Honor.
Honor always attaches great importance to the security of products and services. In order to respond to your security concerns immediately,
we have set up a professional vulnerability response team to serve you and set up an email ([email protected]) for quick response.
We are analyzing the impact of these security issue and will reach a conclusion as soon as possible.
Once again thank you for your concern about the security of Honor. If you have any questions, feel free to contact us through this email at any time.
Honor Security Response Center
Honor to The Citizen Lab — December 5, 2023
We received the following email:
From: security
Subject: 答复: Security issues in Honor keyboard / 荣耀百度输入法高危漏洞
DEAR Citizen Lab
Thank you very much for your report and your patience.
Honor always attaches great importance to the security of products and services. In order to respond to your security concerns immediately,
we have set up a professional vulnerability response team to serve you and set up an email ([email protected]) for quick response.
After our analysis. Baidu is a vendor of Honor, we relied on the vendor to patch this issue. We recommend that you submit this issue to Baidu and negotiate a disclosure plan with Baidu.
Once again thank you for your concern about the security of Honor. If you have any questions, feel free to contact us through this email at any time.
Honor Security Response Center
The Citizen Lab to Honor — March 7, 2024
We sent the following email:
To: security
Subject: Re: Security issues in Honor keyboard / 荣耀百度输入法高危漏洞
Dear Honor Security Response Center,
We have tried disclosing these issues to Baidu, but Baidu has been so far unresponsive to our disclosures.
We would like to note that our Honor Play7T device is still using an older version (v8.2.501.1) of the com.baidu.input_hihonor app. While the latest version of Baidu’s keyboard does not address all of the issues that we have reported, it does contain fixes for the most serious issues. Therefore, we recommend updating the com.baidu.input_hihonor app to the latest version of Baidu’s keyboard.
Sincerely,
The Citizen Lab
iFlytek
The Citizen Lab to iFlytek — September 8, 2023
We sent the following via email:
To: [email protected]
Subject: Security issue in Xunfei Input Method
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed Xunfei Input Method on Android as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found that Xunfei Input Method for Android includes a vulnerability which allows network eavesdroppers to recover the plaintext of insufficiently encrypted network transmissions, revealing sensitive information including what users have typed.
For further details, please see the attached document.
Background
The Citizen Lab is committed to research transparency and will publish details regarding the security vulnerabilities it discovers in the context of its research activities, absent exceptional circumstances, on its website: https://citizenlab.ca/.
If no response is received to this disclosure, the Citizen Lab will publish details regarding the security vulnerability on its website after 15 calendar days from the date of this communication. In other words, where there is no response from you, Citizen Lab will publish details regarding the vulnerability after September 23, 2023.
If a substantive response is received (which excludes, for example, an auto reply) to this disclosure within 15 calendar days from the date of this communication, the Citizen Lab will provide you with 45 calendar days from the date of this communication to fix (whether in whole or in part) the vulnerability before publicly disclosing the issue. In other words, where we do receive a substantive response from you, the Citizen Lab will publish details regarding the vulnerability after October 23, 2023.
We reserve the right to publish details regarding the vulnerability to the general public before the expiry of the 45 calendar days set out above in the following situations: (1) you have disclosed the vulnerability to the general public, (2) you have patched the vulnerability, (3) you have taken the position that there is no security vulnerability, or (4) the Citizen Lab observes the vulnerability is under active exploitation.
All communications associated with this disclosure may be included in the Citizen Lab’s public disclosure of this vulnerability.
Next steps
Please communicate what steps you will take to address the vulnerability that we have described, and please provide the timeline you decide upon for the implementation of fixes.
Finally, upon implementation of any fixes, we ask that you communicate the full extent of the vulnerability to the Citizen Lab.
Should you have any questions about our findings please let us know. We can be reached at this email address: [email protected].
Sincerely,
The Citizen Lab
The Citizen Lab to iFlytek — September 25, 2023
We sent the following via email:
To: [email protected]
Subject: Security issue in Xunfei Input Method
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed Xunfei Input Method on Android as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found that Xunfei Input Method for Android includes a vulnerability which allows network eavesdroppers to recover the plaintext of insufficiently encrypted network transmissions, revealing sensitive information including what users have typed. For further details, please see the attached document.
On September 8 2023 we attempted to disclose these vulnerabilities to [email protected], an email address listed on the product’s Web page, but we have not received a response. If you are not able to process vulnerability disclosures for this product, please ensure that this disclosure is delivered to someone who can.
Background
The Citizen Lab is committed to research transparency and will publish details regarding the security vulnerabilities it discovers in the context of its research activities, absent exceptional circumstances, on its website: https://citizenlab.ca/.
If no response is received to this disclosure, the Citizen Lab will publish details regarding the security vulnerability on its website after 15 calendar days from the date of this communication. In other words, where there is no response from you, Citizen Lab will publish details regarding the vulnerability after October 10, 2023.
If a substantive response is received (which excludes, for example, an auto reply) to this disclosure within 15 calendar days from the date of this communication, the Citizen Lab will provide you with 45 calendar days from the date of this communication to fix (whether in whole or in part) the vulnerability before publicly disclosing the issue. In other words, where we do receive a substantive response from you, the Citizen Lab will publish details regarding the vulnerability after November 9, 2023.
We reserve the right to publish details regarding the vulnerability to the general public before the expiry of the 45 calendar days set out above in the following situations: (1) you have disclosed the vulnerability to the general public, (2) you have patched the vulnerability, (3) you have taken the position that there is no security vulnerability, or (4) the Citizen Lab observes the vulnerability is under active exploitation.
All communications associated with this disclosure may be included in the Citizen Lab’s public disclosure of this vulnerability.
Next steps
Please communicate what steps you will take to address the vulnerability that we have described, and please provide the timeline you decide upon for the implementation of fixes.
Finally, upon implementation of any fixes, we ask that you communicate the full extent of the vulnerability to the Citizen Lab.
Should you have any questions about our findings please let us know. We can be reached at this email address: [email protected].
Sincerely,
The Citizen Lab
The Citizen Lab to iFlytek — November 3, 2023
We sent the following via email:
To: [email protected], [email protected]
Subject: 讯飞输入法高危漏洞
多伦多大学的研究人员发现讯飞输入法使用的加密协议存在高危漏洞，让网路攻击者可以直接看到用户输入的内容。本文用英文解释了研究人员发现高危漏洞的细节。
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed Xunfei Input Method on Android as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found that Xunfei Input Method for Android includes a vulnerability which allows network eavesdroppers to recover the plaintext of insufficiently encrypted network transmissions, revealing sensitive information including what users have typed. For further details, please see the attached document.
On September 8 2023 we attempted to disclose these vulnerabilities to [email protected], and on September 25 2023 we attempted to disclose these vulnerabilities to [email protected]. We have not received a response to these emails. If you are not able to process vulnerability disclosures for this product, please ensure that this disclosure is delivered to someone who can.
Background
The Citizen Lab is committed to research transparency and will publish details regarding the security vulnerabilities it discovers in the context of its research activities, absent exceptional circumstances, on its website: https://citizenlab.ca/.
All communications associated with this disclosure may be included in the Citizen Lab’s public disclosure of this vulnerability.
Next steps
Please communicate what steps you will take to address the vulnerability that we have described, and please provide the timeline you decide upon for the implementation of fixes.
Finally, upon implementation of any fixes, we ask that you communicate the full extent of the vulnerability to the Citizen Lab.
Should you have any questions about our findings please let us know. We can be reached at this email address: [email protected].
Sincerely,
The Citizen Lab
iFlytek to The Citizen Lab — November 6, 2023
We received the following email:
Subject: Feedback on Xunfei Input Method issue
Hello The Citizen Lab,
Sorry for the delay.
Thank you for your detailed report and responsible disclosure on this issue.
We have analyzed your report and confirmed this is mainly due to server-side improper configuration in Xunfei Input Method that causes data transmission to use the HTTP protocol which can be eavesdropped. For the DES encryption algorithm used, is the result of considering the trade-off between performance and security under massive requests condition. As you mentioned in the mitigation part, data transmission is secure under the HTTPS protocol.
We implemented the fix on November 4th, that is, changing the improperly configured HTTP protocol on the server side to HTTPS, and it has taken effect.
Timeline:
November 4, 2023: Latest report received
November 4, 2023: Fix implemented
Because this is an improper configuration on the server side, the client will not be affected after the server is fixed. So there is no specific APK version extent of the vulnerability.
Best Regards,
Iflytek Team
OPPO
The Citizen Lab to OPPO — November 22, 2023
We sent the following via email:
To: [email protected]
Subject: Security issues in OPPO keyboards / OPPO预装的输入法高危漏洞
总结：多伦多大学的研究人员发现OPPO所有预装的中文输入法使用的加密协议有高危漏洞，让网路攻击者可以直接看到用户输入的内容。本文用英文解释了研究人员发现高危漏洞的细节。
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed OPPO pre-installed keyboard apps as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found two that include vulnerabilities that allow network eavesdroppers to decrypt network transmissions. This means third parties can obtain sensitive personal information including what users have typed. To address these issues, we suggest using HTTPS or TLS rather than custom-designed network protocols. For further details, please see the attached document.
Background
The Citizen Lab is committed to research transparency and will publish details regarding the security vulnerabilities it discovers in the context of its research activities, absent exceptional circumstances, on its website: https://citizenlab.ca/.
If no response is received to this disclosure, the Citizen Lab will publish details regarding the security vulnerability on its website after 15 calendar days from the date of this communication. In other words, where there is no response from you, Citizen Lab will publish details regarding the vulnerability after December 7 2023.
If a substantive response is received (which excludes, for example, an auto reply) to this disclosure within 15 calendar days from the date of this communication, the Citizen Lab will provide you with 45 calendar days from the date of this communication to fix (whether in whole or in part) the vulnerability before publicly disclosing the issue. In other words, where we do receive a substantive response from you, the Citizen Lab will publish details regarding the vulnerability after January 6 2024.
We reserve the right to publish details regarding the vulnerability to the general public before the expiry of the 45 calendar days set out above in the following situations: (1) you have disclosed the vulnerability to the general public, (2) you have patched the vulnerability, (3) you have taken the position that there is no security vulnerability, or (4) the Citizen Lab observes the vulnerability is under active exploitation.
All communications associated with this disclosure may be included in the Citizen Lab’s public disclosure of this vulnerability.
Next steps
Please communicate what steps you will take to address the vulnerability that we have described, and please provide the timeline you decide upon for the implementation of fixes.
Finally, upon implementation of any fixes, we ask that you communicate the full extent of the vulnerability to the Citizen Lab.
Should you have any questions about our findings please let us know. We can be reached at this email address: [email protected].
Sincerely,
The Citizen Lab
OPPO to The Citizen Lab — November 23, 2023
We received the following email:
From: OPPO安全中心
Subject: 回复: Security issues in OPPO keyboards / OPPO预装的输入法高危漏洞
The Citizen Lab:
The email has been received. We will transfer it to the corresponding team for content analysis and confirmation. We will reply to the content in a timely manner. Thank you very much for your feedback!
OPPO to The Citizen Lab — December 3, 2023
We received the following email:
From: OPPO安全中心
Subject: 回复: Security issues in OPPO keyboards / OPPO预装的输入法高危漏洞
Dear Citizen Lab Team,
Thank you once again for your attention and contribution to the safety of our products.
In response to the security vulnerability you reported, our OPPO Security Team has swiftly taken a series of measures. We particularly emphasize that for the Sogou Input Method OPPO Custom Edition, the related security issues have been comprehensively resolved and fixed on the latest ColorOS 14 system.
However, considering the wide range of our product models and numerous versions, to ensure that every device receives equal levels of security updates and maintenance, we need more time to thoroughly implement these fixes. Our team is working hard to ensure that all devices running older versions of ColorOS will also receive this important update as soon as possible.
In the meantime, the repair work for the Baidu Input Method OPPO Custom Edition is also proceeding intensely. Currently, this application is still in the internal testing phase. Our engineers are making every effort to ensure that it meets our high standards in terms of security and stability. Our goal is to complete the testing and release the update as soon as possible, ensuring the safety of all our users. We plan to comprehensively update and push both Baidu and Sogou Input Method OPPO Custom Editions by Q1 2024.
We understand that as a technology company, protecting the security and privacy of user data is our primary task. Therefore, OPPO is always committed to continuously improving the security performance of our products and services. We will continue to maintain close cooperation with security research institutions like Citizen Lab, working together to enhance the security standards of the entire industry.
Should you have any questions about our security measures or progress, please feel free to contact us.
Thank you again for your understanding, support, and cooperation.
Sincerely,
OPPO Security Team
OPPO to The Citizen Lab — December 13, 2023
We received the following email:
From: OPPO安全中心
Subject: 回复: Security issues in OPPO keyboards / OPPO预装的输入法高危漏洞
Dear Citizen Lab Team,
It has been over a week since our response. I am not sure if this has answered your questions. If you need further assistance, please contact me!
December 18 2023We sent the following via email:
From: OPPO安全中心
Subject: Re: Security issues in OPPO keyboards / OPPO预装的输入法高危漏洞
Dear OPPO Security Team,
Thank you for your response. We are happy to hear that fixes are underway for your products. Our test device runs ColorOS 13.1, so we are currently unable to test the fix for Sogou Input Method OPPO Custom Edition for ColorOS 14, but please notify us when you have released the fix for ColorOS 13.1 so that we can test it.
Similarly, please let us know when the fix for Baidu Input Method OPPO Custom Edition is available so that we can test it as well.
Sincerely,
The Citizen Lab
OPPO to The Citizen Lab — December 18, 2023
We received the following email:
From: OPPO安全中心
Subject: 回复: Security issues in OPPO keyboards / OPPO预装的输入法高危漏洞
Dear Citizen Lab Team,
Sincerely thank you for your attention and contribution to the safety of our products.
Regarding the two time points mentioned in the email, we will inform you via email when the actual repair is made. You are also welcome to conduct testing to help us improve the security level of OPPO products and services.
Sincerely,
OPPO Security Emergency Response Center
收購samsung
The Citizen Lab to
收購samsung — October 16, 2023
We sent the following via email:
To: mobile.security@
收購samsung.com
Subject: Security issue in
收購samsung Keyboard
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed
收購samsung Keyboard on Android as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found that
收購samsung Keyboard for Android includes a vulnerability which allows network eavesdroppers to recover the plaintext of insufficiently encrypted network transmissions, revealing sensitive information including what users have typed. For further details, please see the attached document.
Background
The Citizen Lab is committed to research transparency and will publish details regarding the security vulnerabilities it discovers in the context of its research activities, absent exceptional circumstances, on its website: https://citizenlab.ca/.
If no response is received to this disclosure, the Citizen Lab will publish details regarding the security vulnerability on its website after 15 calendar days from the date of this communication. In other words, where there is no response from you, Citizen Lab will publish details regarding the vulnerability after October 31, 2023.
If a substantive response is received (which excludes, for example, an auto reply) to this disclosure within 15 calendar days from the date of this communication, the Citizen Lab will provide you with 45 calendar days from the date of this communication to fix (whether in whole or in part) the vulnerability before publicly disclosing the issue. In other words, where we do receive a substantive response from you, the Citizen Lab will publish details regarding the vulnerability after November 30. 2023.
We reserve the right to publish details regarding the vulnerability to the general public before the expiry of the 45 calendar days set out above in the following situations: (1) you have disclosed the vulnerability to the general public, (2) you have patched the vulnerability, (3) you have taken the position that there is no security vulnerability, or (4) the Citizen Lab observes the vulnerability is under active exploitation.
All communications associated with this disclosure may be included in the Citizen Lab’s public disclosure of this vulnerability.
Next steps
Please communicate what steps you will take to address the vul
▲熱銷神機iPhone 15、15 Plus現省超過四千元。（圖／傑昇通信）
記者陳俐穎／綜合報導
為了所有辛苦的勞工朋友，傑昇通信宣布，於今日開始至4月28日推出優惠活動，期間至門市購買Apple Watch S9下殺66折、熱銷神機iPhone 15現省4,610元、三星Galaxy S23激省破萬元，還有免六千就能買到vivo Y36，最低6折起，希望替勞工朋友省荷包。
傑昇通信表示，為體恤全台勞工的辛勞，特別推出iPhone及Apple Watch的勞工慰勞回饋，購買iPhone 15（128G），就能享4,610元折扣，還有iPhone 15 Plus（128G）原價32,900元，傑昇通信再折4,010元，只賣28,890元；以及著重效能及操作手感提升的Apple Watch Series9不銹鋼（45mm）LTE版，下殺66折。
連續四天的限時優惠，價差萬元以上的舊旗艦三星Galaxy S23（8GB/256GB），原價28,900元，只要17,790元；工作之餘，無論自己玩或是揪團開局，傑昇通信加碼ROG Phone 6D，原廠配件擴充性不輸ROG Phone 8，尤其6D上市至今超過一年的時間，空機價20,490元，也來到很不錯的甜蜜點，省下9,500元。
主打「人像專家」的OPPO Reno11，活動期間至傑昇通信門市購機，定價14,990元再打69折，趕快趁這次勞動節快閃優惠購入，喜歡用手機記錄生活的勞工朋友，三星Galaxy A55（8GB/128GB）絕對是不錯的選擇，新機再打71折，折扣後只要10,590元，4月底前回原廠登錄，再送
收購samsung wallet悠遊卡加值金300元。
這次勞動節快閃優惠還有大螢幕、大電量的vivo Y36搭載6.64吋螢幕、電池容量達5,000mAh，並支援44W閃充、具備IP54等級防塵防潑水功能，原廠定價萬元有找，傑昇通信門市不到6千就能入手；另一款電池續航超過20小時的Sony Xperia 10 V，指定薰衣草紫色免九千，非常推薦預算有限的小資上班族群。
收購
收購