Mount the evidence. Move only what you extract.
KEIBIDROP mounts a remote evidence share as a local folder. Reads pull only the bytes they touch, so a 500 GB tree can cost a 500 MB extract.
The evidence machine runs one user space binary. No FUSE, no WinFsp, no kernel driver, no reboot. The filesystem driver goes on the analyst workstation, which is the only side that mounts.
No inbound port on either side. Read only enforced at the source.
KAPE, YARA, grep, a hex editor. The mount is a path, so --tsource takes it directly.
Both sides dial out. No VPN to stand up, no firewall change, no sshd on the target.
The origin refuses every write, delete, rename and attribute change from the peer.
Permission bits, mtime and atime applied to the received file. Serving a read leaves the origin's access time as it was.
WinFsp, fuse3 or macFUSE on the analyst workstation. The evidence machine needs none of them.
A dropped link picks up at the chunk it reached.
| KEIBIDROP | sshfs | scp / rsync | Collector + SFTP | |
|---|---|---|---|---|
| Needs inbound access | No | SSH | SSH | Usually |
| Works on a Windows target | Yes | Needs sshd | Needs sshd | Yes |
| Answer before the copy finishes | Yes | Yes | No | No |
| Second question costs nothing | Yes | Yes | New copy | New collection |
| Resume after a drop | Per chunk | Reconnects | Per file | Restarts |
| Read only enforced at source | Yes | Client flag | n/a | n/a |
| Runs on an appliance with no shell | No | Yes | Yes | No |
Timisoara VPS reading a Singapore Windows Server, clean datacenter link, about 200 ms round trip.
| Read path | Throughput | Trials |
|---|---|---|
| sshfs, 100 MB file | 1.32 to 1.34 MB/s, median 1.33 | n=10 |
| sshfs, 1 GB file | 1.33 MB/s | n=5 |
| KEIBIDROP on demand, same link | 20 to 30 MB/s |
The sshfs rate holds at 1.33 MB/s at both file sizes. That is a latency bound: about 326 KB crosses per round trip whatever the file size.
On a 358 file, 43 MB triage tree over loopback: tree walk 33 ms, cold read of every file header 2.9 s, 310 file extract verified by hash against the source. Loopback shows the work per operation. A wide area link adds round trips to each one, and the byte count stays the same.
The video is one run from beginning to end. A Mac is holding 2,683 files that come to 19.9 GB, and a Windows laptop mounts that folder read only over a link relayed through a bridge 410 km away, so both machines are sharing the same 50 Mbps uplink. You can watch the tree get listed, then a grep go through every log in it, then robocopy pull out the artifact set, and at the end both machines hash the same two registry hives and compare them.
Over the whole session, 606 MB crossed the link against the 19.9 GB sitting on the Mac, which works out at 34 times less data. We take that figure off the network card, so it includes the grep, which had to read every log in the tree. The artifacts that ended up on disk came to 382 MB.
Do not read the clock in that video as a speed you would get. Pulling the artifact set took just over seven minutes, and it was slow because there were 2,174 separate files in it and every one of them waited for its own round trip. We have rewritten that part since the recording. The evidence tree you see was generated for the demo, so the file names look right and a real parser rejects the contents.
No. Both sides dial out and a relay bridges NAT.
One user space binary, run and done.
On a read only share the origin refuses every write, delete and rename.
Yes. Point --tsource at the mount and run it as usual.
We are recording wide area triage numbers now. Mail marius@keibisoft.com for the results and the setup guide.
A form for this arrives once the endpoint is live.