Factory reset

[CopperheadUser]

Hi,

is there any way to make factory reset?
I have forgot unlock password.
Bootloader is locked and i'm unable to unlock it from OS.
Copperhead OS was updated 2-3 weeks ago.
Recovery do not have any options about secure wipe.
Data lose is ok....

Any help is very appreciated...

[thestinger]

If the bootloader is locked, you can unlock it, unless you toggled off OEM unlocking. You can use fastboot unlock. If you toggled off OEM unlocking, then by design it cannot be reset, since the purpose of that feature is anti-theft. It is possible for us to make a build able to wipe it though.

[thestinger]

If the bootloader is locked, you can unlock it, unless you toggled off OEM unlocking. You can use fastboot unlock. If you toggled off OEM unlocking, then by design it cannot be reset, since the purpose of that feature is anti-theft. It is possible for us to make a build able to wipe it though.

[CopperheadUser]

Hi thestinger,

unfortunately, OEM unlocking is toggled off too. I just wanted all of possible security, now it's too much, lol.
Can you cook such "wipe"-build for me please?

Thanks in advance!

[CopperheadUser]

Hi thestinger,

unfortunately, OEM unlocking is toggled off too. I just wanted all of possible security, now it's too much, lol.
Can you cook such "wipe"-build for me please?

Thanks in advance!

[thestinger]

It's a problematic situation. If we give out builds able to wipe on request, that defeats the OEM unlocking feature for everyone. CopperheadOS isn't tied to an account so for this to work as an anti-theft / anti-tampering feature it can't allow wiping via recovery like stock rather than requiring authentication to do it. So I don't know what I should do about this.

[thestinger]

It's a problematic situation. If we give out builds able to wipe on request, that defeats the OEM unlocking feature for everyone. CopperheadOS isn't tied to an account so for this to work as an anti-theft / anti-tampering feature it can't allow wiping via recovery like stock rather than requiring authentication to do it. So I don't know what I should do about this.

[CopperheadUser]

Yes, it's a problematic situation, but wipe-builds would wipe CopperheadOS only, right?
I still have my encryption password so i'm able to start the phone.
But i have switched off all usb-related things, so no adb or such.
It's not even possible to open RMA since i have non-stock OS on my phone.
What if i record a video showing me unlocking encryption password (as a proof that the phone is mine)?
How can i pm you?

[CopperheadUser]

Yes, it's a problematic situation, but wipe-builds would wipe CopperheadOS only, right?
I still have my encryption password so i'm able to start the phone.
But i have switched off all usb-related things, so no adb or such.
It's not even possible to open RMA since i have non-stock OS on my phone.
What if i record a video showing me unlocking encryption password (as a proof that the phone is mine)?
How can i pm you?

[thestinger]

If you have the encryption password, you should still have access. Try powering it off completely, waiting a minute and then power it on. Maybe try alternating between the volume up/down buttons after entering the encryption password until it gets to the home screen to prevent it from going idle.

[thestinger]

If you have the encryption password, you should still have access. Try powering it off completely, waiting a minute and then power it on. Maybe try alternating between the volume up/down buttons after entering the encryption password until it gets to the home screen to prevent it from going idle.

[thestinger]

If that really doesn't work, I can make a build that wipes after the encryption password is entered, but I think you can probably get it working already.

[thestinger]

If that really doesn't work, I can make a build that wipes after the encryption password is entered, but I think you can probably get it working already.

[CopperheadUser]

that's a point, i still have an encryption password, but don't have an unlock password (they are different).
I often change unlock password and now i forgot it.
So it would be great, if you can provide something, wiping after entering encryption password.
Thanks in advance!

[CopperheadUser]

that's a point, i still have an encryption password, but don't have an unlock password (they are different).
I often change unlock password and now i forgot it.
So it would be great, if you can provide something, wiping after entering encryption password.
Thanks in advance!

[thestinger]

Can you try what I said though? Enter the encryption password and then keep the phone active until it gets to the home screen by alternating between the volume up / down buttons. I think it's supposed to stay active but it might take too long and go idle.

[thestinger]

Can you try what I said though? Enter the encryption password and then keep the phone active until it gets to the home screen by alternating between the volume up / down buttons. I think it's supposed to stay active but it might take too long and go idle.

[thestinger]

I can do a build but I'll have to figure that out and test it so it'll be a lot easier if this can work.

[thestinger]

I can do a build but I'll have to figure that out and test it so it'll be a lot easier if this can work.

[CopperheadUser]

