yashsingh1/xdaforums huggingface dataset:
[MTCB Android Head Units Q&A] d31b0y:
Hi, I have been having some issues with my Eonon head unit (Klyde rebrand).

Most of the time the head unit won't come on until about 30 minutes into driving. Most of the time, the reversing camera doesn't work. A lot of the time when I now turn the engine off and take the key out, the stereo will stay on for an indefinite amount of time.

Everything works perfectly sometimes. It's driving me nuts.

I can get to recovery without fail.

It was working perfectly all the time up until a few months ago. I'm not really sure when I first noticed it but it's definitely gotten worse.

I had a few different ideas as to what it could be.

* Battery issues; I got a warning light once a while ago to say my battery was low. This was just after a 20 minute drive when I had turned off the engine but kept the stereo on. It only came up once though. I've tried hooking another battery with jumper leads to rule this out too. With the jumper leads, the stereo still wouldn't come on.

* Fuse in the stereo itself; it's a suggestion to check to see if the fuse is blown in the stereo. Is it just a case of pulling the fuse out and it will be obviously blown? Or would I have to buy a new one to test?

* 12V DC not getting to the stereo; Someone else suggested that they had very similar problems (could get stereo to recovery but not to boot) and their solution was that it wasn't receiving 12V DC. I will check this out with a multimeter tomorrow, but if this is the case, how to I go about testing further and fixing?

* Bad software flash; I am currently running Malysk 4.4.4 rom with KLD1 v2.55 though I have tried a number of different MCU's like 'KLD1 v.2.55 with sleep and redesigned sound processor from darkleo', 'KLD1 v.2.55 factory', 'KLD1 v.2.67'. I also tried some KLD6 as someone mentioned that it might be compatible with many KLD1 systems. Same issue no matter what.

Out of interest, I am 99% sure that I was originally on KLD1 v2.55 but that final 1% won't stop niggling at me that I am wrong. Is there a way to confirm?

* Dead CANBUS decoder; if it was dead or dieing, would that cause these issues. Not sure why I think it might be this but I do...

I can't really think of anything else but any help you can provide would be greatly appreciated!
[MTCB Android Head Units Q&A] MikeO69:
Long time ago but have the same problem so hopping you solved the problem?

Radio not turning on when turning the key. While driving it suddenly starts. Sometimes after 1 minute and sometimes after 30 minutes / 1 hour. Turning of the car and remove the key, radio keeps playing and have to manual turn of the radio.

Next time it repeats itself and sometimes it is working fine and radio starts without problem.

But it is every time random so driving me crazy.

I think the canbus with comes with the radio have problems but radio is old Eonon MG5161 WinCe version.
[Samsung Galaxy S7 Edge Questions and Answers] murdi007:
Hello, i need help with samsung s7 edge. I have random resarts in menu and after that strange screen with stripes.

Phone is after wipe and factory reset with orginal firmware.

Here are those stripes ..

Anyone can help me ?
[Samsung Galaxy S7 Edge Questions and Answers] joe.skelly:
Most likely Hardware issue. Could be a loose connector, but probably more.

Is it still under warranty?

Tapatalk for Android - Works awesome on my Samsung Galaxy S7 Edge
[Samsung Galaxy S7 Edge Questions and Answers] murdi007:
yes under guarantee but guy want sell it cheap so probably problem is with screen and its not under guarantee.. phone is cracked backside.

thanks for reply
[Samsung Galaxy S7 Edge Questions and Answers] joe.skelly:
If it's cracked on the back side, and the issues stated, there is most likely Hardware damage.

With the random freezes on top of the screen issues, there might be more wrong than just the screen.

I'm not sure what "under guarantee" means. Or more to the point, what it means to the seller. Was the case cracked before you bought it?

Ultimately, I would attempt to reach out to the seller and see what, if anything, they are willing to do for you.

But, if the case cracking happened after you purchased it, than most likely they won't do too much. Samsung itself won't fix one of their devices under warranty if it shows signs of abuse (intentional or by accident).

