5 ms·
That is a very good point; in my attempts previously I simply went alphanumerically but windows at the very least does not follow that rule when copying. I thi
by rilita 12y ago
That is a very good point; in my attempts previously I simply went alphanumerically but windows at the very least does not follow that rule when copying.
I think the easiest method would be to simply generate a bunch of files, do copies, and compare the datetime stamps with the theoretical values they should have. Once you can model the discrepancies generated in real life you can fake them.
You do make a good point that it isn't really mentioned in cybercrime books that I know of, but it seems like an obvious thing. Would be a fun chunk of code to publish on github; I'll look into it.
- woodman 12y agoIt really depends on your goals. If your goal is simply to fake the transfer speed in a tarball you leak, the easiest way would be load up a vm of the system you're spoofing - change the clock and somehow rate limit the copy. That wouldn't be nearly as fun though. It is one of those things that appears obvious after you've been walked through it though. I've never been in a position where I needed to fake transfer speed though, so I'm not sure if I'd have thought about it. If it actually is an attempt to fake an insider attack, it is an impressive trick.
- rilita 12y agoRate limiting is not effective. Having copied many terabytes of data do/from usb devices, I can tell you that it is not a consistent throughput. The speed of transfer depends on an inverse square of the file size of sorts. ( sensitive to the block size on both devices I'm sure ) Try copying 100gb of 2k-200k files ( all randomly sized ) It's a huge pain in the butt and works terribly on every system I've tried to do this on. It would be way more awesome to have a utility that can after the fact forge a scenario directly into an existing tarball. Then, you can simply pick a "model to emulate" and click go, and wham you have a forged tarball. Even if you did use a VM, it would be slower imo than a real transfer due to both the emulated system and the usb passthrough ( which is typically limited to USB 2.0 ) Show me a VM that is capable of USB 3.0 passthrough with reasonable speeds. Unless you truly forge the dates in a carefully modeled way, it would be possible to tell that it isn't a real transfer. Speaking of which; who steals data using USB 2.0? That's dumb. Use a modern USB 3.0 external 2.5" SSD. If you must use something small, use a cheapo 256gb USB 3.0 drive. The throughput on those is not bad. If no USB 3.0 ports are available, bring your own PCI Ex USB 3.0 card and open the system and install it. The BIOS may have intrusion detection... so be aware... It is much more likely than direct system transfer that data is leaked slowly through an un-monitored network channel ( DNS tunneling... email... etc ) Hence the need to make things appear to be local; to distract from looking for the real method of transfer.
- woodman 12y agoWhen you get to the point where you are emulating the actual hardware in the spoof (seek time, etc), I think you've already fallen below the noise floor. It would be like a side channel attack on string comparison during hash checks, you would need a huge number of trials to tease out the signal. I wouldn't think it would be that difficult to fake a media speed constraint though - just pay attention to the clock and sleep when you're ahead of the target bitrate. You don't care if the speed is under, you just don't want it any higher than the max theoretical limit. USB 3.0 shouldn't be a problem for VMs, just grant the guest PCI passthrough access to the USB controller. So you'd have to use something like Xen instead of Virtualbox. My workstation doesn't have USB 3.0, so if I were to steal company data - it would be at USB 2.0 speed. Also, if I were already inside - I'd much rather do that than trying to be clever about getting it out over the network (which would be much slower and more likely to be logged).