Related
It's just an idea but if we can access on the entire hard disk, I think it's possible to recover DRM.
It exists softwares to recover datas deleted. Maybe a way to explore.
Everybody knows datas are never totally erased.
Have discuss
Ps : sorry for my bad eng
Sent from my D5803 using XDA Free mobile app
This is flash memory. If they delete it and afterwards send the command to trim or gc then it's gone for good.
The unlocking process is too fast, I do not think they are rewriting the partition. I think they only remove the DRM then dalvik cache / cache and reboot the phone.
But I could be wrong.
I tried different software, they are effective on my SD card.
But my problem is that I do not see the internal hard disk of the phone, so I can not try it.
My phone is boot unlocked. No root / No recovery
If it was possible this would have been done already.
Skickat från min LG-V500 via Tapatalk
I don't talk about "if we can, if it's possible", i talk about doing this, to trying this.
for now, no one has tried.
Being negative without trying, is the best way of failing
dahod said:
It's just an idea but if we can access on the entire hard disk, I think it's possible to recover DRM.
It exists softwares to recover datas deleted. Maybe a way to explore.
Everybody knows datas are never totally erased.
Have discuss
Click to expand...
Click to collapse
The tools that are used to recover deleted files from a file system operate on the premise that deletions are performed by marking the sectors allocated to the file as 'free' in the allocation table without actually erasing the file data contained on the disk. Recovery tools can scan the entire disk to discover file chains and then rewrite the recovered data to some other device.
These tools will not work on the Trim Area (TA) because it is not a file system, but a raw partition that is accessed by directly reading/writing data at known addresses. There is no allocation table or file chains to recover.
The DRM keys are deleted when the bootloader is unlocked by overwriting the key data with 0x00 or 0xFF. This can be verified by dumping the TA partition of an unlocked device and examining the raw partition.
cschmitt said:
The tools that are used to recover deleted files from a file system operate on the premise that deletions are performed by marking the sectors allocated to the file as 'free' in the allocation table without actually erasing the file data contained on the disk. Recovery tools can scan the entire disk to discover file chains and then rewrite the recovered data to some other device.
These tools will not work on the Trim Area (TA) because it is not a file system, but a raw partition that is accessed by directly reading/writing data at known addresses. There is no allocation table or file chains to recover.
The DRM keys are deleted when the bootloader is unlocked by overwriting the key data with 0x00 or 0xFF. This can be verified by dumping the TA partition of an unlocked device and examining the raw partition.
Click to expand...
Click to collapse
That makes perfect sense. Taking things one step back, why shouldn't we consider rewriting the DRM keys to the TA though? They're consistent among Z3C devices after all...Is there a bootloader validator that will just overwrite the keys again? Or preventing the overwrite in the first place, rather than worrying about an impossible recovery of the deleted key data?
If neither is possible, could you explain why please?
matapo said:
That makes perfect sense. Taking things one step back, why shouldn't we consider rewriting the DRM keys to the TA though? They're consistent among Z3C devices after all...Is there a bootloader validator that will just overwrite the keys again? Or preventing the overwrite in the first place, rather than worrying about an impossible recovery of the deleted key data?
If neither is possible, could you explain why please?
Click to expand...
Click to collapse
We don't have the keys because w/o root we cannot dump the TA partition. If bootloader is unlocked to gain root, keys are wiped.
The assumption that the keys are common among all devices may not be correct. In previous Z series devices restoring the TA partition from a different device would brick it. This indicates the TA contains some device specific signature, etc. The keys could be protected with device-dependent public/private key encryption tied to IMEI and some private key. If Sony went to the trouble of protecting their IP with DRM, they are going to protect the DRM keys as well.
i thought with towelroot you can root without bootloader unlock ? if not, we just need a possibility to root without bootloader unlock and than we can backup the keys ?
yelp, only that needing JUST a way to root without unlock sounds so easy while it's not.
dahod said:
The unlocking process is too fast
Click to expand...
Click to collapse
TA.img is exatcly 2MB, writing 2MB of zeros to flash memory only takes fractions of a second.
cschmitt said:
We don't have the keys because w/o root we cannot dump the TA partition. If bootloader is unlocked to gain root, keys are wiped.
The assumption that the keys are common among all devices may not be correct. In previous Z series devices restoring the TA partition from a different device would brick it. This indicates the TA contains some device specific signature, etc. The keys could be protected with device-dependent public/private key encryption tied to IMEI and some private key. If Sony went to the trouble of protecting their IP with DRM, they are going to protect the DRM keys as well.
Click to expand...
Click to collapse
Thanks for the explanation - much appreciated! Hopefully, someone will attempt the 'almost impossible' and find an exploit or two like towelroot, allowing for root access without compromising the bootloader then. Seems like our only option. Sony hasn't made this easy...I can understand why our fellow users are upset.
Just so people don't get confused: that doesn't mean that the DRM keys can be recovered when the phone was already unlocked, but they can be restored if a backup is made before.
PS: and restoring the keys automatically relocks the bootloader which means they can only be used by stock roms iirc. At least that was the case with RomAur I've been using, restoring the keys resulted in a bootloop.
Thank you all for your explanations, I hope that a great mind will find the solution for those who have already unlocked.
Sent from my D5803 using XDA Free mobile app
For the root exploit on the older Z devices, did the exploit work only on certain firmware versions, or could it work on most or all of the versions?
I'm asking this because I've for the notification for a system update, but I've been holding back on installing the update, thinking that perhaps any exploit might be patch in newer versions.
Thanks.
Only specific versions. But it was possible to downgrade, root and then upgrade while keeping root. Towelroot then worked with various versions that used an affected kernel version.
My brain wouldn't let me sleep last night over this (probably stupid) idea:
If /system can be written to by certain tools (correct me if I'm wrong, but afaik you can flash .ftfs with flashtool with a locked bootloader), would it not be easier to find an exploit there (in the .ftfs)?
Much easier said than done, yes, but sounds much easier than finding an exploit in Android, imo.
I guess tampering with an FTF changes its checksum so it cannot be used anymore.
Iruwen said:
I guess tampering with an FTF changes its checksum so it cannot be used anymore.
Click to expand...
Click to collapse
Well yes, you cannot alter an ftf, but what if we somehow made a small img of system and tricked flashtool into tricking it's actually just the system part of an ftf?
Flashtool then flashes the rooted system image and viola, root achieved!
You know, just how Nexus devices have a recovery (factory) image for each partition? Why not make this work?
Ofc just a (probably wayy off) theory, but it seems plausible.
dahod said:
Thank you all for your explanations, I hope that a great mind will find the solution for those who have already unlocked.
Sent from my D5803 using XDA Free mobile app
Click to expand...
Click to collapse
I wouldn't bet on it. The 'issue' has been there since the Xperia Z, the only solution has been to backup the partition before unlocking, else it's gone for good.
Just a thought, if we have our backups of the TA certs from other devices, shouldn't we be able to examine the content of those backups? We could confirm, for example, that hardware IDs are present in the data, and possibly if the same cert pairs are used across devices, and then be able to construct a new TA partition after unlocking--since I'm assuming the private keys are what is contained?
Good luck
The keys are device specific so far only your own will be accepted.
so to confirm, no way to recover it ?
No way to recover it.
Dear readers,
Lets start from the beginning, roughly six months ago:
1) My trusty GT-I9300 died, had two for spare parts but ... SDS;
2) I got a Note 2, got blown off the road and ended up in the canal Phone was soaked, dead;
2) I bought an Xperia Z3+;
3) I unlocked the bootloader;
4) flashed AOSP.
Result: warranty void on day one!
I picked this phone for modability, sadly there are not that any developers active for this device and I have been slowly patching AOSP from Sony with some changes here and there trying to get a CM13 build going. But due to the dive into the water with my car, I have no desktop PC/laptop (both were i7 quad's) and my dualcore iMac makes development kinda tiresome.
Anyway, little did I know that upon unlocking the bootloader my DRM keys would be lost and on that note I did not really care either.
But today I accidentally started working on CM again and figured that the DRM messages about Widevine in logcat should be eliminated. So I looked into solutions, but the DRM "fix" wasn't creative enough (no sources, wtf?) for me and I set my aim on the culprit of it all: the TA partition!
I've probably been looking at it for at least half a day now and hallucinating due to sleep deprivation. BUT, I do NOT believe Sony just scrapped the DRM keys because you unlocked the device. The keys have come from somewhere, and the best thing about keys is: they can be reproduced!
So I have been looking through dumps, comparing things and found out that the keys are most likely "destroyed". I say "destroyed", because I believe there is a good chance of restoring them!
Gory details about the TA partition (post mortem):
CKb keys look like they are "blanked" with:
00XX 0000 0000 YY00
00XX 0000 0000 YY00
(I think XX represents the date (04-02, second of April) and YY represents the time (22:29) when I voided my warranty!
A CKb key is a simple Counter Key, so most likely easily recovered given enough data...
I noticed that there was a SQLite3 database file inside the TA partition, I extracted it and it holds the following data:
CREATE TABLE keytable ( dbAppId BLOB, dbUserId BLOB, dbKeyId BLOB UNIQUE, dbEncKeyType BLOB, dbData BLOB);
Looking at the last column of the table I noticed this:
The first entry = 31
The second entry is 313038
The third 323135
And the fourth 333232...
The dbData column increases with 10097 every time, could it be related to the CKb?
For the rest it looks like everything in the TA partition everything is in fact intact, except for CKb and AUTHCERT="UNKNOWN" for Marlin (not 100% sure if that is present pre-unlock)!
Marlin X509 certificates are intact.
HUK is the Hardware Unique Key, stored on a quite a few places.
Widevine looks intact.
So, why do I focus on the CKb? Simple, look at these reasons:
CBk is used in TLS/SSL authentication (requirement for NEMO (Marlin));
It is used in QSEE. < this is patched with the DRM "Fix";
It can be encoded as RSA and/or SHA1, and is easily verified in SBL with CRC.
TA unlock/lock data is passed as 0x0000000000000000.
If you use 10097 as a CRC polinomal, the last bit of your message changes (in this case your UID for ScubaKey and drm-client swap).
So, my question is:
Is there anyone with a backup of his TA partition that could send me a dump of this folder:
/dev/block/platform/soc.0/<bootdevid>.sdhci/by-name
You can leave userdata, system abd apps_log for what they are. I just want to compare bits spread over the other partitions.
I will need a dump from a locked state and one from an unlocked state where TA is not restored to see what actually gets changed.
You can PM me on the forum or sent an e-mail to my username at gmail.com, I will make you an account on my PC to drop the files!
sfjuocekr said:
Dear readers,
Lets start from the beginning, roughly six months ago:
1) My trusty GT-I9300 died, had two for spare parts but ... SDS;
2) I got a Note 2, got blown off the road and ended up in the canal Phone was soaked, dead;
2) I bought an Xperia Z3+;
3) I unlocked the bootloader;
4) flashed AOSP.
Result: warranty void on day one!
I picked this phone for modability, sadly there are not that any developers active for this device and I have been slowly patching AOSP from Sony with some changes here and there trying to get a CM13 build going. But due to the dive into the water with my car, I have no desktop PC/laptop (both were i7 quad's) and my dualcore iMac makes development kinda tiresome.
Anyway, little did I know that upon unlocking the bootloader my DRM keys would be lost and on that note I did not really care either.
But today I accidentally started working on CM again and figured that the DRM messages about Widevine in logcat should be eliminated. So I looked into solutions, but the DRM "fix" wasn't creative enough (no sources, wtf?) for me and I set my aim on the culprit of it all: the TA partition!
I've probably been looking at it for at least half a day now and hallucinating due to sleep deprivation. BUT, I do NOT believe Sony just scrapped the DRM keys because you unlocked the device. The keys have come from somewhere, and the best thing about keys is: they can be reproduced!
So I have been looking through dumps, comparing things and found out that the keys are most likely "destroyed". I say "destroyed", because I believe there is a good chance of restoring them!
Gory details about the TA partition (post mortem):
CKb keys look like they are "blanked" with:
00XX 0000 0000 YY00
00XX 0000 0000 YY00
(I think XX represents the date (04-02, second of April) and YY represents the time (22:29) when I voided my warranty!
A CKb key is a simple Counter Key, so most likely easily recovered given enough data...
I noticed that there was a SQLite3 database file inside the TA partition, I extracted it and it holds the following data:
CREATE TABLE keytable ( dbAppId BLOB, dbUserId BLOB, dbKeyId BLOB UNIQUE, dbEncKeyType BLOB, dbData BLOB);
Looking at the last column of the table I noticed this:
The first entry = 31
The second entry is 313038
The third 323135
And the fourth 333232...
The dbData column increases with 10097 every time, could it be related to the CKb?
For the rest it looks like everything in the TA partition everything is in fact intact, except for CKb and AUTHCERT="UNKNOWN" for Marlin (not 100% sure if that is present pre-unlock)!
Marlin X509 certificates are intact.
HUK is the Hardware Unique Key, stored on a quite a few places.
Widevine looks intact.
So, why do I focus on the CKb? Simple, look at these reasons:
CBk is used in TLS/SSL authentication (requirement for NEMO (Marlin));
It is used in QSEE. < this is patched with the DRM "Fix";
It can be encoded as RSA and/or SHA1, and is easily verified in SBL with CRC.
TA unlock/lock data is passed as 0x0000000000000000.
If you use 10097 as a CRC polinomal, the last bit of your message changes (in this case your UID for ScubaKey and drm-client swap).
So, my question is:
Is there anyone with a backup of his TA partition that could send me a dump of this folder:
/dev/block/platform/soc.0/<bootdevid>.sdhci/by-name
You can leave userdata, system abd apps_log for what they are. I just want to compare bits spread over the other partitions.
I will need a dump from a locked state and one from an unlocked state where TA is not restored to see what actually gets changed.
You can PM me on the forum or sent an e-mail to my username at gmail.com, I will make you an account on my PC to drop the files!
Click to expand...
Click to collapse
DO NOT USE another xperia devices ta keys on your own device unless you want a nice looking permanent paperweight.
Once you unlock the bootloader without backing them up they are gone forever there's no getting them back.
Sent from my Xperia XA using XDA Labs
aidy.lucas said:
DO NOT USE another xperia devices ta keys on your own device unless you want a nice looking permanent paperweight.
Once you unlock the bootloader without backing them up they are gone forever there's no getting them back.
Sent from my Xperia XA using XDA Labs
Click to expand...
Click to collapse
Exactly and so many times told.
@sfjuocekr
Wrm lees je gwn niet beter man, je kan geen TA van een andere Xperia op jouwe zette, das zo vaak gezegd !
sfjuocekr said:
Dear readers,
Lets start from the beginning, roughly six months ago:
1) My trusty GT-I9300 died, had two for spare parts but ... SDS;
2) I got a Note 2, got blown off the road and ended up in the canal Phone was soaked, dead;
2) I bought an Xperia Z3+;
3) I unlocked the bootloader;
4) flashed AOSP.
Result: warranty void on day one!
I picked this phone for modability, sadly there are not that any developers active for this device and I have been slowly patching AOSP from Sony with some changes here and there trying to get a CM13 build going. But due to the dive into the water with my car, I have no desktop PC/laptop (both were i7 quad's) and my dualcore iMac makes development kinda tiresome.
Anyway, little did I know that upon unlocking the bootloader my DRM keys would be lost and on that note I did not really care either.
But today I accidentally started working on CM again and figured that the DRM messages about Widevine in logcat should be eliminated. So I looked into solutions, but the DRM "fix" wasn't creative enough (no sources, wtf?) for me and I set my aim on the culprit of it all: the TA partition!
I've probably been looking at it for at least half a day now and hallucinating due to sleep deprivation. BUT, I do NOT believe Sony just scrapped the DRM keys because you unlocked the device. The keys have come from somewhere, and the best thing about keys is: they can be reproduced!
So I have been looking through dumps, comparing things and found out that the keys are most likely "destroyed". I say "destroyed", because I believe there is a good chance of restoring them!
Gory details about the TA partition (post mortem):
CKb keys look like they are "blanked" with:
00XX 0000 0000 YY00
00XX 0000 0000 YY00
(I think XX represents the date (04-02, second of April) and YY represents the time (22:29) when I voided my warranty!
A CKb key is a simple Counter Key, so most likely easily recovered given enough data...
I noticed that there was a SQLite3 database file inside the TA partition, I extracted it and it holds the following data:
CREATE TABLE keytable ( dbAppId BLOB, dbUserId BLOB, dbKeyId BLOB UNIQUE, dbEncKeyType BLOB, dbData BLOB);
Looking at the last column of the table I noticed this:
The first entry = 31
The second entry is 313038
The third 323135
And the fourth 333232...
The dbData column increases with 10097 every time, could it be related to the CKb?
For the rest it looks like everything in the TA partition everything is in fact intact, except for CKb and AUTHCERT="UNKNOWN" for Marlin (not 100% sure if that is present pre-unlock)!
Marlin X509 certificates are intact.
HUK is the Hardware Unique Key, stored on a quite a few places.
Widevine looks intact.
So, why do I focus on the CKb? Simple, look at these reasons:
CBk is used in TLS/SSL authentication (requirement for NEMO (Marlin));
It is used in QSEE. < this is patched with the DRM "Fix";
It can be encoded as RSA and/or SHA1, and is easily verified in SBL with CRC.
TA unlock/lock data is passed as 0x0000000000000000.
If you use 10097 as a CRC polinomal, the last bit of your message changes (in this case your UID for ScubaKey and drm-client swap).
So, my question is:
Is there anyone with a backup of his TA partition that could send me a dump of this folder:
/dev/block/platform/soc.0/<bootdevid>.sdhci/by-name
You can leave userdata, system abd apps_log for what they are. I just want to compare bits spread over the other partitions.
I will need a dump from a locked state and one from an unlocked state where TA is not restored to see what actually gets changed.
You can PM me on the forum or sent an e-mail to my username at gmail.com, I will make you an account on my PC to drop the files!
Click to expand...
Click to collapse
I really have to admit that this is hearing very interesting, how you got all extracted? When I had my ta.dd from TA partition of my ZU I couldn't extract anything and I also tried to search a bit about the TA partition, where I was 100% sure was that 1 line is cause for UB able or not (was something with rooting_allowed).
The problem is I don't like so much to share the TA partition because I think u know there is the IMEI inside and with that u can do.... Some bad things for the phone
When I get my Z5P on Christmas I will take a look on it too
What I can do is to give u the databases u need from the TA partition now if u tell me how u extracted them because I seem to be too stupid for that xD
Thanks already for your efforts
Your PDesire
I found a whole collection of interesting things
If you have a backup from before unlocking the bootloader and one after, that would be great to study which bits have changed.
And to the two morons who can not read or did not read, I am NOT planning to flash someone else his TA partition. I just want to analyze it! Je kunt het ook nog zo vaak zeggen, maar ik ben dat niet van plan.
I know that the whole key set is "bound" to your device, namely because it uses a set of "counter keys" for SSL. I have ran so many hashes over "interesting" things found in the partitions, but have yet to strike that illusive "10097" that is being added to the SQLite3 DB INSIDE the TA partition.... It has to come from somewhere, the only bits that are repeating in the file are what I translated into the date + time that I flashed my phone, which is right on the money.
So if that 10097 is indeed a "left over" from the handoff between SBL1 and S1SBL, evidence for this comes from the S1SBL itself:
"Something" from "somewhere" is compared against the HW and SW keys (SHA1 + SHA256) in S1SBL, which is likely saved as a cookie in SBL1. SBL1 also mentions a SHA1 and SHA256 routing, but also this:
DDR: Computed CRC checksum retrieved from flash is %d
DDR: Checksum to be stored on flash is %d
DDR: Checksum on flash is %d
DDR: Recomputed checksum is %d
DDR: The serial number is %d
Hey, there is finally that CRC reference (actually further up in the blob)!
So until I have a good specimen to study further, I'm guessing that the SBL1 calculates the CRC that goes into the SQLite DB with two other keys keys and a "dbEncKeyType".
But I simply do not know, as what I have on those CB spots is 04-02 @ 22:29! The day I got my phone, and did not visit a friends birthday because I "forgot to go" (please, don't tell her )!
It might just be a dumb coincidence, but it would not be the first time multiple layers of security have been put up ... just to be broken by a guy (or girl) who looked the wrong way at the right time! In my case I noticed repetition on a few places while scrolling through the partition dumps!
Besides, I don't even care about the DRM keys at all. I am using an AOSP build on my phone which is able to record phone calls and plays Pokemon GO just fine. Snapping a photo is problematic, unless you like the #nofilter effect of a busted CRT! Had not checked dev progress on the Z3+ at all lately, which is still nowhere to be found, and I decided to take a stab myself.
Also if you look at the data in DDR it contains three values @ 0x800, 0x8e0 and 0x980. Some ones and two, some sequential data but nothing that jumps out at me....
Until I spotted the CRC check in S1SBL.
This is the "10097" column I was talking about:
31303731
31313738
31323835
31333932
31343939
31363036
31373133
31383230
31393237
32303334
32313431
32323438
32333535
32343632
32353639
32363736
32373833
32383930
32393937
33313034
33323131
33333138
33343235
33353332
33363339
33373436
33383533
33393630
34303637
34313734
34323831
34333838
34343935
34363032
34373039
34383136
34393233
35303330
35313337
35323434
35333531
35343538
35353635
35363732
35373739
35383836
35393933
36313030
36323037
36333134
36343231
36353238
36363335
36373432
36383439
36393536
37303633
37313730
37323737
37333834
37343931
37353938
37373035
37383132
37393139
38303236
38313333
38323430
38333437
38343534
38353631
38363638
38373735
38383832
38393839
39303936
39323033
39333130
39343137
39353234
39363331
39373338
39383435
39393532
Click to expand...
Click to collapse
Of which I first thought the response to one of the Marlin certs would be significant, but that does not make sense for a bootloader handover which can end at: IGNORE_CRC
sfjuocekr said:
"Something" from "somewhere" is compared against the HW and SW keys (SHA1 + SHA256) in S1SBL, which is likely saved as a cookie in SBL1. SBL1 also mentions a SHA1 and SHA256 routing, but also this:
Click to expand...
Click to collapse
Which I know ta contain RCK_H (which is sha1 hash), that hash is something like:
sha1("your unlock bootloader key");
unlock bootalader key is stored in 0x8B2 ta unit.
I am more interested where PBL lives, do you have idea where is it stored?
Have not had much time to look at it over the past days, but you will need to solder on a JTAG interface to get the PBL to execute the boot process in secure again (it is a fuse).
The chipset probably has a GPIO PIN you can force high to get back into secure too.
The PBL is stored in ROM, not on flash.
dont bother with warranties.. they do not check for bootloader until or unless you have modified firmware installed... i had got my d6653 repaired twice.. else if you need your bravia engine etc, you can flash kernels with drm fix included..
Hey guys, so as the title states, this is a method in which we can possibly obtain DRM keys from NAND (UFS 2.1). This of course will be pulled off with a locked bootloader.
Here's the method:
1. Extract NAND from Xperia XZ Premium (or any DRM-locked phone) via desoldering.
2. Use a NAND chip reader to dump the contents of the NAND chip.
3. Analyse contents and find DRM keys.
We'll be requiring the following:
1. A donor phone (or a spare NAND)
2. NAND chip reader
But there are some obstacles:
1. FDE is enabled by default, we'll need to find a way to decrypt the data
What are your thoughts guys, is this even possible?
Hmm, interesting idea, but according my understanding it will not work because each DRM key is slightly different. What you need is to find the location of the DRM key in the NAND so it can be backup some way
Wow good idea! .but if we can make universal drm key? Its possible ?
thipok17 said:
Wow good idea! .but if we can make universal drm key? Its possible ?
Click to expand...
Click to collapse
No
PM_ME_YOUR_TATAS said:
Hey guys, so as the title states, this is a method in which we can possibly obtain DRM keys from NAND (UFS 2.1). This of course will be pulled off with a locked bootloader.
Here's the method:
1. Extract NAND from Xperia XZ Premium (or any DRM-locked phone) via desoldering.
2. Use a NAND chip reader to dump the contents of the NAND chip.
3. Analyse contents and find DRM keys.
We'll be requiring the following:
1. A donor phone (or a spare NAND)
2. NAND chip reader
But there are some obstacles:
1. FDE is enabled by default, we'll need to find a way to decrypt the data
What are your thoughts guys, is this even possible?
Click to expand...
Click to collapse
Anythings possible, but this is probably impossible for 99.99% of users. As someone said above, TA keys are device specific. If you flashed my TA backup to your handset, you would have a pretty paperweight.
Hey guys
Having a weird issue that think is caused by missing DRM data on my Nothing Phone
Basically L1 seems to pass according to DRM info but in log complains about missing /data/vendor/mediadrm/IDM1013/L1/cert.bin
Can someone check if file exists and maybe attach it here if does
File is missing for me too.
Short research tells me it should be in the firmware files or will be generated the first time you try to use something L1 related.
What di you do so far?
xtcislove said:
File is missing for me too.
Short research tells me it should be in the firmware files or will be generated the first time you try to use something L1 related.
What di you do so far?
Click to expand...
Click to collapse
well had an app that used to work just fine
after an update to latest NOS or so, seems to not work anymore
did a logcat seeing that is checking DRM data and switching fine from L3 to L1 just that fails with unknown error
somewhere above in log I see it's complaining of said missing file
did some digging in stock firmware files (extracted myself) yet can't find the file so guessing is generated at first boot or so
just want to "prevent" a factory reset first, so thought to ask how other phones behave with said file if available or not
weird thing it that I see L1 under DRM info, so guess should work
gwolfu said:
well had an app that used to work just fine
after an update to latest NOS or so, seems to not work anymore
did a logcat seeing that is checking DRM data and switching fine from L3 to L1 just that fails with unknown error
somewhere above in log I see it's complaining of said missing file
did some digging in stock firmware files (extracted myself) yet can't find the file so guessing is generated at first boot or so
just want to "prevent" a factory reset first, so thought to ask how other phones behave with said file if available or not
weird thing it that I see L1 under DRM info, so guess should work
Click to expand...
Click to collapse
DRM Info says L1 for me too and the file is missing too. Is there any app i could check if l1 is working for me?
xtcislove said:
DRM Info says L1 for me too and the file is missing too. Is there any app i could check if l1 is working for me?
Click to expand...
Click to collapse
well the app I need is working only in my country and with login credentials, so not much can do there
thx for trying anyway
gwolfu said:
Hey guys
Having a weird issue that think is caused by missing DRM data on my Nothing Phone
Basically L1 seems to pass according to DRM info but in log complains about missing /data/vendor/mediadrm/IDM1013/L1/cert.bin
Can someone check if file exists and maybe attach it here if does
Click to expand...
Click to collapse
copied from Paranoid adroid 13 alpa 2 version , with root .
Exodusnick said:
copied from Paranoid adroid 13 alpa 2 version , with root .
Click to expand...
Click to collapse
Usgtable seems there
cert.bin is missing apparently
Anyway this kind of confirmed file not there in two cases
Might be app issue, idk
oh wrong read sorry.
you wanted to have cert.bin .
the leicer is missing with me too
Don't know if it helps. Clear all app date and cache of widevine needed apps.
gwolfu said:
Hey guys
Having a weird issue that think is caused by missing DRM data on my Nothing Phone
Basically L1 seems to pass according to DRM info but in log complains about missing /data/vendor/mediadrm/IDM1013/L1/cert.bin
Can someone check if file exists and maybe attach it here if does
Click to expand...
Click to collapse
im on stock nothing...no file also...i think it lost when root or unlock bootloader
If you just want to watch a video, this is a good way to get around it.
But Widevine will be L3.
GitHub - umylive/liboemcrypto-disabler: Magisk module to disable liboemcrypto.so DRM (e.g. Netflix, My5) on rooted Android devices.
Magisk module to disable liboemcrypto.so DRM (e.g. Netflix, My5) on rooted Android devices. - GitHub - umylive/liboemcrypto-disabler: Magisk module to disable liboemcrypto.so DRM (e.g. Netflix, My5...
github.com
ot_inc said:
If you just want to watch a video, this is a good way to get around it.
But Widevine will be L3.
GitHub - umylive/liboemcrypto-disabler: Magisk module to disable liboemcrypto.so DRM (e.g. Netflix, My5) on rooted Android devices.
Magisk module to disable liboemcrypto.so DRM (e.g. Netflix, My5) on rooted Android devices. - GitHub - umylive/liboemcrypto-disabler: Magisk module to disable liboemcrypto.so DRM (e.g. Netflix, My5...
github.com
Click to expand...
Click to collapse
with this module, indeed does work
cheers
I have reported this matter to Nothing. If there are more reports they will take the issue.
Issues and New Features Form
Please fill in this form to report issues and suggest new features.
docs.google.com
Also submitted info
Maybe they'll help