yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] Demetris:
I have found a possible solution for fixing this.

We need to flash the original nexus s recovery on our phones and be able to wipe with it.

The nexus s recovery can reset the encryption for sure, this is where the reset phone button try to take you when you press it but of course we dont have it :)

may i say "yet".

We need to port the recovery in a wrapper so it can run on our phones, unmodified of any proprietary code, so only google recovery for ics can fix this.
[Captivate Android Development] Demetris:
Here is a package i made so you can flash after rom to fix the internal sd card.

No need to manual edit anymore.

http://www.mediafire.com/?qfub7i9afj8f17f

Enjoy, and report back any issues.

Edit:

OP please move it to the front page.

Thanks
[Captivate Android Development] dvdscr:
no, sorry.

tried it with different versions of ICS and still for the same "encryption failed" screen.
[Captivate Android Development] Demetris:
You must have misunderstood what i mean, sorry if i wasnt clear enough.

This package is to fix this:

Edit etc/vold.fstab with whatever you use personally (root explorer for me) and swap /emmc and /sdcard. Someone more intelligent than me can probably make this a CWM zip. This step is basically telling ICS to swap your /sdcard (internal sdcard) and your /emmc (external sdcard). It will probably look like this when you're done:

Code:

# internal sdcard that is no longer working

dev_mount emmc /mnt/emmc 1 /devices/platform/s3c-sdhci.0/mmc_host/mmc0

# external sdcard

dev_mount sdcard /mnt/sdcard auto /devices/platform/s3c-sdhci.2/mmc_host/mmc2

So you dont have to edit it manually every time you flash a new rom.

Hope now is clear what it does.
[Captivate Android Development] jcjcc:
Convenient, thanks.

No, internal SD is mmc0. (External SD is mmc1 and Broadcom SDIO Wifi chip is on mmc2.)
[Captivate Android Development] bballer182:
Please tell me someone is working on porting over the Nexus recovery?!?!

me and you both:eek:
[Captivate Android Development] Demetris:
I seem to have some really bad news guys.

This problem can only be fixed by fastboot which we dont have on our phones.

The other think that comes in mind is flashing bootloaders, but i dont think it will work. By say flashing bootloaders i mean from froyo to gb or from gb to froyo etc.

Its a long shot but needs to be tested.

I hope no bricks come here claiming my fault, you should be responsible for flashing bootloaders the correct way and never tick reboot on odin intil you see the word pass!
[Captivate Android Development] raz123:
You might benefit by going back a few pages and read what has been researched so far.

