Suche mit Plugins - Vergleich von Feldern möglich?

[Dalai]

Hallo Leute .

Ausgelöst durch einen Kundenrechner habe ich mal wieder eine Frage: Ist es möglich, irgendwie nach Dateien zu suchen und dabei ein Feld eines Plugins mit dem Feld eines anderen (oder desselben) Plugins zu vergleichen?

Konkret geht es mir um eine Suche nach Dateien, deren Dateiname nicht mit dem in den Versionsinformationen hinterlegten Originaldateinamen übereinstimmt. Beispiel: Dateiname lautet "hanswurst.dll" und in den Versionsinformationen steht "blablubber.dll" - nur solche Dateien (mit Unterschieden) sollen gefunden werden.

Geht das irgendwie? Das muss auch nicht notwendigerweise (allein) mit dem TC sein.

MfG Dalai

[milo1012]

Ich glaube kaum dass es im TC nativ geht, da die Alt+F7-Suche nicht erlaubt in den Plugin-Feldern irgendwelche Platzhalter oder Makros einzutragen.

Für solche Geschichten nehme ich normalerweise eine "schnelle" Sichtung, d.h. mit MRT das Plugin-Feld an die Datei(en) anhängen.
Dann alle in Frage kommenden Dateien in eine Liste, oder z.B. auch im TC-Fenster, und dann mit schnellem Auge durchsehen und
entsprechende Dateien aussortieren (und evt. mit MRT wieder umbenennen).

Eine andere Möglichkeit wäre ein Suchtool zu benutzen dass doppelte Strings im Dateinamen findet,
oder in dem Fall eben die invertierte Suche über eine Liste von Dateien.
Wäre wohl was für ein Skript.

Mit so einer mit MRT erzeugten Dateiliste könntest du dich auch an RegEx versuchen:
Die Datei mit den Namen z.B. in RegXract anwenden:
RegEx:

Code: Select all

(?m)([\w.]+)\s*\g{1}$

Ersatzstring:
<leer>
[x] Suchen und ersetzen

Vermutlich geht das auch irgendwie mit awk, da müsste sich aber jemand anders dran versuchen.
Jedenfalls werden damit aus der Liste alle Dateien geschmissen die doppelte Strings haben.
Die Ausgabeliste kannst du dann im TC zum Markieren nutzen, usw.


Abgesehen vom Umbenennen könntest du dich auch an super_wdx versuchen,
allerdings bräuchtest du dann ein Plug-in was die blanken Dateinamen ausgibt.

Konkret geht es mir um eine Suche nach Dateien, deren Dateiname nicht mit dem in den Versionsinformationen hinterlegten Originaldateinamen übereinstimmt. Beispiel: Dateiname lautet "hanswurst.dll" und in den Versionsinformationen steht "blablubber.dll" - nur solche Dateien (mit Unterschieden) sollen gefunden werden.

Welches Plug-in, abseits vom TC-internen, bietet denn Zugriff auf die eingebettete Versionsinfo?
Mir ist nur ExeFormat bekannt,
was aber auf Infos aus dem PE-Header beschränkt ist.

Übrigens: das Letzte worauf man sich verlassen sollte ist die Versionsinformation.
Dann lieber digitale Signaturen oder Ähnliches.

[Dalai]

Ich glaube kaum dass es im TC nativ geht, da die Alt+F7-Suche nicht erlaubt in den Plugin-Feldern irgendwelche Platzhalter oder Makros einzutragen.

Jep, deswegen frage ich hier .

Für solche Geschichten nehme ich normalerweise eine "schnelle" Sichtung, d.h. mit MRT das Plugin-Feld an die Datei(en) anhängen.

Clever! Nur leider nicht für mich anwendbar, weil die Dateinamen exakt so bleiben müssen...

Abgesehen vom Umbenennen könntest du dich auch an super_wdx versuchen,
allerdings bräuchtest du dann ein Plug-in was die blanken Dateinamen ausgibt.

Das schau ich mir mal an.

Welches Plug-in, abseits vom TC-internen, bietet denn Zugriff auf die eingebettete Versionsinfo?
Mir ist nur ExeFormat bekannt,
was aber auf Infos aus dem PE-Header beschränkt ist.

Du meinst Inhaltsplugins? Da gibt's neben dem genannten exeformat noch exeinfo; und eben dieses wollte ich für die Suche benutzen.

Übrigens: das Letzte worauf man sich verlassen sollte ist die Versionsinformation.
Dann lieber digitale Signaturen oder Ähnliches.

Ja und nein. Signaturen wären einerseits deutlich zuverlässiger, andererseits müssen sie zur Verfügung stehen. Die Sache ist etwas komplexer. Ab Vista sind ja die DLLs des Systems nicht mehr einzeln signiert, sondern das System lagert die Signaturen in einem Verzeichnis (IIRC im catroot). Da ich mit der Geschichte hier aber auch DLLs von einem fremden Windows prüfen will (Sigs des fremden Systems liegen im aktuell laufenden nicht vor), die Sache auch noch im BartPE/WinPE und im abgesicherten Modus funktionieren soll, kommt man mit Signaturen nicht weit.