I have entered encryption password, CopperheadOS starts, i'm pressing VolUp & VolDn, but OS loads to lockscreen, not homescreen. So the phone is locked...

[CopperheadUser]

I have entered encryption password, CopperheadOS starts, i'm pressing VolUp & VolDn, but OS loads to lockscreen, not homescreen. So the phone is locked...

[thestinger]

Strange, it boots to the home screen here even if it was locked when powering off.

Which device is this?

[thestinger]

Strange, it boots to the home screen here even if it was locked when powering off.

Which device is this?

[CopperheadUser]

Nexus 5x. Locked & wrong password entered before shutdown? I have to wait 30 sec. now between entering lockscreen password

[CopperheadUser]

Nexus 5x. Locked & wrong password entered before shutdown? I have to wait 30 sec. now between entering lockscreen password

[thestinger]

Ah, that makes sense. Forgot about that. I'll make a Nexus 5X build that wipes after a valid encryption password is entered then.

[thestinger]

Ah, that makes sense. Forgot about that. I'll make a Nexus 5X build that wipes after a valid encryption password is entered then.

[CopperheadUser]

Thank you! Email is in my profile.

[CopperheadUser]

Thank you! Email is in my profile.

[thestinger]

I can just publish it here because there's no harm in a build that wipes after valid encryption pw is entered.

[thestinger]

I can just publish it here because there's no harm in a build that wipes after valid encryption pw is entered.

[thestinger]

I don't know where the code has to go to do this.

[thestinger]

I don't know where the code has to go to do this.

[CopperheadUser]

What do you mean? Is it not just a special image to reflash?

[CopperheadUser]

What do you mean? Is it not just a special image to reflash?

[thestinger]

I need to implement wiping after the encryption password is entered though.

One thing that I'm unclear on is how you've been setting a separate encryption password / PIN when that feature hasn't been added back since the port to 7.x.

[thestinger]

I need to implement wiping after the encryption password is entered though.

One thing that I'm unclear on is how you've been setting a separate encryption password / PIN when that feature hasn't been added back since the port to 7.x.

[thestinger]

An alternative might be setting the lockscreen pw to the encryption pw when it's correctly entered. I don't just have code lying around to do any of this though.

[thestinger]

An alternative might be setting the lockscreen pw to the encryption pw when it's correctly entered. I don't just have code lying around to do any of this though.

[thestinger]

On 7.x, if you change the password, it changes both the encryption password and unlock password, since keeping them separate is not implemented. So if you changed it after upgrading, they'll be the same, and the same password should work for both.

[thestinger]

On 7.x, if you change the password, it changes both the encryption password and unlock password, since keeping them separate is not implemented. So if you changed it after upgrading, they'll be the same, and the same password should work for both.

[CopperheadUser]

I have been setting passwords in Android 6 and always updated OTA via "on board" updater.

[CopperheadUser]

I have been setting passwords in Android 6 and always updated OTA via "on board" updater.

[CopperheadUser]

Just checked, they are not the same... Encryption password does not work on lockscreen.
Might it be possible you send me "general" wiping image and i promise not to share it with anyone / shift+delete after flashing? Because bricked phone is really pain in the a.

[CopperheadUser]

Just checked, they are not the same... Encryption password does not work on lockscreen.
Might it be possible you send me "general" wiping image and i promise not to share it with anyone / shift+delete after flashing? Because bricked phone is really pain in the a.

[thestinger]

The only way to deal with this will be implementing a wipe after entering the encryption password correctly.

[thestinger]

The only way to deal with this will be implementing a wipe after entering the encryption password correctly.

[cypherpunkglobal]

Hi thestinger.

Love the project especially given the things going on in my geographical area at the moment.

I understand the issue here to be if you have lost your encryption password (or set separate encryption and unlock passwords pre-7.0 and lost the unlock password) and have OEM Unlocking disabled in the OS, you cannot wipe and factory reset the device from recovery.

You suggest that OEM Unlocking is an anti-theft feature because it prevents unauthorized resetting and selling of the device. This is true, but imho I would primarily see OEM Unlocking as a security measure to prevent installation of a malicious bootloader which could be used to collect a user’s encryption password and the Anti-Theft part being an effect of said measure.

You suggested on Twitter that a move to collect serial numbers could be used to replace the reset authorization that comes with Google Play account device association.

The issue I see with a move towards collecting serial numbers and/or associating them with a user ID would be precisely that it would recreate the hardware tracking and ID association that Apple (even without Apple ID or iCloud registration), Google, etc currently practice.

