3 ms·

I have been faking date/timestamps on files contributed to both github and pause over the past 10 years. To me that information is private and I see no reason t

by rilita 12y ago

I have been faking date/timestamps on files contributed to both github and pause over the past 10 years. To me that information is private and I see no reason to give real dates out for files I put into the open source world. I messed up once and set the date/times into the future by a bit and got a bug filed against my project when someone tried to merge my software into a mainline linux distro and had problems with the future date/times. I don't know how many people have used this information for malicious purposes, but I can guarantee that I always think about it in any hacks I've been involved in. Do note that file creation time in unix requires kernel level access and quite a bit of low level filesystem knowledge to truly forge. The easily changeable date/time is only access and modify times. If you are going to forge this data to remove tracks from real systems you will need to root the machine completely first. It's nontrivial.

graylights 12y ago
"Do note that file creation time in unix requires kernel level access and quite a bit of low level filesystem knowledge to truly forge." Timestamps are a mess on unix. POSIX doesn't support creation time but instead has ctime (change time). Newer filesystems add crtime but common utilities don't ever display crtime. Also partitions sometimes are mounted to not update atime for performance reasons. crtime (and ctime) can be modified with root privileges without kernel access with debugfs. Or you can go the ugly hackish way: date -s $forgedate && touch tmp && date -s $realdate && cat original >> tmp && mv tmp original Neither are elegant, but certainly not hard. What's really hard to forensically cover up is the order of inodes on a filesystem. That file with forged timestamps to 2012 will still have an inode that looks much more recent.
- rilita 12y ago
  It is the inode trail that I am referring to; not the simple forging of the dates ( which you could obviously do by just changing the date and duplicating the file as you've described ). Messing with the inodes is much more difficult.
woodman 12y ago
Yeah the faked timestamps aren't new to me, it is the potential faking of copy speed that is interesting. To do that you would need to replicate the transfer order of the copy algorithm (cp in linux vs windows 95), and then modify each timestamp based on the prior file size in the ordered list. I've never heard of anybody doing this before.
- 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 ago
    It 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 ago
      Rate 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.

by rilita 12y ago

graylights 12y ago

"Do note that file creation time in unix requires kernel level access and quite a bit of low level filesystem knowledge to truly forge." Timestamps are a mess on unix. POSIX doesn't support creation time but instead has ctime (change time). Newer filesystems add crtime but common utilities don't ever display crtime. Also partitions sometimes are mounted to not update atime for performance reasons. crtime (and ctime) can be modified with root privileges without kernel access with debugfs. Or you can go the ugly hackish way: date -s $forgedate && touch tmp && date -s $realdate && cat original >> tmp && mv tmp original Neither are elegant, but certainly not hard. What's really hard to forensically cover up is the order of inodes on a filesystem. That file with forged timestamps to 2012 will still have an inode that looks much more recent.

rilita 12y ago
It is the inode trail that I am referring to; not the simple forging of the dates ( which you could obviously do by just changing the date and duplicating the file as you've described ). Messing with the inodes is much more difficult.

woodman 12y ago

Yeah the faked timestamps aren't new to me, it is the potential faking of copy speed that is interesting. To do that you would need to replicate the transfer order of the copy algorithm (cp in linux vs windows 95), and then modify each timestamp based on the prior file size in the ordered list. I've never heard of anybody doing this before.

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 ago
  It 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 ago
    Rate 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.