| Author | Message | ||
     rjohnson |
When searching a logical drive (all or down), WinHex appears to always use the beginning of the logical drive as the starting point for any relative offset (Cond: Offset mod)applied, is this correct? I would like to be able to use, for example, "Cond: offset mod: 4096 0", but start the search and apply the offset from the current cursor position (usually the first byte of a sector or cluster) or search within a defined block. A simple example of what I cannot do: search for specific content only, at the first few bytes of each cluster (say 4096 bytes/cluster), but if cluster number 2 does not start at a logical sector number that evenly divides by the sectors/cluster the search fails, and I assume this is why I cannot succeed. If cluster 2 started at logical sector 81,920 then the 4096 offset would probably work (81,920 divided by 4096 = 20 - an even amount) but if the first cluster started at logical sector 81,918 then the search would fail to target just the beginning of each cluster (81,918 divided by 4096 = 19.9995 - not evenly divided) because the offset calculation starts at logical sector zero, not at the beggining of a defined block or from the current cursor when using "Down"?. Is this the correct understanding? Does WinHex have a method built in that will do this? Thank you | ||
| Stefan Fleischmann (Admin) |
Your understanding is all correct. The offset is the absolute offset as shown in the offset column. I recommend you use the condition Offset mod 512=0, that is, search at sector boundaries. The record presentation feature (View menu) can help you to easily recognize cluster boundaries when WinHex shows a hit: [x] Apply different background color First record at offset: e.g. 81918*512 = 41942016 Record size in bytes: 4096 | ||
| rjohnson |
I usually do use mod 512=0, but this time there are way too many "false positives" to manually review, even with 'Record presentaion' (which I love, and always use). This project is using 16k cluster, so it is seaching 32 times the amount of sectors that is needed and finding too many positives in those other 31 sectors/cluster. If I save a .pos file of all the hits, is there a script or routine to eliminate the false offsets from that file? thanks again, | ||
| Stefan Fleischmann (Admin) |
Too many false positives, I see... You could export the positions to an HTML file, open that HTML file in MS Excel, insert a column next to the offset, and use formulas based on the offsets to specially mark lines with false positives. Then sort by that column and cut the lines from the file. I will think about extending the offset feature. | ||
| rjohnson |
Thank you very much for the helpful ideas. I may try exporting. Side note re: too many. I had 5000+ hits. The presentation view setup formula you gave above works perfect to identify the correct 'hit'. However, not only too many hits to manually review, but the postition manager delay to open and close that many positions every time I need to work in a good 'hit' also slows things down. I can now envision the few script routines I would need to collect just the the correct hits 'postitions' needed to store in a .POS file, I am just not sure how to store my 'script hits' (e.g. CurrentPos), as each is found, into a .POS file. I will quickly script this first part (with the help of your offset formula) and see how many perfect hits there are in that 5000+, if few enough, the script could at least find next good hit and halt there for work to be done, then resume when needed??? Thank you very very much for your help and for consideration re: extending the offset feature. | ||
| Stefan Fleischmann (Admin) |
If there are too many hits for the Position Manager to work efficiently, I recommend using Simultaneous Search, archiving the hits in a tab-delimited text file instead, and further processing in MS Excel. There is no script command (yet) to add a position to the Position Manager. | ||
| rjohnson |
Brilliant, thanks! |