If what you meant by serial number collection was simply collecting serial numbers when customers purchase devices directly from you and associating them with purchase details to allow for remote wipe support, I apologise for putting you through reading all this. However, even if this is what you meant, I would also suggest that for the sake of customer security and privacy you at least ask them whether they want you to collect this at purchase.

If what you are suggesting is that devices would automatically send hardware identifiers upon installation for any user to Copperhead servers, I would warn strongly against it.
Given that I would assume many users of CopperheadOS want to maintain maximum anonymity, confidentiality, privacy and security and increasingly authoritarian governments worldwide are using such tracking to find dissidents, if this data collection is what you are suggesting, I strongly suggest it to be optional and possible to completely avoid.

A possible solution I see would be to recreate Google’s bootloader with a simple modification to deal with the problem of a lost encryption password. Couldn’t a bruteforce-protected custom password-based device wipe/reset option be created in recovery or at the unlock prompt? Otherwise, is an iOS-style (despite my criticism of Apple’s tracking) wipe after ten incorrect password entries possible?

Imho security and privacy should trump anti-theft especially in an OS like Copperhead. Minimizing the number of parties potentially harmful data is sent to is essential to security/privacy imho. CopperheadOS is the only modern and reasonably secure OS out there for mobile devices that does not associate the device (iOS does even without iCloud - App Store links device hardware ID to Apple ID, APNS push ID to hardware ID, iMessage - phone number/apple id to hardware ID. These identifiers are then collected and linked to all information given at purchase). I realise that I should contribute code instead of ranting, but I really felt that this was an important aspect for the OS.

Thanks for making this amazing project what it is today!

[cypherpunkglobal]

Hi thestinger.

Love the project especially given the things going on in my geographical area at the moment.

I understand the issue here to be if you have lost your encryption password (or set separate encryption and unlock passwords pre-7.0 and lost the unlock password) and have OEM Unlocking disabled in the OS, you cannot wipe and factory reset the device from recovery.

You suggest that OEM Unlocking is an anti-theft feature because it prevents unauthorized resetting and selling of the device. This is true, but imho I would primarily see OEM Unlocking as a security measure to prevent installation of a malicious bootloader which could be used to collect a user’s encryption password and the Anti-Theft part being an effect of said measure.

You suggested on Twitter that a move to collect serial numbers could be used to replace the reset authorization that comes with Google Play account device association.

The issue I see with a move towards collecting serial numbers and/or associating them with a user ID would be precisely that it would recreate the hardware tracking and ID association that Apple (even without Apple ID or iCloud registration), Google, etc currently practice.

If what you meant by serial number collection was simply collecting serial numbers when customers purchase devices directly from you and associating them with purchase details to allow for remote wipe support, I apologise for putting you through reading all this. However, even if this is what you meant, I would also suggest that for the sake of customer security and privacy you at least ask them whether they want you to collect this at purchase.

If what you are suggesting is that devices would automatically send hardware identifiers upon installation for any user to Copperhead servers, I would warn strongly against it.
Given that I would assume many users of CopperheadOS want to maintain maximum anonymity, confidentiality, privacy and security and increasingly authoritarian governments worldwide are using such tracking to find dissidents, if this data collection is what you are suggesting, I strongly suggest it to be optional and possible to completely avoid.

A possible solution I see would be to recreate Google’s bootloader with a simple modification to deal with the problem of a lost encryption password. Couldn’t a bruteforce-protected custom password-based device wipe/reset option be created in recovery or at the unlock prompt? Otherwise, is an iOS-style (despite my criticism of Apple’s tracking) wipe after ten incorrect password entries possible?

Imho security and privacy should trump anti-theft especially in an OS like Copperhead. Minimizing the number of parties potentially harmful data is sent to is essential to security/privacy imho. CopperheadOS is the only modern and reasonably secure OS out there for mobile devices that does not associate the device (iOS does even without iCloud - App Store links device hardware ID to Apple ID, APNS push ID to hardware ID, iMessage - phone number/apple id to hardware ID. These identifiers are then collected and linked to all information given at purchase). I realise that I should contribute code instead of ranting, but I really felt that this was an important aspect for the OS.

Thanks for making this amazing project what it is today!

[thestinger]

You suggest that OEM Unlocking is an anti-theft feature because it prevents unauthorized resetting and selling of the device. This is true, but imho I would primarily see OEM Unlocking as a security measure to prevent installation of a malicious bootloader which could be used to collect a user’s encryption password and the Anti-Theft part being an effect of said measure.

