Show HN: CLI forensics tool for tracking USB device artifacts on Linux(github.com)
github.com
Show HN: CLI forensics tool for tracking USB device artifacts on Linux
https://github.com/snovvcrash/usbrip
26 comments
Wouldn't this be more reliable by recording udev events instead of parsing the syslog?
Yeah, here's a one-line udev rule to log USB removal and insertion into the journal.
> $ echo 'SUBSYSTEMS=="block", RUN+="/usr/bin/logger --tag=block-device-history -- %E{ACTION} | %E{DEVNAME} | %E{ID_MODEL_ID} | $attr{serial}"' | sudo tee /etc/udev/rules.d/10-block-device-history.rules
Activate the new rule by reloading and retrigging:
> $ udevadm control --reload-rules && sudo udevadm trigger
Then in another terminal run:
> $ sudo journalctl -f
...Insert a USB drive and see information about it printed.
journalctl supports querying with time intervals (eg, journalctl --since "2018-01-10" --until "2019-08-01 23:59").
> $ echo 'SUBSYSTEMS=="block", RUN+="/usr/bin/logger --tag=block-device-history -- %E{ACTION} | %E{DEVNAME} | %E{ID_MODEL_ID} | $attr{serial}"' | sudo tee /etc/udev/rules.d/10-block-device-history.rules
Activate the new rule by reloading and retrigging:
> $ udevadm control --reload-rules && sudo udevadm trigger
Then in another terminal run:
> $ sudo journalctl -f
...Insert a USB drive and see information about it printed.
journalctl supports querying with time intervals (eg, journalctl --since "2018-01-10" --until "2019-08-01 23:59").
Slightly tweaked the above, in case anyone is interested. Copy the following to /etc/udev/rules.d/10-block-device-history-rules:
> SUBSYSTEM=="block",ENV{DEVTYPE}=="disk", RUN+="/usr/bin/logger --tag=block-device-history -- '%E{ACTION} | %E{DEVNAME} | %E{ID_SERIAL}'"
Run
> $ sudo udevadm control --reload-rules && sudo udevadm trigger
> $ sudo journalctl -f SYSLOG_IDENTIFIER=block-device-history
...Then re-inserting a USB device produces output similar to the below:
> Jan 01 12:00:00 hostname block-device-history[12345]: add | /dev/sdY | TOSHIBA_TOSHIBA_USB_DRV_012345678900FF00-0:0
To customize the printed variables, have a look at:
> sudo udevadm info /dev/sdY
> SUBSYSTEM=="block",ENV{DEVTYPE}=="disk", RUN+="/usr/bin/logger --tag=block-device-history -- '%E{ACTION} | %E{DEVNAME} | %E{ID_SERIAL}'"
Run
> $ sudo udevadm control --reload-rules && sudo udevadm trigger
> $ sudo journalctl -f SYSLOG_IDENTIFIER=block-device-history
...Then re-inserting a USB device produces output similar to the below:
> Jan 01 12:00:00 hostname block-device-history[12345]: add | /dev/sdY | TOSHIBA_TOSHIBA_USB_DRV_012345678900FF00-0:0
To customize the printed variables, have a look at:
> sudo udevadm info /dev/sdY
Yes, it is one of possible decisions but that would make the tool a bit less portable. When dealing with text logs, you can move them around as well as keep backup storages updating them with new entries.
I'm confused by this. Why can you not have udev events or the kernel API doing the same thing?
[deleted]
I like this. Is there a way to clean up the logs this uses to hide these traces? I didn't see any such functionality as I skimmed the README.
Looks interesting. Could you please convert the tabs to 4 spaces though?
FYI, you can do this yourself with GitHub, by changing the URL.
for example: https://github.com/snovvcrash/usbrip/blob/master/setup.py?ts...
for example: https://github.com/snovvcrash/usbrip/blob/master/setup.py?ts...
Why are you telling a maintainer which code-style to use?
FYI, I have no idea if I use tabs or spacves in my projects, my IDE is configured to use the popular linting/formatting so it autoformats using that,
Honest question, when you hit issues caused by someone else code not using your favorite style of tab vs spaces? Is there an editor/IDE that can't autodetect this and work properly or is there a language that would fail because is hyper sensitive to white space?
Honest question, when you hit issues caused by someone else code not using your favorite style of tab vs spaces? Is there an editor/IDE that can't autodetect this and work properly or is there a language that would fail because is hyper sensitive to white space?
Python, which this program is written in, uses indentation for blocks. Mixing spaces and tabs is basically a syntax error.
Which is why PEP-8 the Python code style guide enforces 4 spaces. This maintains consistency throughout the community. Also PyCharm one of the more popular IDEs for Python uses 4 spaces by default.
That's not what PEP-8 is for, it was meant to define the style of the standard libraries. A lot of people in the community voluntarily adopted it for their projects, but that wasn't its purpose.
Right, but this doesn't mean that the author can't use tabs to indent their code.
Use PhPStorm, alt f6
That sample command line in the screenshot. Its so easy ;)
Question:
From the screenshots it seems like no year is shown?
Only month, day, time.
It would be IMHO advisable to use not the name of the month and somehow fit in the line the year.
Note: Small typo: the past of "shut down" is "shut down" and not "shutted down".
It would be IMHO advisable to use not the name of the month and somehow fit in the line the year.
Note: Small typo: the past of "shut down" is "shut down" and not "shutted down".
They explain the reason in README:
usbrip works with non-modified structure of system log files only, so, unfortunately, it won't be able to parse USB history if you change the format of syslogs (with syslog-ng or rsyslog, for example). That's why the timestamps of "Connected" and "Disconnected" fields don't have the year, by the way. Keep that in mind.Well that's unfortunate, I tend to be rather militant about switching my syslog to something resembling rfc 3339.
linux /etc/rsyslog.conf $ActionFileDefaultTemplate RSYSLOG_FileFormat
openbsd /etc/rc.conf.local syslogd_flags="-Z"
linux /etc/rsyslog.conf $ActionFileDefaultTemplate RSYSLOG_FileFormat
openbsd /etc/rc.conf.local syslogd_flags="-Z"
Well, no, that is a non-explanation.
If the format of syslogs doesn't change there should be no issues (or should it be read as "the system logs don't have the year"? )
If you don't have the year, it is not a "full date" in the forensic sense of the term, and you simply cannot present such a result in a Court.
A statement like "A Netac USB device was connected on May 26, presumably in the year 2019, exactly at 00:51:54 and soon after disconnected, exactly at 00:52:21" won't be good.
If it is technically not possible to retrieve the year, then the whole stuff has very little relevance on itself.
It would be needed to create a complete timeline of the system under investigation and correlate the month, day, time with activities that have an objective timestamp including the year.
If the format of syslogs doesn't change there should be no issues (or should it be read as "the system logs don't have the year"? )
If you don't have the year, it is not a "full date" in the forensic sense of the term, and you simply cannot present such a result in a Court.
A statement like "A Netac USB device was connected on May 26, presumably in the year 2019, exactly at 00:51:54 and soon after disconnected, exactly at 00:52:21" won't be good.
If it is technically not possible to retrieve the year, then the whole stuff has very little relevance on itself.
It would be needed to create a complete timeline of the system under investigation and correlate the month, day, time with activities that have an objective timestamp including the year.
> or should it be read as "the system logs don't have the year"?
That's the case. RFC 3164, which specifies the log format, is the only one usbrip can read, and it doesn't have an option to specify year.
Well, then the tool has no actual "forensics" use by itself.
It's a pity, of course, but it can only be a tool to confirm findings that have a "proper" timestamp.
Most probably the log consists of "appended" entries that might mitigate the issue, still it is needed a clear and extended "justification" to the procedure with wich the year is "attributed" to the yearless entry for forensics use.
It's a pity, of course, but it can only be a tool to confirm findings that have a "proper" timestamp.
Most probably the log consists of "appended" entries that might mitigate the issue, still it is needed a clear and extended "justification" to the procedure with wich the year is "attributed" to the yearless entry for forensics use.
Please don't quote with code blocks. Use italics or quote arrows instead.
Reading that on mobile was painful.
Reading that on mobile was painful.
Oh, sorry. My third-party app previewed it just fine, but I've just tried it in the browser now and I promise I'll never do such thing again.