Heiner Schneegold Am Steinert 8 97246 Eibelstadt (Deutschland) Tel: 09303/99104 (19.00 - 20.00 Uhr) EMail: Heiner.Schneegold@t-online.de ab VT2.42 ist die Parameterabfrage fuer die Verwendung in der startup-sequence entfernt !!!!! Begruendung: das Prg ist inzwischen viel zu gross fuer die Verwendung in der startup-sequence WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG Entgegen anderslautenden Geruechten ist VT KEIN Hinter- grundprogramm (???). Der Speicherverbrauch ist viel zu hoch. Sie starten bitte VT, testen ihren Speicher und die Disks. Bitte sind Sie so vernuenftig und sehen Sie ein, dass nicht gleichzeitig ein anderes von Ihnen gestartetes Programm, Schreibzugriffe auf die gerade zu testende Disk ausfuehren darf. Es sollte bekannt sein, dass jeder Schreibzugriff die Disk- struktur veraendert ( unter Umstaenden wird auch der BitMapBlock verlagert !!). WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG 2: Mit KS2.04 koennen Hardlinks (mit makelink) und Softlinks (z.B. mit Assembler) erzeugt werden. VT kommt mit Hardlinks unter KS1.3 und KS2.04 zurecht. Softlinks verkraftet VT nur ab KS2.04 . Mit KS1.3 stuerzt VT beim File- u. BlockITest mit GURU B ab. Die Links werden im FileRequester aber auch mit KS1.3 erkannt und ohne GURU ausgewiesen (andere Routine). Hinweis: 26.01.92 Im Januar 92 sind mehrere Anrufe gekommen und zwei Disks geschickt worden, bei denen der BlockKetteTest den Rueckzeiger auf den Fileheader als falsch erkennt. Nach Commodore zeigt beim OFS ein Langwort im DataBlock auf den Fileheaderblock zurueck. Bei diesen Disks zeigt das Langwort auf den EIGENEN Datenblock. Durch die doppelte Verkettung sind diese Files meist lauffaehig. Ein Einzelfilecopy der ganzen Disk behebt diesen Fehler. Versuche mit dem CopyBefehl der neuen WB und ROM KS2.04 ergaben, dass das Betriebssystem mit OFS WEITERHIN diesen Rueckzeiger setzt !!!! Es muss also ein UtilityPrg im Umlauf sein, das diesen Fehler erzeugt. Moeglichkeiten: - einfacher CopyBefehl (unwahrscheinlich) - DiskOptimizer - DirUtility mit eingebautem Copybefehl - DiskCopyPrg mit Option Dir-orientiert - oder eine Moeglichkeit, die ich vergessen habe Wer kennt ein Prg ????? Erste Antworten Feb. 92: alle nennen den gleichen DiskOptimizer-Namen ( kein PD !!!) XCopy 5.2 Fehler (Original ??): Anfang April habe ich einige Disketten bekommen, mit der Bitte, sie zu ueberpruefen. Jeweils bei einem File hat VT bei dem Block-Ketten- Test bad T.Data ausgegeben (d.h. die Kennung eines DatenBlocks = $8 stimmte nicht ). Es war IMMER der Block 2 (also gleich nach dem BB). Telephonische Rueckfragen ergaben, dass der Xcopy-BB IMMER nach- traeglich installiert wurde. Ich vermute nun, dass anstatt 1024 Bytes in einer Schleife 1028 Bytes zurueckgeschrieben werden. Bitte fuehren Sie mit ihrem Original-Xcopy einen entsprechenden Test durch (WICHTIG: Block 2 MUSS von einem File belegt sein). Falls Sie danach $0 anstatt $8 im 2.Block 0.Langwort finden, informieren Sie bitte den Hersteller und MICH . HinweisA Juli 92: (N) = nach meiner Meinung ein Nutzprg, das Vektoren verbiegt, die auch von Viren verbogen werden. (H) = nach meiner Meinung ein harmloser BB (L) = nach meiner Meinung ein BB der mit KS2.04 und/oder 68030 nicht sauber laeuft HinweisB Juli 92: Falls Sie bei einer Disk Fehlermeldungen bekommen, probieren Sie die Disk mit ihrem 2.LW. Oder machen Sie ein einfaches diskcopy (bitte KEIN nibblecopy). Oder verwenden Sie turbobackup. Es kann sein, dass die kopierte Disk KEINE Fehler mehr zeigt. Allerdings sollten Sie dann bedenken, dass ein LW sich verstellt hat. Ent- weder ihr LW oder das LW auf dem die "OriginalDisk" erzeugt wurde. Hinweis Aug 92: Im Icon ist ein Stack von 4096 eingetragen. Dies kann fuer eine grosse Festplatte bei FileTest zu wenig sein. Tragen Sie dann bitte 8192 oder mehr ein. Beim Start von VT aus Shell muss dann zuerst der Stack-Befehl eingegeben werden. Danke Sollte behoben sein: 17.08.92 Hinweis 19.11.92: Es ist ein XCopy 6.5 pro (Laenge: 27196) aufge- taucht, das beim Start im Cli zuerst in grossen Buchstaben SARON usw. ausgibt. Nach meiner Meinung enthaelt das File KEINEN Virus. Hinweis 20.11.92: Es ist ein MagiCall (Laenge: 149664) aufgetaucht, an das am Anfang ein einfacher Hunk (mit Namen) angehaengt wur- de. Wenn Sie MagiCall aus dem Cli starten, passiert nichts. Starten Sie dagegen mit dem Icon, so beschwert sich MagiCall mit DisplayAlert ueber die falsche Hunkanzahl. Das Programm selbst enthaelt nach meiner Meinung KEINEN Virus. Nachtrag 05.12.92: Es handelt sich um ein HunkLab-Prg. s.u. Hinweis 05.12.92: Ich gehe davon aus, dass die Gruppe (falls es sie gibt) nicht ihre eigene Disk verseucht ??? Falls Sie dies beim Booten einer Disk sehen, so ist HOECHSTE Vorsicht geboten: THE IMMORTAL _ _ /\ /\ ___ ______ ____)\ ____ ____/\ ____)\ /__\ / \ /\ \_ \\ // __ // __ \\ _ \\ / _____/ \/ \ / /_\ // /__\// / \/ \ / \\ / / / \ \ // _\\// _/ / \ _ \/ \\/ / \ \ // / V / \__/\ \__)\ / \ \ \ /\ / \ / : \ \ \\ \ \ ____\/ \/ \/ \_ ____ /____ / \ _____ \ \( V V \/ \/ V \/ | | : . is back with : it's latest . . release ! Utility Dream #32 RELEASED IN THE END OF SEPTEMBER 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |HOLD BOTH BUTTONS TO SELECT A FILE WITHOUT RELOADING THE BOOT MENU!| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auf der Disk, die mir zugeschickt wurde, sind mehrere Prg.e im Unterverzeichnis PRG mit PP4.0 gepackt. Wenn Sie diese Prg.e ent- packen, werden Sie feststellen, dass an mehrere Prg.e das AIBON- Virus gelinkt ist (z.B. an DW). Nach Aussagen im mitgelieferten Text-File gibt es ein Programm Hunklab, welches dafuer verant- wortlich ist. Dieses Programm soll bei XCopy mitgeliefert werden. Hunkbeginn: 0000: 000003f3 00000000 00000009 00000000 ................ 0010: 00000008 0000002b 00000020 000001c4 .......+... .... 0020: 00000003 000024bd 00000d5a 00000357 ......$....Z...W 0030: 000004c1 40000012 000003e9 0000002b ....@..........+ 0040: 4feffe08 48e7fffe 227afff2 d3c9d3c9 O...H..."z...... 0050: 58892f49 003c4cdf 7fff4e75 556e6974 X./I.File->Sp) und ersetzen df0: durch CD0: . Dann sollte ein Inhaltsverzeichnis erscheinen. Mit DirFTest koennen Sie jetzt die ganze CD oder einzelne Unterverzeichnisse testen. Hinweis Maerz 95: Wenn Sie ihre Festplatte mit DiskExpander gepackt haben, dann schalten Sie bitte vor dem Test mit VT im DiskExpander Exam und Exnext AUS. Hinweis 19.04.96 nach Telephonanruf: Der Hintergrundchecker in VT findet immer wieder den HappyNew- Year96 im Speicher. Nach dem Loeschen im Speicher taucht er NICHT mehr auf bis zum NAECHSTEN Reset. Der Filetest mit VT und anderen Antivirusprogrammen verlaeuft immer negativ. Loesung: In den Rigid-Bereich wurde ein FastFileSystem eingespielt, das mit dem HNY96 verseucht war. Alle Filetests MUSSTEN deshalb negativ verlaufen. Untersuchen Sie deshalb bitte ab und zu auch mit VT den Rigid-Bereich Ihrer Festplatte. - z.Zyl - phys. 0 - gewuenschte Festplatte - mit Cursortastem BIS ZUM ENDE des Rigid-Bereichs durch- blaettern. Ich bedanke mich bei dem genervten User, der Zeit UND auch VIEL Geld (Fernzone) geopfert hat, bis wir gemeinsam die Loesung gefunden hatten. Dieser Vorgang ist AUCH auf ANDERE Viren anwendbar !!!!! Hinweis 20.06.96 nach Telephonanruf: WICHTIG !!!!! BITTE fertigen Sie fuer das Antivirusprogramm Ihrer Wahl IMMER !!! SOFORT !!!! eine Bootdisk an. Begruendung: Viele neuere Linkviren (Anrufgrund war Hitch-Hiker-2) haben KEINE Laengen- oder Buchstabenbeschraenkung mehr oder die Routine arbeitet auf 68030/40/60 nicht sauber. Wenn Sie nun auf einer verseuchten HD versuchen, Ihr gewuenschtes AV-Prg.-LHA-Archiv zu entpacken, wird SCHON beim Schreiben das AVPrg verseucht. Danach versuchen Sie das AVPrg. zu starten und muessen erleben, dass das AVPrg. er- kennt, dass es veraendert wurde, und deshalb die Arbeit einstellt. Mit einer SCHREIBGESCHUETZTEN AV-Bootdisk koennte das NICHT passieren. Hinweis 97-05-09: Da einige Linkviren inzwischen jeden Ladevorgang auf einen File- namen ueberwachen, der mit "v" oder "V" beginnt, waere es vielleicht sinnvoll, VT privat (Weitergabe bitte weiterhin als VTx.yz) umzu- benennen. Sonst koennten Sie glauben, ihr System waere sauber, nur weil sich das Virusteil schnell abgeschaltet hat. Hinweis 98-12-20: Bei UAE zeigt VT nicht immer alle Laufwerke an. Verwenden Sie deshalb bitte fuer Filetest das "Sp-File-Sp"-Gadget. letzte Aenderung: 2000-06-24 Aenderungen seit VT3.16 VT-Laenge: 392812 Bytes WICHTIG !!!!! Um Linkviren SICHER zu finden, die sich HINTER den 1.Hunk linken, MUESSEN Sie FileTest aufrufen !!!! - STD-L700-Trojan 2000-Juni - MOTABA-3-LVirus 2000-Juni - Port-4097-Trojan 2000-Juni - Port-2001-Trojan 2000-Juni Programmvoraussetzungen: - fuer den PrgAblauf werden ueber 2 Mb Mem (Fast und Chip) benoetigt: z.B. fuer - 720Kb eigenes Prg - 20Kb Hauptfenster (Betriebssystem) - 15-20Kb fuer Requester (Betriebssystem) - 5Kb kurzfristig fuer neu eingelegte Disk (Betriebssystem) - 40Kb FileRequester - 64Kb BlockSizeBuffer wg. HDToolBox (Blockgroesse bis 32Kb) - usw. Hinweis: Falls Probleme mit nur 2Meg-Speicher (z.B. A1200), bitte startup-sequence abbrechen und OHNE loadwb aus cli starten. Es kann aber auch sein, dass der Speicher zu sehr fragmentiert ist. Dann hilft nur noch ein Tastaturreset oder KReset (VT-Ut). Falls es dann immer noch nicht geht: Oeffnen Sie ein Cli-Fenster Formatieren Sie ein Disk mit format drive df0: name "VTTest3" (return) Geben Sie bitte danach ein install df0: (return) Kopieren Sie NUR VT3.xy auf diese Disk. (xy steht fuer eine Zahl) Booten Sie von dieser Disk und geben Sie bitte im Cli-Fenster ein VT3.xy (return) Jetzt sollte es gehen. Mit 2MB Speicher sollten die Probleme geringer sein. - KickRom V1.2 oder V1.3 - laeuft mit Kick V1.3 auf A3000 - sollte mit 37.175 auf A3000 laufen = ROM - sollte mit 40.068 auf A3000 laufen - sollte mit 40.070 auf A3000 laufen = PROMS (KS3.1) - sollte mit KS2.04 auf A500Plus laufen = ROM - sollte mit 37.175 auf A2000 laufen = ROM - sollte mit 40.063 auf A2000 laufen = PROM (KS3.1) - sollte mit KS2.05 auf A600 laufen (37.300) = ROM - sollte mit KS2.06 auf A600HD laufen (37.350) = ROM - sollte mit 40.063 auf A600 laufen = ROM (KS3.1) - sollte mit Commodore-CDTV laufen (getestet KS1.3) - 37.175 ROM - 37.300 ROM - 37.350 ROM - sollte mit KS39.106 auf A4000 laufen = ROM - sollte mit KS40.068 auf A4000 laufen - sollte mit KS40.070 auf A4000 laufen = PROMS (ohne NCR) - sollte mit KS40.070 auf A4000T laufen = EPROMS (mit NCR) - sollte mit KS39.106 auf A1200 laufen = ROM - sollte mit KS40.068 auf A1200 laufen = PROMS - sollte mit KS40.056 auf CD32 laufen = ROM - laeuft n i c h t mit SKick, ZKick, LKick auf A2000 - laeuft n i c h t mit Kickit B1-Bx auf A2000 - mit gepatchten Kickepromversionen erwarte ich Probleme - mit KickDisk V1.2 Vers.33.166 laeuft mein Prg. nicht (Trackdisk.device liegt an anderer Stelle) Hinweis: OHNE Festplatte zeigt das BootIntro bei mir 40.063 !! ^ - PalScreen (geht nicht immer, ist Commodore bekannt !!) bei KS1.2 u. 1.3 bei NTSC Angebot Kreset oder Interlace aus CLI sollte moeglich sein: VTx.yz -i = 640x400 NTSC Interlace (ohne Flickerfixer mit PAL unbrauchbar) VTx.yz -p = 640x256 PAL ;ab KS2.04 !!!!!!! VTx.yz -Pro = 640x480 Productivity (Sie brauchen mind. ECS o. AA mind KS2.04 und einen geeigneten Monitor. Haben Sie den ??? Dann kann man es mit Euro72 oder Prod anschauen. VTx.yz -Dbl = DblPAL VTx.yz -DbN = DblNTSC 640x400 VTx.yz -E72 = EURO72 640x400 VTx.yz -Pi4 = Picasso 640x480 VTx.yz -Pi6 = Picasso 800x600 VTx.yz -Pi7 = Picasso 1024x768 VTx.yz -P10 = Picasso 1280x1024 VTx.yz -Pc4 = Piccolo 640x480 VTx.yz -Pc6 = Piccolo 800x600 VTx.yz -Pc7 = Piccolo 1024x768 VTx.yz -Pc1 = Piccolo 1280x1024i VTx.yz -S72 = SUPER72 800x600i VTx.yz -C48 = CyberVision 640x480 VTx.yz -C60 = CyberVision 800x600 VTx.yz -PWB = Versuch mit Workbenchgroesse zu oeffnen VTx.yz -P94 = Picas96 640x480 VTx.yz -P96 = Picas96 800x600 VTx.yz -P97 = Picas96 1024x768 VTx.yz -P91 = Picas96 1280x1024 VTx.yz -CV6 = CVPPC 800x600 VTx.yz -CV7 = CVPPC 1024x768 falls ueber Icon gestartet: - ToolTypes (SCREEN=Hex_0x40120000) ermitteln Sie mit z.B. getmodeid die ID und wandeln Sie die Dez-Zahl in eine 8-stellige Hex-Zahl um (SCREEN=NTSC) (SCREEN=PAL) (SCREEN=PROD) (geklammert=nichtaktiv) (SCREEN=DblPAL) (SCREEN=DblNTSC_640x400) (SCREEN=EURO72_640x400) (SCREEN=Picasso_640x480) (SCREEN=Picasso_800x600) (SCREEN=Picasso_1024x768) (SCREEN=Picasso_1280x1024) (SCREEN=Piccolo_640x480) (SCREEN=Piccolo_800x600) (SCREEN=Piccolo_1024x768) (SCREEN=Piccolo_1280x1024i) (SCREEN=S72_800x600i) (wollte jemand fuer ScanD.) (SCREEN=CyberVis_640x480) (SCREEN=CyberVis_800x600) (SCREEN=Picas96_640x480) (SCREEN=Picas96_800x600) (SCREEN=Picas96_1024x768) (SCREEN=Picas96_1280x1024) (SCREEN=CVPPC_800x600) (SCREEN=CVPPC_1024x768) (SCREEN=CVPPC_1280x1024) (SCREEN=Altais_640x480) (SCREEN=Altais_800x600) (SCREEN=Altais_1024x768) (SCREEN=PubWB) ab KS2.04 versucht Groesse und Mode zu uebernehmen. Da zur Auswertung VTxyz.info geladen werden muss, entfernen Sie bitte die VT-Disk erst nach dem Erscheinen des VEKTOR-Bildschirms. Danke Beachten Sie bitte die Schreibweise !!! . Sind alle Werte geklammert, versucht VT Pal-Aufloesung. Sollte ein "netter" PD-Vertreiber die Eintraege nicht uebernommen habe, so koennen Sie selbst einen Ein- trag auf der WB vornehmen. Klicken Sie aufs Icon und dann in WB-Leiste auf INFO. Vergessen Sie das Abspeichern nicht. Hinweis zu Picasso: Die IDs gehoeren zur village.library V2.57 (20.12.93) auf Disk Jan 94. Nach Fremdaussagen haben die IDs frueher schon gewechselt. Falls Sie aeltere Libs haben, sollten Sie updaten, da vielleicht andere IDs verwendet werden. Falls Sie neuere Libs haben, bitte ich Sie um einen entsprechenden Hinweis. Danke Hinweis: A4000 (A1200) + 1084S Bitte entfernen Sie aus devs/monitors alle Typen ausser PAL und NTSC. Sie koennen die anderen Typen sowieso nicht verwenden. Oder stellen Sie in Prefs/Icontrol "Mode uebernehmen" ab. Es nuetzt bei ihrer Hardwarezusammenstellung NICHTS. Denken Sie bitte ueber einen neuen Monitor nach. Prg.ablauf: - Programm im Cli starten oder von WB starten Einschub: - Test auf KickRomV1.2, V1.3, V2.0 oder V3.0 - Test auf PAL-Screen - ein Fenster wird geoeffnet (muss immer kurz erscheinen !!!) - einige Vektoren werden getestet und angezeigt - wenn Veraenderung, dann: - Suche nach bekannten Viren (s.u.) beginnt - falls erfolgreich - Namensausgabe - Vektoren werden zurueckgesetzt und angezeigt - Virenprogramm wird im Speicher mit RTS ueberschrieben - also kein Reset mehr notwendig - falls erfolgreich 2 aus programmtechnischen Gruenden, ist es bei einigen Viren not- wendig, vor der Vektoranzeige das VirusPrg. zu loeschen (z.B. Extreme) und mit RTS aufzufuellen. Es taucht dann der Requester auf: XYZ-NameVirus war im Speicher Weiter Weiter - falls Nein - Request unbekanntes Programm im Speicher KReset weiter - weiter: es werden keine Veraenderungen vorgenommen und das Programm beendet. - KReset: - Vektoren werden zurueckgesetzt - reset wird ausgefuehrt dieser Weg wurde gewaehlt, damit zukuenftige Viren mit eigenen Task (hier reicht das Zuruecksetzen der Vektoren nicht mehr, sondern es muss auch der/das Task entfernt werden) geloescht werden koennen, ohne den Computer auszuschalten. ARBEITS-Fenster: ================ ZWEI BITTEN falls Sie Schreibzugriffe planen !!!!!! - Setzen Sie im VorPrg. die OrigVectoren, auch wenn Sie ein fuer Sie wichtiges Resident-Prg. spaeter neu laden muessen - Arbeiten Sie mit einer Disk-Kopie (bedenken Sie, auch mir koennen Fehler unterlaufen !!!!) Erklaerung: Im Hauptfenster sind in manchen Gadgets Buchstaben unterstrichen. Wenn Sie die entsprechende Taste druecken, wird bei Gadgets, die in DF0: und DEVS unterteilt sind, die Aktion fuer DF0 ausgeloest. Bei Gadgets ohne Unterteilung sollte eine Auswahl erscheinen (z.B. Listen). Ende = Prg.Ende E-Taste = Ende ---- Listen: ------- Mit diesem Programmteil koennen Sie sich einen schnellen Ueberblick verschaffen, was in ihrem Computer im Moment aktiv ist (z.B. SnoopDos) oder einen Virus-Task finden. Falls bei Resident eine Adresse NICHT ins ROM (>$F8 o. >$FC) zeigt, fangen Sie bitte mit Nachforschungen an !!! Hinweis: Die Listen werden pro Aufruf nur 1x gelesen. Der Task-Zustand aendert sich also NICHT !! ThisTask wird NICHT angezeigt (muss VT sein) Hinweise zu IntVecExec: Unter KS2.04 werden Aud0-3 erst beim 1.Aufruf des audio.device eingebunden. Es wird jeweils auch die Ausgangszeile eines IntVec an- gezeigt, obwohl die Verwaltung über Listen erfolgt. Aber VirenProgrammierer halten sich nicht an Listen und ver- biegen direkt (sehr beliebt Nr.5=VertB). Deshalb diese Zeilen. (Beispiel DASA) Hinweise zu ResidentCm: Ab KS2.04 sind mehr Cli-Befehle RESIDENT als unter KS1.3. Diese Befehle sind als Intern oder System ausgewiesen und koennen nicht geaendert werden. Sie selbst koennen Befehle resident im Speicher halten, indem Sie bei dem File das Pure-Flag setzen (z.B. in VT-FileReq). Sie installieren dann das File auf Cli-Ebene mit: resident Filename Return KS3.0 gibt bei externen Befehlen im UserC bei Aufruf des Resident-Befehls in der shell haeufig 0 aus, obwohl in der Struktur WIRKLICH NICHT 0 steht. Fragen Sie Commodore! Abbruch mit ESC-Taste oder re.Maustaste Ausdruck mit Druck Nachtrag 09.08.93: Der Prioritaetswert von z.B. exec.library stimmt in Resident und library nicht ueberein. Warum ? Fragen Sie Commodore Stack wird mit 4094 und nicht mit 4096 angegeben, weil in ARKRM libs steht S465: /* stack upper bound +2*/ Obergrenze von Mem wird mit 7FFFF und nicht mit 80000 ange- zeigt, weil in ARKRM libs steht S462: /* upper memory bound + 1 */ Datumsausgabe bei Listen: Bei libs, device, resource versucht VT eine Datumsausgabe. Bedingungen: (TT.MM.JJ) oder (TT MMM JJJJ) Zeiger nicht Null KS1.3 intuition.lib-zeiger leer !!!! KS2.04 dos.lib-zeiger leer !!!! warpdrive.device-zeiger leer !!!! vector.device-zeiger leer !!!! Zeiger zeigt in vorhandenen Speicher negativ-Beispiele gibt es (dann Enforcer-Hits) Nachtrag Nov.96 zu OpenCount: Bei machen Libs ist der Wert 0 und dennoch lassen sich diese Teile nicht mit MemFlush entfernen. VT testet deshalb auch #34(LibNode) und gibt " 0 x" aus, falls dieser Wert NICHT 0 ist. (Danke fuer den Hinweis) Vergl. : (Vergleiche) -------- - Abbruch: ESC-Taste oder re.Maustaste - Ausdruck von 2048 Bytes mit Druck-Gadget je 1024 Bytes - lege Testbeginn fuer 2. Objekt fest oder 0 Es geht nur eine Verschiebung in 2-Byte-Schritten. Diese Einstellung muss ZUERST gemacht werden, wenn der Beginn beim 2. Objekt verschoben werden soll !!!! Warum: Manche BootblocksaveUtilities legen vor dem eigentlichen BB 1 LW zur Erkennung ab. Sie muessen also 4 einstellen. Sie haben ein bekanntes Linkvirusfile. Sie wollen dieses File mit einem anderen File vergleichen. Da das 2. File mehr Hunks hat (Zahl steht im 3.LW) muessen Sie den den Testbeginn fuer das 2. File solange verschieben, bis $000003E9 deckungsgleich sind. - BB <-> BB lade 2 BB jeweils von Track 0 . So koennen Sie auf Nachahmungen testen. Oder Sie wollen den codierten Bereich herausfinden, von einem BB-Virus, der sich bei jedem Schreibvorgang neu codiert (z.B. mit Inhalt von $DFF006). - BB <-> File vergleiche BB von Track 0 mit einem archivierten File - File <-> File vergleiche zwei Files VT - Tools : ------------ - PolPower - sucht im Speicher nach POLISHPOWER-Linkvirus - SpMon einfacher Speichermonitor - auch ueber Tastatur zu bedienen - mit Speichern (es erscheint der Filerequester und Sie koennen 1024 o. 2048 Bytes einstellen) - mit Druck 512, 1024 und 2048 Bytes - Aufpassen muessen Sie im $DFF000-Bereich und im $E80000-Bereich. In diesen Bereichen liegen NUR-Lese- und NUR-Schreib-Register. Ueberspringen Sie bitte diese Bereiche, sonst kann ein System- Absturz NICHT verhindert werden. - $00 in Sp Wie Flush-Sp (siehe unten). Zusaetzlich wird versucht, freie Speicher-Chunks mit dem Wert $00 zu fuellen. Dieser Vorgang kann einige Sekunden dauern. In der Zeit "haengt" dann der Uhr-Maus- zeiger. Keine Angst es ist bei mir immer der Mauszeiger wieder gekommen. - Flush-Sp Loescht nicht benoetigte (nicht mehr benutzte) Module aus dem Speicher. Die MAGIC-Zahl stammt nicht von mir, sondern wurde im FIDO-Netz diskutiert. Beispiel: Sie betreiben DFUE. Danach ist immer noch serial.device im Speicher (Beweis:VT/Listen/device). Nach Flush haben Sie wieder mehr Speicher. usw. Nachtrag Aug.93: Einige Libs muessen unter KS3.0 einen "Schutz" dagegen haben, der NICHT den Commodore-Richtlinien entspricht. Obwohl Open- Count 0 ist und damit die Speicherfreigabe erlaubt waere, ver- schwinden diese libs nicht. - zeige Vek zurueck mit Weiter-Gadget Ausdruck mit Druck-Gadget - zeigt wichtige Vektoren, die von Viren verbogen werden (aber auch von einigen Nutzprogrammen) - Konfiguration Sollte auch unter KS1.3 und OHNE setcpu sinnvolle Wer- te ausgeben. Hinweis 1 : Sollten Sie bei CPU 68030 finden und bei MMU nichts, dann sollten Sie ihre Maschine aufschrauben und nach- schauen, ob ihr Prozessor vielleicht die Bezeichnung EC68030 (Billigversion ohne MMU) hat. Hinweis 2 : VBlank wird aus execbase+$212 ausgelesen (vgl. ARKRM S.803 Z.129) Neu: LoadSeg-Vektor Sie werden staunen, wieviele Nutzprogramme inzwischen diesen Vektor verbiegen. Rufen Sie dann Loadseg in Tools auf und versuchen Sie einen ASCII-Text zu finden. - SystemTest naechste Seite: Space oder li.Maustaste Abbruch : ESC oder re.Maustaste Ausdruck : mit Druck-Gadget (Seite fuer Seite) Testet alle SprungVektoren von libs, devices und resources, die sich im Speicher befinden. Vektoren die nicht ins ROM weisen, werden angezeigt. Da alle Vektoren von nachgeladenen Teilen (z.B. diskfont.library) nicht ins ROM zeigen, wird auch ein Vektorzeiger, der nicht ins ROM zeigt und nicht mehr als +- $6000 von einer bestimmten Adresse abweicht, als gueltig von VT anerkannt, wenn Sie im Requester NEIN waehlen. Beispiel: DoIo Exec -$1c8 KS2.04 -$1c8 -$1c6 $4ef9 $00f80808 JMP Sprungziel 2 4 Bytes = 6 Bytes Sollte DoIo verbogen sein, so gibt VT aus: -$1c6 $xxxxxxxx (zeigt also das Sprungziel) Hinweis1: setpatch von KS1.3 verbiegt schon mehrere Vektoren !!! Hinweis2: ab KS2.04 ist NegOff nicht immer durch 6 teilbar ohne Rest (z.B. graphics.library und andere), sondern langwortorien- tiert. Warum, fragen Sie Commodore !! Hinweis3: auch ohne setpatch weisen bei KS1.3 mehrere Vektoren von Exec.lib nicht ins ROM !!!! Hinweis4: Es ist ein Prg (StreamLineOS) aufgetaucht, das sehr viele Vektoren von Libs, devices, usw. ersetzt. Im Systemtest werden Sie dann SEHR OFT "JMP fehlt ?" lesen. Einen Rechner in diesem Zustand und dann noch der Versuch einen SICHEREN Virustest durchzufuehren, halte ich fuer SINNLOS !!!! Booten Sie bitte Ihren Rechner neu, OHNE dieses Programm zu starten. Danke - LW-Info Ausdruck mit Druck-Gadget Bei Disk-LW MUSS eine Disk eingelegt sein !!! Gibt wichtige Parameter des LW`s und der Disk aus. Hinweis: Unter KS1.2 und KS1.3 werden fuer LW DF0-3 folgende Daten NICHT ausgegeben, weil sie unbrauch- bare Werte enthalten: PreAlloc, MaxTransfer, Mask, BootPri u. DosType Fragen Sie Commodore oder schauen Sie ins ROM oder DosEnvec, da steht die unbrauchbare Tabelle fuer DF0-3. Sie finden dann z.B. fuer Prealloc #11 usw. ?????? obwohl der Wert richtig 0 sein muesste. Bei KS2.04 ist der Fehler behoben. Bei CDROM sind die LW-Info-Werte meist ohne Sinn, da die verschiedenen Treiber (ASIM, BABEL), teilweise DosEnvec nicht bedienen. Es ist also KEIN VT-Fehler !!!!!!!! Rechnung: UsedBlocks+FreeBlocks+2(reserved)=BlocksperDisk LW-880Kb SectorperBlock 1 BlocksperTrack 11 HD-LW 2 22 Das HD-LW CHINON FB357A arbeitet mit ROM KS2.04 auch im A2000C . Install schreibt entgegen meinen Erwartungen KEINEN ANDEREN BB !!!! Hinweis: Auch mit KS2.04 wird der BufferWert in DOS-Envec nicht geaendert, wenn Sie AddBuffers aufrufen (Commodore-Fehler ??) Hinweis2: Auch mit KS1.3 muss DosType (aus DosEnvec) und Disk- Type (aus InfoData) NICHT uebereinstimmen !!! Warum ?? Bitte fragen Sie Commodore !! Beweis fuer KS1.3: - mount VD0 - mountlist muss natuerlich l:fastf... und $444f5301 ent- halten - formatieren Sie VD0 mit FFS - danach LW-Test - DosType wird immer noch DOS0 sein und DiskType DOS1 !!!! Mitteilung eines VT-Users: Habe ich mal probehalber getestet: 1.) mit zwei Syquest Wechselplatten je 88 MB als DH0: und DH1: an einem GVP II Controller mit 8 MB RAM in einem AMIGA 2000 C: Mainboard Rev. 6.2, einem internen Floppylaufwerk unter KS1.3 ... mit Fastprep (spezielles Utility fuer GVP II Controller) zwei neue Medien FFS (!) formatiert und VT2.46-LW Info angewaehlt; VT meldet Format : OFS (?) DosType : $444F5301 DiskType: $444F5300. sicherheitshalber nochmals FastPrep aufgerufen; FileSys zeigt FFS (!) -Format an ... VT2.46-BlockITest meldet "BB: DOS1-FFS-N.BB" (also doch FFS ?) Antwort 17.11.92: siehe Hinweis2 oben. VT kann nur das anzeigen, was er in DosEnvec und InfoData findet. zu PC0: u. PC1: (df0: u. df1: als MSDOS-Laufwerke 720Kb) Warum hier 1439 Blocks reserviert sind, fragen Sie am besten die Commodore-Entwickler. Weiterhin liegen die Directory- Eintraege meist in Zylinder 0 Block 7 und nicht wie angegeben RootBlock=0. Suchen Sie also bitte dort nach den Filenamen. - setze OVek = setzt alle wichtigen Vektoren, aber ein Prg. wird nicht mit RTS aufgefuellt, wie im Vorprg. - zeige Vec = Vectorenanzeige im Hauptprogramm o h n e Virustest - KRESET mit Sicherheitsabfrage - KRESA3 mit Sicherheitsabfrage (fuer A3000) (schaltet fuer sauberen RESET MMU ab) - Base: Ausdruck mit Druck-Gadget Dos.lib es wird die Lage der Dos.lib im Speicher angezeigt und nach Block 2 $00 gelegt. In Block 0 u. 1 liegen also die negativen Offsets und in Block 2 u 3 die positiven Offsets (Verwendung meist von Commodore nicht erlaubt). Exec.lib vgl. Dos.lib positive Offsets von Com. erlaubt. Graphics.lib Int.lib TrackDiskDevice (Struktur ist sehr kurz) HDdev.Base sollte ein Festplattendevice finden ateam.device AT-Bus Mainhattan.Data ;AmigaPlus 11/92 S58 scram8.device ;FF 698 scram16.device ;FF 698 scsi.device Com. hddisk.device Com. xt.device Com. gvpscsi.device gvpat.device scsidev.device GVP alt alf.device ALF.device ;AmigaSpezial 11/92 S27 oktagon.device ;AmigaPlus 5/92 S100 BOIL.device FSE ;AmigaPlus 12/92 S58 scsi3.device Golem SCSI II ;Amiga Magazin nexus.device Advanced Systems ;AmigaSpezial 11/92 S27 icddisk.device ICD ADSpeed ;AmigaSpezial 11/92 S27 HardFrame.device Microbotics harddisk.device Supra ;AmigaSpezial 11/92 S27 SerieIII.device Supra ;AmigaPlus 5/92 S100 suprascsi.device SupraDriveXP500 ;von privat 08.09.92 vector.device HK-Computer ivs_scsi.device Trumpcard ;AmigaSpezial 11/92 S27 imscsi.device Memphis ;AmigaPlus 5/92 S100 protarscsi.device Protar ;AmigaPlus 5/92 S100 evolution.device Macro ;AmigaPlus 5/92 S100 pbscsi.device Phoenix A1000 ;Fido-Netz MASOBOSHI.device Mastercard 2 ;Fido-Netz jkscsi.device Rossm. ;Firma Messe vortex.device ATONCE ;von privat 10.10.92 PPSscsi2.device Zeus-Turbokarte ;AmigaPlus 11/92 S65 ossi.device OTRONIC-SCSI ;INCUBUS_Box 20.10.92 comspechd.device ?????? ;AmigaSpezial 11/92 S27 syndisk.device Hardital ;von privat 03.11.92 AT-Apollo.device 3-state ;Firma Messe SCSI-Apollo.device3-state ;Firma Messe IVS_SCSIpro.deviceTrumpcard Prof. ;Amiga Magazin IVSgslam.device Trumpcard ;FIDO 19.01.93 spartan.device SCSI PD ;INCUBUS_Box 03.12.92 harddisk1.device AccessX ;AmigaSpezial 3/93 S30 IVS_SCSIvector.device ;Markt&Technik 10.03.93 omti.device Omti-Kontroller ;INCUBUS 25.05.93 Malibu.device Malibu Board ;privat 25.05.93 z3scsi.device FastLane ;AmigaSpezial 10/93 S36 2nd.scsi.device A4091 ;ASIM V2.0 19.09.93 empscsi.device EMPLANT ;INCUBUS 25.09.93 parscsi.device Mainhatten ;Amiga 11/93 S76 --------- hidedisk.device HD-Disk FSE ;Kickstart 12/92 S55 hidedisk19.device HD-Disk FSE ;Kickstart 12/92 S55 Sollte ihr Festplattentreiber nicht erkannt werden, so suchen Sie bitte in Listen - device und schreiben den Namen ab ( Bitte auf Gross- und Kleinschreibung GENAU achten). Schicken Sie mir bitte eine Postkarte mit AbCd27.device . Danke - ZeroPage zeigt Speicher ab $0 mit den wichtigen Vectoren (Hallo Enforcer-Freunde) - VecPage ab 68010 kann die ZeroPage mit movec verschoben werden. Die Lage steht dann in VBR . VT zeigt die Lage im Speicher und den Inhalt ab Block 0 (Unterschied zu Libs !!!) Base - VecPage: Der gezeigte Speicherbereich kann im Filerequester abgespeichert werden (2048 einstellen !!) BlockITest ---------- Abbruch: ESC oder re.Maustaste Anzeige eines defekten Blocks moeglich (geht selbstverstaendlich nicht bei Trackerror) Test1: Suche nach Trackerror's (weiss angezeigt) - Fehler 30 SeekError Track nicht gefunden - Fehler 29 Disk Changed Disk gewechselt (auch wenn Sie es nicht glauben, dieser Fehler steht manchmal in Byte 31 des DiskIoReq. Meist passiert dies, wenn der Lesekopf zum naechsten Zylinder faehrt. Brechen Sie den Test dann ab und starten ihn neu.) - Fehler 28 WriteProtected wird hier nicht geprueft - Fehler 27 BadSecHdr ungueltiger Sektor-Header - Fehler 26 TooFewSecs zuwenig Sektoren gefunden - Fehler 25 BadSecSum falsche Sektor-Checksumme - Fehler 24 BadHdrSum falsche Header-Checksumme - Fehler 23 BadSecId falsche Sektor-ID - Fehler 22 BadSecPreamble falscher Sektor-Vorspann - Fehler 21 NoSecHdr keinen Sektor-Header gefunden - Fehler 20 Fehler (aber mir unbekannt) - Meldung Daten im SecHeader s.u. bei Test5 Hinweis 29.10.92: zu Fehler 20 Ich habe eine Disk erhalten, auf der Track 1 (=Block 11-21) NICHT oder NICHT RICHTIG formatiert war. Das AmigaBetriebsSystem gibt dann FehlerCode 20 zurueck. Wieder etwas gelernt. Danke fuer Disk. Empfehlung: (gilt NICHT fuer Original-Spiele mit Fremdformat !!!!) - mit Einzelfilecopy oder DiskSalv retten was moeglich ist - Disk neu formatieren, falls OriginalCommodore abbricht, Disk in den Abfalleimer. Bitte nicht mit XYZ-Format ohne Verify arbeiten. HinweisB Juli 92: Falls Sie bei einer Disk Fehlermeldungen bekommen, probieren Sie die Disk mit ihrem 2.LW. Oder machen Sie ein einfaches diskcopy (bitte KEIN nibblecopy). Oder verwenden Sie TurboBackup. Es kann sein, dass die kopierte Disk KEINE Fehler mehr zeigt. Allerdings sollten Sie dann bedenken, dass ein LW sich verstellt hat. Ent- weder ihr LW oder das LW auf dem die "OriginalDisk" erzeugt wurde. Test2: Suche nach Blockinhalt, der von Viren angelegt wurde: (blau angezeigt) - Lamer! 85 mal + 1 mal !! = 512 Bytes - LAMER! 85 mal + 1 mal !! = 512 Bytes - LAMER!!! 64 mal = 512 Bytes (Return of the Lamer) - VIRUS Track 0 (Digital Emotion) - Warsaw 85 mal + 1 mal !! = 512 Bytes - MAD 85 mal - HIV 85 mal (boot-aids by hiv) - 11111111 22222222 44444444 88888888 = Glasnost ab $100 im Block - SACHSEN3 64 mal = 512 Bytes - " Fast Eddie " = Fast Eddie ab $100 im Block - "INFECTOR GO!" = Infector ab $100 im Block (Fast Eddie Clone) - SHIT ab $30 im Block - 1234 ab $5a und 4E71(=NOP) 66 mal ab $64 (DiskVal1234) - Overkill by the ENEMY ! ab $22 im Block - FUCK!! 85 mal + 1 mal !! = 512 Bytes von INGO'S RETURN zerstoert - == ZENKER == 4 Bloecke von ZENKER-BB in Zyl 40 Sektor 16-19 zerstoert. - STC!STC!STC!STC = FLASHBACK = Glasnost-Clone ab $100 im Block - STC!R! 85 mal + 1 mal !! = The Return of STARCOM = LAMER4-Clone - STC!aw 85 mal + 1 mal !! = STARCOM 5 = Boot aids clone - BURN 128 mal = BURN-Virus - $BAF00D0D 128 mal = Burn 2 Virus - $0A444154 usw. = DATALOCK V1.1 - $0F3E3E3E usw. = DATALOCK V1.2 - SADDAM7! mehrmals = SADDAM-7 Disk-Validator Sollte ein obengenannter Block innerhalb eines Files liegen (Test mit Blockkette), so kann dieses File NICHT gerettet werden. - IRAK 1.Filedatenblock von SADDAM-VIRUS codiert kann gerettet werden (Es sind einige Nachahmungen aufgetaucht, die nicht IRAK als Kennung verwenden. Auch diese sollte VT erkennen und decodieren koennen.) ( Clones = z.B. LAME, LOOM, RISC, 1.29, Laurin, Animal KICK, NATO, AFFE, IRAN, GRAL, 4711=Parfum usw. ) - $ABCD0008 Datenblock von Little Sven codiert. Sollte VT erkennen und decodieren. Test3: Falls Blocktyp 2,8 oder $10 erkannt wird (d.h. bei FFS-Databloecken, BootGirlDatas oder aehnlichen Programmteilen entfaellt der 8er-Test) Die Pruefsumme ueber dem Block wird berechnet und mit dem 5. Langwort verglichen. Fehlermeldung (weiss): - BadBloCheckSum Hinweis zu Test3 und Festplatten mit FFS: Bei HDs mit 165000 Bloecken waechst die Wahrscheinlichkeit, dass ein FFS-Data-Sektor mit 2, $10 ,$20, $21 zufaellig beginnt. VT erkennt den Block nun nicht als Data-Block, sondern glaubt einen Dir-Block oder Fileheader-Block gefunden zu haben (je nach Kennung) und bildet eine Pruefsumme ueber den Block. Da beim FastfileSystem keine Pruefsumme fuer Datenbloecke eingetragen wird, meldet VT einen Fehler. Ich kann dieses Verhalten von VT NICHT abstellen, da ich keinen einfachen Weg kenne, um einen Datenblock im FFS entgegen der vorhandener Kennung -Dir- im Langwort 0, als Datenblock zu erkennen. Nehmen Sie diese "Fehlermeldung" nicht zu ernst. Schauen Sie aber ab und zu mit einem Monitor nach. Beim alten AmigaDosSystem (auf Disk oder HD) handelt es sich SICHER um einen defekten Block !!!! Ein Beispiel von meiner HD0-Partition DOS3 also FFS (Ich hab nur diesen einen "dubiosen" Block auf der Partition) Block: 15865 0000: 00000002 00000001 00000066 0000001a ...........f.... ^^^^^^^^ 0010: 00000000 000003f2 000003ea 00000006 ................ 0020: 00000000 0000004e 00000680 00000000 .......N........ 0030: 00000020 00000000 000003ec 00000002 ... ............ 0040: 00000000 00000008 00000010 00000000 ................ 0050: 000003f2 00000000 00000000 00000000 ................ 0060: 00000000 00000000 00000000 00000000 ................ 0070: 00000000 00000000 00000000 00000000 ................ 0080: 00000000 00000000 00000000 00000000 ................ 0090: 00000000 00000000 00000000 00000000 ................ 00a0: 00000000 00000000 00000000 00000000 ................ 00b0: 00000000 00000000 00000000 00000000 ................ 00c0: 00000000 00000000 00000000 00000000 ................ 00d0: 00000000 00000000 00000000 00000000 ................ 00e0: 00000000 00000000 00000000 00000000 ................ 00f0: 00000000 00000000 00000000 00000000 ................ 0100: 00000000 00000000 00000000 00000000 ................ 0110: 00000000 00000000 00000000 00000000 ................ 0120: 00000000 00000000 00000000 00000000 ................ 0130: 00000b2f 00000b2e 00000000 00000000 .../............ 0140: 00000002 00000274 00000000 00000000 .......t........ 0150: 00000000 00000000 00000000 00000000 ................ 0160: 00000000 00000000 00000000 00000000 ................ 0170: 00000000 00000000 00000000 00000000 ................ 0180: 00000000 00000000 00000000 00000000 ................ 0190: 00000000 00000000 00000000 00000000 ................ 01a0: 00000000 00001618 000001ec 000004cd ................ 01b0: 0c507269 6e746572 2e696e66 6f000000 .Printer.info... 01c0: 00000000 00000000 00000000 00000000 ................ 01d0: 00000000 00000000 00000000 00000000 ................ 01e0: 00000000 00000000 00000000 00000000 ................ 01f0: 00000000 0000069a 00000000 fffffffd ................ ^^^^^^^^ Die Kennungen lassen einen Fileheaderblock vermuten. Ist es aber nicht, sondern das Ende eines Files (vgl. $0050= $000003f2) Entstehung dieses Blocks: - Der Block war wirklich einmal ein Fileheader. - Dann wurde das Info-File geloescht. Leider ueberschreibt dabei das Betriebssystem die freigegebenen Bloecke NICHT, sondern aendert nur den Direintrag und die Bitmap. Sonst wuerden auch Prg.e wie undelete oder DiskSalv2 nicht ar- beiten. - Jetzt wurde ein neues File aufgespielt und der letzte Teil des Programms ist in diesem Block gelandet. Das Betriebs- system ueberschreibt in diesem Block nur den Teil, den es braucht. Der Rest bleibt unveraendert. - In diesem Block sind also jetzt wichtige Daten und Teile eines nicht mehr benoetigten "Uralt-Fileheaders". - Dies ist kein Problem im Normalfall. - Aber hier beginnt der Rest des neuen Files zufaellig mit $00000002 und das ist halt eine Kennung fuer das Betriebs- system. Deshalb irrt hier VT. - Im OFS wuerde der Datenblock mit $00000008 beginnen und VT wuerde sich nicht melden. Ich glaube, jetzt sollte auch klar sein, warum ich der Funktion "Correkt CheckSum" an dieser Test-Stelle von VT ablehnend gegen- ueberstehe. Die Gefahr der falschen Anwendung ist mir trotz "wollen Sie wirklich"-Requesters zu gross. Test4: Alle LinkViren, die ich kenne, werden mit Blocknummer (egal ob ADos oder FFS) weiss angezeigt. Ausbauversuch bitte mit Filetest. Hinweis: BlockITest testet ALLE Bloecke. D.h. es kann ein LinkVirus gefunden werden, der schon aus dem Verzeichnis geloescht ist, gar nicht mehr aktiv werden kann und auch von FileTest nicht gefunden wird. Grund: Amiga-Dos entfernt bei Rename und Delete nur den Filenamen aus dem Verzeichnis und gibt die Bloecke in der Bitmap frei. Die FileDataBloecke dagegen werden NICHT veraendert. Merken Sie sich die Blocknummer und setzen Sie den Blockinhalt mit einem Diskmonitor oder Block loeschen (s.u.) auf NULL. decode IRAK (09/10.07.91) Block loeschen: Zuerst bitte die Disk mit Blockkette und Filetest ueberpruefen. Ge- meldete Fehler dort schon ausbessern. Dann und wirklich erst dann Bloecke mit BlockITest loeschen. VT kann ein File (z.B. Jack ver- seucht) danach NICHT mehr reparieren. Warum dann dieser Programm- teil: weil AmigaDos die Databloecke nicht mitloescht. Ich habe mehrere aeltere PD-Disks zugeschickt bekommen, bei denen die User mit BlockITest nicht mehr von Dos benutzte aber verseuchte Bloecke gefunden haben. Um diese Unruhe zu beseitigen, wurde dieser Programm- teil eingebaut. Ablauf: -Block zeigen ja -Block loeschen ja usw. Test5: Wird nur durchgefuehrt, wenn Sie in VT-Prefs den Haken gesetzt haben. Dann wird ueberprueft, ob im Sector-Header Daten abgelegt sind. Im Header sind 16 Bytes ungenutzt. Vor einigen Jahren gab es Programme, die in diesen Bereich Daten ablegen konnten und auch wieder lesen. Nachteil: Nicht jedes Diskcopy-Programm kopiert den SectorHeader mit: Commodore-DiskCopy Nein TurboBackup Ja D-Copy Ja usw. Damit nun nicht jemand denkt, er kann eine neue Variante plazieren, wird ab VT2.54 dieser Bereich auf Wunsch beim BlockITest mitgetestet. Der Test wird dadurch nicht einmal 1 Sekunde langsamer. Falls Sie mehrmals die Meldung -Daten im SecHeader- erhalten, sollten Sie abbrechen und in VT-Prefs den Haken entfernen. Danach koennen Sie den BlockITest wiederholen und Sie werden nicht mehr mit der Meldung konfrontiert. ABER !!! Sie wissen, dass in den SectorHeadern der Disk zusaetzliche Daten untergebracht sind. Unternehmen Sie etwas dagegen. z.B. Kopie anfertigen mit Commodore-Diskcopy und ueberpruefen Sie danach die Lauffaehigkeit der Programme auf der Disk. Rechnung fuer DD-Disk: 16 Bytes x 11 Sektoren x 160 Tracks = 28160 Bytes Viel Platz also . Falls Daten im Sektorheader enthalten sind, so werden diese dann im BlockITest angezeigt. Weiter dann mit li.Maustaste oder Space . Ab- bruch mit re.Maustaste oder Esc . BlockKette ---------- Hinweis 26.07.93: Sollte beim Test HARDLink oder SOFTLink auftauchen, so handelt es sich weder um einen Virenbefall noch um einen Cruncher, sondern um den Hinweis auf eine Routine des Betriebssystems. Nachzu- lesen bei VT3.xyd am Ende von FileTest (weiter unten). Hinweis 13.08.92: Unter KS1.3 kann rechts oben fuer 2 Sekunden der Hinweis " Status: validating!" auftauchen. Ein Teil der Disk ist dann defekt. In Tools/LWinfo muesste dann auch Status: validating stehen. Dabei kann die Bitmap IN ORDNUNG sein !!!! Dieser Fehler wird ab KS2.04 von AmigaDos abgefangen. Die Disk ist aber irgend- wo DEFEKT. z.B. Bad Listblock, Byte<->Block, Bad T-List usw. Die Disk kann von AmigaDos NICHT repariert werden (von VT auch nicht). Probieren Sie DiskSalv (Erfolg: gering). Probieren Sie BlockKette, damit Sie die Fehlerquelle finden koennen. SchnellStopp: Space o. linke Maustaste weiter dann wieder mit Space Abbruch: Esc oder re.Maustaste Testet JEDEN Block EINES Files auf Fehler (siehe bei BlockITest) und Viren (siehe bei FileTest). Hinweis: das alte Amiga File System arbeitet mit einer doppelten Ver- kettung. Sollte ein "Soft"-Fehler auftauchen (z.B. bad HeaderKey), so so kann dieser haeufig mit copy df0: to df1: all behoben werden. Bei Trackfehlern verwenden Sie bitte z.B. Disksalv . Hinweis: Feb 92 Es scheint ein kommerzielles Diskoptimierungsprogramm zu geben, das die Anforderungen von Commodore (jeder DatenBlock unter OFS enthaelt einen Rueckzeiger auf den Fileheader) in bestimmten Situationen NICHT einhaelt und den Rueckzeiger auf den eigenen FileDatenblock zeigen laesst. Inzwischen scheint ein Prg. aufgetaucht zu sein, das entgegen den Commodore-Richtlinien $00000000 als Rueckzeiger eintraegt. Wird Halt nach jeder Seite in VT-Prefs nicht gewaehlt, so stoppt VT bei jedem Fehler (aber nicht bei Cruncher). Read-Bit hat keine Auswirkungen, da ueber Blockroutine gelesen wird. Hinweis: Die LinkViren LZ, Golden Rider und Crime! koennen hier nicht sicher erkannt werden, da die Routine nur je einen Block einlesen kann (geht nicht anders). Da die Viren sich ans Ende des 1.Hunks haengen, kann ein Teil der 3 Testlangworte im gelesenen Block und der andere Teil im naechsten Block liegt. VT findet dann beim Vergleichen nicht alle 3 Langworte und meldet sich nicht. Beim FileTest SOLLEN die Viren SICHER erkannt werden. Hinweis: Shell hat den Wert Null. Beim EinzelFileCopy gibt es manchmal einen Fehler. VT meldet dann der Zeiger aus dem Fileheader auf den Datenblock stimmt nicht. Loeschen Sie das shell-File und kopieren Sie noch einmal. Vergleichen Sie mit der OrigWB. hier meldet sich VT NICHT !!! Am Schluss werden die untersuchten Verzeichnisse und Files ausgegeben. wichtig: in der Verzeichnisanzahl sind die Rootdir und leere Subdirs enthalten. Fehlermeldungen: - Blockanzahl falsch Im Fileheader steht ab $c die Blockanzahl fuer das File. Diese Zahl und die wirklich im Fileheader eingetragenen Bloecke stimmen NICHT ueberein. Kann mit copy df0: df1: all behoben werden. - Block o. Byteanzahl falsch Die Blockanzahl im Fileheader ergibt -multipliziert mit den Daten der Bloecke (OFS=488, FFS=512)- NICHT die im Fileheader eingetragene Filelaenge. Dass der letzte Datenblock nicht voll sein muss, wird von der TestRoutine beruecksichtigt. - Filelistfehler Ein in der Blockliste im Fileheader eingetragener Block gehoert NICHT zu dem File. - bad headerKey Der Rueckzeiger ($4) im Datenblock auf den Fileheader ist FALSCH Versuchen Sie copy df0: df1: all - bad SequenzNr Im DatenBlock steht bei OFS ein falscher Wert. Beispiel: es kaeme jetzt der 5.Block des Files und im entsprechenden Langwort des Datenblocks steht 20 . BB -> Speicher --------------- bitte DF0: oder Devs anklicken Lade Bootbloecke in Speicher und teste Viren, die ich habe, werden auf drei !!! Langwoerter getestet im BB Sollte ein Virenname und vier umgedrehte Fragezeigen erscheinen, so besitze ich den BBVirus nicht und habe ein Langwort in einer Veroeffentlichung gefunden. Hier lehne ich jede !!!! Verantwortung ab! Bitte schicken Sie diese Bootbloecke an mich! DANKE! Es wird ab VT2.33 Block0-3 gezeigt. Festplatte: Bei der Partition mit dem niedrigsten LowCyl wird der echte PHYSIKALISCHE Block 0 angezeigt. Bei den anderen Partitionen der LOGISCHE Block 0. BITTE aendern Sie den ECHTEN Block 0 NICHT !! EIN Fehler und der Zugriff auf ALLE Daten der HD wird unmoeglich !! Speicher -> BB --------------- bitte DF0: oder Devs anklicken schreibe Speicher in Bootblock 0 u 1 von DfX MERKE: Nach Track 0 werden IMMER NUR 1024 Bytes geschrieben, auch wenn Sie vorher 2048 Bytes geladen haben !!!! Warum ? Damit mit VT keine 4-Block-Viren installiert werden koennen !!! Sie koennen damit also auch BBe kopieren (aber bitte keine Viren!) Schreibbedingungen: - 512 Bytes/Sektor Ueberlege, bevor Du einen BB auf Festplatte schreibst !!!!!!!!!! MERKE: Auf den physikalischen Block 0 der HD schreibt man nicht, wenn man einen Nervenzusammenbruch vermeiden will !!! MERKE 2: Bitte schreiben Sie auf eine FFS-Disk NIE einen OFS-BB (und gegen- gleich). Warum ?? Nach einem Reboot wird die Disk als OFS behandelt und wenn Sie jetzt ein File auf diese Disk kopieren, zerstoeren Sie die Diskstruktur. Glauben Sie nicht. Dann probieren Sie es aus. Ich habe es auch nicht fuer moeglich gehalten, bis mir die 1.Disk so zerstoert zugeschickt wurde. Speicher -------- Hinweis 20.03.93: Falls Sie im Icon SCREEN=PROD eingestellt haben, so werden jetzt 2 Bloecke angezeigt, da mehr Platz ist. Lassen Sie sich nicht verwirren. Der 2.Block beginnt bei $200. Sie sehen dann also den ganzen BB (1024 Bytes) auf einem Blick. alle Veraenderungen werden nur im Speicher vorgenommen auf Disk wird der Speicher erst mit s.o. geschrieben NoBoot = erstelle Blocks ohne BootPrg. klicke: OF fuer altes AmigaDosSystem FF fuer FastFileSystem insta. = erstelle bootbare Disk klicke: OF fuer altes AmigaDosSystem FF fuer FastFileSystem BLK0/1/2/3 = Wechselgadget zur Anzeige von Blk 0-3 in HEX und ASCII .-Taste = BLK 0-3 Pfeil rechts-Taste = BLK 0-3 Mit install (Ver.37.5 vom 28.4.91) der WB 37.67 wird ein neuer Bootblock geschrieben, der die expansion.library patched. Ob das bei der ROM-Version von KS2.0 auch notwendig ist, wird sich zeigen. Stand 27.10.91: Auch der Install-Befehl des A500+ schreibt diesen BootBlock. Wahrscheinlich war die Entwicklung des ROM`s zu weit fortgeschritten. BB-KS2.0 mit expansion.library dc.l $444F5300,$E33D0E73,$00000370,$43FA003E dc.l $70254EAE,$FDD84A80,$670C2240,$08E90006 dc.l $00224EAE,$FE6243FA,$00184EAE,$FFA04A80 dc.l $670A2040,$20680016,$70004E75,$70FF4E75 dc.l $646F732E,$6C696272,$61727900,$65787061 dc.l $6E73696F,$6E2E6C69,$62726172,$79000000 BB-FFS-KS2.0 mit expansion.library dc.l $444F5301,$E33D0E72,$00000370,$43FA003E dc.l $70254EAE,$FDD84A80,$670C2240,$08E90006 dc.l $00224EAE,$FE6243FA,$00184EAE,$FFA04A80 dc.l $670A2040,$20680016,$70004E75,$70FF4E75 dc.l $646F732E,$6C696272,$61727900,$65787061 dc.l $6E73696F,$6E2E6C69,$62726172,$79000000 BB KS2.0 mit expansion.library 25.08.91 ;DOS0 PruefSumme Zeiger auf RootBlock (nicht wichtig) 000A0000 444F5300 E33D0E73 00000370 ;Zeiger auf Name "expan...." 000A000C 43FA003E LEA $A004C(PC),A1 ;mind. Vers 37 000A0010 7025 MOVEQ #$25,D0 ;openlib 000A0012 4EAEFDD8 JSR -$228(A6) 000A0016 4A80 TST.L D0 ;nicht gefunden 000A0018 670C BEQ.S $A0026 000A001A 2240 MOVEA.L D0,A1 ;patch 000A001C 08E900060022 BSET #6,$22(A1) ;closelib 000A0022 4EAEFE62 JSR -$19E(A6) ;Zeiger auf Name "dos..." 000A0026 43FA0018 LEA $A0040(PC),A1 ;FindResident 000A002A 4EAEFFA0 JSR -$60(A6) 000A002E 4A80 TST.L D0 ;nicht gefunden 000A0030 670A BEQ.S $A003C 000A0032 2040 MOVEA.L D0,A0 ;hole Zeiger auf Initial. nach a0 000A0034 20680016 MOVEA.L $16(A0),A0 000A0038 7000 MOVEQ #0,D0 000A003A 4E75 RTS ;FehlerFlag setzen 000A003C 70FF MOVEQ #-1,D0 000A003E 4E75 RTS 000A0040 dc.b "dos.library",0 000A004C dc.b "expansion.library",0,0,0 000A0060 00000000 00000000 00000000 00000000 OriginalBB (frueher Lam3) -------------------------- Nur aktiviert, wenn gefunden wurde: - Lamer 3 (Block2 u 3 codiert) - Little Sven (Block2 u 3 codiert) - MALLANDER (Block2 u 3 nicht codiert) - Overkill (Block2 u 3 nicht codiert) - ZENKER (Zylinder 40) Lamer3 und Little Sven verschieben OrigBB codiert nach Block 2 u. 3 Block 2 u. 3 wird entschluesselt und in Speicher geschrieben. Danach kann man den OrigBB zurueckschreiben. Wann nuetzt das nicht viel ??? - Wenn der Kopierschutz schon auf Track 0 beginnt (Longtrack usw) (das Prg ist aber schon mit Lam3 nicht mehr gelaufen). - Wenn ein File oder BootblockIntro Block 2 u 3 belegt hat. So habe ich Lamer3 damals auf einer PD-Disk gefunden (das File ist aber schon durch Lamer3 zerstoert worden). FileTest: (ProgrammFileTest) --------- - Sie haben in VTPrefs SeitenStopp eingestellt - oder Stopp mit Space-Taste oder li. Maustaste weiter dann wieder mit Space oder li. Maustaste - Abbruch mit ESC-Taste oder re.Maustaste Hinweis: Seit KS2.04 oder FFS wird das Read-Bit getestet. Verwenden Sie bitte bei so einem File BlockKette oder lassen Sie VT das Bit loeschen. Die restlichen Bits bleiben im Originalzustand. Mit dem WB-Befehl (in c zu finden) protect oder Protect im VT-FileRequester koennen Sie spaeter das READ-Bit wieder setzen. - entsprechende Disk einlegen u n d warten bis LW-Led aus ist!!! - DF0, Devs oder RAM anklicken - F-Taste startet FileTest DF0 - M-Taste startet FileTest RAM (ab VT2.54) Test1: Dieser Test wird nur durchgefuehrt, wenn DOS0 (=OFS) gefunden wurde. Teste Langwort 0 des FileHeaderBlock auf 2 : Fehlermeldung: bad T.SHORT Teste Langwort 0 des FileDataBlock auf 8 : Fehlermeldung: bad T.DATA Teste ob der Zeiger in Langwort 1 auf den Fileheader zeigt: Fehlermeldung: bad HEADERKEY Teste ob der Wert in Langwort 2 die richtige Reihenfolge enthaelt: Fehlermeldung: bad SEQNumber - normale Schrift: nichts gefunden Hinweis 16.06.93: Dieser Test ist bei der variablen RAM-Disk NICHT moeglich, geht aber bei RAD . Test2: - normale Schrift: nichts gefunden - blaue Schrift und Requester: wahrscheinlich Virus im File - weisse Schrift: File ist gepackt (z.B. PowerPacker) oder Archiv (z.B. lha) k e i n Test auf Virusbefall moeglich bitte entpacken und dann neu testen - blaue Schrift und Text: File defekt ? Datenstruktur am Fileanfang stimmt nicht. Bitte merken Sie sich den Filenamen und versuchen Sie das File aus dem Cli zu starten. Hinweis: ein Fehler z.B. im 55 Datenblock eines Files wird in diesem Programmteil NICHT erkannt !!! Verwenden Sie dafuer bitte Blockkette. Eine grosse Anzahl von gefundenen defekten Dateien auf einer Disk, kann den VT zum Absturz bringen. Dies liegt NICHT am VT, sondern am AmigaDos. Jedes defekte File im Cli gestartet, fuehrt zum GURU. Wer's nicht glaubt, bitte selbst ausprobieren. - findet IRQ I, IRQ II, BGS9 I-III, Disaster Master, Revenge Lamer1+2, OrigPrg.e, die von Bgs9 I, BGS9 II oder Terrorists verschoben wurden, XENO, JEFF-BUTONIC I+II+3.10, Terrorists, THE SMILY CANCER1+2, Traveling Jack I+II, Return Of The Lamer (Disk-Validator), CCCP-Link TimeBomb V0.9, TimeBomber, EM-Wurm, BRET HAWNES, SADDAM, Color, BlueBox, LZ, Lamer-LoadWB, Gotcha, PP-Bomb, Virusblaster V2.3, Byte- Parasite1+2+3, Freedom, initial_cli, NoGuru, Disk.info, LAMER8-File, Mem- Check, Golden Rider, Disktroyer V1.0, CHAOS-MASTER, NoVi, Hochofen, DATA CRIME, Crime!, Excreminator 1, IRAK+Clones, NaST, METHAMORPHOSIS, Challenger, DARTH VADER, Crime!++, DriveInfo, DiskVal1234, LAME, LOOM, Infiltrator, RISC, HARD, 1.29, 4711, NATO, KICK, - loescht auf Wunsch Prg.Viren ein Requester erscheint, es ist aber auch 'Weiter' moeglich in der startup-sequence muss bei Bedarf mit ed die 1. Zeile geloescht werden. DOpusRT-Virus: wird geloescht Lameralt-File: wird geloescht, da jeder endcli besitzt BGS9 /3 VT unternimmt einen Renameversuch mit devs/A0,0 Infiltrator VT unternimmt Ausbauversuch DARTH VADER ($A0) einfach loeschen, bitte 1.Zeile Startup- sequence mit Editor loeschen Challenger (setclock) VT sucht nach OrigFile in devs/keymaps, falls nicht gefunden, wird Virus allein geloescht. Nast=BGS9-Clone VT sucht nach OrigFile in c, falls nicht ge- funden, wird Virus allein geloescht. RobNorthern=BGS9-Clone VT sucht nach OrigFile in devs, falls nicht gefunden, wird Virus allein geloescht. Libs/Exec.library ( 4 Bytes), gehoert zu Excreminator 1 einfach loeschen Excreminator 1 einfach loeschen NoVi: versucht zuerst Rename mit .fastdir,$a0 (Aenderung der startup-s. dann nicht notwendig !!) falls File nicht gefunden wird, wird die Loeschung des Viren- Prg.s allein angeboten (bitte dann startup-sequence aendern) CHAOS-MASTER = dir und disk.info wird geloescht, bitte dir-Befehl von OrigWB neu kopieren Disktroyer V1.0: wird geloescht, bitte startup-sequence ueberpruefen. memcheck: wird geleoscht, bitte 1.Zeile Startup-sequence loeschen LAMER8-File: (haengt an VirusX) wird geloescht, da sich jeder Original-VirusX besorgen kann. Disk.info: mit Text manipuliert wird geloescht, bitte von Original-WB neu kopieren NoGuru: wird geloescht, fuer Arbeit nicht notwendig initial_cli: (AMIGAKNIGHT-Virus) wird geloescht, 1.Zeile startup-sequence bitte mit ED loeschen !! Freedom: wird geloescht JEFF BUTONIC V3.10: wird geloescht, 1.Zeile startup-sequence bitte mit ED loeschen !! ByteParasite1+2+3: wird geloescht Virusblaster V2.3: wird geloescht PP-Bomb: wird geloescht (Bitte kopieren Sie Powerpacker 3.0b) Gotcha LAMER: wird geloescht (Bitte kopieren Sie bei Bedarf dir, run, cd oder execute von Orig.WB zurueck) Lamer-LoadWB: wird geloescht (Bitte kopieren Sie LoadWB von Orig.WB zurueck) icon.library-BlueBox-Virus: wird geloescht (Bitte kopieren Sie icon.library von Orig.WB zurueck) color-Filevirus: wird geloescht (Aenderung in startup-s. nicht notwendig) IRAK-DataBlock: decodiert den Datenblock und schreibt ihn zurueck (sehr langsam) geht schneller mit BlockITest. SADDAM: loescht Disk-Validator (Aenderung in startup-s. nicht notwendig) BRET HAWNES: loescht $C0A0E0A0C0 in Root 1.Zeile in startup-sequence muessen sie mit ed loeschen EM-Wurm: loescht $A0 in c loescht gefundene zerstoerte Dateien auf Wunsch Disaster Master: loescht cls Revenge Lamer 1 u. 2 : loescht A0A0A0A0A0 Jeff-Butonic 1 u. 2 : loescht unsichtb. File oder Alias-Name (s.b. Jeff-Beschreibung) TimeBomb V0.9: loescht .info in c und falls vorhanden pic.xx in Root TimeBomber: loescht virustest und falls vorhanden VIRUSTEST.DATA Return of the Lamer: loescht Disk-Validator (Aenderung der startup-s. nicht notwendig !!) BGS9 1+2 und Terrorists: versucht zuerst Rename mit unsichtbarem File (Aenderung der startup-s. dann nicht notwendig !!) falls unsichtbares File nicht gefunden wird, wird die Loeschung des Viren-Prg.s angeboten Traveling Jack loescht auf Wunsch von Jack erzeugtes File (VIRUS.xy) - baut auf Wunsch CCCP, IRQ1+2, The Smily Cancer1+2, Traveling Jack1+2 Xeno, LZ, Golden Rider, Hochofen, DATA CRIME, Crime!, Crime!++, Infiltrator, Crime92, aus File aus ( K e i n e 100% Garantie fuer Lauffaehigkeit !!!! Falls der Ausbau misslingt, schicken Sie mir bitte das verseuchte Original- file. Danke ! ) Bei einem Fehlschlag kopieren Sie das verseuchte File auf eine leere formartierte Disk und versuchen dann den Ausbau. oder Um stark fragmentierten Speicher (kann eine Fehlerursache sein) zu beseitigen, starten Sie Kreset oder schalten Sie den Computer eine Minute aus. Wichtig: Nach dem Ausbauversuch startet das Programm neu um das Zurueck- schreiben zu ueberpruefen. Sollte das File immer noch blau sein, so waere ich fuer eine Nachricht dankbar. oder: Sie haben ein File, das mehrfach von IRQ2, Smily, LZ, Golden Rider, Crime, Crime!++ verseucht ist. Ich besitze ein IRQ2-verseuchtes File mit sechs Links, ein Smily-File mit vier Links und ein LZ-File mit zwei Links. Grenze bei Golden Rider ist 100000 Bytes. Hier muessen Sie dann ueber den File-Requester die Abnahme der Filegroesse kontrollieren und den Ausbauversuch fortsetzen. - sucht nach von BootControl V4.0, FileBootBlock, BB 2.0 aus BB-Viren erzeugte Files (vgl. Fish). Entgegen meiner Erwartung laufen einige so erzeugte Files (Laenge:1048, 1056, 1060, 1072) ohne Absturz an !!!!! - Am Schluss werden die untersuchten Verzeichnisse und Files ausgegeben. wichtig: in der Verzeichnisanzahl sind die Rootdir und leere Subdirs enthalten, aber nicht SOFT- oder HARDLinks. Hinweis 26.07.93: Sollte beim Test HARDLink oder SOFTLink auftauchen, so handelt es sich weder um einen Virenbefall noch um einen Cruncher, sondern um den Hinweis auf eine Routine des Betriebssystems. Soft- und HardLinks geben ab KS2.04 die Moeglichkeit, "Schein"-Files oder "Schein"-Dirs zu erzeugen. Der Vorteil: Es wird auch fuer ein riesiges Verzeichnis NUR 1 Block gebraucht. Sie sparen also Platz. Nachteil: Falls Sie solche Links mit KS2.04 auf Disk erzeugen und dann zu KS1.3 wechseln, koennen Sie SICHER mit einem GURU rechnen. Das hat nichts mit VT oder einem anderen Prg zu tun, sondern KS1.3 kennt einfach keine Links. VT testet jetzt diese Links nicht mehr, sondern nur noch die Originale, da sonst ein "Doppeltest" stattfindet. VT gibt in heller Schrift SOFTLink oder HARDLink aus, haelt aber NICHT an. HardLinks: Koennen mit makelink im c-Verzeichnis erzeugt werden. Fuer HardLinks auf ein Verzeichnis muessen Sie eingeben: makelink df0:hardc df0:c FORCE Fuer HardLinks auf ein File muessen Sie eingeben: makelink df0:hardVT df0:Test/VT Sie arbeiten also nur auf der gleichen Partition. Das Betriebssystem kann sauber zwischen Dir und File unterscheiden. SoftLinks: Koennen mit makelink im c-Verzeichnis NICHT erzeugt werden. Es gibt aber Prg. (z.B. von Stefan Becker) im PD-Bereich, die das koennen. Sie arbeiten auch mit verschiedenen Partition. also z.B. : makelink df0:softVT hd3:schutz/VT Das Betriebssystem kann leider NICHT zwischen Dir und File unter- scheiden. Es wird IMMER ein positiver Wert zurueckgegeben. Na ja Commodore koennte den Fehler beheben, indem man in Zukunft auf -+ 5 ausweicht. Dann waere im rekursiven Test wieder eine Unter- scheidung in File und Dir SICHER moeglich. VT zaehlt Soft- und HardLink weder bei der Verzeichnis- noch bei File-Anzahl mit !!!! Startup-S DF0/Devs ------------------ - zeigt 2KB der startup-sequence falls vorhanden, umschalten bitte mit BLK0/1/2/3-Gadget, hilfreich fuer schnelle Suche nach $A0 usw. in 1. Zeile aber bitte nicht $0A mit $A0 verwechseln !! - zeigt n i c h t startupII oder startup-sequence.hd (Anzeige jetzt moeglich = Umweg ueber FileRequester) Sp -> File -> Sp = FileRequester ----------------------------------- entfernt Aug 92 siehe Dok VT-FileReq Devs=Device-Requester ===================== Nimmt bis zu 30 "gemountete" Devices auf. (also kein assign, kein RAW AUX, s usw.) Nach 30 uebernommenen Eintraegen wird die Suche beendet. Ende Abbruch ohne Auswahl Auswahl mit linker Maustaste Scroll mit PropGadget Die "einfache" Commodore-RAM-Disk wird nicht erkannt. CDROM mit der Kennung CDx: sollten ab VT2.49 angezeigt werden. was kann das Prg. nicht: ------------------------ - ist nicht speicherresident - bitte P-Bit nicht setzen - sicherer Guru !!!! - bitte nicht mehrere Programme gleichzeitig laufen lassen - Virennamen aus der startup-sequence entfernen (verwenden Sie hierfuer bitte Ihren Editor) Es werden nur Viren ohne Reset geloescht, die ich selbst reassembliert habe. Leider werden die Virenroutinen immer besser (immer mehr Listen und Zeiger veraendert), sodass mit vernuenftigen Aufwand der Orig.Zustand nicht mehr hergestellt werden kann. Deshalb inzwischen auch bei einigen Viren, die ich reassembliert habe, nur noch RESET !! Alles andere ist mir zu gefaehrlich !! (Zeiger vergessen, Task nicht erkannt usw.) BEKANNTE PROBLEME: ================== - Probleme mit Mach2.4, dann nehmen Sie bitte MachII V2.6 (z.B.Fish254) und lesen Sie bitte Mach2.6Doc !! Tip von J.K. fuer Mach2.4 : waehrend des Aufbaus von VT Mauszeiger bewegen - oder MachIII (z.B.Fish378) - oder MachIII.1 (z.B.Fish471) - oder Mach IV - Probleme mit MyMenu, dann versuchen Sie bitte ParM (Fish 540) MyMenu haelt sich nicht an die Commodorerichtlinien. - VT meldet unter Kick1.3 eine 68030-Karte als 68020. Mit Kick2.0 wird die Karte IMMER richtig erkannt. Der Fehler liegt bei Kick1.3 (inzwischen auch in Literatur dokumentiert), da Bit 0 und 1 nicht aber Bit 2 gesetzt werden. Abhilfe: Aufruf von setcpu (auch ohne Parameter) setzt Bit 2. erledigt 09.08.91: VT erkennt jetzt auch unter KS1.3 OHNE setcpu 68030/40 richtig - Memorywert von VT und z.B. Mach III sind verschieden. Bitte haengen Sie an MachIII-Wert 3 Nullen an und teilen dann durch 1024 (=1KB). Sie erhalten den VT-Wert. Also rechnet VT richtig !!! Faellt erst bei grossen MemWerten auf. - weitere Probleme bitte melden - Fuer Aenderungswuensche bin ich dankbar !! Texte bitte auf Disk (aber bitte nicht gecruncht, sondern als ASCII, Ihr Text- oder CrunchPrg besitze ich nach Murphy bestimmt nicht) D A N K E !! D A N K E !! Bitte Disk mit "Viren" kennzeichnen !!! Adresse und Tel. nicht vergessen, kleiner Text waere nicht schlecht (Beides aber nicht unbedingt notwendig, nur das VIRUS-Prg. zaehlt) Hinweis: Ich suche n u r Viren und neue Cruncher!! , Disk wird nach kopieren des VirusBBs oder des VirusPrgs formatiert. Adresse und Tel. wandert nach Virusanalyse in Papierkorb !! (da keine Rueckfrage mehr notwendig) Ich pflege meine Zusagen auch einzuhalten !! Heiner Amiga ist ein eingetragenes Warenzeichen von Gateway 2000