![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
nsrlquery has been split off into two subprojects, nsrlsvr and nsrllookup. I finally realized that putting both applications in the same tarball made about as much sense as bundling a web browser with every download of a web server — which is to say, none at all.
The project website hasn’t changed: it’s just that there are now two different tarballs you can download. Both are currently at version 1.0.6, and some substantial improvements have been made since 1.0.
One question I’ve had from a few people is, “so how much will this affect my workflow?” I hate to sound snarky, but I don’t know what your workflow is and I’m unable to answer that question. Likewise, “How fast is it compared to md5deep?” isn’t a fair question: the two of them are so vastly different that all comparisons are suspect. We’re not talking apples and oranges, we’re talking salt and single-malt Scotch.
md5deep reads a lot of data. As such, it’s primarily limited by the speed of your disk I/O. Given the I/O differences between slow hard drives and lightning-fast SSDs, md5deep’s performance can easily vary by more than an order of magnitude.
By comparison, nsrllookup reads only a very small amount of data, but it has to push it across a network connection that’s probably considerably slower than a hard drive. If you’re querying a server on your local subnet that’s connected by gigabit Ethernet you’ll have much different performance than if you’re in Kandahar querying a server in Japan over a network connection where the packets at one point have to be carried through the Khyber Pass by a Tajik courier called Anxious Jack.
The lesson to draw here is that there are lies, damn lies, and performance benchmarks. All results are suspect, and none of them should be considered to apply to your system. Yours will quite likely be a lot different.
All this being said, here’s a hint for how fast nsrllookup acts. On an Asus U56E laptop, running md5deep 4.0.0 over my 3Gb home directory spanning 6,146 files took just over four minutes. Piping that output through nsrllookup over a consumer-grade cable connection to a remote server off my local network but still nearby took three seconds.
So, if you’re wondering, “can I integrate nsrllookup into my forensics toolchain without introducing delays,” the best advice I can give you is to try it for yourself. I think you’ll be pleasantly surprised by how it performs.