Unlocking the device will wipe user data so there will be no data left to decrypt with the encryption password entered by the user. It makes far more sense to swap the device with another ready to capture the password, and then enter that on the real device which wouldn't have needed to be wiped. I don't see the value prospect of the OEM unlocking toggle as a security feature.

If what you meant by serial number collection was simply collecting serial numbers when customers purchase devices directly from you and associating them with purchase details to allow for remote wipe support, I apologise for putting you through reading all this. However, even if this is what you meant, I would also suggest that for the sake of customer security and privacy you at least ask them whether they want you to collect this at purchase.

That's what it meant. Recording the serial number of the devices we sell, so that we could make updates for specific users designed to wipe their devices without impacting other devices. There's a purchase record where we bought the device and then shipped it anyway. I don't see any privacy impact from recording that. It's simply an arbitrary unique number per device and Google has the numbers since they manufactured and shipped the devices to us. For all I know it might even be recorded on the invoice already.

If what you are suggesting is that devices would automatically send hardware identifiers upon installation for any user to Copperhead servers, I would warn strongly against it.

Given that I would assume many users of CopperheadOS want to maintain maximum anonymity, confidentiality, privacy and security and increasingly authoritarian governments worldwide are using such tracking to find dissidents, if this data collection is what you are suggesting, I strongly suggest it to be optional and possible to completely avoid.

No that's not what was said and it wouldn't be relevant to this. Not going to be giving out updates able to wipe devices without knowing that the user requesting it really bought it.

A possible solution I see would be to recreate Google’s bootloader with a simple modification to deal with the problem of a lost encryption password. Couldn’t a bruteforce-protected custom password-based device wipe/reset option be created in recovery or at the unlock prompt? Otherwise, is an iOS-style (despite my criticism of Apple’s tracking) wipe after ten incorrect password entries possible?

The whole point is that it's not supposed to be possible to wipe without having the password. iOS and Google Android devices get tied to accounts, so they can lock down devices into logging into the account and they rely on the normal account recovery.

[thestinger]

You suggest that OEM Unlocking is an anti-theft feature because it prevents unauthorized resetting and selling of the device. This is true, but imho I would primarily see OEM Unlocking as a security measure to prevent installation of a malicious bootloader which could be used to collect a user’s encryption password and the Anti-Theft part being an effect of said measure.

Unlocking the device will wipe user data so there will be no data left to decrypt with the encryption password entered by the user. It makes far more sense to swap the device with another ready to capture the password, and then enter that on the real device which wouldn't have needed to be wiped. I don't see the value prospect of the OEM unlocking toggle as a security feature.

If what you meant by serial number collection was simply collecting serial numbers when customers purchase devices directly from you and associating them with purchase details to allow for remote wipe support, I apologise for putting you through reading all this. However, even if this is what you meant, I would also suggest that for the sake of customer security and privacy you at least ask them whether they want you to collect this at purchase.

That's what it meant. Recording the serial number of the devices we sell, so that we could make updates for specific users designed to wipe their devices without impacting other devices. There's a purchase record where we bought the device and then shipped it anyway. I don't see any privacy impact from recording that. It's simply an arbitrary unique number per device and Google has the numbers since they manufactured and shipped the devices to us. For all I know it might even be recorded on the invoice already.

If what you are suggesting is that devices would automatically send hardware identifiers upon installation for any user to Copperhead servers, I would warn strongly against it.

Given that I would assume many users of CopperheadOS want to maintain maximum anonymity, confidentiality, privacy and security and increasingly authoritarian governments worldwide are using such tracking to find dissidents, if this data collection is what you are suggesting, I strongly suggest it to be optional and possible to completely avoid.

No that's not what was said and it wouldn't be relevant to this. Not going to be giving out updates able to wipe devices without knowing that the user requesting it really bought it.

A possible solution I see would be to recreate Google’s bootloader with a simple modification to deal with the problem of a lost encryption password. Couldn’t a bruteforce-protected custom password-based device wipe/reset option be created in recovery or at the unlock prompt? Otherwise, is an iOS-style (despite my criticism of Apple’s tracking) wipe after ten incorrect password entries possible?

The whole point is that it's not supposed to be possible to wipe without having the password. iOS and Google Android devices get tied to accounts, so they can lock down devices into logging into the account and they rely on the normal account recovery.

[thestinger]

Anyway, the solution for this issue is to make @CopperheadUser a build wiping the device after the encryption password is correctly entered. It's fine to publish that here, and I would have built it already if the code existed. It doesn't exist though, and I don't have time to develop and test it. It's a very unique situation so it would ever be reused...