Tapatalk for Android - Works awesome on my Samsung Galaxy S7 Edge
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] kevcruz092:
Anyone got the New Wallpaper from the S8 leaks?
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] tallman43:
Zedge is your friend >> http://www.zedge.net/wallpaper/11134939/ << :D
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] adamb30:
We want the blue one!
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] Ragazzza:
the only one that leaked is this, the gradient blue one.
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] Bart3n:
Awesome, thanks man!
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] frankfurtjr:
Thank you !
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] absinthe77:
Thanks a lot
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] Ragazzza:
Too bad we can't yet get a HD sample
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] raakaysh:
All of them are in QHD quality.
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] cottino:
All of them are fake!
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] Sir Hamude:
Thanks!Looks great.
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] Ragazzza:
:good:
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] baruaberger:
how to use this as built in wallpaper from wallpaper picker in setting
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] Bart3n:
Then you will have to edit the wallpaperchoser apk and add the wallpaper in there.. otherwise.. not possible
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] baruaberger:
Could you please help me to do how to edit wallpaperchoser apk?Or if you have any useful link regarding edition of wallpaperchoser apk ,please provide me to do.Thanks in advance for your valuable suggestion.
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] Kimmy96:
Anyone already got S8 infinity wallpapers to share us?
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] sandman997:
View attachment 4094186View attachment 4094187View attachment 4094188
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] tymex928:
Any chance to change the new icons (home, back, ...) at the bottom bar?
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] tu3218:
Anyone think we'll be able to get the new infinity live wallpaper?
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] RileyIssKing:
yesss i need these
[Samsung Galaxy S7 Edge Themes, Apps, and Mods] Ragazzza:
Here are Wallpapers in QHD!

http://www.mediafire.com/file/b41xt3ogqlfdld9/Galaxy+S8+Stock+Wallpapers+By+HITMAN-CREED.zip

all credits go to [MENTION=5380611]HITMAN-CREED[/MENTION]
[OnePlus 3T Guides, News, & Discussion] smaeul:
WARNING: Before playing around with any of this, enable OEM unlocking in Developer options and downgrade to the OOS 4.0.1 bootloader, or you may lock yourself out permanently!

How to extract the signature from a stock boot.img:

Find the end of the Android boot image data in the file. Use unpackbootimg (e.g. from LineageOS) and add up the size of the extracted "zImage" and "ramdisk.gz" files, or read the sizes of the kernel and initramfs directly from the boot image header. Round up each of these sizes to a multiple of 4096, since each section of the boot image data is always a multiple of the page size.

Add one page (4096 bytes) for the header at the beginning of the file.

The next bytes immediately following that will be the signature. From the documentation/bootloader source, it can vary in length, but OnePlus's signatures are around 1320 bytes long. The size of the signature is a variable-length integer starting with the second byte of the signature. In short, take 256*sig[2]+sig[3]+4 as full length of the signature data.

How to fool the current bootloader and bypass all warnings:

Concatenate any valid-format signature to the end of your boot image.

Flash your boot image with fastboot or in TWRP.

Profit.

Note that this method works for any modified kernel: TWRP, stock with Super-SU, LineageOS, franco.kernel, etc. (Well, almost any. The signature records the size of the boot image in it, and if that happens to match, you will get a warning, but it will still boot.)

The attached zip file will perform this operation on the currently-installed boot image.
[OnePlus 3T Guides, News, & Discussion] smaeul:
I have added a zipfile (sha256sum c4a15c0d3d6f8efa4c4e14196b48790cdb86f6110bcb51e92dbfce32c959db11) to the second post that will "sign" the currently-installed boot image using the certificate from the OP3T beta 3 stock kernel (though any one will work). It is intended to be flashed last after installing your ROM or kernel. Unfortunately, you will have to do this after every update. It will be obvious if you forget, but the reboot cycle won't hurt anything (just use the button combo to get back to recovery).

