Having trouble with CaSe in preprocessor eval:#exact:
Having trouble with CaSe in preprocessor eval:#exact:
So I'm trying to compare an SHA hash in a file's Alternate-Data-Stream versus the value in its sha512sum digest file. That is, verifying the sameness of the file's digest to its ads data. I am easily able to transpose the hash value from the ads via regex-match-1: so I can compare it to its sha512sum-SHA512: column. Both columns populate.
My problem: Everything makes the sha512sum-SHA512 column data UPPERCASE, while the ads is in lowercase, and I apparently don't know how to crack this.
regex:ads-ansi:"sha512=(\w+)" !eval:#<:#exact:#regex-match-1:,#sha512sum-sha512:#>:
I've tried mashing all sorts of syntax to ignore or augment the case of either property, but #exact: doesn't care what I try. Suggestions?
Side question: Why 'sha512sum-sha512' and not just 'sha512sum' ? <cipher>-<extension> for future sidecar file extensions?
My problem: Everything makes the sha512sum-SHA512 column data UPPERCASE, while the ads is in lowercase, and I apparently don't know how to crack this.
regex:ads-ansi:"sha512=(\w+)" !eval:#<:#exact:#regex-match-1:,#sha512sum-sha512:#>:
I've tried mashing all sorts of syntax to ignore or augment the case of either property, but #exact: doesn't care what I try. Suggestions?
Side question: Why 'sha512sum-sha512' and not just 'sha512sum' ? <cipher>-<extension> for future sidecar file extensions?
Re: Having trouble with CaSe in preprocessor eval:#exact:
Please try the following:
#stricmp:
Code: Select all
regex:ads-ansi:"sha512=(\w+)" !eval:#<:#stricmp:<#regex-match-1:,#sha512sum-sha512:>==0#>:
#stricmp:
Re: Having trouble with CaSe in preprocessor eval:#exact:
I'm afraid this isn't working either.
I have created a test set for this, attached. It is a .7z (7-Zip) archive of a .wim (windows image) archive. 7-Zip can extract both archives. I chose .wim because it is the only container I know of that can store ADS data.
Contains 2 text files and 2 .sha512 digest files. All 4 files contain ADS data supplied by FastCopy. The 'mismatch' file's .sha512 digest no longer matches the file contents, because I altered the file's contents prior to using FastCopy. The mismatch file's ADS is a correct match. You ought to just ignore the ADS data on the .sha512 files themselves because they are not pertinent to this experiment.
I have created a test set for this, attached. It is a .7z (7-Zip) archive of a .wim (windows image) archive. 7-Zip can extract both archives. I chose .wim because it is the only container I know of that can store ADS data.
Contains 2 text files and 2 .sha512 digest files. All 4 files contain ADS data supplied by FastCopy. The 'mismatch' file's .sha512 digest no longer matches the file contents, because I altered the file's contents prior to using FastCopy. The mismatch file's ADS is a correct match. You ought to just ignore the ADS data on the .sha512 files themselves because they are not pertinent to this experiment.
- Attachments
-
- shamatch.wim.7z
- (1.54 KiB) Downloaded 75 times
Re: Having trouble with CaSe in preprocessor eval:#exact:
Thanks for your reply raccoon,
Lots of bugs in Everything here..
eval: doesn't understand regex-match-1:
sha512sum-sha512: is leaking memory.
regular-expression-match-1 will cause a stack overflow in eval.
I will get this going and simplify the process for the next alpha update.
There's a lot of changes coming in the next alpha update for comparing properties.
I would like to phase out eval.
In the next alpha update you'll be able to search for:
regex:ads-ansi:"sha512=(\w+)" #regex-match-1:!=#sha512sum-sha512:
Lots of bugs in Everything here..
eval: doesn't understand regex-match-1:
sha512sum-sha512: is leaking memory.
regular-expression-match-1 will cause a stack overflow in eval.
I will get this going and simplify the process for the next alpha update.
There's a lot of changes coming in the next alpha update for comparing properties.
I would like to phase out eval.
In the next alpha update you'll be able to search for:
regex:ads-ansi:"sha512=(\w+)" #regex-match-1:!=#sha512sum-sha512:
Re: Having trouble with CaSe in preprocessor eval:#exact:
<3
Do you have a match operator to determine case sensitivity and case insensitivity? I've seen '===' used to mean case-sensitive, and '~=' and '~==' can mean case-insensitive, while '=' and '==' can mean obey-match-case-setting?
Do you have a match operator to determine case sensitivity and case insensitivity? I've seen '===' used to mean case-sensitive, and '~=' and '~==' can mean case-insensitive, while '=' and '==' can mean obey-match-case-setting?
Re: Having trouble with CaSe in preprocessor eval:#exact:
Case insensitive by default.
For case sensitive:
case:#regex-match-1:!=#sha512sum-sha512:
I will have an update soon.
For case sensitive:
case:#regex-match-1:!=#sha512sum-sha512:
I will have an update soon.
Re: Having trouble with CaSe in preprocessor eval:#exact:
Everything 1.5.0.1304a improves comparing two properties.
You can now search for:
regex:ads-ansi:"sha512=(\w+)" regmatch1:==sha512sumsha512:
width:<height:
dm:date-taken:
Use the case: search modifier to match case.
Use the diacritics: search modifier to match diacritics.
For example:
case:regmatch1:==sha512sumsha512:
Use double quotes ("") to escape literal text.
For example, find the literal text ==sha512sumsha512: in regmatch1:
regmatch1:"==sha512sumsha512:"
The following operators are supported:
== is equal
!= is not equal
<= less than or equal
>= greater than or equal
< less than
> greater than
Everything will try to match properties with a number primitive first and then fall back to text comparison.
(kind-of like Javascript)
Number primitives support the following additional operators:
(no operator) is equal
= is equal
! is not equal
Everything 1.5.0.1304a also improves the regmatch properties.
regular expression match properties should now update in real-time.
For example: regex:sha512:(.*) should now show the correct capture once the property has been gathered.
Previously, regex:sha512:(.*) would match the empty value before it was gathered and would not update.
You can now search for:
regex:ads-ansi:"sha512=(\w+)" regmatch1:==sha512sumsha512:
width:<height:
dm:date-taken:
Use the case: search modifier to match case.
Use the diacritics: search modifier to match diacritics.
For example:
case:regmatch1:==sha512sumsha512:
Use double quotes ("") to escape literal text.
For example, find the literal text ==sha512sumsha512: in regmatch1:
regmatch1:"==sha512sumsha512:"
The following operators are supported:
== is equal
!= is not equal
<= less than or equal
>= greater than or equal
< less than
> greater than
Everything will try to match properties with a number primitive first and then fall back to text comparison.
(kind-of like Javascript)
Number primitives support the following additional operators:
(no operator) is equal
= is equal
! is not equal
Everything 1.5.0.1304a also improves the regmatch properties.
regular expression match properties should now update in real-time.
For example: regex:sha512:(.*) should now show the correct capture once the property has been gathered.
Previously, regex:sha512:(.*) would match the empty value before it was gathered and would not update.
Re: Having trouble with CaSe in preprocessor eval:#exact:
Thanks @void for spending so much time performing surgery on these features. reg-match, ads, sha512, column/property compare. it all adds up to some very powerful stuff now!
Just in my case, now I can quickly detect bit rot when copying copies of copied copy because their digests don't match up to the most recent transfer hash. Such a rare occurrence, but helps me sleep at night, and saving me from 48 ~ 200 hours for a full read verification to know for sure.
Update: This has already paid off. Just found 3 totally corrupt copies that I probably wouldn't have caught otherwise for a very long time.
Just in my case, now I can quickly detect bit rot when copying copies of copied copy because their digests don't match up to the most recent transfer hash. Such a rare occurrence, but helps me sleep at night, and saving me from 48 ~ 200 hours for a full read verification to know for sure.
Update: This has already paid off. Just found 3 totally corrupt copies that I probably wouldn't have caught otherwise for a very long time.