[Verizon Galaxy Note 4 General] 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.