4 ms·

I've done this without compression but just sending infinite data. On some days I've sent a TB to a single IP address... Might be an idea to combine this. I'd a

I've done this without compression but just sending infinite data. On some days I've sent a TB to a single IP address... Might be an idea to combine this. I'd assume the resulting gzip file here contains a repeating pattern that you can generate on the fly?

joshspankit 3y ago
Back in the day if you had a faster modem and typed faster than the other person’s modem could receive, you could kick them offline. The more things change, the more they stay the same?
tuyiown 3y ago
A zip bomb is way more effective as it will be transferred very quickly and saturate attacker storage as fast as possible, with a good probability to make the system inoperable (login into a machine with with 0 storage left can be challenging).
Retr0id 3y ago
Yes, it would be trivial to make an "endless" gzip stream.
- lifthrasiir 3y ago
  And if you need an explicit binary, it is very easy to make one. Prepare a large enough file filled with the same byte (or generate them on the fly), let gzip to compress it, then observe where the zero byte start to repeat. Cut everything after that point and repeat the zero byte from there on. In my system: $ head -c 10000000 /dev/zero | gzip -c -9 | hexdump 0000000 8b1f 0008 530a 659e 0302 c1ec 0101 0000 0000010 8000 fe90 eeaf 0a08 0000 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 0000 0000 * 0002010 0000 0000 0000 db80 0383 0012 0000 4100 0002020 5fff 23b7 0150 0000 0000 0000 0000 0000 0002030 0000 0000 0000 0000 0000 0000 0000 0000 * 00025f0 0000 0000 0000 0000 0000 0000 0000 e000 0002600 cb26 3ba5 803e 9896 0000 0002609 So you can keep the first 0x18 bytes and repeat zero bytes after that, preferably very slowly. (The middle bit is an arbitrary block boundary, while the last bit is CRC-32 and the uncompressed size which the client will never see.) I have also used `-c` option to avoid the original file name in the result, which precedes the compressed data.
inglor_cz 3y ago
Was your hosting OK with that? ZIP bombs are light on the "data transferred" front, a TB is pretty massive.
- iforgotpassword 3y ago
  I've got a limit of 50TB which I never came even close to. I'm still with them, but the script got lost at some point.
- pixl97 3y ago
  The other thing to do here is tarpitting/slow feeding data keeping the bot busy for a long time. Not sure if modern bots are better at timing out than in the past.

joshspankit 3y ago

Back in the day if you had a faster modem and typed faster than the other person’s modem could receive, you could kick them offline. The more things change, the more they stay the same?

tuyiown 3y ago

A zip bomb is way more effective as it will be transferred very quickly and saturate attacker storage as fast as possible, with a good probability to make the system inoperable (login into a machine with with 0 storage left can be challenging).

Retr0id 3y ago

Yes, it would be trivial to make an "endless" gzip stream.

lifthrasiir 3y ago
And if you need an explicit binary, it is very easy to make one. Prepare a large enough file filled with the same byte (or generate them on the fly), let gzip to compress it, then observe where the zero byte start to repeat. Cut everything after that point and repeat the zero byte from there on. In my system: $ head -c 10000000 /dev/zero | gzip -c -9 | hexdump 0000000 8b1f 0008 530a 659e 0302 c1ec 0101 0000 0000010 8000 fe90 eeaf 0a08 0000 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 0000 0000 * 0002010 0000 0000 0000 db80 0383 0012 0000 4100 0002020 5fff 23b7 0150 0000 0000 0000 0000 0000 0002030 0000 0000 0000 0000 0000 0000 0000 0000 * 00025f0 0000 0000 0000 0000 0000 0000 0000 e000 0002600 cb26 3ba5 803e 9896 0000 0002609 So you can keep the first 0x18 bytes and repeat zero bytes after that, preferably very slowly. (The middle bit is an arbitrary block boundary, while the last bit is CRC-32 and the uncompressed size which the client will never see.) I have also used `-c` option to avoid the original file name in the result, which precedes the compressed data.

inglor_cz 3y ago

Was your hosting OK with that? ZIP bombs are light on the "data transferred" front, a TB is pretty massive.

iforgotpassword 3y ago
I've got a limit of 50TB which I never came even close to. I'm still with them, but the script got lost at some point.
pixl97 3y ago
The other thing to do here is tarpitting/slow feeding data keeping the bot busy for a long time. Not sure if modern bots are better at timing out than in the past.