[Verizon Galaxy Note 3 General] alexp1289:
So I found some info in the note 4 dev edition conversion thread. Someone reposted what npjohnson said. This makes sense as to why things are taking so long and why we must remain patient. Don't try any of this on your own. Just wait patiently and don't bug any developers please :)

-------------------------------------

Search Thread

PaulPizz

Yesterday, 10:19 PM |#181

Senior Member171 posts Thanks: 88

Quote:

Originally Posted by chriskader

So... using some searching I was able to set my CID to something random:

Code:

[+] CID at boot time is/was: 15111111111111111111111111111100

[-] RTFC!! ./samsung_cid [NEW_CID]

I used temp root obtained through KingRoot and this CID stuck after reboot (My actual CID is safe).

I did not reflash anything, I simply used the tool to change my CID. I do not really use this note 4 so I figured I had nothing to loose.

If setting an actual Dev CID does something, I am willing to try.

I've successfully change my cid to a developer cid. It doesn't unlock it unfortunately. We need a developer edition aboot.mbn flashed to the matching cid. People on here keep implieing that I'm wrong but it seems to me that's the issue. What bootloader is the device on?

chriskader

Yesterday, 10:22 PM |#182

Senior Member287 posts Thanks: 51

I am currently on 5.0.1 and B0G5

Based on what I read, the version does not matter as long as the bootloader matches the CID it was changed to. If someone wants to send their aboot and CID I am willing to try for science!

sixtythreechevy

Yesterday, 10:26 PM |#183

Senior Member124 posts Thanks: 32

From [MENTION=5848265]npjohnson[/MENTION]:

"New exploits allow for CID change, which allows is to flash Developer Edition a boots if we use a corresponding CID."

So flashing the aboot is part of it it appears.

1 users say Thank You to sixtythreechevy for this useful post Gift sixtythreechevy Ad-Free

chriskader

Yesterday, 10:27 PM |#184

Senior Member287 posts Thanks: 51

Quote:

Originally Posted by sixtythreechevy

From [MENTION=5848265]npjohnson[/MENTION]:

"New exploits allow for CID change, which allows is to flash Developer Edition a boots if we use a corresponding CID."

So flashing the aboot is part of it it appears.

That would be correct, however other dev's have noted that the bootloader does not need to match.

XxD34THxX

Yesterday, 10:44 PM |#185

Senior Member951 posts Thanks: 123

The real trick is(if I missed anyone saying this) is that the CID and aboot has to be FROM THE SAME DEV DEVICE.

PaulPizz

Yesterday, 10:46 PM |#186

Senior Member171 posts Thanks: 88

Quote:

Originally Posted by chriskader

I am currently on 5.0.1 and B0G5

Based on what I read, the version does not matter as long as the bootloader matches the CID it was changed to. If someone wants to send their aboot and CID I am willing to try for science!

I've got cid's and aboot.mbn files for boaf and ni1. I've attempted to use them on a device with bof1 which is closer to boaf and it didn't work. The cid changed with no problems. But no unlock. There has to be something in the aboot that has to match that developer device cid in order to unlock it. You can't revert back to BOAF for instance with Odin anyway. I have some ideas in mind I'm gonna try to get the firmware back if it's even possible. So if anyone has any input I'd like to hear it.

chriskader

Yesterday, 10:49 PM |#187

Senior Member287 posts Thanks: 51

Quote:

Originally Posted by npjohnson

The note about backing up the current CID is a good point, and I have previously had those who are testing for me do so.

EDIT: As for testing, we can write the CID, though, and it seems that the CID is writing to all areas (as all sysfs probes readout the new CID), but somewhere along the line, there is another CID permanent getting left behind, as we still can't flash the developer edition Aboot to match that CID (ODIN generic error, SecureBoot error on device). We need to track down the register that is not being written, and write a module to use the vendor commands to write to that register. I'll admit here, I'm not very well-versed in kernel modules, but can sure track down the register that is being left over. I'll contact some kernel developers I know about this. But, we will also need loadable module support (shouldn't be too hard, we've done it on the S4 many times). This is now a multi-part project, so, it 100% can work, and ahs an obvious path to follow, though, it became a slightly more winding path now

Onto the note of increment. Surge1223 seems to think (with high certainty) that once the CID is changed, and the aboot is flashed, that increment would no longer matter, as when you try to flash a higher increment Developer Edition bootloader w/o the CID change, the ODIN error isn't related to increment as it would be expected. It errors on SecureBoot, not revision (could just be an order of operations).

Heres the thing though, in terms of aboot, ODIN WILL NOT flash a developer edition aboot if the CID write didn't go correctly. Also, ODIN won't flash a bootloader if it is below of increment. So, there is 0 risk there. No bricks unless the user dd's it, or uses Heimdall, which may force it.

As for CID overlap issues (multiple users using the same one), it is FINE. Samsung doesn't identify the device any differently in any user-space applications. And, if any applications checked the CID, it would appear as a developer edition, which isn't directly blocked by any end-user app/tool I can think of. The HTC guys do this consistently. They convert to GPE/Sense/Super CID's all the time, and they are almost all identical.

I personally think that providing open instructions like this is in a thread is dangerous, as many users who think "Oh, a single command, I can do that!" end up changing their CID's to a non-valid CID and bricking. Just a thought, that's why I didn't describe it above, but users who have access to the pre-requisites will enjoy the instructions.

I think you have overlooked one important factor here... just changing the CID & flashing a developer edition aboot will not unlock the device... the CID & Developer Edition Aboot need to be from the same device, as they all have differing CID's that are hashed in their specific Aboot. So, you could make a TAR, but would need to ensure the end user has the correct CID and Aboot combo.

To respond to your notes: dm-verity, and write-protection have no pertinence to any partition except /system. All other partitions can be freely remounted without consequences. SELinux is no more enforcing on the Note 4 than it is on the Note 3/S5.

This method works on the S5, as Beaups showed. The Note 3 should apply similarly.

I still need a Devleoper Edition S5 VZW and Developer Edition N5 VZW tester to get CID/Aboot combo dumps.

To users: Until we get that, no help can be offered. As I said, don't go publicly posting your CID in the thread, there is just no point in cluttering with useless CID's.

Also, don't just go testing a random CID, you WILL BRICK.

To respond to some others in the thread, NDK had trouble building this for me, as did MM AOSP/CM13, though, it built without a hitch in my CM11 tree.