VS99025A has released for me yesterday, Not sure if new patch may be to stop exploits or improve customer experience(laugh)
Was curious if perhaps someone smarter then me could exploit the V10 via exploits in Android Security Patch Level.
I am on ASPL 2016-10-1
I checked Googles logs.
https://source.android.com/security/bulletin/2016-10-01.html
https://source.android.com/security/bulletin/2016-11-01.html
https://source.android.com/security/bulletin/2016-12-01.html
https://source.android.com/security/bulletin/2017-01-01.html
Figured someone could exploit something like this
2017-01-05 security patch level�Vulnerability summary
Elevation of privilege vulnerability in Qualcomm bootloader
CVE-2016-8422,
CVE-2016-8423
Critical Yes
Shouldn't we be able to use an exploit in between the two dates to narrow down a applicable exploit/root method?
I mean there is like 50+ Critical exploits
And then over 80+ High exploits
between 2016-10-01 &&& 2017-01-01.
Surely we can find something right?
PS : didnt take VS99025A update, not going too.
Stop OTA Updates with
gatesjunior - Debloater Tool https://forum.xda-developers.com/android/software/debloater-remove-carrier-bloat-t2998294
fire3element - V10 Guide https://forum.xda-developers.com/lg-v10/general/how-to-disable-updates-otas-t3289145
info discussion exploit solution references
Google Android Products Qualcomm Bootloader Multiple Integer Overflow Vulnerabilities
Bugtraq ID: 95241
Class: Failure to Handle Exceptional Conditions
CVE: CVE-2016-8423
CVE-2016-8422
Remote: Yes
Local: No
Published: Jan 03 2017 12:00AM
Updated: Jan 12 2017 01:09AM
Credit: The vendor reported the issue.
Vulnerable: Google Pixel XL 0
Google Pixel 0
Google Nexus 6P
Google Nexus 6
Not Vulnerable:
http://www.securityfocus.com/bid/95241
Hi guy i'm building LineageOS for Razer Forge TV. The rom works fine but i can't get DRM/Widevine to work.
The board for this device it's apq8084 like shamu, quark and kccat6.
I succesfuly build the vendor tree including this blobs:
Code:
/vendor/lib/libdrmfs.so
/vendor/lib/libdrmtime.so
/vendor/lib/liboemcrypto.so
/vendor/lib/libprdrmdecrypt.so
/vendor/lib/libQSEEComAPI.so
/vendor/lib/libwvdrm_L1.so
/vendor/lib/libWVStreamControlAPI_L1.so
/vendor/lib/drm/libdrmprplugin.so
/vendor/lib/drm/libdrmwvmplugin.so
/vendor/lib/mediadrm/libprmediadrmdecrypt.so
/vendor/lib/mediadrm/libprmediadrmplugin.so
/vendor/lib/mediadrm/libwvdrmengine.so
But nothing seems to work. Boardconfig.mk contains:
Code:
# DRM Protected Video
BOARD_USES_LIBDRM := true
BOARD_WIDEVINE_OEMCRYPTO_LEVEL := 1
I also try using blobs from shamu as many other roms similars for this board, with no luck.
As far i see in logcat the device can't get or create certs and credentials, so it's keep falling back to L3.
With L3 i can't get TV Netflix or casting to work...
Here is the logcat: https://pastebin.com/F43RkkKa
Any help or clue will be appreciated!
Thanks
Well this is hard to solve...as far i see in the logs in some point QSEECOMAPI or OEMCrypto fails to encrypt (or decrypt?) probably certs...
I test it all, even with bullhead blobs, no luck. I also replace the proprietary kestore.qcom.so with the opensource provided by LineageOS and i get the same error....
Code:
WVCdm : Could not read /data/mediadrm/IDM1013/ay64.dat2: No such file or directory
QSEECOMAPI: : Error::send command ioctl failed. ret = -1, errno = 22
DrmWidevineDash: Error: OEMCrypto_Initialize ioctl returns -1
WVCdm : DeviceFiles::RetrieveHashedFile: /data/mediadrm/IDM1013/L3/cert.bin does not exist
[Update: See the bottom of this post for what's apparently Google's own solution.]
Back in the days of the first incarnation of the Apt Runtime on Chrome (I guess that was the first ARC), it was suggested you could tell an android app if it was running in the chromeOS:
If you need to check if your app is running on Chrome OS, look for chromium as the android.os.Build.BRAND and android.os.Build.MANUFACTURER.
Click to expand...
Click to collapse
This seems to have been S-canned. as these evaluate to "google" and "google" respectively. "google"/"google" doesn't seem to be a consistent, unique name for only Android-on-Chrome on all device, especially as the Pixel C (a phone) uses "google/Google" (capital "G") which isn't exactly the same, but is close enough.
For fun, I dumped Build.BRAND, Build.MANUFACTURER, Build.DEVICE, Build.PRODUCT, Build.MODEL, and Build.BOARD for my Chromebook Pro, as outputted by a Log.e():
07-02 00:25:08.735 8407 8407 E : Brand google
07-02 00:25:08.735 8407 8407 E : Manufacturer google
07-02 00:25:08.735 8407 8407 E : Device caroline_cheets
07-02 00:25:08.735 8407 8407 E : Product caroline
07-02 00:25:08.735 8407 8407 E : Model Samsung Chromebook Pro
07-02 00:25:08.735 8407 8407 E : Board caroline
"Caroline_cheets"? That's a weird name for the board... wonder who caroline is... well I've also learned a few more device names:
kevin_cheets -- the Samsung Chromebook Plus
minnie_cheets -- Asus Chromebook Flip C 100PA
samus_cheets - Chromebook Pixel (2015)
tiger_cheets - AOpen RK3288 10" Chromebase
fievel_cheets -- AOpen RK3288 Mini Chromebox Mini
cyan_cheets -- Acer Chromebook R11 (C738T)
Some of these seem to be the same devices that are announced to have Android. Anyone have any idea what the device names refer to? Tiger and Feivel are characters from An American Tail. But anyway...
Does the _cheets in the device name mean that it has android support? Probably not a long-term solution, but it might work for current devices (?)
Update: Looks like I'm not so far off. Google themselves are checking for this! Here's their ArcCheck:
Code:
public static boolean isInArc() {
return Build.DEVICE != null && Build.DEVICE.matches(ARC_DEVICE_PATTERN);
}
where:
Code:
private final static String ARC_DEVICE_PATTERN = ".+_cheets";
Another proposed solution in stackoverflow is to check if
Code:
context.getPackageManager().hasSystemFeature("org.chromium.arc.device_management");
Haven't tried it yet to see if it works.
Update to my update... Google has updated their code, and there is a more comprehensive check described here.
Hello,
This OP3 I got here, had a dm_verity error. Afterwards I used the Qualcomm way to get past that.
Now I'm getting the issue that it shows me the "Start do md5 checksum" list and there are 2 things in red (System : failed) and at the end it said md5 checksum failed.
I tried various amount of things I found all around the internet but this is what prevents them from fixing my problem:
- My lack of skill and probably knowledge
- Phone isn't oem unlocked
- Phone's partition can't be edited
- Bootloader version is empty (locked aswell, used an AIO tool to confirm)
- FastBoot is possible (volume up + power)
- I can't get into ADB sideload
- There's no TWRP or anything
There are some stuff in this list that most likely are the same thing (as I said, I lack knowledge).
I don't know what else I can do. Do you guys have an idea?
Much love,
rZergling
fastboot oem device-info gives:
Code:
Device tampered: false
Device unlocked: false
Device critical unlocked: false
Display panel:
Have console: true
Selinux type: <none>
Boot_mode: normal
Kmemleak_detext: false
Most likely USB debugging is off.
Hello, please can you report your experience with Galileo reception and custom ROMs?
Development team reported, through official forum, that Galileo is not supported but smartphone was advertised with Galileo support.
It is still advertised as supported in italian, spanish and indian page. It has been removed from all the other pages (de, fr, uk, se, cn, id, ru and global).
According to european laws, advertising a product with different real specification is prohibited and sanctioned and customer have the right to ask for a replacement of refund.
Please, if you have a custom ROM, can you check if it is supported or not?
Interesting, the official galileo webpage still lists the note 9 pro as supported device. The GPStest app shows no usage of galileo satellites on my phone.
Thank you very much for sharing this link! The same for me with GPSTest. Attached you can find a screenshot. Once I saw a satellite with PRN 236, which is unknown and I can't find any reference about it using google.
Leni_YO said:
Interesting, the official galileo webpage still lists the note 9 pro as supported device. The GPStest app shows no usage of galileo satellites on my phone.
Click to expand...
Click to collapse
simone982 said:
Hello, please can you report your experience with Galileo reception and custom ROMs?
Development team reported, through official forum, that Galileo is not supported but smartphone was advertised with Galileo support.
It is still advertised as supported in italian, spanish and indian page. It has been removed from all the other pages (de, fr, uk, se, cn, id, ru and global).
According to european laws, advertising a product with different real specification is prohibited and sanctioned and customer have the right to ask for a replacement of refund.
Please, if you have a custom ROM, can you check if it is supported or not?
Click to expand...
Click to collapse
according to qualcomm-snapdragon-720g-mobile-platform-product-brief.pdf it is supported by hardware
Code:
GPS, Glonass, BeiDou, Galileo, QZSS,
and SBAS
• NavIC support
• Dual-Frequency GNSS (L1 + L5)
According to Xiaomi_Kernel_OpenSource xiaomi use (qcom) source branch
Code:
Branch: curtana-q-oss
Base tag: LA.UM.8.9.r1-07100-SM6xx.0
Looking into GPS relevant source code at hardware/qcom/gps/tree/?h=LA.UM.8.9.r1-07100-SM6xx.0 and compare it with e.g. newer branch sm8150 (Snapdragon 855) hardware/qcom/gps/tree/?h=LA.UM.8.1.r1-14500-sm8150.0
there is missing code for dual frequency GNSS support for branch SM6xx
Code:
...
void
+GnssAdapter::requestSvPolyForClient(LocationAPI* client, const LocationCallbacks& callbacks) {
+ if (callbacks.gnssSvPolynomialCb) {
+ LocationCallbacks oldCallbacks = getClientCallbacks(client);
+ if (!oldCallbacks.gnssSvPolynomialCb) {
+ LOC_LOGd("request sv poly");
+ GnssAidingDataSvMask svDataMask = GNSS_AIDING_DATA_SV_POLY_BIT;
+ mLocApi->requestForAidingData(svDataMask);
+ }
+ }
+}
+
+void
+GnssAdapter::reportSvPolynomial(const GnssSvPolynomial &svPolynomial)
+{
+ for (auto it=mClientData.begin(); it != mClientData.end(); ++it) {
+ if (nullptr != it->second.gnssSvPolynomialCb) {
+ it->second.gnssSvPolynomialCb(svPolynomial);
+ }
+ }
+}
+
+void
...
+typedef uint32_t LocSvDgnssMeasStatusMask;
+#define LOC_MASK_DGNSS_EPOCH_TIME_VALID 0x1 /**< DGNSS Epoch time is valid */
+#define LOC_MASK_DGNSS_MEAS_STATUS_PR_VALID 0x2 /**< Pseudo Range correction is valid */
+#define LOC_MASK_DGNSS_MEAS_STATUS_PRR_VALID 0x4 /**< Pseudo Range rate correction is valid */
...
+#define GNSS_SV_MEAS_HEADER_HAS_DGNSS_CORRECTION_SOURCE_TYPE 0x08000000
+#define GNSS_SV_MEAS_HEADER_HAS_DGNSS_CORRECTION_SOURCE_ID 0x010000000
+#define GNSS_SV_MEAS_HEADER_HAS_DGNSS_REF_STATION_ID 0x020000000
+#define GNSS_SV_MEAS_HEADER_HAS_REF_COUNT_TICKS 0x040000000
...
+ /** Unique SV Identifier.
+ * SV Range for supported constellation is specified as below:
+ * - For GPS: 1 to 32
+ * - For GLONASS: 65 to 96
+ * - For SBAS: 120 to 158 and 183 to 191
+ * - For QZSS: 193 to 197
+ * - For BDS: 201 to 237
+ * - For GAL: 301 to 336
+ * - For NAVIC: 401 to 414 */
...
+// carrier frequency of the signal tracked
+#define GPS_L1CA_CARRIER_FREQUENCY (1575420000.0)
+#define GPS_L1C_CARRIER_FREQUENCY (1575420000.0)
+#define GPS_L2C_L_CARRIER_FREQUENCY (1227600000.0)
+#define GPS_L5_Q_CARRIER_FREQUENCY (1176450000.0)
+#define GLONASS_G1_CARRIER_FREQUENCY (1602000000.0)
+#define GLONASS_G2_CARRIER_FREQUENCY (1246000000.0)
+#define GALILEO_E1_C_CARRIER_FREQUENCY (1575420000.0)
+#define GALILEO_E5A_Q_CARRIER_FREQUENCY (1176450000.0)
+#define GALILEO_E5B_Q_CARRIER_FREQUENCY (1207140000.0)
+#define BEIDOU_B1_I_CARRIER_FREQUENCY (1561098000.0)
+#define BEIDOU_B1C_CARRIER_FREQUENCY (1575420000.0)
+#define BEIDOU_B2_I_CARRIER_FREQUENCY (1207140000.0)
+#define BEIDOU_B2A_I_CARRIER_FREQUENCY (1176450000.0)
+#define BEIDOU_B2A_Q_CARRIER_FREQUENCY (1176450000.0)
+#define QZSS_L1CA_CARRIER_FREQUENCY (1575420000.0)
+#define QZSS_L1S_CARRIER_FREQUENCY (1575420000.0)
+#define QZSS_L2C_L_CARRIER_FREQUENCY (1227600000.0)
+#define QZSS_L5_Q_CARRIER_FREQUENCY (1176450000.0)
+#define SBAS_L1_CA_CARRIER_FREQUENCY (1575420000.0)
+#define NAVIC_L5_CARRIER_FREQUENCY (1176450000.0)
...
maybe Xiaomi use custom branch of LA.UM.8.9.r1-07100-SM6xx.0
doubt, if snapdragon 720G (sm7125) really based on sm6xx/atoll source code branch
Thank you for your answer. I'll try to ask also on ROM threads if someone with different kernel can give us feedback
Oh, there is a newer branch LA.UM.8.9.r1-08900-SM6xx.0 from April 29, 2020 which add more DGNSS stuff
moreroid said:
Oh, there is a newer branch LA.UM.8.9.r1-08900-SM6xx.0 from April 29, 2020 which add more DGNSS stuff
Click to expand...
Click to collapse
I have rooted redmi note 9s.
Maybe someone knows how to modify the kernel or gps.confg or some other way.
To improve the handling of gps galileo and dual gps.
How someone knows how to do it.
Then I can test it.
That's a question for developers anyway.
sad, current xiaomi.eu V11.0.10.0.QJWMIXM (curtana) release don't include latest gps related source branch
one change between LA.UM.8.9.r1-07100-SM6xx.0 and LA.UM.8.9.r1-08900-SM6xx.0 was:
Code:
- LOC_LOGD("%s]: Delta:%" PRIi64 "ns time too large, retry number #%u...",
- __FUNCTION__, sinceBootTimeDeltaNanos, i+1);
+ LOC_LOGd("Delta:%" PRIi64 "ns time too large, retry number #%u...",
+ sinceBootTimeDeltaNanos, i + 1);
but old result was found
Code:
curtana:/ # getprop ro.build.fingerprint_real
Redmi/curtana_global/curtana:10/QKQ1.191215.002/V11.0.10.0.QJWMIXM:user/release-keys/1595409748
curtana:/ # strings /vendor/lib64/hw/[email protected] | grep Delta:
%s]: Delta:%lins time too large, retry number #%u...
Same (previous) version in 11.0.4.0 joyeuse.
A developer here said that something should be enabled by Xiaomi in boot/vendor
https://forum.xda-developers.com/showpost.php?p=83170851&postcount=739
moreroid said:
sad, current xiaomi.eu V11.0.10.0.QJWMIXM (curtana) release don't include latest gps related source branch
one change between LA.UM.8.9.r1-07100-SM6xx.0 and LA.UM.8.9.r1-08900-SM6xx.0 was:
Code:
- LOC_LOGD("%s]: Delta:%" PRIi64 "ns time too large, retry number #%u...",
- __FUNCTION__, sinceBootTimeDeltaNanos, i+1);
+ LOC_LOGd("Delta:%" PRIi64 "ns time too large, retry number #%u...",
+ sinceBootTimeDeltaNanos, i + 1);
but old result was found
Code:
curtana:/ # getprop ro.build.fingerprint_real
Redmi/curtana_global/curtana:10/QKQ1.191215.002/V11.0.10.0.QJWMIXM:user/release-keys/1595409748
curtana:/ # strings /vendor/lib64/hw/[email protected] | grep Delta:
%s]: Delta:%lins time too large, retry number #%u...
Click to expand...
Click to collapse
simone982 said:
Same (previous) version in 11.0.4.0 joyeuse.
A developer here said that something should be enabled by Xiaomi in boot/vendor
https://forum.xda-developers.com/showpost.php?p=83170851&postcount=739
Click to expand...
Click to collapse
for curtana Xiaomi must take newer qcom source branch LA.UM.8.9.r1-08900-SM6xx.0 (April 29, 2020) compile it and provide it in usual way
current used(?) qcom source branch LA.UM.8.9.r1-07100-SM6xx.0 (December 25, 2019) is supposed to old for dgnss (dual-frequency gps) support
there is no excuse it wouldn't work for Xiaomi
There is a discussion here about the lack of galileo and dual gps.
https://c.mi.com/thread-3124154-5-1.html
Galileo support has been removed also from italian and spanish page
moreroid said:
for curtana Xiaomi must take newer qcom source branch LA.UM.8.9.r1-08900-SM6xx.0 (April 29, 2020) compile it and provide it in usual way
current used(?) qcom source branch LA.UM.8.9.r1-07100-SM6xx.0 (December 25, 2019) is supposed to old for dgnss (dual-frequency gps) support
there is no excuse it wouldn't work for Xiaomi
Click to expand...
Click to collapse
Moderator xiaomi handed over
this valuable information to xiaomi developers.
https://c.mi.com/thread-3124154-5-1.html
Yes, thanks, I saw
kriss3 said:
Moderator xiaomi handed over
this valuable information to xiaomi developers.
https://c.mi.com/thread-3124154-5-1.html
Click to expand...
Click to collapse
Italian customer service told me that Galileo is not supported in Redmi Note 9 Pro. That's disappointing and what a shame for Xiaomi!
I've also have a Mi A2 and developers are able to update Qualcomm drivers by themselves, is it because this super partition system that they're not able to do this for curtana/joyeuse?
It seems that kernel source for joyeuse has been published here:
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/tree/gram-q-oss
I'll dig into this
simone982 said:
It seems that kernel source for joyeuse has been published here:
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/tree/gram-q-oss
I'll dig into this
Click to expand...
Click to collapse
I have xiaomi eu miui 12 i used the cortana kernel
Kernel] [MIUI-AOSP] Yuki- ユ キ Kernel [curtana, excalibur, gram, joyeuse]
The aosp kernel seems to have a newer branch
maybe galileo and dual gps would work
Unfortunately, I do not have aosp.
https://c.mi.com/thread-3424963-1-0.html
https://forum.xda-developers.com/redmi-note-9-pro/development/kernel-yuki-kernel-3-0-t4182393
Rebased over LA.UM.8.9.r1-10600-SM6xx.0 (AOSP variant only)
Merge tag 'LA.UM.8.1.r1-16200-sm8150.0'
Wifi, Audio tag used LA.UM.8.9.r1-10600-SM6xx.0
Net Wireward
Enable PSI monitor
Add pidfd backport
Fixed boot on Joyeuse (Miui variant)
Last xiaomi changes (Miui variant)
Disable LMK
Removed
[TESTING] exec: Add node tampering blacklist function
[TESTING] allow power @ 2 and perf 2 to tampering blacklist
https://forum.xda-developers.com/showpost.php?p=83804167&postcount=15
I asked already if someone can check
kriss3 said:
I have xiaomi eu miui 12 i used the cortana kernel
Kernel] [MIUI-AOSP] Yuki- ユ キ Kernel [curtana, excalibur, gram, joyeuse]
The aosp kernel seems to have a newer branch
maybe galileo and dual gps would work
Unfortunately, I do not have aosp.
https://c.mi.com/thread-3424963-1-0.html
https://forum.xda-developers.com/redmi-note-9-pro/development/kernel-yuki-kernel-3-0-t4182393
Rebased over LA.UM.8.9.r1-10600-SM6xx.0 (AOSP variant only)
Merge tag 'LA.UM.8.1.r1-16200-sm8150.0'
Wifi, Audio tag used LA.UM.8.9.r1-10600-SM6xx.0
Net Wireward
Enable PSI monitor
Add pidfd backport
Fixed boot on Joyeuse (Miui variant)
Last xiaomi changes (Miui variant)
Disable LMK
Removed
[TESTING] exec: Add node tampering blacklist function
[TESTING] allow power @ 2 and perf 2 to tampering blacklist
Click to expand...
Click to collapse
simone982 said:
https://forum.xda-developers.com/showpost.php?p=83804167&postcount=15
I asked already if someone can check
Click to expand...
Click to collapse
I have miui 12 europe redmi note 9s
This is the newest one I downloaded from November 14 Cortana.
Everything's fine with the kernel.
The GPS works.
It does not detect only galileo and dual gps frequency,
but never detected it.
Although the 720g snapdragon supports
Someone needs to do a gps fix to detect galileo and dual gps