FYI: Multiple bootloaders/kernels/roms have been tried. Nothing worked. The internal MMC is stuck in its internal initialization phase, constantly responding "busy" to external commands.
[Captivate Android Development] amtrakcn:
Bootloader is not helpful here, I tried Eclair, Froyo and GB bootloaders.
[Captivate Android Development] parkerdjohnson:
Ughhhhh nooooo this is so bad :(:(:(

I have become the most recent victim

If there's any way I could help please tell me. I can give you log cats or whatever.
[Captivate Android Development] Wdustin1:
I thought as long as you didn't hit reset and just pulled the battery you were OK.?
[Captivate Android Development] Happy2cu:
Same Issue

I bricked my phone and reset it with:

2.1,2.2,2.3.3,4,5,6,7

Changed all possible combinations and nothing.....The phone is up and working but with a sd card.

I have a question? I cant seem to install any programs(apk files)The phone reboots as soon as I install a program, any solutions?:confused:
[Captivate Android Development] parkerdjohnson:
Are you saying that by flashing different stock builds, one or more of them was able to wipe the disk through the encryption?

Before I had heard about this issue, I had come to the encryption unsuccessful screen. I hit reset like an idiot. But before it did anything different, I pulled the battery after about a minute. When I booted back up, recovery gave me that image of the dead android.

Can anybody tell me my survival rate? Am I still safe? By flashing different BL's could I bring back the dead?
[Captivate Android Development] Happy2cu:
Unsuccessful

Havent fixed the encryption issue):
[Captivate Android Development] simple man:
I think it would be helpful if those encountering this problem would post what ICS build they were on. It may help narrow down the cause.
[Captivate Android Development] parkerdjohnson:
I was running aokp milestone 4 stock kernel

Never ever happened before that.
[Captivate Android Development] Demetris:
AOKP build 27
[Captivate Android Development] drakester09:
Unfortunately this has happened with a large variety of builds. There's enough randomness to say it's not rom specific but rather an ICS issue.

For me it was ICSSGS RC3, not CM9.
[Captivate Android Development] Demetris:
Reboot to cwm and adb shell then write this:

cd proc

then

cat crypto devices.

If you have this:

loop

sd

mmc

and,

device-mapper

Then dm-crypt is not your friend :)

I have e-mailed the author and waiting for a solution, i hope :(

This is the e-mail sent:

Hi

A lot of users using android ics v4 have our internal sd card destroyed by this crypto engine.

Is there a way to undone it?

Here is what is the problem:

http://xdaforums.com/showthread.php?t=1447303

Any way out of this would be really really appreciated as the list of non working phones are increased by the day.

Thanks in advance for any help given.

This is the authors email:

christophe@saout.de

Maybe a user that has english as a native language can write a better one so he can understand better, maybe;
[Captivate Android Development] simple man:
I've been following this thread since the early stages, when I first saw it, I went back to GB, because I didn't want to take a chance on this happening. I finally flashed Darknight v3 this weekend because I miss using a rom with active development. I've followed a few ICS threads but everytime I see the problem of encryption unsuccessful mentioned in those threads, there's no response, it seems as if people are in denial that this problem exists (other than those who this has effected). I would think that this would be a priority to figure out, over many less important issues. I think if some of the very talented and knowledgeable developers would look in to this issue it would be great. I really hope this is figured out before long, and I'm sorry for all those this has effected.

GOD bless!
[Captivate Android Development] jmtheiss:
I'll ask the dumb question, as that is what I'm best known for.

Is there a way to brute-force push through the "busy" reply from the mmc0 initialization?

I realize I don't understand much about how software works, but would it be possible to tell the device to ignore all signals from the mmc0 and just start writing anyway?

The other question I have is whether there is a way to reallocate space on the internal SD so that even though some portion of it is still encrypted, the master file table says that the bulk of the internal SD is non-encrypted?

In other words - Before:

13gb encrypted, 0gb free

After:

1.2gb encrypted, 11.8gb free

(or something like this).
[Captivate Android Development] Demetris:
Mcc is encrypted so it will not announce it self until a pass code is sent, it will be always busy and vold will report it as -1, never be able to initialize it for read/write, if we are able to have back the emmc in any form i have the mbr.bin that can kick start it to be up again with dd command in a seconds time.
[Captivate Android Development] jmtheiss:
Interesting. So to keep playing the hypothetical game:

1. Would there be a way to modify vold to change how it reports? Like a filter that steps in and changes the data so that vold sees a value other than -1, or a modified version of vold that converts -1 to another value?

2. Is there a way to test if each instance of this happening results in the same key being generated each time? In other words, what if each time the encryption fails, it is because it generates a key that is the same across all builds, as they all are using the same dm-crypt scenario? If that were the case, would it be possible to sandbox this process in an Android virtual machine, force the encryption failure, and see if there were a way to check what key it tried to encrypt the mmc0 with?

Again, I may be babbling nonsense, but it's fun to do.
[Captivate Android Development] Demetris:
1.Vold has nothing to to with hardware encryption so even if you make it to report is there it wont manage to mount or use because master boot record is encrypted and need the proper answer to be usable again.

2.Is possible but we dont know how to make this encryption unsuccessful to emerge and secondly i dont think google are that dump to encrypt the mbr with the same key but even if they did is aes 128bit unhackable.
[Captivate Android Development] parkerdjohnson:
Now I am not educated in the ways of development, but I did gather this much on the issue...

I flashed back to stock kk4 (post-encryption failure), and flashed SimplyStock 1.5a.

(side note: some people were saying that samsung roms dont boot past the att screen. Mine boots up just fine.)

I went to go plug in my phone via mtp (samsung kies option) and when it connected, my external sd appeared AS WELL AS my internal! It was unaccesible obviously, and windows 7 reported a negative size on the disk (versus 12gb for external sd.) I attempted to format the drive, but windows just erred out and reported a "format complete" when it obviously had not. I will post a screen shot later, but I did not have the time.

Can anybody attest to this data? Again, sorry for lack of knowledge. I can probably get any data you are curious to know, as I am relatively proficient with computers.

EDIT: Not sure if this necessary but I added the screenie I said that I would.
[Captivate Android Development] jmtheiss:
Just a thought - I know there is a tool called HP USB Disk Storage Format Utility (I've used it in the past on flash drives and SD cards that were all messed up). Maybe try using that instead of the windows-based format utility?

Probably won't do anything, but if you're willing to take a shot with it, there's always a chance.
[Captivate Android Development] DaNaRkI:
Only way to do this is literally the exact same process as how connexion2005 could fix a hard brick. It might even need the same RIFF box. Just that you would need to find/use the actual pins for the build-in memory as they are not going to have a J-tag like set of connection points.

Going off what raz123 says and my knowledge of how flash memory works, within the chip is it's own programming that governs the physical process of reading and writing to the "memory" section of the chip (or any SD card). It is this very low level programming that is getting stuck in an initialization phase. Most hardware has this internal programming because it is necessary for things like "plug and play."

I recall reading that for our Samsung made flash memory that it is also able to handle things like changing where the next new file gets written to in the "memory" section to prevent excessive read/write to any one part of the memory chip. This is great in allowing the flash memory to last longer, but the added level of complexity means more steps in the whole process that can fail. As well as more things we can't possibly fix because that kind of programming is very specific to the physical make of the memory and very proprietary (literally trade secret kinda stuff).

- - - - - - In related news - - - - - -

I was doing a google search for the "error -110 whilst initialising" and came across some old forum posts for various Linux builds, to sum it up, the worst case was someone that said they had to let an SD card sit plugged in for 5 min before trying to mount to get it to respond. So I'm wondering just how much time have any of you given the SD card to finish the initialization phase? If it's not long, then maybe what ever is triggering this is sending a jolt to the card and making it totally forget where everything is and you guys are not giving it enough time to actually finish looking.
[Captivate Android Development] parkerdjohnson:
Is this the same as attempting to write a file to the drive and just waiting for it to react (if ever)?
[Captivate Android Development] Happy2cu:
How do I access..

After I EMMC Reverse Fix the phone.Now, I can see the Ext SD card on my phone. The only issue I have is that I cant install any apps without the device rebooting itself, is there a way to make this go way??

I can deal with using an ext card, but how can I use it for system and storage? without the phone rebooting after I try to install apps?:confused:

Any suggestions????

Example: I can add files to my Ext SD from CWM by mounting via USB. But I cant see them when I go into My Files folder after the phone is rebooted and I enter my rom?
[Captivate Android Development] parkerdjohnson:
I can confirm that hp usb utility sees "no media" in the encrypted nand.
[Captivate Android Development] gocats7:
This is very a very concerning issue. I have read the entire thread and I see no hard fix. I also do not see this mentioned in any rom development threads....at least what I have read anyway. I realize all custom roms are used at ur own risk but I would have thought I would see more developers chiming in if this is a development issue. Kinda feel like I am sitting on a time bomb if I reboot! Hope someone can narrow this down. Good luck.
[Captivate Android Development] jmtheiss:
So you've got me wondering now - would AdamOutler's Unbrickable Mod be of any use in this situation? In other words, would bringing the phone down to development board level be useful?
[Captivate Android Development] raz123:
A bit of confusion going here, hopefully this post clarifies things.

What is going on?

As the kernel boots, it attempts to power on different devices in the phone.

One of these devices is the internal mmc/sd (aka mmc0, aka movinand chip).

The regular procedure to powering on this chip is to set certain parameters (voltage, clock, powermode, etc) and ask the chip if it's ready to communicate. If the chip says no, the kernel keeps asking it. So far, it is all very basic. There is no encryption key exchange or anything of the sort going on.

On a "working" Captivate with debugging enabled, you would see something of the sort:

mmc0: starting CMD1 arg 40000080 flags 000000e1 [COLOR="Blue"]; Are you ready yet?[/COLOR]
mmc0: req done (CMD1): 0: [COLOR="Red"][B]0[/B][/COLOR]0ff8080 00000000 00000000 00000000 [COLOR="blue"]; NO![/COLOR]

mmc0: starting CMD1 arg 40000080 flags 000000e1 [COLOR="blue"]; Are you ready yet?[/COLOR]
mmc0: req done (CMD1): 0: [COLOR="Lime"][B]c[/B][/COLOR]0ff8080 00000000 00000000 00000000 [COLOR="blue"]; YES![/COLOR]

Proceed with further commands! (CMD2, 3, 9, 7, etc...)

On a "defective" Captivate, the chip continuously responds that is is not ready, thus further communication does not take place. No data at all is exchanged. MBR has nothing to do with it, we're not even at this stage.

Comparing the boot log (with debugging enabled) of a "working" vs "defective" Captivate shows no discernible difference.

What triggers it?

This issue is ICS-related. Most reports have been coming from CM9-based ROMS. There were a few (one/two?) user reports mentioning that ICSSGS also caused it.

Can it be fixed?

At the present time, there is no solution to fix the seemingly defective internal MMC. A workaround involves using an external SD card that is partitioned to act as the internal mmc. OP describes in detail what to do. For those that wish to avoid manually changing void.fstab as mentioned in the OP, there is a flashable zip file that does it. See here. Yes, it will have to be applied every time a new ROM is installed, as ROMs tend to overwrite the changes made to void.fstab.

Future work?

There are a few ideas that I'm contemplating:

1. Usually, an mmc card will not respond to any data-exchanging commands as long as it is not ready (busy). However, for this mmc chip (movinand), Samsung appears to have built-in a few troubleshooting commands that, if I'm reading this well, could inform us of the state of the chip. The problem is: how do we manually send these commands and manually interface with the chip? According to Rebellos, one could interface with the chip by using the SBL command line through UART (using a uart<->usb cable) or by using a modified SDHCI driver inside the kernel.

2. SBL mode contains a bunch of internal/factory test commands, including something called "mmctest". It would be interesting to test and see if it accomplishes anything.
[Captivate Android Development] DaNaRkI:
Last I knew we don't yet have a way to communicate directly to memory.

The UnBrickable mod technically does allow for it, but we don't have the info. That's why the only thing we can do with the mod is get download mode. Adam and crew have only been able to figure out how to access a very limited part of the RAM.

leaked from my

ICS

- FUSED SGS I897 contaminating you via XDA app.
[Captivate Android Development] Demetris:
Here is cryptsetup for arm

http://www.mediafire.com/?1xw6dd535nw37n0

Push it with adb to /bin folder and chmod it to be usable.

Then issue a

cryptsetup luksOpen /dev/block/loopx x is either 0,1 through 7 and hope for the best

You must be on ics btw.
[Captivate Android Development] Happy2cu:
i have adb and ICS installed how do I push it to the device?
[Captivate Android Development] jmtheiss:
Put the file into the adb folder (usually platform-tools in the android SDK). From a command prompt:

cd (type the directory to where you have adb installed)

adb push filename /bin

adb shell

(I know it's something like "chmod 777 filename", but I don't remember the exact syntax on this one)

That should get you there - someone who knows the chmod command will need to chime in with the rest of that command.
[Captivate Android Development] parkerdjohnson:
What exactly is this (for us idiots)?
[Captivate Android Development] jmtheiss:
Looks like it's part of the Linux Unified Key Setup - namely, a way to do some settings changes on how the encryption is handled.

The command "cryptsetup luksOpen /dev/block/loopx" appears to be a way of trying to tell the device to run the cryptsetup program (setting up cryptography, I'm assuming), with the luksOpen parameter (no idea what that specifically does), to the mount point at /dev/block/loop(number 0-7).

Just a guess, though.
[Captivate Android Development] Happy2cu:
can some one write this into a zip file that can be installed thru CWM?
[Captivate Android Development] parkerdjohnson:
+1 10 char
[Captivate Android Development] jmtheiss:
I think this is what you're looking for, although I'd feel better if someone who knows how to write the updater-script double-checked my work to make sure it will run right.

I just took the EMMC Reverse fix, dropped in the cryptsetup file, and updated the updater-script to move stuff to the right places.

Obviously, you run this at your own risk. It shouldn't hurt anything, but again, be careful.
[Captivate Android Development] Demetris:
The cryptsetup command is used deal with the Linux Unified Key Setup (LUKS) on-disk format and mount the partition.

chmod +x will make it executable.

http://en.wikipedia.org/wiki/Dm-crypt

Issuing a:

losetup -f

you will see what loop number is not used.

That number dont need to use cryptsetup because there is not an encrypted partition to it for sure.
[Captivate Android Development] Happy2cu:
Thanks for the clarification , your right..now how can this be applied to this issue?
[Captivate Android Development] Demetris:
Has everything to do with this issue.

Dm-crypt encrypts the device then virtualizes it behind a loop device and partition like this is always hidden until unlocked.

Now Our movinand has become a hidden mount(block device) that corresponds to a loop device and only cryptsetup can unlock and mount it.
[Captivate Android Development] Happy2cu:
Cryptsetup

SO, how is this possible? I mean loading "Crypt"
[Captivate Android Development] jmtheiss:
If I'm understanding what you're asking correctly, you would need to run the cryptsetup program from either an ADB-based shell, or from a program like terminal emulator.

In any case, you need to be in a shell with access to the files in /system/bin.
[Captivate Android Development] Happy2cu:
Ok, got it ;), but I cant access the usb??? Ive tried with adb mount, but it tells me that no device is present? any solutions?
[Captivate Android Development] Demetris:
adb shell is the correct command.

adb push *file* destination

e.g adb push ring.mp3 /sdcard/Ringtones

adb pull /sdcard/Ringtones/ring.mp3 will copy it back to where adb folder is executed.
[Captivate Android Development] Happy2cu:
Thanks for your help ;) Will try now and see how it goes
[Captivate Android Development] Demetris:
Unlock the physical volume: cryptsetup luksOpen dev/block/loop0 (password)

Lets hope no password will be needed ;)
[Captivate Android Development] Happy2cu:
A Little Help....

cd C:\android-sdk\platform-tools\cryptsetup

adb system/bin/cryptsetup

adb shell

chmod +x

losetup -f

cryptsetup luksOpen /dev/block/loopx x is either 0,1 through 8

I need some help writing the adb command??? Any help would be appreciated?:confused:
[Captivate Android Development] parkerdjohnson:
I like all this action!! keep it up!!!
[Captivate Android Development] jmtheiss:
Small item to fix:

cd C:\android-sdk\platform-tools\cryptsetup

adb push cryptsetup /system/bin/cryptsetup

adb shell

cd /system/bin

chmod +x cryptsetup

losetup -f

cryptsetup luksOpen /dev/block/loopx x is either 0,1 through 8 - these are notes. Replace the "x" in "loopx" with a number.
[Captivate Android Development] Happy2cu:
Thank you

I appreciate your help
[Captivate Android Development] Demetris:
Small Correction ;)

