(ter aanvulling, geen kritiek!)
Inderdaad, mits je naar ASCII en unicode strings zoekt die
minstens (als ik me niet vergis) 3 karakters lang zijn en
waar geen "bijzondere" tekens tussen zitten; waar
strings.exe precies op checkt weet ik niet, en dat is nou
net het probleem in dit geval (die implementatie is helaas
geen open source). Het
is een filter programma dat
veel false positives oplevert, en missen van belangrijke
info is helaas ook mogelijk! Desalniettemin handig voor een
quick check, maar als je kunt programmeren en weet waar je
naar zoekt is het schrijven van een eigen tooltje soms safer
en sneller (ik zou wel even strings gebruiken om te checken
of m'n eigen programma niets mist).
Let ook op, als je strings.exe van Mark Russinovich al jaren
geleden gedownload hebt: bij oudere versies krijg je by
default alleen unicode strings, en met /A alleen ASCII.
Verder zijn er nogal wat programmeurs die gevoelige
informatie "versleutelen" door elke byte bijv. met XOR 0x55
(of ROT13 etc) in het geheugen te laten staan (en alleen op
het moment dat ze het nodig hebben even decoderen en direct
daarna weer coderen). Iemand die weet waar hij naar moet
zoeken vindt dit wel, maar strings.exe is kansloos - en als
strings.exe al meent een karakterreeks te herkennen, zullen
de meeste lezers dergelijke output als false positives
beschouwen.
Ten slotte: als de pagefile groter is dan 2GB (en met name
indien groter dan 4GB) kunnen oudere tools zoals "strings"
(maar ook nieuwe indien de programmeur daar geen rekening
mee houdt) in de fout gaan, ofwel door te stoppen met een
foutmelding ofwel door niets te melden maar wel een deel van
de file over te slaan. Of de laatste strings.exe van Mark
dit goed doet weet ik niet uit m'n hoofd.