Zudem stellt sich mir die Frage, wie man das (automatisiert) prüfen will. Sysinternals Sigcheck is ja schick, aber wie prüfe ich damit Dateien eines Win7 auf einem XP (oder umgekehrt)? Sieht so aus, als wären die Signaturen für die verschiedenen Dateien in verschiedenen Catalog-Dateien im catroot ...

Ich glaub, ich probier mal, ein Skript mit AutoIt zusammenzuklöppeln. Schließlich kann man damit auch Versionsinfos auslesen.

MfG Dalai

[milo1012]

Ja und nein. Signaturen wären einerseits deutlich zuverlässiger, andererseits müssen sie zur Verfügung stehen. Die Sache ist etwas komplexer. Ab Vista sind ja die DLLs des Systems nicht mehr einzeln signiert...

Schon klar, die Frage ist nur warum überhaupt so eine Prüfung?
Sind dafür nicht die üblichen Verdächtigen, wie Virenschutz, zuständig?
Für Windows-Systemdateien gibt es ja sowieso den Systemdateischutz.
Wenn das in PE-Umgebungen laufen soll würden einfache Prüfsummen evt. auch schon reichen.
Die Versionsinfo ist IMO ungeeignet, da erstens komplett vom Entwickler auf freiwilliger Basis, und der Originaldateiname
u.U. schon von Haus aus nicht stimmt.

Nur leider nicht für mich anwendbar, weil die Dateinamen exakt so bleiben müssen...

Vorheriges Rauskopieren?
Oder noch besser: benutzerdefinierte Spalten und dann cm_CopyFileDetailsToClip ?

Zudem stellt sich mir die Frage, wie man das (automatisiert) prüfen will. Sysinternals Sigcheck is ja schick, aber wie prüfe ich damit Dateien eines Win7 auf einem XP (oder umgekehrt)?

Sind das Systemdateien oder eigenständige (installierte) Programme?

Da gibt's neben dem genannten exeformat noch exeinfo; und eben dieses wollte ich für die Suche benutzen.

Okay. Ist mir nie in den Sinn gekommen, da das TC-interne wdx meistens reicht.

[ZoSTeR]

Kurz mal nen Beispiel in PowerShell:

Code: Select all

$dir = "C:\_Temp\_7zip"
$dllFiles = Get-ChildItem -Path $dir -Filter "*.dll" -Recurse

foreach ($file in $dllFiles)
{
    $file.Name
    $file.VersionInfo | Select *

    If ($file.Name -ne $file.VersionInfo.OriginalFilename)
    {
        echo "*** Dateiname ungleich OrignalFilename"
    }
}

[Dalai]

Schon klar, die Frage ist nur warum überhaupt so eine Prüfung?
Sind dafür nicht die üblichen Verdächtigen, wie Virenschutz, zuständig?

Naja, wie du weißt, bringt der nichts, wenn die Dateien zu frisch sind.

Für Windows-Systemdateien gibt es ja sowieso den Systemdateischutz.

Stimmt, aber das hilft nichts, wenn irgendein Depp Dateien zusätzlich in ein Systemverzeichnis ablädt.

Wenn das in PE-Umgebungen laufen soll würden einfache Prüfsummen evt. auch schon reichen.

Und woher kommen die Prüfsummen? Richtig, man müsste sie vorher selbst berechnen. Und dieses Spiel nach jeder einzelnen Änderung wiederholen, wobei Windows Updates nur die offensichtlichste davon darstellt.

Die Versionsinfo ist IMO ungeeignet, da erstens komplett vom Entwickler auf freiwilliger Basis, und der Originaldateiname
u.U. schon von Haus aus nicht stimmt.

Ja, dessen bin ich mir bewusst. Die Sache soll nur einen kleinen Eindruck verschaffen, nichts weiter.

Vorheriges Rauskopieren?

Naja, wir kopieren erstmal 20G oder mehr durch die Kante, bevor's losgeht .

Oder noch besser: benutzerdefinierte Spalten und dann cm_CopyFileDetailsToClip ?

Das würde bedingen, dass entweder alle Verzeichnisse einzeln durchgeklapptert werden (viel zu aufwendig) oder man die Zweigansicht benutzt, deren Aufbau bei solchen Datenmengen/Dateianzahlen ebenfalls ewig dauert. => Unpraktikabel.

Wie lange eine Suche dauert, ist mir im Zweifel egal, denn wenn selbige fertig ist, ist die Ergebnisliste bereits gefiltert.

Sind das Systemdateien oder eigenständige (installierte) Programme?

