51–60 of 111 posts
Earlier quoted context omitted.
Still useful today. Try to transmit a 100G file through any service is usually a pain especially if one end has non-stable Internet.
If the point is being able to access some files even if the whole archive isn’t uploaded, why not create 100 separate archives each with a partial set of files? Or use a protocol that supports resume of partial transmits.
Earlier quoted context omitted.
Still useful today. Try to transmit a 100G file through any service is usually a pain especially if one end has non-stable Internet.
If the point is being able to access some files even if the whole archive isn’t uploaded, why not create 100 separate archives each with a partial set of files? Or use a protocol that supports resume of partial transmits.
WinRAR does it right, 7zip and Windows Explorer do it wrong according to https://en.m.wikipedia.org/wiki/ZIP_(file_format) > only files specified in the central directory at the end of the file are valid. Scanning a ZIP file for local file headers is invalid (except in the case of corrupted archives)
WinRAR does it right, 7zip and Windows Explorer do it wrong according to https://en.m.wikipedia.org/wiki/ZIP_(file_format) > only files specified in the central directory at the end of the file are valid. Scanning a ZIP file for local file headers is invalid (except in the case of corrupted archives)
This contradicts the specification, which explicitly supports stream-processing zip files, which necessarily can't happen if your source of truth is the central directory record. Unless if you can wrap your stream processing in some kind of transaction that you can drop once you discover foul play.
In ZIP, later info wins. I don't see how that isn't always streamable.
This is sometimes used non-maliciously to concatenate zipped eBooks to a JPEG of the cover art. 4Chan's /lit/ board used to do this, but I can't find any reference to it anymore. https://entropymine.wordpress.com/2018/11/01/about-that-jpeg... https://github.com/Anti-Forensics/tucker
That first read should be an HN post in its own right.
I swear this has been widely known at least since the Win 98 era.
Remember, secure encryption, good compression, and truely random data are indistinguishable. It's best to paste that encrypted payload into a JPG with some bullshit magic headers and upload that to a trusted Exfil pivot instead. Or, to get SuperMarioKart.rom to work with your chromeApp-XEMU emulator to play during down-time at work, just rename it to SMB.png, and email it you yourself.
> Remember, secure encryption, good compression, and truely random data are indistinguishable. Yes, and the only reason the bad guys get away with this is the people who trust signature-based scanning at the perimeter to detect all threats. One of the hacks I'm most proud of in my whole career was when we were doing a proof of concept at an enterprise client we were being deliberately obstructed by the internal IT gr…
Crazy that this is easier than dealing with the bullshit politics, to get some essentials tools to do my job. German public service is a joke. I quit since.
Earlier quoted context omitted.
Still useful today. Try to transmit a 100G file through any service is usually a pain especially if one end has non-stable Internet.
That's a very bad way of solving that issue. If transmission is a problem, either use a proper retry-friendly protocol (such as bittorrent) or split the file. Using hacks on the data format just leads to additional pain
Wait, I'm confused. Isn't this what OP was talking about?
Earlier quoted context omitted.
Still useful today. Try to transmit a 100G file through any service is usually a pain especially if one end has non-stable Internet.
If the point is being able to access some files even if the whole archive isn’t uploaded, why not create 100 separate archives each with a partial set of files? Or use a protocol that supports resume of partial transmits.
A single video can easily be over 20GB, for example.