[Verizon Galaxy S 5 Android Development] AdmiralKirk:
Alright, so here is what I know so far. Everything they used to crack the Samsung eMMC chips is pretty much worthless for the Toshiba's, or at least it probably is. Basically Samsung screwed up and the firmware that shipped with their eMMC's on the Galaxy S5 and I believe one of the Notes had a defect in it. As such Samsung had to put code in the kernal to hot patch the firmware on bootup. Since the kernel is open source and the GPL requires them to share modifications they had to post this patch publicly. This patch contained vendor commands that allowed others to dump the entire contents of the eMMC including the currently running firmware. Then it was a matter of reversing the firmware to discover that the burn in command that sets the CID (which is supposed to be write once, btw) was in fact not so well protected. It existed in the regular volatile memory area and only a simple security command protected it. So they were able to reverse this and come up with a vendor command that could be run from kernel mode that would then re-write this write-once CID.

As you can see, so far all of this has relied on Samsung's crappy QA on their eMMC. Those of us with Toshiba eMMC are kind of hoping that Toshiba is as lazy as Samsung was and store the CID in volatile memory with a simple vendor command to set it and piss poor security to keep it from being re-writen. Before we can even know that, however, we need the firmware of the eMMC itself so we can reverse the vendor commands. Our road will be even longer than the one for the Samsung because we don't have the clues that Samsung left in the kernel code to even help us get started.

But to even get started, we need said code. So unless someone stumbles on the necessary documentation or piece of code to nicely dump the contents of the eMMC like they did for the Samsung, we are stuck reading the eMMC the hard way. That means we would either need to find the appropriate exposed test points/pads to hijack the eMMC signal, or we would need to de-solder the entire eMMC from the board and read it. (Assuming the firmware exists on the chip itself, more below) Reading it isn't too difficult, if it conforms to the eMMC standard, it works much like an SD card. (ex: https://www.reboot.ms/forum/threads/guide-emmc-nand-dump-backup-restore.530/ - Reading the eMMC off of a WiiU). I am assuming that such easily used exposed pads/points don't exist or someone would have done that already. De-soldering the eMMC brings with it a very high risk of destroying the donor phone.

So, on to your oDroid device. If it infact uses the exact same eMMC as our Samsungs (and that is still a question I am trying to determine. Finding the exact model of the Toshiba eMMC for the S5 is proving hard, same for the exact model used by the oDroid), and the exact same firmware, it might be a very viable option for getting the necessary data, since the eMMC on the oDroid is modular and they even have a nice little SD card adapter for it. Still, it is my understanding that the firmware code we are looking for does not exist in the volatile memory until the device in question is booted. I am also uncertain as to where the firmware comes from, is it stored in non-volatile memory on the eMMC, somewhere in the volatile memory, or is it provided by a memory controller (on the cpu). So their are some unknowns their (i think, others know more than I do on this subject so may end up correcting me on this or other points that I am only making educated guesses on).

Ideally we could get the vendor documentation on the eMMC in the phone and it would tell us literally everything we could ever want to know. Unfortunately they don't give that stuff out to just anyone. Hope this helps clear up a few things, I believe most of this was available on the first post of this topic or perhaps on the other one in regards to unlocking the Samsung eMMCs. I would suggest reading the details from those posts to get a clearer understanding, specifically http://theroot.ninja/disclosures/SAMDUNK_1.0-03262016.pdf that link.

edit: spelling