Wenn 4eh Datei = 0b.tmp -> Ende

Hier könnt ihr sowohl zur x86 Architektur als auch zu Win32ASM Fragen stellen.

Moderatoren: crack, Marwin, Krüsty

Darthshoot
Member
Beiträge: 23
Registriert: Dienstag 11. Juli 2006, 20:25

Wenn 4eh Datei = 0b.tmp -> Ende

Beitrag von Darthshoot » Dienstag 11. Juli 2006, 20:32

Hallo!

Ich arbeite mit TASM 5.0.

Ganz kurz und knackig:
Es werden sehr dubiose .tmp Dateien in System32 kopiert.
Dagegen habe ich etwas gebaut, was ständig alle .tmp Dateien in System32 löscht. (Mit Assembler.) Allerdings darf 0b.tmp auf keinen Fall gelöscht werden, da diese Datei von einem Programm von mir gebraucht wird.

Das System arbeitet so: Es sucht sich immer eine andere .tmp Datei und löscht sie. Also mit 4eh + 4fh. Jetzt müsste irgendwie sobald das Programm eine Datei gefunden hat, es erst auf den Namen überprüfen. Wenn der Name 0b.tmp ist, dann soll er beenden. Wenn es nicht ist, soll er es löschen.

Also wie vergleiche ich nun eine gefundene Datei mit einem Namen?

Danke im Voraus.
MfG Darthshoot
Hallo! Hallo!

Benutzeravatar
crack
Administrator
Beiträge: 280
Registriert: Dienstag 21. Dezember 2004, 15:02
Wohnort: 53783 Eitorf
Kontaktdaten:

Beitrag von crack » Donnerstag 13. Juli 2006, 10:15

Hi Darthshoot,

Nun, eigentlich sollten .tmp Dateien im Verzeichniss C:\TEMP landen ...
egal, was Du benötigst wäre ein Parser, schau dir mal dieses Beispielan, vielleicht kannst Du daraus was basteln. 8)
mit freundlichen grüssen,
with best regards,

crack

Darthshoot
Member
Beiträge: 23
Registriert: Dienstag 11. Juli 2006, 20:25

Beitrag von Darthshoot » Donnerstag 13. Juli 2006, 13:22

Hmm also mit anderen Worten, würde das hier:

Code: Alles auswählen

0bSearch:
	mov si, offset DetecT
	mov di, [bp+offset NDTA+1eh]
FirstByte:
	es:cmpsb
	je FirstByte
	dec si
	es:lodsb
	cmp al, '@'
	je NextFileB
Alle .tmp Dateien normal weiterlaufen, nur bei dem, was in DetecT drin steht, sucht er sich ein neues? P.S. NextFileB könnt ihr euch ja alle denken, dass dabei eine neue Datei gesucht wird.

Also aufjeden Fall sagt er, dass er nicht mit 2 es: zurecht kommt.

Was kann ich da tun? :/
Hallo! Hallo!

Benutzeravatar
crack
Administrator
Beiträge: 280
Registriert: Dienstag 21. Dezember 2004, 15:02
Wohnort: 53783 Eitorf
Kontaktdaten:

Beitrag von crack » Donnerstag 13. Juli 2006, 13:34

Ja, bei den Stringbefeflen CMPSB und LODSB sind die Segmentpräfixe implimentiert:

LODSB lädt ein Byte von DS:SI in AL und inkrementiert SI um eins.

CMPSB Vergleicht zwei Strings Byteweise, und zwar DS:SI und ES:DI ...
Da die Segmentpräfixe in den Anweisungen implimentiert sind, soll-braucht- und darf man Sie im Code nicht nocheinmal verwenden ...

[Literaturempfehlung: Joachim Rohde; Assembler GE-PACKT ISBN 3-8266-0786-4]
mit freundlichen grüssen,
with best regards,

crack

Darthshoot
Member
Beiträge: 23
Registriert: Dienstag 11. Juli 2006, 20:25

Beitrag von Darthshoot » Donnerstag 13. Juli 2006, 14:09

Hmm und was mach ich jetzt mit anderen Worten?
Hallo! Hallo!

Benutzeravatar
crack
Administrator
Beiträge: 280
Registriert: Dienstag 21. Dezember 2004, 15:02
Wohnort: 53783 Eitorf
Kontaktdaten:

Beitrag von crack » Donnerstag 13. Juli 2006, 14:17

versuch doch mal dein Programm zu compilieren ohne das es: vor den Anweisungen...
mit freundlichen grüssen,
with best regards,

crack

Darthshoot
Member
Beiträge: 23
Registriert: Dienstag 11. Juli 2006, 20:25

Beitrag von Darthshoot » Donnerstag 13. Juli 2006, 14:24

Code: Alles auswählen

NSearch:
	mov si, offset DetecT
	mov di, [bp+offset NDTA+1eh]
FirstByte:
	cmpsb
	je FirstByte
	dec si
	lodsb
	cmp al, '@'
	je NextFileB

DetecT	db '0b.tmp@'
Verschohnt 0b.tmp nicht.
Hallo! Hallo!

Benutzeravatar
crack
Administrator
Beiträge: 280
Registriert: Dienstag 21. Dezember 2004, 15:02
Wohnort: 53783 Eitorf
Kontaktdaten:

Beitrag von crack » Donnerstag 13. Juli 2006, 14:52

Also auf Anhieb sehe ich keinen Fehler, schick mir doch mal deinen gesammten Quellcode gezipt zu, das ich das ganze mir mal betrachten kann.
mit freundlichen grüssen,
with best regards,

