unable to repartition SD card from Android phone

[Mark Copper]

Maybe I should just toss it, but I'm curious why none of my tools can
recover an SD card previously used for Android internal storage.

Here's how gdisk sees it:
gdisk -l /dev/sdc

GPT fdisk (gdisk) version 0.8.10

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 62333952 sectors, 29.7 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 7DA17515-4FE8-43DF-A424-86C8EA090235
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 62333918
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number Start (sector) End (sector) Size Code Name
1 2048 34815 16.0 MiB FFFF android_meta
2 34816 62333918 29.7 GiB FFFF android_expand

Utilities like dd, fdisk, parted, wipefs, gdisk all report success in
modifying the partition table none actually do.

Here's an example:

wipefs -a /dev/sdc
/dev/sdc: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20
50 41 52 54
/dev/sdc: 8 bytes were erased at offset 0x76e47fe00 (gpt): 45 46 49 20
50 41 52 54
/dev/sdc: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
/dev/sdc: calling ioctl to re-read partition table: Success

But nothing is actually affected:

partx --show /dev/sdc
NR START END SECTORS SIZE NAME UUID
1 2048 34815 32768 16M android_meta
ea26c4a2-1eb3-4dd3-90b4-a2f4c6e2d993
2 34816 62333918 62299103 29.7G android_expand
43ad70ab-2890-fa97-93a1-ae5e86950d19

Can anything return this card to a single ext4 partition for external
storage/data transfer?

Thanks.

[Fungi4All]

From: mlco...@gmail.com

Maybe I should just toss it, but I'm curious why none of my tools can

recover an SD card previously used for Android internal storage.

Is it still functional in android?

I think google locks the mbr so no other system can ever use it again.

But while it gives you a long error message in another system it notifies

google of what that system is and which android user is attempting it.

Then it returns and burns up your android device.

Maybe I can write a novel on it, so you will have to pay google to read

the rest :)

[David Christensen]

On 05/26/2017 12:52 PM, Mark Copper wrote:
> Maybe I should just toss it, but I'm curious why none of my tools can
> recover an SD card previously used for Android internal storage.

Does you SD card and/or SD card adapter have a write-protect tab or
other such mechanism? If so, put it in the unlocked position.


Have you tried using dd to wipe the first megabyte (including the
partition table)?

# dd if=/dev/zero of=/dev/sdc count=2048; sync


David

[David Christensen]

On 05/26/2017 03:23 PM, Fungi4All wrote:
> I think google locks the mbr so no other system can ever use it again.

How? Please provide citation(s).

> But while it gives you a long error message in another system it notifies
> google of what that system is and which android user is attempting it.

How? Please provide citation(s).

> Then it returns and burns up your android device.

How? Please provide citation(s).

> Maybe I can write a novel on it, so you will have to pay google to read
> the rest :)

Please do, but release it under a license that allows us to read it
on-line for free and then decide if we want to buy it.


David

[Fungi4All]

From: dpch...@holgerdanske.com

On 05/26/2017 03:23 PM, Fungi4All wrote:

> I think google locks the mbr so no other system can ever use it again.

How? Please provide citation(s).

I am kidding, but you may want to try this straight off your debian repository or 

the latest from its developers http://www.embedded-projects.net/usbprog/

USBprog, it may give hints  of whether something may be fixible.  I don't have

much experience on it, I tried to see once whether you can read and/or write

firmware on something.  I was wondering whether the diference between a

manufacturers usb-sticks was firmware and the rest was identical between 8GB 

and 128GB.  So I had identical models of the same issue of 2 different sizes and

was trying to compare.  It seemed a bit more complex than programming eprom

chips.

> But while it gives you a long error message in another system it notifies

> google of what that system is and which android user is attempting it.

How? Please provide citation(s).

That's my shot on science fiction, but you wouldn't think they are that evil, do you?

>Please do, but release it under a license that allows us to read it

>on-line for free and then decide if we want to buy it.

Only Greeks provide you with free gifts if you are a heroic Thracian city.  For

everything else there is always a cost.

Have you by any chance read The Bourne Identity by Robert Ludlum, or anything else

by him.  Some were made into movies but as always, read the book first.

(AK)

[JPlews]

On 26/05/17 20:52, Mark Copper wrote:
> Maybe I should just toss it, but I'm curious why none of my tools can
> recover an SD card previously used for Android internal storage.
>