I can't attach a fixed recovery because it's too large, but you can modify the zip to sign the recovery partition (the path at the top of the script). Of course, you would have to do this before locking your bootloader.
[OnePlus 3T Guides, News, & Discussion] rk2612:
The above maths is fine for the boot.img of OP3 but the recovery.img leaves 5420 bytes (both are attached). When I compared these trailing 1320 and 5420 bytes, they seemed similar but the 5420 bytes extracted from recovery.img have a lot of trailing zeros. What explains this? (PS: I used the tail command on ubuntu to extract these bytes from 4.0.3 stock boot and recovery images).
[OnePlus 3T Guides, News, & Discussion] smaeul:
The math I provided earlier is also only right when the kernel or ramdisk happens to be a multiple of 4096 bytes. The correct algorithm for the offset (and I'll update the second post) is round_to_4096(kernel)+round_to_4096(ramdisk)+4096.

The size of the signature is actually encoded at the beginning of the DER data, as a variable-length integer (see the source). Pasted below is the first 64 bytes of the signature from the stock recovery. You can see that the first byte matches what the bootloader expects (line 106 of the code). The second byte tells us the signature length is two bytes long. The next two bytes are 0x0528 (hexadecimal), which is 1320 when converted to decimal. So those 4 bytes + the next 1320 are the signature. So the remaining 4096 bytes (exactly one flash page) is something else. It could be junk or some other (OnePlus-specific?) metadata.

00000000 30 82 05 28 02 01 01 30 82 03 fd 30 82 02 e5 a0 |0..(...0...0....|
00000010 03 02 01 02 02 09 00 97 0f 98 39 09 aa 89 49 30 |..........9...I0|
00000020 0d 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 30 81 |...*.H........0.|
00000030 94 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 13 |.1.0...U....US1.|

This matches what we expect from the boot.img, which has a signature that is 4+0x0524 = 1320 bytes long, and that is exactly the length of the extra data after the ramdisk. When we have the whole signature, we can use openssl to decode it:

openssl asn1parse -i -in signature.der -inform der

Oh, and I'll add this to the OP, I found the official Android description about how this all works: https://source.android.com/security/verifiedboot/verified-boot.html
[OnePlus 3T Guides, News, & Discussion] rk2612:
But then comparing these 1320 bytes from recovery and boot images, aren't they different?
[OnePlus 3T Guides, News, & Discussion] smaeul:
Yes, of course. The last 256 bytes of the signature are an encrypted hash of the boot image. The bootloader is supposed to 1) calculate a hash of the boot image and 2) decrypt the hash in the signature using the public key from the certificate (also in the signature), and then verify that the two hashes match. The reason that we can just throw these existing signatures around is that, when the boot image is the wrong size, the bootloader doesn't even look at the hash in the signature.

The point of what you quoted was to say that the math that tells us how many bytes there should be, matched the actual number of bytes remaining in the file, so therefore the math was reasonable. The signatures from the two files do not match. They are not even the same size (though I haven't investigated why yet). But it doesn't matter what they contain, as long as they cause the bootloader to 1) not crash and 2) trigger the bug.
[OnePlus 3T Guides, News, & Discussion] rk2612:
Thanks. Try concatenating the 5420 bytes from the stock recovery to TWRP and see the magic!!! I was brave enough to try with a locked bootloader. :cowboy: .....Of course with OOS 4.0.1 bootloader. Reminds me of Bump! on LG G3. Not sure if this will work with OOS 4.0.3 bootloader.

A few other things I tried which seem weird and quite likely to be a security loophole:

1. When you unlock a bootloader, it boots back into the security warning screen. At that time, the data partition is still not wiped!

2. The data partition is wiped when it starts to boot and goes into recovery. I think the code --wipe-data is used with a recovery script (openrecoveryscript or recovery.command) stored in cache.

3. Therefore, if a modified recovery is flashed immediately after unlocking and before it boots into recovery, then it possible to defeat the script (...can be done by either not mounting cache or by not mounting data partitions ... deleting mount points in fstab).

4. Even if an official TWRP is flashed immediately after unlocking, the data wipe does not wipe data/media as TWRP treats these wipes differently than stock recovery.

From a tigher security point of view, I would have expected fastboot to wipe the data partition rather than rely on recovery to do it. Therefore, this sounds like a security loophole but I do not have enough technical knowledge to say with full certainty as I consider myself a "cut-and-paste" developer. :o

And I also wonder whether this behaviour is specific to OnePlus 3 or if it is similar across all devices where bootloader can be unlocked.
[OnePlus 3T Guides, News, & Discussion] smaeul:
You wouldn't have to use a modified recovery. "fastboot erase cache" before booting into recovery mode should do the trick.