[thestinger]

Anyway, the solution for this issue is to make @CopperheadUser a build wiping the device after the encryption password is correctly entered. It's fine to publish that here, and I would have built it already if the code existed. It doesn't exist though, and I don't have time to develop and test it. It's a very unique situation so it would ever be reused...

[thestinger]

If you can wipe the device, then you can boot up the freshly wiped device and toggle off OEM unlocking. It has no value if wiping the device is possible without a password. Google now ties the OEM unlocking toggle to Google account credentials on the Pixel and Pixel XL but that's not something CopperheadOS will be reimplementing. If a user wants to allow wiping the device before entering the password, then they simply shouldn't disable OEM unlocking. There is no loss compared to any other way of exposing wiping like that.

[thestinger]

If you can wipe the device, then you can boot up the freshly wiped device and toggle off OEM unlocking. It has no value if wiping the device is possible without a password. Google now ties the OEM unlocking toggle to Google account credentials on the Pixel and Pixel XL but that's not something CopperheadOS will be reimplementing. If a user wants to allow wiping the device before entering the password, then they simply shouldn't disable OEM unlocking. There is no loss compared to any other way of exposing wiping like that.

[thestinger]

Anyway need help implementing wipe after successful entry of the encryption password so that I can make a signed build for @CopperheadUser to wipe. I have my hands full as the only developer working on this project... today is both the security update day and the migration to 7.1.1 and there's a whole lot of other high priority stuff.

[thestinger]

Anyway need help implementing wipe after successful entry of the encryption password so that I can make a signed build for @CopperheadUser to wipe. I have my hands full as the only developer working on this project... today is both the security update day and the migration to 7.1.1 and there's a whole lot of other high priority stuff.

[CopperheadUser]

For all facing the same problem:
http://forum.xda-developers.com/nexus-5x/help/req-help-to-unbrick-t3251740
after this sideload OTA update:
howto: https://drive.google.com/file/d/0Bz6x7k-VkpUJam5Mc1hKa09PVGc/view
Enable OEM unlocking.

[CopperheadUser]

For all facing the same problem:
http://forum.xda-developers.com/nexus-5x/help/req-help-to-unbrick-t3251740
after this sideload OTA update:
howto: https://drive.google.com/file/d/0Bz6x7k-VkpUJam5Mc1hKa09PVGc/view
Enable OEM unlocking.

[thestinger]

Are you saying you were able to bypass it?

[thestinger]

Are you saying you were able to bypass it?

[CopperheadUser]

Yes, i was able to recover my semi-bricked phone.
Moreover, i'm thinking, that it's not a purpose of CopperheadOS, to provide anti-theft security for hardware (300 bucks), but for data on the phone.
And holding own customers hostage of bootloader is not good, sorry.

[CopperheadUser]

Yes, i was able to recover my semi-bricked phone.
Moreover, i'm thinking, that it's not a purpose of CopperheadOS, to provide anti-theft security for hardware (300 bucks), but for data on the phone.
And holding own customers hostage of bootloader is not good, sorry.

[thestinger]

Toggling off OEM unlocking isn't something that has to be done.

[thestinger]

Toggling off OEM unlocking isn't something that has to be done.

[thestinger]

@CopperheadUser So were you able to access download mode and work around this? You just flashed the factory images again? Good to know that LG deviated from Google's requirements similar to how they did for uart support and by passing slab_debug on the kernel line for some reason.

[thestinger]

@CopperheadUser So were you able to access download mode and work around this? You just flashed the factory images again? Good to know that LG deviated from Google's requirements similar to how they did for uart support and by passing slab_debug on the kernel line for some reason.

[CopperheadUser]

sorry my late response,
yes, i was able to start download mode and flash special "TOT" image with special flasher.
I think, it's art of emergency flash tool and somehow forged image.
After this i had to sideload google image and was able to enable OEM unlock.

[CopperheadUser]

sorry my late response,
yes, i was able to start download mode and flash special "TOT" image with special flasher.
I think, it's art of emergency flash tool and somehow forged image.
After this i had to sideload google image and was able to enable OEM unlock.

[sigenc]

Is this also possible with Nexus 6P

[sigenc]

Is this also possible with Nexus 6P

[thestinger]

I doubt it, it's a design flaw in the Nexus 5X (it offers a download mode not disabled by default and walled off by bootloader locking).

[thestinger]

I doubt it, it's a design flaw in the Nexus 5X (it offers a download mode not disabled by default and walled off by bootloader locking).