crack

Darthshoot
Member
Beiträge: 23
Registriert: Dienstag 11. Juli 2006, 20:25

Beitrag von Darthshoot » Donnerstag 13. Juli 2006, 15:04

Nein halt! Ich habs! :D Es geht schon, aber irgendwo ist hier:

Code: Alles auswählen

NSearch:
	mov si, [bp+offset DetecT]
	mov di, [bp+offset NDTA+1eh]
FirstByte:
	cmpsb
	je FirstByte
	dec si
	lodsb
	cmp al, '@'
	je Ende
eine Endlosschleife eingebaut. Kannste mir noch kurz sagen wo? Das wäre klasse.
Hallo! Hallo!

Benutzeravatar
crack
Administrator
Beiträge: 280
Registriert: Dienstag 21. Dezember 2004, 15:02
Wohnort: 53783 Eitorf
Kontaktdaten:

Beitrag von crack » Donnerstag 13. Juli 2006, 15:20

Oh, kannst Du evtl versuchsweies eine Ausgaberoutine 'zwischenschalten? evtl. müsstest Du das etwas umbauen ... oder mittels Debug . Trace einmal die Schleife 'zu Fuss' durchwandern, um festzustellen ob Di und Si weitergezählt werden, und in der richtigen Richtung zählen ... das 'Direction Flag' des 'Machine Status Register' stellt das ein: STD (Setdirection) lässt DI und SI inkrementieren (aufwärtszählen) und CLD (clear Direction) entsprechen abwärts, vielleich liegt das Problem da irgendwo ...
mit freundlichen grüssen,
with best regards,

crack

Darthshoot
Member
Beiträge: 23
Registriert: Dienstag 11. Juli 2006, 20:25

Beitrag von Darthshoot » Donnerstag 13. Juli 2006, 15:41

Oje :/ ich bin noch ein Newbie in Assembler. Kannst du mir das als Hilfe mal umbauen? Das ist noch alles Neuland für mich. Das wäre großeklasse :D

Momentmal! Lässt sich das ganze nicht irgendwie loopen, sodass einfach eine bestimmte Anzahl an Bytes verglichen werden? (also 6 Bytes, wegen 0b.tmp) Dann würde man sich eigendlich das @Verfahren sparen und das Endlosschleifenproblem wäre ebenfalls gelößt. Allerdings gibt es da so ein Problem. Irgendwie bekomme ich keine Schleifen mehr hin seit neustem... Er loopt einfach unendlich. Ich stelle mir das ganze so vor:

Code: Alles auswählen

NSearch:
mov si, [bp+offset DetecT]
mov di, [bp+offset NDTA+1eh]
mov cx, 6
FirstByte:
cmpsb
jc NextFileB
loop FirstByte
Zuletzt geändert von Darthshoot am Donnerstag 13. Juli 2006, 15:53, insgesamt 2-mal geändert.
Hallo! Hallo!

Benutzeravatar
crack
Administrator
Beiträge: 280
Registriert: Dienstag 21. Dezember 2004, 15:02
Wohnort: 53783 Eitorf
Kontaktdaten:

Beitrag von crack » Donnerstag 13. Juli 2006, 15:50

Ja, so könnte man das machen, sollte auch funktionieren ...
mit freundlichen grüssen,
with best regards,

crack

Darthshoot
Member
Beiträge: 23
Registriert: Dienstag 11. Juli 2006, 20:25

Beitrag von Darthshoot » Donnerstag 13. Juli 2006, 15:56

Code: Alles auswählen

NSearch:
	mov si, [bp+offset DetecT]
	mov di, [bp+offset NDTA+1eh]
	mov cx, 6
FirstByte:
	cmpsb
	jc Routine
	loop FirstByte
Die Endlosschleife ist weg. Dafür löscht er 0b.tmp ^^
Hallo! Hallo!

Darthshoot
Member
Beiträge: 23
Registriert: Dienstag 11. Juli 2006, 20:25

Beitrag von Darthshoot » Donnerstag 13. Juli 2006, 16:02

Ich habs mit diesem Verfahren gelößt:

NSearch:
mov si, [bp+offset DetecT]
mov di, [bp+offset NDTA+1eh]
FirstByte:
cmp di, si
jc Routine
jmp NextFileB
Hallo! Hallo!

Benutzeravatar
crack
Administrator
Beiträge: 280
Registriert: Dienstag 21. Dezember 2004, 15:02
Wohnort: 53783 Eitorf
Kontaktdaten:

Beitrag von crack » Donnerstag 13. Juli 2006, 16:04

Äh, was kommt unter 'loop FirstByte' ...
... weil diese Operation muss ja in zwei verschiedenen Aussprungbedingungen enden:
1. beide Strings sind bis zum Schluss 100% Identisch, und
2. beide String sind nicht 100% Identisch ...
... deswegen hatte ich auch damals dieses Konstrukt mit dem '@' am Ende entworfen das funktioniert ja so:
mit CMPSB werden die Strings verglichen, bis der erste Unterschied gefunden wurde, danach wurde geprüft ob dieser erste Unterschied das '@' Zeichen am Ende des Vergleichsstrings ist, wenn Ja, dann Aussprung zur 'Seite' 'Ok, der String wurde verifiziert' wenn Nein, sind beide Strings nicht identisch, und es wird zu einer anderen Programmstelle gesprungen ...
mit freundlichen grüssen,
with best regards,

crack

Antworten