I have returned 2 cards from this state, dd has never failed me but
needs extra steps to remove both places GTP is storing data, should
fdisk or similar fail

[JPlews]

On 27/05/17 18:18, Fungi4All wrote:

>> > But while it gives you a long error message in another system it
>> notifies
>> > google of what that system is and which android user is attempting it.
>>
>> How? Please provide citation(s).
>
> That's my shot on science fiction, but you wouldn't think they are that
> evil, do you?

It would be naive to think they are not logging card and phone info,
does the Google PDF reader actually need a phone ID for the purposes of
displaying a file or storing IDs for everything you open with it on
their systems?

[Mark Copper]

>
> Does you SD card and/or SD card adapter have a write-protect tab or other
> such mechanism? If so, put it in the unlocked position.

The micro SD cards used in phones don't appear to have such
mechanisms, but your point is well taken; viz. I've not adequately
checked the hardware path (MB, card reader, etc. red-faced here...)

>
> Have you tried using dd to wipe the first megabyte (including the partition
> table)?
>
> # dd if=/dev/zero of=/dev/sdc count=2048; sync
>

Yes, but no effect. Even count=1 gets to non-zero bytes:

dd if=/dev/sdc count=1 | od -b
0000000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
*
0000700 002 000 356 377 377 377 001 000 000 000 377 043 267 003 000 000
0000720 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
*
0000760 000 000 000 000 000 000 000 000 000 000 000 000 000 000 125 252
1+0 records in
1+0 records out
0001000
512 bytes (512 B) copied, 0.00365101 s, 140 kB/s

dd if=/dev/zero of=/dev/sdc count=1; sync
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.0170507 s, 30.0 kB/s

dd if=/dev/sdc count=1 | od -b
0000000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
*
0000700 002 000 356 377 377 377 001 000 000 000 377 043 267 003 000 000
0000720 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
*
0000760 000 000 000 000 000 000 000 000 000 000 000 000 000 000 125 252
, 0.00290682 s, 176 kB/s
1+0 records in
1+0 records out
512 bytes (512 B) copied
0001000

Maybe I'm not looking at this right...

The idea that a card could be locked up by the OS is titillating but
improbable. There would have to be an (apparently) unpublished trap
door or a back door to the disk controller in a generic disk. So it's
gotta be hardware and this has all been noise.

[David Christensen]

On 05/27/2017 10:18 AM, Fungi4All wrote:
> From: dpch...@holgerdanske.com

>
>> Please do, but release it under a license that allows us to read it
>> on-line for free and then decide if we want to buy it.
>
> Only Greeks provide you with free gifts if you are a heroic Thracian city. For
> everything else there is always a cost.

You are incorrect:

https://mitpress.mit.edu/sicp/

http://hop.perl.plover.com/


David

[David Christensen]

On 05/27/2017 11:30 AM, Mark Copper wrote:
>>
>> Does you SD card and/or SD card adapter have a write-protect tab or other
>> such mechanism? If so, put it in the unlocked position.
>
> The micro SD cards used in phones don't appear to have such
> mechanisms, but your point is well taken; viz. I've not adequately
> checked the hardware path (MB, card reader, etc. red-faced here...)

I bought a SanDisk 32GB Micro SDHC card for my Android phone a while
back. It came with a Micro SDHC to SD adapter, and the adapter has an
unmarked switch in the same style and location of the write-protect
switches on my other SD cards. I'm not sure if the switch actually does
anything.

I think you are looking at it correctly. Your console session indicates
that the drive appears to accept writes, but is actually discarding them.

> The idea that a card could be locked up by the OS is titillating but
> improbable. There would have to be an (apparently) unpublished trap
> door or a back door to the disk controller in a generic disk. So it's
> gotta be hardware and this has all been noise.

Perhaps the drive firmware has decided the device is failing, and has
forced read-only mode so that you have a chance to recovery any viable
data (?).


Have you tried contacting technical support for the drive manufacturer?


David

[Pascal Hambourg]

Le 27/05/2017 à 22:58, David Christensen a écrit :
>
> I bought a SanDisk 32GB Micro SDHC card for my Android phone a while
> back. It came with a Micro SDHC to SD adapter, and the adapter has an
> unmarked switch in the same style and location of the write-protect
> switches on my other SD cards.

It is not a switch. It is a lock. Its physical position is sensed by a
switch inside the card reader, just like the lock on floppy disks was
sensed by a switch inside the floppy disk drive.

[David Christensen]

Thanks for the clarification. :-)


David