so, i ran into a challenge and want to see if using dd is possible.

is it possible to use dd to copy a disk from disk to /dev/null but in the middle try and do pattern matching?

dd --> pattern match --> /dev/null

i am trying to find some data that seems to be hidden from std find or searching.

ideas please. thanks.

any way better/faster than this. i'll be on a vm (vmdk) under esxi, etc.

dd if=/dev/sda2 bs=16065 | hexdump -C | grep 'some text'

It'll work for ASCII text, but I've never done it for an entire disk. Yep, it'll be slow, but everything has a cost.
Be aware that it won't find anything that has been obfuscated - docx or pdf for example.

how can be anything "hidden from std find" ?
find / -type f ... (as root)

Can you please go into more detail about the background behind the "unfindable" data?

Background.

A replication agent sends files to a replication server whenever a file is created or modified. That data then traverses an IPS before it goes into a VPN to its destination.

The IPS is alerting on a specific signature and we see specific text in the payload. We are now trying to hunt down where that text is located. To keep this short, we know it's on two of many esxi hosts. These two hosts have about a dozen or so live vmdk's. Not all are linux boxes. McAfee took the text and made a dat for it, we ran McAfee w/o exceptions and it found nothing (we did test the dat successfully). We know the data is there somewhere, but need a better way of searching for it.

Using dd seemed to be the best/fastest was to get every disk block scrubbed looking for the match. This would at least tell us which vmdk is the one that holds the text. Once we know what vmdk it is we can then go fishing in deeper waters, etc.

I don't know about this sort of stuff at all, but does the replication agent not know, perhaps in the packets it receives or in its log, which host and vmdk the data came from?

Nope, the agent has no idea what the data is in a file, it simply sends it to one of many replication servers locally. There's a 1:1 mapping between replication server and esxi host. The IPS events show only two replication servers as the source IP of the traffic, so with this 1:1 mapping we know it's coming from two esxi hosts, and each host has multiple OS's running, etc.

Strings will find data in allocated space, unallocated space, slack space and swap.
I'm guessing your bs=value is block size? kind of an odd number.
Reference material

Thanks Brains for the info.

Yeah, that block size was taken from an example I was looking at.

My command is this
But is using strings any better/faster than using hexdump -C ? I am not after the actual location on disk, but rather just wanting to know what disk on what vmdk has the text.

since the "slow" part is dd probably hexdump will not be faster/slower than strings. But strings is much safer. grep does not really like binary input.

hexdump -C is hex + ascii

How does strings see printable ascii when output of dd is the input to strings?

One problem with using hexdump here is that the text you are seeking may be split over multiple lines in the formatted output.

Good point.

I guess strings is the better way.

Yeah, that's what strings is for, looking for a string. The example above would also show 10 lines before and after the string, the string having a minimum of 8 characters, strings defaults to 4 characters, helps lower false positives.
EDIT: I thought, just in case you would want a copy of the file, I gave you the resources to dig it out with the link I provided earlier. Since you couldn't find the string with other tools could suggest it's not in allocated space where the file system would know where it is.