I'm on the latest open beta bootloader for the 3T (I haven't bothered to update since OOS 4.1.0 came out), and nothing has changed. Even if OnePlus does pull changes from Qualcomm and fix the bug, it will still boot, albeit with the warning shown here: [IMG="red boot state"]https://securityresear.ch/images/opo3-red-bootstate.jpg[/IMG] Ironically, according to Google's documentation, the "red boot state" shown there should force the device to turn off after the delay (prevent booting).

Further explanation of the wiping comes from Google's verified boot documentation. Search for "Binding TEE root of trust". Basically, the disk encryption key is derived from the kernel signing key and the boot verification state, in addition to your password. So when you boot an unsigned (or signed-by-somebody-else) recovery/kernel, the encryption key will be different, even for the same password. That's what causes the impossible password prompt in TWRP, and how they can implement "wiping without actually wiping" once you break dm-verity or install a custom ROM.

Of course, since the bug lets you still be in the green bootstate, that means you can keep your data from stock, locked, unrooted OOS, since the keys stay the same. So, yes, this is a huge security vulnerability, because it allows somebody to install a malicious OS without triggering a wipe. For this and other reasons, security on this phone is a joke, and there's nothing we can do about it.
[OnePlus 3T Guides, News, & Discussion] rk2612:
Somehow that didn't work me. Maybe the wipe instruction are placed into cache again after the device starts booting.

---------- Post added at 07:10 AM ---------- Previous post was at 06:35 AM ----------

I used the following way to get around this impossible password:

1. After unlocking, immediately flashed a modified TWRP recovery which did not mount cache.

2. Backed up system and data with TWRP on usb-otg.

3. Flashed stock recovery, which did a factory reset at next boot (...because the script to wipe data was still there).

4. Flashed TWRP at the next startup (...device is without any data).

5. Used TWRP to flash a modified boot image (...with encryptable data partition and system verify deleted in boot fstab).

6. Restored backed up system from TWRP and set up the device as a fresh device (... data is unencrypted).

7. Booted back into TWRP and restored backed up data from TWRP and wiped cache.

8. Delected the 5 lock settings files in /data/system/.

9. Booted back into device with original data unencrypted and without any impossible password!

10. Booted into fastboot and flashed stock recovery (...to enable full data wipe if the device falls into not so experienced hands).

11. Locked bootloader and used fastboot oem disable_dm_verity using OOS4.0.1 bootloader (...because I am using a modified hosts file in my system).

12. Set up passwords again after booting into device.

(...I think this works because I had file encryption rather than full device encryption).

The security warning that you refer to is still showing but the device is locked and has original data. I think the data can be encrypted back again (...because boot fstab has a flag of encryptable). And then stock boot and system images can also be flashed back again (...unless system has modifications like a modified hosts file like mine). Perhaps without system modification and with original boot, this warning will also go away but I do not want to give up on my modified hosts file as yet.

Two things that are still bugging me:

1. Is there any way to get rid of security warning (...using a properly self signed boot image rather than an invalid signature)? I'm aware that with all the security loopholes in this device / bootloader / android, that does not grant full security but all I am trying to achieve is for the device to look unmodified so that not so experienced persons who find my device believes that confidential information cannot be extracted from it.

2. If I flash either of systemless or system SuperSu before locking, the device does not boot fully and gets stuck at the rotating dots animation. BTW, I do not miss root so much on nougat as hosts file can be replaced through TWRP and data control in nougat serves as an effective firewall. But I'm still looking for flexibility in case it is needed.