adb push cryptsetup /system/bin

adb shell

chmod +x /system/bin/cryptsetup
[Captivate Android Development] bimbim18:
I'm having the same issue,

Slim ICS 2.8
[Captivate Android Development] Happy2cu:
Still not workin

I tried all the combinations I could think of in adb....couldnt get it to work.:(
[Captivate Android Development] amtrakcn:
Maybe we should make a poll for this issue?
[Captivate Android Development] Demetris:
Am investigating booting an ubuntu arm distro if it would have the parted tools to partition the movienand and if the ubuntu distro would have the drivers and full access to it to do so because all i would find is a side by side execute of android+ubuntu.
[Captivate Android Development] bimbim18:
I agree. Maybe narrowing the causes and identifying common denominators truthfully will lead to a more accurate solution. I wish I could help more but I'm still noob, so here I sit while you guys discuss things way over my head as I wait for a 'this works' post ><
[Captivate Android Development] jmtheiss:
I'm not sure how you're approaching it, but you may want to contact AdamOutler - I recall that he was working on Andbuntu at one point, which may be of some use to what you're pursuing.
[Captivate Android Development] Demetris:
To make it clear what i have in my mind for all:

Ubuntu as of now runs sideways with android and gets whatever android gives to it.

We need a full distro booting without android in the way so we can have that internal sd card seen on a more mature platform with more tools to work it out.

If native ubuntu sees that movienand we would be capable of just format it with dd zeroing it, mbr will be back to normal and its smooth sailing after that.

Now the ubuntu just boots from android and any problems exist on android will be tranfered to ubuntu, maybe am wrong on this, adam will be able to clear things out.
[Captivate Android Development] lowgoz:
gents, i've had the same issue on my asus transformer.

checking in to this thread as it seems to be the only one discussing this issue.

my /data/ and /sdcard/ are totally locked down and i have no way of unlocking or flashing a new rom. Im happy to test any suggestions you have !