From: Firewalker on 14 Jan 2010 00:44 For some reason, your latest response didn't show on this board, but on another board (htfc.com), but I am going to reply to you on this one (windows xp general group) since this is how I have been posting from the beginning. I hope this gets to you. Anyway, thank you very much for the detailed help, Tim. I tried this command: dd if=/dev/zero of=\\?\Device\Harddisk3\Partition0 bs=512 count=10000 It returned: 10000+0 records in 10000+0 records out But, when I went into disk management, it still shows up as having 961MB. It did at least remove the file system specification on the card. So, I think we might be on the right track? Should I try this command (or perhaps double the bs or count) to erase the whole disk? dd if=/dev/zero of=\\?\Device\Harddisk3\Partition0 bs=262144 count=30592
From: Paul on 14 Jan 2010 02:51 Firewalker wrote: > For some reason, your latest response didn't show on this board, but on > another board (htfc.com), but I am going to reply to you on this one (windows > xp general group) since this is how I have been posting from the beginning. > I hope this gets to you. > > Anyway, thank you very much for the detailed help, Tim. > > I tried this command: > > dd if=/dev/zero of=\\?\Device\Harddisk3\Partition0 bs=512 count=10000 > > It returned: > 10000+0 records in > 10000+0 records out > > But, when I went into disk management, it still shows up as having 961MB. > It did at least remove the file system specification on the card. So, I > think we might be on the right track? Should I try this command (or perhaps > double the bs or count) to erase the whole disk? > > dd if=/dev/zero of=\\?\Device\Harddisk3\Partition0 bs=262144 count=30592 > > When you do "dd --list", what size is it showing there ? Paste this kind of stuff for the device. Removable media other than floppy. Block size = 512 size is 8019509248 bytes I would expect the size detection in "dd" is the same as the size detection in Windows. If Windows sees 961MB, then "dd" probably will too. I believe "dd" at least has to go through the normal drivers to get to the device, so it can't "invent" anything on its own. If you try "bs=262144 count=30592", it should stop at the point it thinks it hit the end. Due to the end detection bug for flash devices, I can't really predict what it will do. Maybe it will stop at 3844 ? (961MB) You can certainly try it. I don't expect it will do anything to the device, any more than crafting a command that exactly erases 961MB would have. What we're relying on here, is for the driver for that device, to be doing the right thing. I don't know if there is a way around that, as in something more "raw" that looks at device registers. On IDE devices, there is a command called SETMAX, that allows redefining the size of a drive (in the downward direction). But most modern machines will prevent you from playing with that. The BIOS is supposed to "close the door" to changes, for security reasons. If the BIOS did not provide a mechanism for locking out SETMAX, then malware could use it to ruin disks for people. I don't know if your storage device would support that or not. See in particular, the "Identification methods" section here. Apparently Linux can detect an HPA (done by SETMAX). Whether such concepts apply to your flash device, I can't tell you. http://en.wikipedia.org/wiki/Host_protected_area Paul
From: Firewalker on 19 Jan 2010 21:54 Sorry for the late response. Thanks for the continued support. This is getting very complicated to understand now. When I ran dd0 --list, it returned: \\?\Device\Harddisk1\Partition0 link to \\?\Device\Harddisk1\DR20 Removable media other than floppy. Block size = 512 size is 1007681536 bytes \\?\Device\Harddisk1\Partition1 link to \\?\Device\Harddisk1\DP(1)0-0+15 Removable media other than floppy. Block size = 512 size is 1007681536 bytes I'll do some research on the HPA to see if I could find a potential solution there. -Toby "Paul" wrote: > Firewalker wrote: > > For some reason, your latest response didn't show on this board, but on > > another board (htfc.com), but I am going to reply to you on this one (windows > > xp general group) since this is how I have been posting from the beginning. > > I hope this gets to you. > > > > Anyway, thank you very much for the detailed help, Tim. > > > > I tried this command: > > > > dd if=/dev/zero of=\\?\Device\Harddisk3\Partition0 bs=512 count=10000 > > > > It returned: > > 10000+0 records in > > 10000+0 records out > > > > But, when I went into disk management, it still shows up as having 961MB. > > It did at least remove the file system specification on the card. So, I > > think we might be on the right track? Should I try this command (or perhaps > > double the bs or count) to erase the whole disk? > > > > dd if=/dev/zero of=\\?\Device\Harddisk3\Partition0 bs=262144 count=30592 > > > > > > When you do "dd --list", what size is it showing there ? Paste this kind of > stuff for the device. > > Removable media other than floppy. Block size = 512 > size is 8019509248 bytes > > I would expect the size detection in "dd" is the same as the size detection > in Windows. If Windows sees 961MB, then "dd" probably will too. I believe > "dd" at least has to go through the normal drivers to get to the device, > so it can't "invent" anything on its own. > > If you try "bs=262144 count=30592", it should stop at the point it thinks it > hit the end. Due to the end detection bug for flash devices, I can't really > predict what it will do. Maybe it will stop at 3844 ? (961MB) > > You can certainly try it. I don't expect it will do anything to the device, > any more than crafting a command that exactly erases 961MB would have. > > What we're relying on here, is for the driver for that device, to be doing > the right thing. I don't know if there is a way around that, as in something > more "raw" that looks at device registers. > > On IDE devices, there is a command called SETMAX, that allows redefining the > size of a drive (in the downward direction). But most modern machines will > prevent you from playing with that. The BIOS is supposed to "close the door" > to changes, for security reasons. If the BIOS did not provide a mechanism > for locking out SETMAX, then malware could use it to ruin disks for people. > I don't know if your storage device would support that or not. > > See in particular, the "Identification methods" section here. Apparently > Linux can detect an HPA (done by SETMAX). Whether such concepts apply to > your flash device, I can't tell you. > > http://en.wikipedia.org/wiki/Host_protected_area > > Paul > . >
From: Paul on 22 Jan 2010 06:33
Firewalker wrote: > Sorry for the late response. Thanks for the continued support. This is > getting very complicated to understand now. When I ran dd0 --list, it > returned: > > \\?\Device\Harddisk1\Partition0 > link to \\?\Device\Harddisk1\DR20 > Removable media other than floppy. Block size = 512 > size is 1007681536 bytes > \\?\Device\Harddisk1\Partition1 > link to \\?\Device\Harddisk1\DP(1)0-0+15 > Removable media other than floppy. Block size = 512 > size is 1007681536 bytes > > I'll do some research on the HPA to see if I could find a potential solution > there. > > -Toby That means as far as "dd" is concerned (a program that accesses the device at a raw level), it is finding the size is around 1GB. At the moment, I don't see much reason to go any further with "dd", because the problem doesn't appear to be a size coming from the file system itself. The size must be coming from the hardware. You'd have to contact the manufacturer, in the hope they have some piece of software to fix it (or perhaps they'll offer a warranty return as an option). The design of the SD chip is similar to a USB flash, in that there is a flash chip and a controller. Which presumably leaves room for the same capacity changing options that USB sticks have. The protocol would be different and I haven't a clue what options it might support. On ATA you have things like SETMAX to mess up storage devices. I don't know if SD has an equivalent capability or not. http://en.wikipedia.org/wiki/File:Sdcard_panasonic64mb_inside_front.jpg Paul |