Hex in Dez umwandeln innerhalb einer Batchdatei, SAFER HASH-Regeln erstellen
Hallo,
kann mir einer sagen wie ich innerhalb einer Batchdatei ein in einer Variablen stehender Dezimal Wert von >DEZ in HEX< umwandeln kann?
kann mir einer sagen wie ich innerhalb einer Batchdatei ein in einer Variablen stehender Dezimal Wert von >DEZ in HEX< umwandeln kann?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 194418
Url: https://administrator.de/forum/hex-in-dez-umwandeln-innerhalb-einer-batchdatei-safer-hash-regeln-erstellen-194418.html
Ausgedruckt am: 22.12.2024 um 13:12 Uhr
50 Kommentare
Neuester Kommentar
Hallo speedy26gonzales!
Damit Du nicht selbst (nach "dec to hex batch") suchen musst: http://www.dostips.com/DtTipsArithmetic.php
Grüße
bastla
Damit Du nicht selbst (nach "dec to hex batch") suchen musst: http://www.dostips.com/DtTipsArithmetic.php
Grüße
bastla
[OT]
Hallo bastla.
Hab ich gelegentlich gelesen (vieles von @jeb-the-batcher, auch in anderen Foren). Variablen beginnend mit = sind CMD-intern. Du hast keine Chance sie per SET Befehl zu ändern und im Normalfall siehst du sie auch nicht. Mittels
Was in der ersten Zeile erscheint, habe ich noch nicht herausgefunden.
Auf LW C: war ich zuletzt auf C:\Windows, Auf LW D: zuletzt im Root.
Nun kommt der "Errorlevel" als HEX Wert, dann als ASCII Zeichen (sofern er sich als druckbares Standard-ASCII Zeichen darstellen lässt).
Grüße
rubberman
[/OT]
Hallo bastla.
Hab ich gelegentlich gelesen (vieles von @jeb-the-batcher, auch in anderen Foren). Variablen beginnend mit = sind CMD-intern. Du hast keine Chance sie per SET Befehl zu ändern und im Normalfall siehst du sie auch nicht. Mittels
SET;
machst sie letztlich aber doch sichtbar.@echo off &setlocal
cd /d C:\Windows
cd /d D:\
cmd /c exit /b 65
set; | findstr /b "="
=::=::\
=C:=C:\Windows
=D:=D:\
=ExitCode=00000041
=ExitCodeAscii=A
Auf LW C: war ich zuletzt auf C:\Windows, Auf LW D: zuletzt im Root.
Nun kommt der "Errorlevel" als HEX Wert, dann als ASCII Zeichen (sofern er sich als druckbares Standard-ASCII Zeichen darstellen lässt).
Grüße
rubberman
[/OT]
Hallo speedy26gonzales.
Ein REG_QWORD ist letztlich ein 64 Bit breiter Ganzahlwert. Mit einem Hex-String kommst du für REG ADD und Batch schon mal um einiges weiter. Testen kannst du ja in einem dafür angelegten Key, den du anschließend wieder löscht.
Beispiel:
In strHex findet sich dein Hex String (im Beispiel der für den größtmöglichen Wert). Für REG ADD musst du noch ein 0x davor setzen.
Grüße
rubberman
Ein REG_QWORD ist letztlich ein 64 Bit breiter Ganzahlwert. Mit einem Hex-String kommst du für REG ADD und Batch schon mal um einiges weiter. Testen kannst du ja in einem dafür angelegten Key, den du anschließend wieder löscht.
Beispiel:
set "strHex=FFFFFFFFFFFFFFFF"
reg add "HKCU\test" /v "test_value" /t REG_QWORD /d "0x%strHex%" /f
Grüße
rubberman
Hallo speedy26gonzales.
Ein kurzer Test macht das klar.
Wenn du einen REG_QWORD Wert exportierst, siehst du wie es aussehen muss.
Hier wird der Wert 0x1234567890ABCDEF repräsentiert. Das niedrigste Byte steht also am Anfang. Es sind immer alle 8 Bytes anzugeben
Für deinen Batch bedeutet das, du musst den Hex String ggf. mit vorangestellten Nullen auf 16 Stellen erweitern und ihn dann in Zweiersteps von hinten nach vorn in der Ausgabe arrangieren.
Beispiel:
Grüße
rubberman
Ein kurzer Test macht das klar.
Wenn du einen REG_QWORD Wert exportierst, siehst du wie es aussehen muss.
"test_value"=hex(b):ef,cd,ab,90,67,56,34,12
Für deinen Batch bedeutet das, du musst den Hex String ggf. mit vorangestellten Nullen auf 16 Stellen erweitern und ihn dann in Zweiersteps von hinten nach vorn in der Ausgabe arrangieren.
Beispiel:
set "strHex=A1B2AF"
set "strHex=0000000000000000%strHex%"
set "strHex=%strHex:~-16%"
>>"test.reg" echo "test_value"=hex(b):%strHex:~-2%,%strHex:~-4,2%,%strHex:~-6,2%,%strHex:~-8,2%,%strHex:~-10,2%,%strHex:~-12,2%,%strHex:~-14,2%,%strHex:~,2%
Grüße
rubberman
Hallo speedy26gonzales.
Wenn du dir die Hilfe zu SET ansiehst (
Zuerst werden 16 Nullen deinem Hex String vorangestellt. Um auf die exakte Länge von 16 Stellen insgesamt zu kommen, werden im Nachgang per
BTW: Sowohl bastlas Link, als auch mein und dein Lösungsweg zur Erstellung des Hex Strings funktioniert nur mit Zahlen, die die CMD auch als Zahlenwert verarbeiten kann. Im Klartext bedeutet das, ein ganzzahliger vorzeichenbehafteter Wert mit max. 32 Bit Breite (-2147483648 bis 2147483647). Dateien können aber gerne mal größer sein und auch ein REG_QWORD ist dafür gemacht einen nicht-vorzeichenbehafteten ganzahligen Wert von 64 Bit Breite (bis 18446744073709551615) anzunehmen. Dafür brauchst du aber eine Sonderbehandlung. Batch kann damit nur schrittweise rechnen.
Dieser Algorithmus aus Stringmanipulation und bitweiser Arithmetik könnte das und gibt dir auch gleich einen 16-stelligen Hex String aus:
Grüße
rubberman
Wenn du dir die Hilfe zu SET ansiehst (
SET /?
), wirst du die passenden Erklärungen finden.Zuerst werden 16 Nullen deinem Hex String vorangestellt. Um auf die exakte Länge von 16 Stellen insgesamt zu kommen, werden im Nachgang per
%strHex:~-16%
nur die letzten 16 Stellen des Variablenwertes wieder der Variablen zugewiesen. Der Rest funktioniert genauso.%strHex:~-2%
- die letzten beiden Zeichen%strHex:~-4,2%
- die ersten beiden Zeichen der letzten 4.- ...
%strHex:~,2%
- die ersten beiden Zeichen des Strings (auch als%strHex:~0,2%
falls es so deutlicher wird)
BTW: Sowohl bastlas Link, als auch mein und dein Lösungsweg zur Erstellung des Hex Strings funktioniert nur mit Zahlen, die die CMD auch als Zahlenwert verarbeiten kann. Im Klartext bedeutet das, ein ganzzahliger vorzeichenbehafteter Wert mit max. 32 Bit Breite (-2147483648 bis 2147483647). Dateien können aber gerne mal größer sein und auch ein REG_QWORD ist dafür gemacht einen nicht-vorzeichenbehafteten ganzahligen Wert von 64 Bit Breite (bis 18446744073709551615) anzunehmen. Dafür brauchst du aber eine Sonderbehandlung. Batch kann damit nur schrittweise rechnen.
Dieser Algorithmus aus Stringmanipulation und bitweiser Arithmetik könnte das und gibt dir auch gleich einen 16-stelligen Hex String aus:
@echo off &setlocal
set "strBigint=18446744073709551615"
:: set "strBigint=1311768467294899695"
:: set "strBigint=15"
setlocal EnableDelayedExpansion
set "strHex="
set "strPool=0123456789ABCDEF"
set "strBigint=00000000000000000000%strBigint%"
for /f "tokens=* delims=0" %%i in ("%strBigint:~-20,5%") do set "int4=%%i" &if not defined int4 set "int4=0"
for /f "tokens=* delims=0" %%i in ("%strBigint:~-15,5%") do set "int3=%%i" &if not defined int3 set "int3=0"
for /f "tokens=* delims=0" %%i in ("%strBigint:~-10,5%") do set "int2=%%i" &if not defined int2 set "int2=0"
for /f "tokens=* delims=0" %%i in ("%strBigint:~-5%") do set "int1=%%i" &if not defined int1 set "int1=0"
for /l %%i in (1,1,16) do (
set /a "int3 += (int4 & 15) * 100000 , int4 >>= 4"
set /a "int2 += (int3 & 15) * 100000 , int3 >>= 4"
set /a "int1 += (int2 & 15) * 100000 , int2 >>= 4"
set /a "x = int1 & 15 , int1 >>= 4"
for %%j in (!x!) do set "strHex=!strPool:~%%j,1!!strHex!"
)
endlocal &set "strHex=%strHex%"
echo %strHex%
pause
Grüße
rubberman
Hallo speedy26gonzales.
Solange du von ein paar hundert MB redest, ist alles OK. Und dass du mit negativen Zahlenwerten nichts anfangen kannst, war mir klar. Darum auch mein Vorschlag, zugleich nur im positiven Bereich zu arbeiten, den Bereich auszuschöpfen den das REG_QWORD bietet und ohne Umschweife einen 16-stelligen Hex String zu bekommen.
Dass du dich damit bei den möglichen Dateigrößen im Exabyte Bereich bewegst und das sicher etwas overkill ist, ist mir bewusst. Andererseits bist du auf der sicheren Seite.
Grüße
rubberman
Solange du von ein paar hundert MB redest, ist alles OK. Und dass du mit negativen Zahlenwerten nichts anfangen kannst, war mir klar. Darum auch mein Vorschlag, zugleich nur im positiven Bereich zu arbeiten, den Bereich auszuschöpfen den das REG_QWORD bietet und ohne Umschweife einen 16-stelligen Hex String zu bekommen.
Dass du dich damit bei den möglichen Dateigrößen im Exabyte Bereich bewegst und das sicher etwas overkill ist, ist mir bewusst. Andererseits bist du auf der sicheren Seite.
Grüße
rubberman
Hallo.
Scheint so
... sollte dann hoffentlich einigermaßen universal funktionieren.
Ersetze des
Scheint so
FOR /R "%SystemDrive:~,2%\" %%I IN ("*.exe") DO CALL :MAKERULE "%%I"
Zitat von @speedy26gonzales:
Habe das Skript jetzt mal so laufen lassen. Irgendwann bricht er mir ab mit dem Fehler "fehlender Operand" , was könnte das sein?
Das kannst du nur selbst herausfinden.Habe das Skript jetzt mal so laufen lassen. Irgendwann bricht er mir ab mit dem Fehler "fehlender Operand" , was könnte das sein?
Ersetze des
@echo off
mal durch ein @prompt $g
um den Befehlsprompt etwas übersichtlicher zu machen. Nun solltest du die Stelle im Batch sehen und auch welcher Wert warum fehlt.
Hallo bastla,
kann ich nur bestätigen. Dass die FOR /R Schleife auf Win7 auch ohne Backslash am Ende funktioniert, allerdings nicht. Ich gehe davon aus, dass sich speedy26gonzales bei seinen Tests auf Win7 bereits im Root des Laufwerks als Arbeitsverzeichnis bewegt hat. Anders kann ich mir das scheinbar unterschiedliche Verhalten nicht erkären.
Grüße
rubberman
kann ich nur bestätigen. Dass die FOR /R Schleife auf Win7 auch ohne Backslash am Ende funktioniert, allerdings nicht. Ich gehe davon aus, dass sich speedy26gonzales bei seinen Tests auf Win7 bereits im Root des Laufwerks als Arbeitsverzeichnis bewegt hat. Anders kann ich mir das scheinbar unterschiedliche Verhalten nicht erkären.
Grüße
rubberman
Hi,
eine potenzielle Fehlerquelle ist mir noch eingefallen (wenn auch unwahrscheinlich).
Durch das CALL werden mögliche Prozentzeichen im Dateinamen eleminiert, bzw. in Prozentzeichen eingefasste Teilstrings versucht zu Variablenwerten zu expandieren. Du solltest die Varablenzuweisung also bereits in die FOR Schleife auslagern.
Was für dich wesentlich interessanter sein dürfte, ist die Tatsache, dass du per FOR /R längst nicht alle Dateien erwischt. Im Grunde nur die, die du auch im Explorer siehst. Dateien, die das Attribut "hidden" oder "system" tragen, bleiben außen vor.
Folgender Änderungsvorschlag:
~~~ snip ~~~
~~~ snip ~~~
Die FOR /F Schleife hat zwar den Nachteil, dass der gesamte Ausgabestream des DIR Commands erst mal gepuffert wird und somit dein Batch etwas langsamer läuft, dafür erwischt du so jede Datei mit Endung .exe.
Zum "LastModified" kann ich dir leider keine Antwort geben
Teste einfach aus, ob der Wert notwendig ist.
Grüße
rubberman
Edit: Option /S vergessen
eine potenzielle Fehlerquelle ist mir noch eingefallen (wenn auch unwahrscheinlich).
Durch das CALL werden mögliche Prozentzeichen im Dateinamen eleminiert, bzw. in Prozentzeichen eingefasste Teilstrings versucht zu Variablenwerten zu expandieren. Du solltest die Varablenzuweisung also bereits in die FOR Schleife auslagern.
Was für dich wesentlich interessanter sein dürfte, ist die Tatsache, dass du per FOR /R längst nicht alle Dateien erwischt. Im Grunde nur die, die du auch im Explorer siehst. Dateien, die das Attribut "hidden" oder "system" tragen, bleiben außen vor.
Folgender Änderungsvorschlag:
~~~ snip ~~~
FOR /F "DELIMS=" %%I IN ('DIR /A-D /B /S "%SystemDrive:~,2%\*.exe"') DO (
REM Schreibe Pfadname
SET "FILEPATH=%%~I"
SET "FILESIZE=%%~zI"
SET "FILENAME=%%~nI
CALL :MAKERULE
)
CALL :CLEAN
EXIT /B
:MAKERULE
REM Erstelle eine GUID
Die FOR /F Schleife hat zwar den Nachteil, dass der gesamte Ausgabestream des DIR Commands erst mal gepuffert wird und somit dein Batch etwas langsamer läuft, dafür erwischt du so jede Datei mit Endung .exe.
Zum "LastModified" kann ich dir leider keine Antwort geben
Teste einfach aus, ob der Wert notwendig ist.
Grüße
rubberman
Edit: Option /S vergessen
Hi.
Ich kann nur mutmaßen. Um den Hash zu erstellen, muss die Datei Bit für Bit gescannt werden. Sollte die Datei vom System gesperrt worden sein, könnte der Zugriff das zu tun verwehrt sein.
Grüße
rubberman
EDIT:
Noch eine Möglichkeit:
Dein 3rd Party Tool kann nicht in die Datei schreiben, weil der Virenscanner gerade drauf hängt.
Kannst du die Ausgabe nicht ohne temporäre Datei gleich in einer FOR /F Schleife auswerten?
Zitat von @speedy26gonzales:
vermutlich kommt daher auch der Fehler dass er für manche Dateien keinen HASH erstellen konnte?
vermutlich kommt daher auch der Fehler dass er für manche Dateien keinen HASH erstellen konnte?
Ich kann nur mutmaßen. Um den Hash zu erstellen, muss die Datei Bit für Bit gescannt werden. Sollte die Datei vom System gesperrt worden sein, könnte der Zugriff das zu tun verwehrt sein.
Grüße
rubberman
EDIT:
Noch eine Möglichkeit:
Dein 3rd Party Tool kann nicht in die Datei schreiben, weil der Virenscanner gerade drauf hängt.
Kannst du die Ausgabe nicht ohne temporäre Datei gleich in einer FOR /F Schleife auswerten?
Hi.
Grüße
rubberman
Zitat von @speedy26gonzales:
Mir ist gerade ein noch gravierender Fehler aufgefallen.
Ich meinte bei dem Eintrag "SaferFlags" muss IMMER 0 drin stehen. Ist aber nur bei Pfadregeln so.
Wenn ich jetzt eine HASH-Regel über das SnapIn "gpedit.msc" erstelle schreibt er aber in dieses REG_DWORD etwas anderes wie "0". Vorallem erstellt er einen md5 UND sha1 Hash und je nachdem welcher HASH steht etwas anderes in dem "SaferFlags".
Bevor du mit dem ganzen Spaß angefangen hast, wirst du dich sicher informiert haben. Wo ist denn die Doku dafür zu finden?Mir ist gerade ein noch gravierender Fehler aufgefallen.
Ich meinte bei dem Eintrag "SaferFlags" muss IMMER 0 drin stehen. Ist aber nur bei Pfadregeln so.
Wenn ich jetzt eine HASH-Regel über das SnapIn "gpedit.msc" erstelle schreibt er aber in dieses REG_DWORD etwas anderes wie "0". Vorallem erstellt er einen md5 UND sha1 Hash und je nachdem welcher HASH steht etwas anderes in dem "SaferFlags".
Zitat von @speedy26gonzales:
Ich habe leider keine Möglichkeit hinbekommen es ohne das schreiben in eine Datei zu machen, war ewig lang dran dass es überhaupt geht.
So schwer kann das nicht sein.Ich habe leider keine Möglichkeit hinbekommen es ohne das schreiben in eine Datei zu machen, war ewig lang dran dass es überhaupt geht.
REM Erstelle eine GUID
:: cscript.exe //NoLogo uuid.vbs > "GUID.txt"
:: SET /P GUID=<GUID.txt
FOR /F %%i IN ('cscript //nologo uuid.vbs') DO SET "GUID=%%i"
REM Erstelle einen sha1 - HASH
:: fciv.exe -add "%~1" -sha1 > "HASH.txt"
:: FOR /F "skip=3 eol=; tokens=1 usebackq delims= " %%a IN ("HASH.txt") DO (SET HASH=%%a)
FOR /F "skip=3" %%a IN ('fciv.exe -add "%FILEPATH%" -sha1') DO SET "HASH=%%a"
rubberman
Hi,
das gibt mir schon mal einen kleinen Einblick.
"SaferFlags" ist natürlich nicht immer 0. Der Name sagt bereits aus, dass hier mehr als nur eine Information drin steckt. Normalerweise bedeutet "Flags", dass jedes Bit eine eigene (boolesche) Bedeutung hat.
Beispiel zur Verdeutlichung:
Ein Objekt hat 4 Eigenschaften (A, B, C, und D) die durch Flags repräsentiert werden sollen. Das kannst du also mit einem Wert von 4 Bit Breite darstellen, wobei du definiert hast, dass das niedrigste Bit die Eigenschaft A repräsentiert und das höchste die Eigenschaft D.
Siehst du nun als Flags bspw. die Zahl 12, ergibt sich folgendes:
Binäre Darstellung der 12 in 4 Bits ist 1100 => A ist falsch, B ist falsch, C ist wahr, D ist wahr.
Du hast nun 2 Möglichkeiten für dein Problem mit dem Wert "SaferFlags". Entweder du bekommst durch Tests heraus, dass der Wert im Fall von SHA1 Hashes immer gleich ist, oder du musst dir eine Doku suchen, die dir die Bedeutung der Flags im einzelnen erklärt.
Andere Sache:
Du erzeugst per Script eine GUID. Wie stellst du sicher, dass
Grüße
rubberman
das gibt mir schon mal einen kleinen Einblick.
"SaferFlags" ist natürlich nicht immer 0. Der Name sagt bereits aus, dass hier mehr als nur eine Information drin steckt. Normalerweise bedeutet "Flags", dass jedes Bit eine eigene (boolesche) Bedeutung hat.
Beispiel zur Verdeutlichung:
Ein Objekt hat 4 Eigenschaften (A, B, C, und D) die durch Flags repräsentiert werden sollen. Das kannst du also mit einem Wert von 4 Bit Breite darstellen, wobei du definiert hast, dass das niedrigste Bit die Eigenschaft A repräsentiert und das höchste die Eigenschaft D.
Siehst du nun als Flags bspw. die Zahl 12, ergibt sich folgendes:
Binäre Darstellung der 12 in 4 Bits ist 1100 => A ist falsch, B ist falsch, C ist wahr, D ist wahr.
Du hast nun 2 Möglichkeiten für dein Problem mit dem Wert "SaferFlags". Entweder du bekommst durch Tests heraus, dass der Wert im Fall von SHA1 Hashes immer gleich ist, oder du musst dir eine Doku suchen, die dir die Bedeutung der Flags im einzelnen erklärt.
Andere Sache:
Du erzeugst per Script eine GUID. Wie stellst du sicher, dass
- diese noch nicht in Verwendung ist,
- bei den hunderten von Dateien, die du verarbeitest, nicht 2x der gleiche Wert erzeugt wird?
Grüße
rubberman
Hi.
Fakt ist, da du vorhast erst alles in eine .reg Datei zu schreiben, statt gleich in die Registry, reicht es nicht nur auf das Vorhandensein in der Registry zu prüfen, du musst auch noch wissen, welche neue GUID du bereits generiert hast.
Zu welchem Ergebnis bist du eigentlich bzgl. "LastModified" gekommen? Notwendig oder nicht?
Falls notwendig, fürchte ich dass du nicht ohne ein weiteres 3rd Party auskommen wirst. Falls du nichts brauchbares finden solltest, biete ich an ein paar Zeilen in C für diesen Zweck zu schreiben.
Grüße
rubberman
Zitat von @speedy26gonzales:
Wie weiß denn das SnapIN was es schon an GUIDs gibt? Geht es darum um die GUIDs in der ganzen Registry oder nur in dem SAFER Unterverzeichniss? Weil ich steh sofern es dann mal laufen sollte auch vor dem Problem wie gehe ich bei einem Update eines einzelnen Programms vor. Dort sollte ich ja eigentlich die alte Regel löschen und eine neue erstellen.
Hmm, da von einer eindeutigen GUID die Rede war, würde ich mal auf alle GUIDs tippen. Ergo wird wohl das SnapIn im Vorfeld alle GUIDs auslesen und bei der Neuerstellung gegenprüfen. Ich weiß nicht wie Windows das intern regelt, ggf. sind auch nur bestimmte GUIDs für diesen Anwedungsbereich reserviert, was die Sache vereinfachen würde. Keine Ahnung, da sollten die Admins sich mal zu Wort melden (ich gehöre eigentlich zu denen, die auf die Arbeit von Admins angewiesen sind ).Wie weiß denn das SnapIN was es schon an GUIDs gibt? Geht es darum um die GUIDs in der ganzen Registry oder nur in dem SAFER Unterverzeichniss? Weil ich steh sofern es dann mal laufen sollte auch vor dem Problem wie gehe ich bei einem Update eines einzelnen Programms vor. Dort sollte ich ja eigentlich die alte Regel löschen und eine neue erstellen.
Fakt ist, da du vorhast erst alles in eine .reg Datei zu schreiben, statt gleich in die Registry, reicht es nicht nur auf das Vorhandensein in der Registry zu prüfen, du musst auch noch wissen, welche neue GUID du bereits generiert hast.
Zitat von @speedy26gonzales:
EDIT2: Was auch komisch ist, wenn ich ECHO OFF drin hab steigt es ab und an mal aus mit dem Fehler "Fehler Operand" oder "Find Path not". Sobald ich aber "@prompt $4" drin stehen hab läuft es immer durch ??? Muss man das verstehen ?
Das fällt entweder unter die Rubrik "dummer Zufall", oder du bekommst die Fehler einfach nicht mit, bei der Flut an Ausgaben bei eingeschaltetem Commandprompt. Läuft denn der Batch trotzdem weiter?EDIT2: Was auch komisch ist, wenn ich ECHO OFF drin hab steigt es ab und an mal aus mit dem Fehler "Fehler Operand" oder "Find Path not". Sobald ich aber "@prompt $4" drin stehen hab läuft es immer durch ??? Muss man das verstehen ?
Zu welchem Ergebnis bist du eigentlich bzgl. "LastModified" gekommen? Notwendig oder nicht?
Falls notwendig, fürchte ich dass du nicht ohne ein weiteres 3rd Party auskommen wirst. Falls du nichts brauchbares finden solltest, biete ich an ein paar Zeilen in C für diesen Zweck zu schreiben.
Grüße
rubberman
Hi.
Das von dir angesprochene M$ Tool kopiert die GUID in die Zwischenablage. Nicht besonders vorteilhaft um damit per Batch weiter zu arbeiten .
Wie du siehst, hat die Ausgabe aber nicht mal ansatzweise etwas damit zu tun, was du 1:1 verwerten könntest. Und bei dem Versuch daraus was Brauchbares zu machen, kommst du wieder über das 32 Bit Limit. Darum mein Angebot, dir das Leben etwas zu erleichtern.
EDIT:
sizedate.zip
Beispielaufruf und Sourcecode sind freilich dabei. Hoffe es hilft.
Grüße
rubberman
Zitat von @speedy26gonzales:
Ich hab dazu jetzt noch einen Artikel gefunden, werde aber trotzdem nicht ganz schlau daraus:
http://www.aboutvb.de/khw/artikel/khwcreateguid.htm .Es wird wirklich nirgends beschrieben dass vorher kontrolliert wird ob die GUID schon besteht. Die schreiben dass die Generierung wohl so sicher ist dass es jedesmal eine neue erstellt.
Dieser Code nutzt die COM Funktion CoCreateGuid, die wiederum die Remote Procedure Call Funktion UuidCreate aufruft. Das scheint der von M$ vorgegebene Weg zu sein. Aber, wie gesagt, du wendest die erzeugten GUIDs nicht sofort an. Ich weiß somit nicht, ob nicht trotzdem eine GUID mehrfach erzeugt wird.Ich hab dazu jetzt noch einen Artikel gefunden, werde aber trotzdem nicht ganz schlau daraus:
http://www.aboutvb.de/khw/artikel/khwcreateguid.htm .Es wird wirklich nirgends beschrieben dass vorher kontrolliert wird ob die GUID schon besteht. Die schreiben dass die Generierung wohl so sicher ist dass es jedesmal eine neue erstellt.
Das von dir angesprochene M$ Tool kopiert die GUID in die Zwischenablage. Nicht besonders vorteilhaft um damit per Batch weiter zu arbeiten .
Zitat von @speedy26gonzales:
Zu "LastModified" bin ich soweit gekommen dass der Wert wohl nicht zwingend gebraucht wird. Ich habe das Feld mal leer gelassen und gestern sowohl md5 wie auch sha1 HASHs erstellt. Mit dem Ergebnis dass danach die gesacnnten Dateien unter Zuschaltung der SAFER - Richtlinien ausführbar waren.
Mein Gedanke war evtl. das Datum der gescannten Datei auszulesen und in "LastModified" reinzuschreiben, aber obs Sinn macht?
Nein. Wenn schon, must du dort einen FILETIME Wert rein bringen. Außer WMIC fällt mir kein Befehl ein, der die Zeit beinah in dieser Genauigkeit rüber bringt, á laZu "LastModified" bin ich soweit gekommen dass der Wert wohl nicht zwingend gebraucht wird. Ich habe das Feld mal leer gelassen und gestern sowohl md5 wie auch sha1 HASHs erstellt. Mit dem Ergebnis dass danach die gesacnnten Dateien unter Zuschaltung der SAFER - Richtlinien ausführbar waren.
Mein Gedanke war evtl. das Datum der gescannten Datei auszulesen und in "LastModified" reinzuschreiben, aber obs Sinn macht?
set "fpath=c:\pagefile.sys"
WMIC DATAFILE WHERE "name='%fpath:\=\\%'" GET LastModified /value
EDIT:
sizedate.zip
SIZEDATE provides (1) the size [bytes] and (2) the last write
time [100-nanosecond intervals since 1/1/1601 UTC] of the
specified file.
They are retrievable as space separated 16 digits long
HEX strings.
Usage:
SIZEDATE "file path"
Zitat von @speedy26gonzales:
Aktuell erstelle ich pro Datei jeweils einen md5 und sha1 HASH. Jetzt frag ich mich wie ich dann die ganzen verschiedenen BATCH-Files steuern kann. Hab jetzt 16 verschiedene Batchs die ausgeführt werden sollen.
Alternativ könnte man eine "Steuer-Batch" machen die dann jeweils in den Such-Algo eine Variable mit Dateiendung und Pfad übergibt.
Nächster Gedanke war, ob ich die erstellten Daten in eine *.INF Datei schreibe (siehe die vorgefertigte weiter oben) und sie über die INF installiere.
Haha, ich glaube ich müsste vor deinem Rechner sitzen um zu verstehen, über was du da redest. 16 Batch Dateien? Da solltest du dir überlegen, ob du die parallel oder in Reihe schaltest, wenn du sie ausführst. Was ich meine ist, per START kannst du asynchron arbeiten. Das erspart dir Zeit, falls die Batchdateien nicht synchron nacheinander laufen müssen.Aktuell erstelle ich pro Datei jeweils einen md5 und sha1 HASH. Jetzt frag ich mich wie ich dann die ganzen verschiedenen BATCH-Files steuern kann. Hab jetzt 16 verschiedene Batchs die ausgeführt werden sollen.
Alternativ könnte man eine "Steuer-Batch" machen die dann jeweils in den Such-Algo eine Variable mit Dateiendung und Pfad übergibt.
Nächster Gedanke war, ob ich die erstellten Daten in eine *.INF Datei schreibe (siehe die vorgefertigte weiter oben) und sie über die INF installiere.
Grüße
rubberman
Hi.
Wie auch immer, habe dir auf dem selben Share noch eine guid.exe abgelegt, die die CoCreateGuid Funktion nutzt. Kannst selbst entscheiden ob du sie nutzen willst. Sie dürfte aber um Längen schneller sein, als das VBScript aufzurufen.
Hmm,ich kann dir schlecht sagen wie du das regeln sollst. Das ist schon deine Entscheidung.
Möglich wäre immerhin eine FOR Schleife, á la
Grüße
rubberman
Zitat von @speedy26gonzales:
Ich habe mich am WE nochmals mit jemand unterhalten, er meinte dass es wahrscheinlicher ist mehrmals im Lotto zu gewinnen wie 2x die gleiche GUID zu erstellen. Bei einer 128 Bit Zahl kann es fast nicht vorkommen. Somit wäre eine Überprüfung nicht unbedingt notwendig.
Über diese Statistik habe ich noch gar nicht nachgedacht. Das Argument einer Chance 1:340 Sextillionen ist in der Tat unschlagbar Ich habe mich am WE nochmals mit jemand unterhalten, er meinte dass es wahrscheinlicher ist mehrmals im Lotto zu gewinnen wie 2x die gleiche GUID zu erstellen. Bei einer 128 Bit Zahl kann es fast nicht vorkommen. Somit wäre eine Überprüfung nicht unbedingt notwendig.
Wie auch immer, habe dir auf dem selben Share noch eine guid.exe abgelegt, die die CoCreateGuid Funktion nutzt. Kannst selbst entscheiden ob du sie nutzen willst. Sie dürfte aber um Längen schneller sein, als das VBScript aufzurufen.
Zitat von @speedy26gonzales:
Bei meinen Tests ist mir aufgefallen dass der Wert "LastModified" gar nicht benutzt/gebraucht wird. So wie es aussieht ist er überflüssig.
Du kannst das Programm trotzdem nutzen. Da ich automatisch eine Reihe an Daten erhalte, habe ich auch gleich die Ausgabe der Dateigröße als 16 stelligen Hex String mit implementiert. Das erspart dir die Umrechnung Dec2Hex im Script.Bei meinen Tests ist mir aufgefallen dass der Wert "LastModified" gar nicht benutzt/gebraucht wird. So wie es aussieht ist er überflüssig.
Zitat von @speedy26gonzales:
Jetzt ist mein Gedanke ob es irgendwie möglich ist eine "Hauptbatch" zu machen von der ich die anderen steuern kann, oder sogar nur eine Batch habe in der ich Paramter übergebe?
Zitat von @speedy26gonzales:
Oder geht es vielleicht einfacher? Wie gesagt ich hab ca. 4 verschiedene Dateiendungen und insgesamt dann 4 verschiedene Verzeichnisse in denen automatisch gesucht werden soll.
Jetzt ist mein Gedanke ob es irgendwie möglich ist eine "Hauptbatch" zu machen von der ich die anderen steuern kann, oder sogar nur eine Batch habe in der ich Paramter übergebe?
Zitat von @speedy26gonzales:
Oder geht es vielleicht einfacher? Wie gesagt ich hab ca. 4 verschiedene Dateiendungen und insgesamt dann 4 verschiedene Verzeichnisse in denen automatisch gesucht werden soll.
Hmm,ich kann dir schlecht sagen wie du das regeln sollst. Das ist schon deine Entscheidung.
Möglich wäre immerhin eine FOR Schleife, á la
for %%i in ("c:\pfad1" "d:\pfad2" "x:\pfad3" "z:\pfad4") do (
pushd %%i
for /f "delims=" %%j in ('dir /a-d /b /s *.cmd *.exe *.ocx *.jar') do (
call :MAKERULE "%%j"
)
popd
)
Zitat von @speedy26gonzales:
Zum Asynchronen ausführen: Dürfte nicht so einfach gehen weil ich aus der Batch heraus das GUID Skript und einmal die fciv.exe um den Hash zu erstellen aufrufe. Wenn ich jetzt 2x darauf zugreife wird er mit ziemlicher Sicherheit abschmieren.
Nein, es sollte keine Probleme geben, Programme/Scripte mehrfach aufzurufen. Geht nur dann in die Grütze, wenn alle Instanzen versuchen in die selbe Datei zu schreiben, bzw aus der selben Datei zu lesen. Darum auch mein Vorschlag, die Ausgabe dieser Tools direkt in einer FOR /F Schleife zu verwursten.Zum Asynchronen ausführen: Dürfte nicht so einfach gehen weil ich aus der Batch heraus das GUID Skript und einmal die fciv.exe um den Hash zu erstellen aufrufe. Wenn ich jetzt 2x darauf zugreife wird er mit ziemlicher Sicherheit abschmieren.
Grüße
rubberman
Zitat von @speedy26gonzales:
EDIT: Was ich auch nicht verstehe: Der "Description" Eintrag steht zwar in er safer.reg wird aber nicht in die Registry importiert. Dort taucht er nicht mehr auf
EDIT: Was ich auch nicht verstehe: Der "Description" Eintrag steht zwar in er safer.reg wird aber nicht in die Registry importiert. Dort taucht er nicht mehr auf
Hi,
dürfte daran liegen dass Backslashes verdoppelt werden müssen.
>>"%Speicherpfad%" ECHO "Description"="%FILEPATH:\=\\%"
Grüße
rubberman
Hi,
der Aufruf war nur beispielhaft mit der Datei als Argument. Wie schon geschrieben, gibt es dabei eine potenzielle Fehlerchance, im Fall dass irgendwo im Pfad oder Dateinamen Prozentzeichen vorkommen. Natürlich kannst du auch hier die Variablenwerte vorher zuweisen.
Grüße
rubberman
der Aufruf war nur beispielhaft mit der Datei als Argument. Wie schon geschrieben, gibt es dabei eine potenzielle Fehlerchance, im Fall dass irgendwo im Pfad oder Dateinamen Prozentzeichen vorkommen. Natürlich kannst du auch hier die Variablenwerte vorher zuweisen.
for %%i in ("c:\pfad1" "d:\pfad2" "x:\pfad3" "z:\pfad4") do (
pushd %%i
for /f "delims=" %%j in ('dir /a-d /b /s *.cmd *.exe *.ocx *.jar') do (
set "FILEPATH=%%~j"
set "FILESIZE=%%~zj"
set "FILENAME=%%~nj"
call :MAKERULE
)
popd
)
Grüße
rubberman
Hi.
Ja, liegt am Wechsel der Arbeitsverzeichnisse. Dass lässt sich leicht beheben, indem man PUSHD und POPD mit dem DIR verknüpft. Somit findet die weitere Verarbeitung wieder im ursprünglichen Arbeitsverzeichnis statt.
Grüße
rubberman
Ja, liegt am Wechsel der Arbeitsverzeichnisse. Dass lässt sich leicht beheben, indem man PUSHD und POPD mit dem DIR verknüpft. Somit findet die weitere Verarbeitung wieder im ursprünglichen Arbeitsverzeichnis statt.
for %%i in ("c:\pfad1" "d:\pfad2" "x:\pfad3" "z:\pfad4") do (
for /f "delims=" %%j in ('pushd %%i ^& dir /a-d /b /s *.cmd *.exe *.ocx *.jar ^& popd') do (
set "FILEPATH=%%~j"
set "FILESIZE=%%~zj"
set "FILENAME=%%~nj"
call :MAKERULE
)
)
rubberman
Die Variable wird ja nicht überschrieben?
Nicht solange du sie nicht explizit überschreibst.Macht es Sinn anstatt C:\Pfad1 , Registrierungspfade oder Umgebungsvariablen zu benutzen?
Ich sehe kein Problem in der Verwendung von Umgebungsvariablen.Was du mit "Registrierungspfade" meinst, müsstest du aber noch mal erläutern. Willst du DIR auf die Registry loslassen? Das funktioniert natürlich nicht. Dafür gibt es REG QUERY.
Grüße
rubberman