Search for hex value content at specific position

[Madma]

Hello!
I just found that Everything 1.5 can search for hex values content. That's awesome! Thank you so much! Exactly what I need right now!

But now I have a couple of problems:

1) How can I search for a hex value specificly on the 9th and 10th bytes?

By writing this I can list all files containing the hex values 30 00, is this correct?

Code: Select all

hex:content:3000

But is there a way to find all the files that have those hex values only on the 9th and 10th bytes of the first "row"?

HxD_2021-05-02_21-10-04.png (17.58 KiB) Viewed 19885 times

Really hope there's a way because this would literally save me tons of hours of work.


2) I also noticed that if I write the whole row like this

Code: Select all

hex:content:"464C686406000000"

HxD_2021-05-02_21-28-09.png (15.55 KiB) Viewed 19885 times

or like this:

Code: Select all

hex:content:"464C6864060000002000"

HxD_2021-05-02_21-32-30.png (13.12 KiB) Viewed 19885 times

I don't get any result.
Can someone explain me why?

Thanks a lot for your help

[NotNull]

Can someone explain me why?

In Everything 1.5, when you use the content: function, it will only search in indexed content. And that content has been pre-processed by an iFilter. That means that for example a PDF file will be read by a program that understands PDF files and is able to distill the plain text out of it. Everything never sees hex codes in that case.

How can I search for a hex value specificly on the 9th and 10th bytes?

You can try the following, but no guarantees as there is more to be reckoned with (and I have limited knowledge in this area, that doesn't help either ..):

Code: Select all

"C:\this folder"   ext:pdf   regex:hex:notindexed:ansicontent:^.{8}3000

(replace "C:\this folder" and ext:pdf with somthing that is appropriat for your situation; for testing, start with a limited amount of files/folders.

This will search in files that are NOT content-indexed, so it will be slow(er).

[Madma]

Oh yeah!! It works flawlessly!
Thanks a lot!

But I don't understand why you used ^ and .

^ Matches the start of the filename
Why using this if then you used {8}? Wouldn't be the same to just write {8}?

. Matches any single character
What does exactly mean "any single character"? I don't understand why if I delete the . I don't get any result.

(actually, I don't understand neither the "ansicontent:" . because before it you wrote "hex:" , so why you can write {8} which refers to the ansi but then write 3000 in hex?
why this doesn't work?

Code: Select all

regex:hex:^.{16}3000

I thought that by writing this, it would start matching the 3000 from the 16th digit on (9th byte). hmm


Anyway, Thank you so much! You really saved me hours of work.

You guys are great and Eveything Search Engine is simply incredible <3 <3 <3

[NotNull]

Regex can be used to specify a pattern in filenames, but it can also be used for text. Here the content of the file is seen as 'text'
In that case:
^ => marks the beginning of a "line" of text
. => a random character
{8} => 8 times (= 8 random characters)

When you specify hex: , you can specify a single character using hex values like "30", but it is still a single 'character', just typed in a different way.
So the "." random character matches 30 and not 3.


Using ansicontent: was a bit of a hack here (but if it works .. who's complaining? ).
Files can have special encodings (UTF-16, UTF-8 BOM and what have you). Specifying ansicontent: basically means 'no special encoding' here. That way the content will be seen as raw data (sorry, can't explain it any better).
Another reason for using ansicontent: is that then each 'character' is represented in 8 bits, which is needed for hex: (00-FF = 256 = 8 bits). In UTF-16 for example each character is represented in 16 or 32 bits (both can be mixed in a single text or even word), which would cause this operation to fail (I think; not tested).


Note:
Everything might find "3000" as the 9th and 10th character on another 'line' in your file, so make sure you test this on files that should *not* be found too

[void]

Thank you for your feedback madma,

There are a few quirks here with Everything and hex:, which I will work on for the next alpha update.

The documentation for hex: mentions: treats content as binary.
This is currently not happening which may give unexpected results.

For now, please use hex: and binary: together.

For example:

hex:binary:content:464c686406000000

Without binary: content is normally loaded from an iFilter and may not match the raw data on disk (this is a bug).


A small optimization can be made with the following search:
startwith:hex:binary:content:464c686406000000
the addition of startwith: will only search the first few bytes of the file (fast), where as 'hex:binary:content:464c686406000000' will search the entire file (slow).

1) How can I search for a hex value specificly on the 9th and 10th bytes?

I have put on my TODO list to add a search function to search content at an offset.
Thanks for the suggestion.

But is there a way to find all the files that have those hex values only on the 9th and 10th bytes of the first "row"?

wildcards:hex:binary:content:????????3000*

[Madma]

Thanks a lot for your answer!

This solution works perfectly too! Actually this one found a few that weren't listed before. Great!!
startwith:hex:binary:content:464c6864060000003000 (I added 3000 at the end of it)


but this one instead is simply filtering out .txt and desktop.ini files. Not sure why.
wildcards:hex:binary:content:????????3000*

Anyway, you've been really helpful. thanks again.

[void]

but this one instead is simply filtering out .txt and desktop.ini files. Not sure why.
wildcards:hex:binary:content:????????3000*

There's a bug with wildcards:

I'm working on a fix.

In Everything 1.5, when you use the content: function, it will only search in indexed content.

Just to clarify, If you are not indexing content, content: will search unindexed content.
content: will only search indexed content when content indexing is enabled

regex:hex:^.{16}3000

Please note: . does not match new lines!

regex:hex:^(.|\R){8}3000

\R = match newline (\r or \n or \r\n)

[void]

Everything 1.5.0.1258a fixes an issue with wildcards: not using the correct escaped character code when using hex:

The following should now work as expected:
wildcards:hex:content:????????3000*


binary: is no longer needed as it is now implied when using hex:

When using hex: or binary:, the search AND the content are both treated as a byte stream.
Searching for ASCII characters is allowed with hex: or binary:

[void]

Everything 1.5.0.1276a improves wildcards:hex:content:????????3000* by only reading the necessary number of bytes at the start of the file.