Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

True Capacity


  • Please log in to reply
8 replies to this topic

#1 Guest_hollowface_*

Guest_hollowface_*

  • Guests
  • OFFLINE
  •  

Posted 13 December 2015 - 01:38 AM

gUJDtze.png

True Capacity 1.0 Stable:
True Capacity is bash script that tests for a fake capacity on flashdrives/memory cards, and provides an approximate of the true capacity. It likely won't work against all fakes, but it's working for one of mine, which is what I hoped to accomplish by writing it. It was written, and tested on Ubuntu 14.04 Desktop AMD64, but provided you install the dependencies (they are listed in the "About.txt" file), and use Bash as your shell, it should work on most distros. Your flashdrive/memorycard must be prepped as described in the "About.txt" file, mounted, and you must have permission to write to it (this is the part that you'll likely overlook).

Please keep in mind that flashdrives/memory cards are solid state storage, which means they have a limited number of writes. True Capacity's tests involve using DD for zeroing nearly the entire device.

Depending on the size and speed of your device, the test may take quite a while. Be patient. If you decide to abort mid way, use "control" + "c", depending how far along you are, this may leave a temporary file on your device that you'll need to delete manually.

Download Link:

https://mega.nz/#!A5JnUSDY!OWt2C2zL2OmYvHrjd-UN4t2vq59nfQeuC5_A9GACU48

Edited by Al1000, 10 September 2016 - 02:00 PM.
update download link


BC AdBot (Login to Remove)

 


#2 myrti

myrti

    Sillyberry


  • Malware Study Hall Admin
  • 33,768 posts
  • OFFLINE
  •  
  • Gender:Female
  • Location:At home

Posted 13 December 2015 - 07:25 AM

So running your script to get the size of any device will always result in totaly data loss?


is that a bird?  a plane? nooo it's the flying blueberry!

If I have been helping you and haven't replied in 2 days, feel free to shoot me a PM! Please don't send help request via PM, unless I am already helping you. Use the forums!

 

Follow BleepingComputer on: Facebook | Twitter | Google+


#3 Guest_GNULINUX_*

Guest_GNULINUX_*

  • Guests
  • OFFLINE
  •  

Posted 13 December 2015 - 12:10 PM

 True Capacity's tests involve using DD for zeroing nearly the entire device.

So running your script to get the size of any device will always result in totaly data loss?

 

I think so...  :whistle:

 

Greets!



#4 Guest_hollowface_*

Guest_hollowface_*

  • Guests
  • OFFLINE
  •  

Posted 13 December 2015 - 02:42 PM

@mytri

So running your script to get the size of any device will always result in totaly data loss?
-REF:http://www.bleepingcomputer.com/forums/t/599216/true-capacity/#entry3884850

No. Firstly, the script uses a file-based action for tests, rather than acting directly on the device's sectors, so technically some space isn't included in the test because it's in use by the partition table and filesystem. Originally I wanted to test the sectors directly, but it didn't seem to work against my fake (I suspect some kind of looping action is being used), so I used a file-based approach, as some other testing tools do. In regards to data loss, the script expects the user to have prepped the drive (the requirements are covered in the "About.txt" file). While I could have written the script to automatically prep the device, I decided not to, in part for safety reasons (eg: user chooses wrong drive by accident), but mostly because I didn't want to add additional depenedencies that might be difficult to install on some distros. One of the prep requirements is that the drive contain no files or folders. If the device does contain files and folders, the script won't touch them, but the space they use cannot be tested so it means the test results will be inaccurate. The only file that the script writes to and deletes is "truecapacity.tmp", if you have a file bearing that name, it will be overwritten and deleted. Because zeroing is used (within the truecapacity.tmp file), if the drive previously contained files the user will no longer be able to recover deleted data using recovery tools.
 

#5 myrti

myrti

    Sillyberry


  • Malware Study Hall Admin
  • 33,768 posts
  • OFFLINE
  •  
  • Gender:Female
  • Location:At home
  • Local time:09:15 AM

Posted 13 December 2015 - 08:18 PM

I'm confused, you anwser my question with "No, then go on to say "the user will no longer be able to recover deleted data".

Sounds like there will be dataloss and this sounds quite dangerous to me..

Especially since the data loss is not mentioned in the tool workings, but rather just as the last side note in the about.txt, which you don't even say must be read before running the tool. What about firmware installed on your flash drive (eg encryption, music player, etc) for example. You can't 'back that up' because it's not accessible to you. But your method might override it, rendering the device inoperable.. I think backups here would be vital.

 

dd has an option to not write the output file, iirc. Just do a dry run, maybe that would make it safer.. Alternatively utilities like fdisk or testdisk might bring a safer approach to detecting hard drive/ flash drive sizes.

 In the same way it can 'fail if the output file already exists', that would solve the 'output file gets overwritten' issue, you mention. But I don't think that will be a real issue at all

 

regards

myrti


is that a bird?  a plane? nooo it's the flying blueberry!

If I have been helping you and haven't replied in 2 days, feel free to shoot me a PM! Please don't send help request via PM, unless I am already helping you. Use the forums!

 

Follow BleepingComputer on: Facebook | Twitter | Google+


#6 Guest_hollowface_*

Guest_hollowface_*

  • Guests
  • OFFLINE
  •  

Posted 13 December 2015 - 08:59 PM

I'm confused, you anwser my question with "No, then go on to say "the user will no longer be able to recover deleted data".

You asked if use of the script would result in total data loss, the answer is no, it doesn't delete user files, nore is 100% of the drive's storage is even accessible by the script.

then go on to say "the user will no longer be able to recover deleted data".

Sounds like there will be dataloss and this sounds quite dangerous to me..

When you delete a file off a storage device, the sectors housing that data still have that data, until a new file requests to be stored there. Since this script creates a file that uses most of the device's space, all free sectors will be requested by the file, which means recovery of previously deleted files will no longer be possible. This is no different then when a user saves files to the device; previously recoverable files get overwritten, and are no longer recoverable. Nothing dangerous or abnormal about this.

What about firmware installed on your flash drive (eg encryption, music player, etc) for example. You can't 'back that up' because it's not accessible to you. But your method might override it, rendering the device inoperable.. I think backups here would be vital.

I don't follow you here. This script is only writing to a file on the partition, it's not touching firmware, or deleting user files. If it's not accessible to the user, then it's not accessible to the script, because it's run under the user account. I think perhaps you're misunderstanding how the script works?

dd has an option to not write the output file

An output file is required for this script's purposes. Writing a file for testing fakes is not a unique approach. h2testw uses the file-based approach too.

 In the same way it can 'fail if the output file already exists', that would solve the 'output file gets overwritten' issue, you mention. But I don't think that will be a real issue at all

I'm still not following you. The drive is blank before (done by the user) and after testing (because the script removes the tmp file), unless a test is aborted, in which case overwriting the tmp file during the next test is ideal.
 

#7 Guest_GNULINUX_*

Guest_GNULINUX_*

  • Guests
  • OFFLINE
  •  

Posted 14 December 2015 - 04:54 AM

If I understand this correctly... the file (truecapacity.tmp) is only written on "empty" sectors on the device?

So if a user doesn't clear the device in advance, he gets a "faulty" result which is the "free" space of the device?

 

Clever!  :thumbsup:

 

Greets!



#8 myrti

myrti

    Sillyberry


  • Malware Study Hall Admin
  • 33,768 posts
  • OFFLINE
  •  
  • Gender:Female
  • Location:At home

Posted 14 December 2015 - 07:05 AM

Hi,

I see now. I thought you were getting the actual size of a flash drive (sdb) rather than a partition (sdb1,2,3,4). I guess I got confused because you're comparing the result in your screenshot to the size of the device rather than the size of a partition.

I agree if you use dd on a partition without higher permissions, it should not cause any problems.


regards
myrti

is that a bird?  a plane? nooo it's the flying blueberry!

If I have been helping you and haven't replied in 2 days, feel free to shoot me a PM! Please don't send help request via PM, unless I am already helping you. Use the forums!

 

Follow BleepingComputer on: Facebook | Twitter | Google+


#9 Guest_hollowface_*

Guest_hollowface_*

  • Guests
  • OFFLINE
  •  

Posted 14 December 2015 - 06:24 PM

@GNULINUX

 

If I understand this correctly... the file (truecapacity.tmp) is only written on "empty" sectors on the device?

Yes, data is only being written to free space (as listed by the filesytem).

 

So if a user doesn't clear the device in advance, he gets a "faulty" result which is the "free" space of the device?

Yes, approximately (assuming the device has 1 full length partition). This all comes down to the blocksize being used by DD. 512 bytes would give the most accurate results because it's a common sector size, but also slower speeds on devices capable of using a higher blocksize. Currently the script uses a blocksize of 1MB, but I am considering lowering it to 512 bytes. Not so much because of the minut increase in accuracy, but because some people load memory cards into cheap generic usb-card-adapaters from china (common on Ebay), and some of these (like one I have) have really poor read/write speeds (despite the capabilities of the memory card), and therefore may not handle a 1MB blocksize well. I haven't decided at this point.

 

Clever!

Thanks. Wish I could take the credit, but the idea of testing flashdrives by writing a large file to a parition, isn't new, other testing programs do this too.

@myrti

 

I see now. I thought you were getting the actual size of a flash drive (sdb) rather than a partition

Unfortunately the test is using a partition :(. I did want to take a sector-based approach which would allow examination of the entire drive, but the code didn't seem to work on my fake (though it did work on my virtual test ramdrive). Not surprising really. So I went with a file-based approach. It's not as accurate, but it gets the job done. If do get a sector-based approach working to my needs, I will likely incorporate it as an additional authentication test.


Edited by hollowface, 14 December 2015 - 06:26 PM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users