home *** CD-ROM | disk | FTP | other *** search
/ Amiga MA Magazine 1998 #7 / amigamamagazinepolishissue1998.iso / varia / vtschutz / schutz / vt.dokumente / vt.rootblt < prev    next >
Text File  |  1998-01-12  |  13KB  |  249 lines
  1.  
  2.    VT.RootBlTest     frueher BitMapTest
  3.  
  4.    Stand: 97-08-30
  5.  
  6.  
  7.    Taste = R   oder  Mausklick
  8.  
  9.    Original-WB-Rootblock leicht modifiziert
  10.             Block:     880
  11.  00000000: 00000002 00000000 00000000 00000048 ...............H
  12.  00000010: 00000000 f099533b 00000400 00000372 ......S;.......r
  13.                               ^^^^^^^
  14.  00000020: 00000000 00000000 00000374 00000000 ...........t....
  15.  00000030: 00000000 00000375 00000377 0000041b .......u...w....
  16.  00000040: 00000000 00000000 00000000 00000000 ................
  17.  00000050: 00000000 00000371 00000000 0000045d .......q.......]
  18.  00000060: 00000000 00000000 00000000 00000000 ................
  19.  00000070: 00000475 00000000 00000498 000004ab ...u............
  20.  00000080: 00000000 00000000 00000000 00000000 ................
  21.  00000090: 00000000 00000000 00000000 FFFF0800 ................
  22.                                        ^^^^^^^
  23.  000000a0: 00000000 00000000 00000000 00000000 ................
  24.  000000b0: 00000000 000004ac 00000000 00000000 ................
  25.  000000c0: 00000000 00000000 00000000 00000000 ................
  26.  000000d0: 000004f0 00000000 00000000 00000000 ................
  27.  000000e0: 00000000 00000000 00000501 00000000 ................
  28.  000000f0: 00000504 00000000 00000506 00000000 ................
  29.  00000100: 00000509 00000000 00000000 00000000 ................
  30.  00000110: 00000000 0000050b 00000000 00000000 ................
  31.  00000120: 00000000 0000050d 00000000 0000050f ................
  32.  00000130: 0000054d 00000000 ffffffff 000004a6 ...M............
  33.                               ^^^^^^^  ^^^^^^^
  34.  00000140: 00000000 00000000 00000000 00000000 ................
  35.             ^^^^^^^
  36.  00000150: 00000000 00000000 00000000 00000000 ................
  37.  00000160: 00000000 00000000 00000000 00000000 ................
  38.  00000170: 00000000 00000000 00000000 00000000 ................
  39.  00000180: 00000000 00000000 00000000 00000000 ................
  40.  00000190: 00000000 00000000 00000000 00000000 ................
  41.  000001a0: 00000000 00000f6d 000003e8 000004df .......m........
  42.  000001b0: 0d576f72 6b62656e 6368312e 33440000 .Workbench1.3D..
  43.  000001c0: 00000000 00000000 00000000 00000000 ................
  44.  000001d0: 00000000 00000000 00000f6d 00000492 ...........m....
  45.  000001e0: 000003c9 00000f6d 000003e8 000004df .......m........
  46.  000001f0: 00000000 00000000 00000000 00000001 ................
  47.  
  48. Test1 fuer Disk undFestplatte:
  49.  
  50.    BiTMapZeigerTest:   ($13c s.o.)
  51.    -----------------
  52.       Bitte verwenden Sie diesen Programmteil bei Disk-Validator-Viren
  53.       verseuchten Disketten. (FileTest und BlockKette melden Bitmap
  54.       ungueltig).
  55.       Fall1: Bitmapflag =$138 im Rootblock ist Null
  56.       VT bietet Neuberechnung an. Danach entnehmen Sie bitte diese
  57.       Disk fuer 10 Sekunden (Betriebssytem "vergisst diese Disk"). Danach
  58.       legen Sie die Disk wieder ein, Filetest muesste laufen.
  59.  
  60.       Fall2: SADDAM hat Zeiger auf den Bitmapblock = $13c im Rootblock
  61.       nach $140 verschoben. VT bietet Aenderung an, danach bitte Disk
  62.       entnehmen. siehe oben
  63.  
  64.       Fall3: SADDAM sitzt auch noch im Disk-Validator. VT bietet Rename
  65.       an. Neuer Name: fal.Disk-Valc  (notwendig damit Hash-Wert stimmt)
  66.       Bitte Disk kurz entnehmen. siehe oben
  67.  
  68.       Fall4: der schlimmste Fall, mir wurden 3 solche Disks zugeschickt.
  69.       $13c UND $140 enthalten den Wert 0. Hier braucht VT ihre Hilfe.
  70.       Loesung: suchen Sie bitte mit BitMapTest auch noch den Disk-
  71.          Validator und falls vorhanden Rename. Rename MUSS gemacht wer-
  72.          den, wenn verseuchter Disk-Validator gefunden wurde. Verseuchte
  73.          Disk bitte entnehmen und offen lassen !!!! Jetzt bitte KReset.
  74.          Booten Sie neu von einer Disk mit ORIGINAL-Disk-Validator. Danach
  75.          legen Sie bitte die verseuchte Disk in DF0 oder DF1. Das Be-
  76.          triebssystem erkennt nun den $13c-Fehler und versucht den
  77.          Disk-Validator von der verseuchten Disk zu laden, was aber nicht
  78.          moeglich ist, da Sie den Namen geaendert haben (hoffentlich !!).
  79.          Also wird der saubere Disk-Validator von der Sys-Disk geladen
  80.          (Bei nur 1 Laufwerk erscheint "insert ...." 2 Wechsel notwendig!)
  81.          Das Betriebssystem schreibt nun $138 u. $13c neu (dauert eine Weile,
  82.          warten Sie bitte bis Laufwerks-LED aus ist.). Jetzt starten Sie
  83.          VT neu und decodieren IRAK-Blocks und loeschen fal.Disk-Valc .
  84.          Bis jetzt (10.07.91) habe ich so  JEDE  SADDAM-verseuchte Disk,
  85.          die mir zugeschickt wurde, retten koennen.
  86.  
  87.       Hinweis  28.07.93
  88.          WICHTIG !!!!!  Dieser Hinweis gilt NUR fuer KS1.3, da ab KS2.04
  89.          der Disk-Validator im ROM sitzt.
  90.          Es handelt sich um ein "brutales" Vorgehen, das Sie nur als
  91.          letzte Rettung verwenden sollten.
  92.          Mir wurde eine Disk zugeschickt, die neben dem SADDAM-Disk-Vali-
  93.          dator auch noch jede Menge bad-HeaderKey-Fehler hatte. Der
  94.          Bitmapzeiger war noch in Ordnung !!! und es waren noch keine
  95.          Files codiert.
  96.          Hallo Othmar aus Wien (PTA-Disk). Ohne Adresse kann ich nicht
  97.          antworten, Deshalb versuch ich es auf diesem Weg !!!!!
  98.          Unter KS2.04 konnte das Virus-File ohne Probleme geloescht wer-
  99.          den.
  100.          Aber mit KS1.3 gab es Probleme wegen der anderen Fehler.
  101.          Gefundener und mehrmals wiederholter Weg:
  102.           - Man braucht KS1.3 (und nur dann kann dieser Weg notwendig
  103.                                sein, zusaetzliche Fehler siehe oben)
  104.           - Eine SCHREIBGESCHUETZTE Bootdisk mit sauberen Disk-Validator
  105.           - Eine verseuchte Disk mit zusaetzlichen Fehlerquellen.
  106.          Ablauf:
  107.          Starten Sie VT
  108.          Falls VT SADDAM im Speicher findet, loeschen.
  109.          Dann RootblockTest
  110.             - bei Bedarf Bitmapzeiger richten
  111.             - Disk-Validator umbenennen in fal.DisV
  112.          Dann BlockITest
  113.             - sobald VT SADDAM findet
  114.                  - zeigen
  115.                  - loeschen  (Frage nach Filetest ignorieren)
  116.          Dann BB->File->BB
  117.             - Laufwerk waehlen
  118.             - L waehlen
  119.             - fal.DiskV anklicken
  120.             - Delete
  121.          Falls jetzt groessere Fehler ausser SADDAM auf der Disk sind,
  122.          erscheint ein GURU. (Hat nichts mit VT zu tun, sondern mit
  123.          dem Betriebssystem)
  124.          Falls nur ein LW, Disk entnehmen und von sauberer Disk neu
  125.          booten.
  126.          SADDAM-Disk einlegen
  127.          Requester erscheint und verlangt Bootdisk (wg.Disk-Validator).
  128.          Bootdisk einlegen und wieder entnehmen.
  129.          SADDAM-Disk einlegen und warten bis Licht ausgeht. Original-
  130.          Disk-Validator behebt Fehler.
  131.          VT-Disk einlegen und VT starten.
  132.          SADDAM-Disk einlegen
  133.          mit BB->File->BB  fal.DiskV loeschen. Geht jetzt OHNE GURU.
  134.          Dieser Dieskwechsel entfaellt bei 2 LWen. Legen Sie ihre
  135.          Saubere Bootdisk in DF0 und die SADDAM-Disk in DF1 .
  136.          Hinweis fuer Othmar: Die bad HeaderKey-Fehler werden behoben,
  137.          wenn Sie jetzt alle Files von der ehemaligen SADDAM-Disk im
  138.          Einzelfile-Copymodus (also copy df1: ram: all) ins RAM kopieren
  139.          und dann wieder zurueck (copy ram: df1: all) .
  140.          Nocheinmal !!! Dieser umstaendliche Weg war nur notwendig:
  141.              - bei KS1.3
  142.              - wegen der bad HeaderKey-Fehler
  143.                (die gleiche Disk OHNE bad HeaderKey war auch unter
  144.                 KS1.3 ohne Probleme zu bearbeiten. Also loesche
  145.                 SADDAM-Virus mit FileTest !!!)
  146.  
  147.  
  148.          Erkennt Zombi-Disk, bitte lesen Sie Zombi-Virus-Text
  149.          Erkennt Freedom-Disk (hoffe ich), lesen Sie Freedom-Text
  150.  
  151.          Kann bei Original-Spielen mit "echtem" FremdFormat den Root-
  152.          block ($370=880) natuerlich nicht zeigen.
  153.  
  154.       Hinweis: Nach Commodore ist die BitMap gueltig, wenn im LW -1 =
  155.          $FFFFFFFF steht. Dies stimmt nur zum Teil. Da das Betriebs-
  156.          system gegen 0 testet (auch KS2.04), wird z.B. auch der Wert 1
  157.          vom Betriebssystem als gueltig angesehen.
  158.  
  159.   Test2 NUR fuer Disk:   (ab VT2.50)
  160.   --------------------
  161.         Falls VT im Verlauf dieses Test Veraenderungen vornehmen will,
  162.         brechen Sie bitte UNBEDINGT ab und fertigen Sie zuerst mit z. B.
  163.         turbobackup eine Kopie dieser Disk an !!!! Lassen Sie die Ver-
  164.         aenderungen von VT dann NUR an der Kopie vornehmen !!!!
  165.         Dieser Test wird nur bei Disketten angeboten. Es wird die Block-
  166.         zeigerliste des Rootblocks (s.o. von $18 bis $134 = 72 Eintraege)
  167.         geprueft.
  168.         Es erscheint ein Requester: Blockzeiger-Test
  169.         Mit "Nein" koennen Sie diesen Test ueberspringen und den RootBlT
  170.         beenden.
  171.         Bei DD-Disketten gibt es die Bloecke 0-1759 = max. $000006DF
  172.         Bei HD-Disketten gibt es die Bloecke 0-3519 = max. $00000DBF
  173.  
  174.         Wie Sie oben feststellen koennen, MUSS NICHT jeder Zeiger in der
  175.         Liste belegt sein, sondern kann auch Null sein. Die  Liste sieht
  176.         also bei jeder Disk anders aus (abhaengig vom Hash-Wert der File-
  177.         und/oder SubDir-Namen).
  178.  
  179.         Fall a:
  180.         Nun tauchen in letzter Zeit immer wieder Disks bei mir auf (auch
  181.         kopierte Fish, die unmoegliche Blockzeiger besitzen. Also z. B.
  182.         $FFFF0800 s. o. bei $9c . Ab KS2.04 werden diese Fehler meist
  183.         abgefangen, aber nicht immer. Mit KS1.3 kommt beim dir- oder
  184.         copy-Befehl SICHER  der GURU. Ich habe KEINE Vorstellung, ob
  185.         ein DiskCopy-Prg. oder die Hardware (Disk oder Laufwerk) diese
  186.         Fehler erzeugt. Ich habe es bis jetzt nicht geschafft, selbst so
  187.         eine Disk zu erstellen.
  188.         VT testet nun im 1. Durchgang jeden Blockzeiger in der Liste auf
  189.         Ueberschreitung der max. Block-Nummer. Sollte dies der Fall sein,
  190.         so erscheint ein Requester:   z. B.
  191.                         Blockzeiger falsch
  192.                             $ 00001400
  193.                      Loeschen           Weiter
  194.         Sie koennen nun zuerst auf dem Bildschirm nachschauen, welcher
  195.         Blockzeiger diesen falschen Inhalt hat.
  196.         Wenn Sie Weiter waehlen, wird der Test abgebrochen und RootBlT
  197.         beendet.
  198.         Waehlen Sie Loeschen, so wird der entsprechende Blockzeiger auf
  199.         Null gesetzt, die RootBlockCheckSum neu berechnet und der Root-
  200.         block auf Disk zurueckgeschrieben. So werden im 1. Durchgang
  201.         alle 72 Zeiger durchgetestet.
  202.  
  203.         Fall b:
  204.         Die Blockzeiger der Liste MUESSEN (Kenntnisstand Feb.93) auf
  205.         einen SubDir-Block oder einen FileHeader-Block zeigen. Es war
  206.         nun 1986/87 ein Trick, gleich nach der RootBlockCheckSum bei
  207.         $18 einen Blockzeiger einzusetzen, der NICHT auf obengenannte
  208.         Blocktypen zeigt, sondern auf einen FileDataBlock. Erfolg damals:
  209.         Unter KS1.1/2/3 konnte man das Spiel booten und ohne Probleme
  210.         damit spielen. Wollte man aber mit dem dir-Befehl sich die Disk
  211.         anschauen, so kam sofort ein Task held ... .
  212.         Unter KS2.04 bekommt man jedoch mit dem dir-Befehl eine Ausgabe
  213.         ohne GURU.
  214.         Irgendjemand bringt nun seit Herbst 92 wieder solche Disketten,
  215.         ABER mit Viren verseucht, in Umlauf.
  216.         Mit KS2.04 koennen diese Viren (File, Link, Trojan usw.) ohne
  217.         Problem mit vielen AntiVirusPrg.en entfernt werden.
  218.         Anders sieht es aber fuer die Benutzer von KS1.3 aus. Die Dis-
  219.         ketten koennen NICHT getestet werden.
  220.         Entweder ein Prg. unter KS1.3 bricht den Test ab (VT meldet:
  221.         Object not found) oder die Prg.e verabschieden sich mit GURU .
  222.  
  223.         Deshalb fuehrt VT einen 2. Testdurchgang durch und ueberprueft
  224.         die Zeiger, ob sie auf den richtigen Blocktyp zeigen. Falls nein,
  225.         erscheint ein Requester:  z. B.
  226.                      kein Dir/FileHzeiger
  227.                           $ 00000400
  228.                   Loeschen           Weiter
  229.         Waehlen Sie Weiter, so wird der RootBlT beendet.
  230.         Waehlen Sie Loeschen, so wird der entsprechende Zeiger (NICHT der
  231.         Block) geloescht, die RootBlockCheckSum neu berechnet und der
  232.         Rootblock zurueckgeschrieben.
  233.         Wenn Sie DANACH unter KS1.3 die Disk testen, so sollte das Virus-
  234.         teil gefunden werden.
  235.         Aber auch wenn Sie selbst KS2.04 haben, sollten Sie den falschen
  236.         Block loeschen, das Virusteil loeschen und erst DANN die Disk
  237.         weitergeben. Der Bekannte koennte ja noch KS1.3 haben !!!!!
  238.  
  239.      Hinweis 10.10.93:
  240.         Falls Sie versuchen mit KS1.3 eine FastFileSystem-Disk zu testen,
  241.         erhalten Sie beim Rootblock die Meldung "RootBlockProblem", da
  242.         unter KS1.3 das FastFileSystem noch nicht im ROM eingebaut war.
  243.         Der RootBlock ist unter KS2.04 bestimmt ohne Probleme testbar.
  244.  
  245.         Heiner Schneegold
  246.  
  247.   Amiga ist ein eingetragenes Warenzeichen von Gateway 2000
  248.  
  249.