Im Zweifel sowohl als auch.

Okay. Ist mir nie in den Sinn gekommen, da das TC-interne wdx meistens reicht.

Ich glaube mich zu erinnern, dass TC diese Felder zur Versionsnummer erst später anbot; das Plugin existiert aber schon sehr lange. (Ich will aber nicht ausschließen, dass ich das Feld damals übersehen habe.)

@ZoSTeR: Danke, nette Sache! Aber PowerShell steht mir nicht in jedem Fall zur Verfügung.

MfG Dalai

[Dalai]

Ich hab nun mal fix ein AutoIt-Skript geschrieben, stelle aber fest, dass selbst auf einem normalen XP-System, auf dem nicht viel installiert ist, schon über 500 DLLs allein im Windows-Verzeichnis gefunden werden. Und da sind noch nicht einmal die ohne Versionsinfo bzw. ohne OriginalFilename drin...

Fazit: Unbrauchbarer Ansatz. Naja, jeder hat mal eine Schnapsidee .

Weiteres Fazit: TC braucht eine Möglichkeit, Pluginfelder in der Suche zu vergleichen .

Mal sehen, ob Sigcheck etwas bringt, aber ich fürchte, dass sich dabei viele Dateien finden lassen, die nicht signiert sind (so wie auf meinem), sei es weil sie von alter Software stammen oder zu Open Source Software gehören oder aus anderen Gründen ...

MfG Dalai

[milo1012]

Das würde bedingen, dass entweder alle Verzeichnisse einzeln durchgeklapptert werden (viel zu aufwendig) oder man die Zweigansicht benutzt, deren Aufbau bei solchen Datenmengen/Dateianzahlen ebenfalls ewig dauert. => Unpraktikabel.

Hm, meine Win7 DLLs, DRVs und EXEs im Win-Verzeichnis habe ich in knapp 20 Sekunden gesucht und sortiert.

• Suche anwenden -> alles markieren
• Auf Benutzerdefinierte Spalte schalten, cm_CopyFileDetailsToClip
• In Notepad2 und Konsorten einfügen
• Datei wie oben angesprochen nach doppelten Strings filtern
• Dann evt. nochmal filtern um nur Dateinamen drin zu lassen
• Diese Datei mit cm_LoadSelectionFromFile anwenden

-> nur in Frage kommende Dateien sind markiert.

Zugegeben etwas aufwändig, tut aber was es soll.

Für Windows-Systemdateien gibt es ja sowieso den Systemdateischutz.

Stimmt, aber das hilft nichts, wenn irgendein Depp Dateien zusätzlich in ein Systemverzeichnis ablädt.

Bei so einem Szenario hat man i.d.R. sowieso andere Probleme, da hilft so ein Scan eher wenig, da es verdammt noch Rootkit und Co. klingt.
Im Zweifel System so lange einfrieren bis man mit einem vernünftigen Virenscanner rangehen kann, bei dem die Signaturen aktuell sind.
Nun ja, deine Baustelle.

Weiteres Fazit: TC braucht eine Möglichkeit, Pluginfelder in der Suche zu vergleichen .

Würde ich unterstützen.
Vielleicht ist ja auf der TC9-Agenda noch Platz.

[Dalai]

Zugegeben etwas aufwändig, tut aber was es soll.

Das war mir für einen ersten Test, ob mein Vorhaben überhaupt vom Ansatz her sinnvoll ist, zu aufwendig. Und nun, da sich der Nutzen als zweifelhaft herausstellte, hat es sich eh erledigt. Aber vielleicht kann ich es (oder jemand anders) in Zukunft doch noch brauchen .

Bei so einem Szenario hat man i.d.R. sowieso andere Probleme, da hilft so ein Scan eher wenig, da es verdammt noch Rootkit und Co. klingt.

Näh, ich hatte eher reguläre Installationen von irgendwelcher Schrottsoftware im Sinn, oder Adware & Co.

Im Zweifel System so lange einfrieren bis man mit einem vernünftigen Virenscanner rangehen kann, bei dem die Signaturen aktuell sind.

"Aktuell" reicht nicht immer, genau das ist ja das Problem. Konzeptionell schon nicht. Aber da wir ja nicht über Virenscanner diskutieren wollen (denn dazu könnte man sich endlos auslassen), belassen wir es mal dabei.

Nun ja, deine Baustelle.

Ja, leider.

---

Ich versuche mich gerade an den Signaturen, aber ich fürchte das wird sich als ähnlich unbrauchbar erweisen. Ich hab ein Skript von Helge Klein angepasst (als Wichtigstes fehlte dem Signtool der Schalter /a), und lasse es gerade durchlaufen. Weiß nicht, wie viele Dateien er noch zu verarbeiten hat, aber schon jetzt sind es knapp 300 unsignierte Dateien...

MfG Dalai