Any suggestions?
[OnePlus 3T Guides, News, & Discussion] rk2612:
The signature on an Android verifiable boot image is an ASN.1 DER-encoded message (https://source.android.com/security/verifiedboot/verified-boot.html). This can be parsed using online tools (https://lapo.it/asn1js/#30820524020...B24FF93E4ADF5F5D7D4153F794D2EE9D87422AB8A2258) to show that 1320 bytes of the boot signature comprise of a 1316 byte length sequence.

Decoding the signature of the recovery block indicates that the differences are:

1. An extra page in the end (4096 bytes) in addition to the above (as you'd already pointed out)

2. Before that, recovery signature is 4 bytes longer because "/recovery" string takes 4 extra bytes to represent compared to "/boot" string.

3. Size of the recovery image (as mentioned within the 1324 bytes) is different from boot image as well.
[OnePlus 3T Guides, News, & Discussion] smaeul:
It may be an kernel command-line argument or on the "persist" or "misc" partition instead of inside /cache. I haven't looked into it.

Is the security warning about dm-verity, or that it cannot verify the kernel/OS? (Post an image?) If it's dm-verity, see the verified boot documentation (search for "Recovering from dm-verity errors") for how that gets reset. I don't know which way device uses, since I haven't spent much time on a dm-verity enforcing ROM/kernel. If the warning is about something else, I don't know. My device never shows any warnings except with a modified stock kernel/recovery that matches the original size.

Well that makes perfect sense :).
[OnePlus 3T Guides, News, & Discussion] rk2612:
No, I think it is in the cache as the command does not execute if a modified recovery (which does not mount cache) is used. But the command may be getting pushed from devinfo partition (where I think fastboot related status is stored).

The warning is the same one as in the image that you posted. And that's because I am using a modified kernel (no forced encryption and no verify for /system) for the time being. I doubt if there is a way to get rid of that warning and keep a modified kernel or system. Also, if I go back to stock kernel and have a modified system (...not yet ready to give up on hosts file ad-blocking after so many years), then I will have to rely on the fastboot oem disable_dm_verity and that may also trigger a warning I think. No?
[OnePlus 3T Guides, News, & Discussion] smaeul:
Are you using the stock kernel that you unpacked and repacked? And are you using the signature from the stock kernel? That's the one case where you will get that warning. Since the repacked kernel is the exact same size as the original one, the bug in the bootloader isn't triggered, and the verification fails as it should. Try using the signature from the stock recovery with your kernel and see if the warning goes away.
[OnePlus 3T Guides, News, & Discussion] rk2612:
I'm currently using the stock kernel modified with a modified fstab (no verify for /system and encryptable instead of forced encryption for /data). When I repacked the kernel, it came to be a slightly different size even without the signature. The warning remains ....with or without a signature (from either boot or recovery).

What triggers the warning in your case?
[OnePlus 3T Guides, News, & Discussion] smaeul:
I was only able to trigger the warning by unpacking and repacking the stock kernel, and appending the original signature from the same stock kernel. Any custom kernel, SuperSU rooted stock kernel, recovery kernel, etc. signed with the stock kernel signature did not produce any warning/prompt at all. This is with the bootloader from OOS 4.0.1, 4.0.3, and 4.1.0 beta 3. I haven't updated to the 4.1.0 stable yet. What is your bootloader version.

Send me your modified boot.img and I'll create a signature for it that should avoid the warning.
[OnePlus 3T Guides, News, & Discussion] rk2612:
SOLVED

Thanks. I'm using bootloader 4.0.1 but have modified boot and system from 4.0.3. Modified boot image attached.

EDIT: Reading your comment again, I realize what I missed. You mention that the warning comes after by unpacking and repacking the stock kernel (with modifications, I presume). That is the case with me as well. However, I have now locked the device and if I try to flash SuperSu 2.79SR3 (systemless) now, I get into a bootloop.

SOLVED: On a hunch, I hex edited the boot signature to reduce the size mentioned after the "/boot" and made it nearly half of the original boot.img size. And it worked without throwing up any warning!!! Thanks to you for pointing out that size variation triggers the bug which causes the warning not to be displayed. The size difference needs to be (perhaps) big enough for the warning not to be triggered (...maybe bigger than the 1,320 bytes being added / bigger than one page ).
[OnePlus 3T Guides, News, & Discussion] smaeul:
If you flash a zip that modifies your boot image, like SuperSU, you should expect to get the boot loop. They work by running unpackbootimg and mkbootimg on your device, which will throw away any signature. If you flash the fakesign.zip from post 2 after flashing SuperSU (or adb pull the boot partition and manually add the signature yourself), it should work.

Try the boot image in the attached zip and see if it works or produces any warning.
[OnePlus 3T Guides, News, & Discussion] rk2612:
Boot loops caused by SuperSu are not due to signature. If modified stock boot works without a signature and only a warning, why should be any different for further modifications to boot image by SuperSu?