Talk:Badblocks

random option is insecure

Latest comment: 5 July 20123 comments2 people in discussion

Note: Moved from Securely wipe disk and prior to that from Dm-crypt_with_LUKS.

I wrote this down at the Gentoo wiki. Since I've been getting into Arch I thought I would share...

Here's an example:

If you write to a device with the command...

# /sbin/badblocks -c 10240 -s -w -t random -v /dev/loop0

... or somthing similar as recommended in many places.

Then...

# xxd /dev/loop0
---SNIP---
002e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
002e810: 1a18 a663 0b58 0e53 054f b72f 8058 d7a1  ...c.X.S.O./.X..
002e820: a4f8 b5a5 c74e 0bf9 a11e 447b 6edd 5888  .....N....D{n.X.
002e830: f5fe ec00 56fa 535c 490b 8bc9 6363 6b07  ....V.S\I...cck.
002e840: 5b20 ac22 6eb7 1c0f d560 8a43 3de2 cc32  [ ."n....`.C=..2
002e850: e0b8 3236 b286 92fc 911e c5f4 8130 fbdc  ..26.........0..
002e860: 50a7 ffbe 5f1b cd34 7b57 78b8 3944 ea19  P..._..4{Wx.9D..
002e870: fc1c 50ae a2e2 aa33 0070 2781 a022 5ef1  ..P....3.p'.."^.
002e880: ca5d af29 787d 5df3 d4d5 ab0e 1995 2715  .].)x}].......'.
002e890: b177 c454 5a6e 875a deaf dc7f d13a 709b  .w.TZn.Z.....:p.
---SNIP---

Then... looking for the data at 0x002e800...

# xxd /dev/loop0 | grep "214c 2113 01ce 9965 3253 134a da50 99dd"

You'll get

---SNIP---
002e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
0a2e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
142e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
1e2e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
282e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
322e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
3c2e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
462e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
502e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
5a2e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
642e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
6e2e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
---SNIP---

Tell me if I'm wrong, but that kinda seems to defeat the purpose of randomizing the HDD

--

This guy is correct. Remember badblocks is a random pattern it just repeats its randomness over and over again.

0800000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
1200000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
1c00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
2600000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
3000000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. 0
3a00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. A
4400000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. 4
4e00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. e
5800000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
6200000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
6c00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
7600000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
8000000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
8a00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
9400000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
9e00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
a800000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
b200000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
bc00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
c600000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. 0
d000000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. a
da00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. 4
e400000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. e
ee00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
10200000:cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.

As you can see the pattern is repeating and it isn't very long between each time it repeats. This hardly makes it any more secure. --Tama00 15:11, 19 November 2010 (EST)

Warning is added to the article. -- Fengchao (talk) 03:22, 8 June 2012 (UTC)Reply[reply]

Wouldn't it make more sense to completely remove it from the article instead? Seeing as it apparently provides no security benefit compared to using zero bytes... --Sas (talk) 12:39, 4 July 2012 (UTC)Reply[reply]

At the same time, using badblock to erase data has no major problem. In Arch the decision should be made by users themself. -- Fengchao (talk) 04:41, 5 July 2012 (UTC)Reply[reply]

Example will fail with drives larger than 2TB

Badblocks only supports 32bit integer block start / stop points, and will fail with an error similar to this one: "badblocks: Value too large for defined data type invalid end block (4883770580): must be 32-bit value" when you try and run "badblocks -wsv <device>"

I'm thinking it's a good idea to add some mention of this error and that you can resolve it by specifying a larger block size (eg -b 4096) - perhaps a section on large drives, troubleshooting or mentioning it inside the existing Testing for Bad Sectors section?

—This unsigned comment is by Azelphur (talk) 08:49, 4 July 2017‎. Please sign your posts with ~~~~!

fsck does not have a badblocks option

Latest comment: 2 January 20223 comments2 people in discussion

In the article it is mentioned that fsck can be used for running a read-write non-destructive badblocks test. This is false for me and does not seem to be present in the fsck source code hosted here. --Ilario (talk) 22:55, 24 December 2021 (UTC)Reply[reply]

The -c option is documented in e2fsck(8). — Lahwaacz (talk) 12:11, 27 December 2021 (UTC)Reply[reply]

Ah! You're right, it's here. I never noticed that this was implemented also in the standalone badblocks as -n, it's really useful! --Ilario (talk) 21:26, 2 January 2022 (UTC)Reply[reply]

Crypto layer might not be faster

In this screenshot shred speed fluctuates between 140-170MB/s while badblocks is steady at 154MB/s for a Dell R720 server. However, these tests take just too long for large drives and I have not done comprehensive testing.

—This unsigned comment is by Costis (talk) 14:52, 26 April 2023. Please sign your posts with ~~~~!