Author Topic: ScanDEEP  (Read 5932 times)

Offline Guillaume

  • Newbie
  • *
  • Posts: 9
« on: June 04, 2010, 02:55:10 PM »
This tool will be useful for analyze Amiga TOSEC disk, example :

  ScanDEEP 0.8 beta2 - (c)2001 Ralf 'hippie2000' Steines
  For legal ADFs check out    

  Arch "17bit-0085.dms" (5.201 secs)              
  17bit-0085.dms 454403 ---arwed 01-Jun-2003 03:26:56.00 E4372C11 d {A} DMS disk archive  
    =>           901120 -------- ........... ........... F873FD2A d {S} Standard ADF image

  Disk "17bit-0085.dms=>" (1.221 secs)                    
  =>                 901120 -------- ........... ........... F873FD2A ADF_NORM, DSDD, 2 x 80 x 11  
  Bootable-Disk        1024 altered: 10-Jan-1978 15:37:45.24 7C9EFC5E OFS, Standard bootblock (1.3)
  "17 Bit Disk 85"      Vol created: 14-Feb-1987 05:14:58.18 98A7FFE5 OFS, 444F5300, Validated    
  .fastdir              496 ----rwed 10-Jan-1978 15:37:40.14 707C6D91 d                                  306 ----rwed 24-Apr-1988 17:25:04.37 566FBE95 d {D} Disk icon              
  loader1              1860 ----rwed 24-Oct-1997 21:58:13.33 6BB4881E x                            
  loader2              1580 ----rwed 24-Oct-1997 21:59:18.18 C407FEF9 x                            
  MoreRawData        262143 ----rwed 24-Oct-1997 21:51:09.00 E490B37A d                            
  picshow              2016 ----rwed 10-Jan-1978 14:45:24.34 AE240EA6 x                            
  Print                2176 ----rwed 01-Aug-1986 06:17:15.09 E50901F4 x                            
  RawData            274431 ----rwed 24-Oct-1997 21:47:57.27 ........ d                            
    ### Blk 1187 (FileData) - wrong CHECKSUM (after 253272 bytes)                                  
  SetMap               4500 ----rwed 10-Jan-1978 14:21:48.44 94A8CB75 x                            
  title               37412 ----rwed 24-Apr-1988 17:50:36.48 3FC1ACED d {D} IFF ILBM picture            458 ----rwed 24-Apr-1988 17:50:39.26 56EE8B8A d {D} Project icon          
  devs/                 Dir ----rwed 10-Jan-1978 14:20:14.45                                      
    .fastdir             40 ----rwed 10-Jan-1978 14:20:14.48 3B8CF715 d                            
  devs/keymaps/         Dir ----rwed 14-Feb-1987 14:49:12.14                                      
    17bit              1456 ----rwed 14-Feb-1987 14:49:13.43 8B990D9E x {I} system keymap file    
  s/                    Dir ----rwed 10-Jan-1978 14:46:51.41                                      
    .fastdir             40 ----rwed 10-Jan-1978 14:07:09.42 4FBDDC6D d                            
    startup-sequence     28 ----rwed 10-Jan-1978 14:46:52.18 70F6DFF4 d {S} ASCII Text (7bit)      
  "SLAMMER 1988/"       Dir ----rwed 26-Aug-1987 23:14:56.46                                      

  Scan conditions                                                                  
  ScanDEEP 0.8b2           21.03.2004 -                                            
  xvs.library 33.42        16.05.2004 804 viri (326 boot, 374 file, 104 link)      
  xadmaster.library 12.1   28.09.2003 120 archivers (80 disk, 27 file, 15 filesys)
  xfdmaster.library 39.15  09.03.2003 300 packers (141 int, 159 ext)              
  xpkmaster.library 5.2    08.09.1999 36 packers (34 pack, 0 arc, 10 crypt)        
  FileID.library 8.0       9.7.98     645 filetypes (645 by data)                  
  Idm.library 1.144        28.2.99    1161 filetypes, (1161 by data)              


A public distribution is it possible?

Offline PandMonium

  • Administrator
  • Hero Member
  • *****
  • Posts: 1329
Re: ScanDEEP
« Reply #1 on: June 05, 2010, 02:12:33 PM »
Hi, i've no idea of what is that tool maybe mai knows more. If not i'm sure that at EAB someone knows :D
The tool itself should be cataloged in our dats, no?

Offline Guillaume

  • Newbie
  • *
  • Posts: 9
Re: ScanDEEP
« Reply #2 on: June 06, 2010, 12:56:25 AM »
It seems to be a private tool of the owner back2roots  ???

Offline Symmo

  • TOSEC Contributor
  • Jr. Member
  • **
  • Posts: 55
Re: ScanDEEP
« Reply #3 on: June 07, 2010, 05:25:04 PM »
Interesting seen some scan results around the place does tar and gz stuff to .
Its a info displayer of whats in the actual disk images etc.. .
Shows proper dos type for eg a 1.3 disk so could be handy to sort and know what os it was for etc..
also gives details like library info (dos disk) for what system its for like .60

Arch "FTP:pub/geekgadgets/amiga/m68060/alpha/ixemul-47.2-060.tgz/ixemul-060-47.2.tar" (1.762 secs)
  ixemul.debug   1649772 ----rwed 10-Mar-1998 17:17:58.00 E57391E7 x {T} ixemul.library {$} ixemul 47.2 [68060, fpu, amigaos] (10.2.98)
  ixemul.library  165764 ----rwed 10-Mar-1998 17:17:05.00 780B6887 x {T} ixemul.library {$} ixemul 47.2 [68060, fpu, amigaos] (10.2.98)
  ixemul.trace    204564 ----rwed 10-Mar-1998 17:17:48.00 B49C7C3D x {T} ixemul.library {$} ixemul 47.2 [trace, 68060, fpu, amigaos] (10.2.98)
  ixnet.debug     216656 ----rwed 11-Mar-1998 01:04:32.00 DC74979A x {T} ixnet.library {$} ixnet 47.2 [68060, amigaos] (10.2.98)
  ixnet.library    15512 ----rwed 11-Mar-1998 01:04:32.00 BF0D4D31 x {T} ixnet.library {$} ixnet 47.2 [68060, amigaos] (10.2.98)

At the bottom were it gives results u see the scandeep version its old 2004?
the info below that is the things it scans for i take it  like virus scannners and id matchers and the amount they do.
And with those lib type looks like a amiga program i take it .

could be handy for something similar to quickly sort new stuff for the amiga renamers.

Try this as your wallpaper if you are new :-)

Offline Aral

  • TOSEC Member
  • Sr. Member
  • ****
  • Posts: 410
Re: ScanDEEP
« Reply #4 on: June 09, 2010, 12:36:28 PM »
The best program to check .adf files is Andreas's excellent ADFCHK program.

Here is the readme file

adfchk v0.2.2 by A. Eibach (c) 2007 - 2010               03 Dec 2009

A long-time spare-time project of mine has finally MATERIALIZED!

This tool makes it possible to check ADFs (Amiga Disk Files) without needing
any Amiga tool at all!
A software like this is necessary because the amount of ADFs has exponentially
increased in these almost 15 (!) years of UAE (Ubiquitous Amiga Emulator)
Floppy emulation is more and more accurate and sometimes simply must be slowed
down to correctly read every sector, especially with alien format disk images.
Now imagine you've got 1,000 ADF images on your hard disk and you need to
check them! A possible way is to use one of the excellent checking programs
like Dave Haynie's DiskSalv[TM] and probably be unable to finish your checking
task within 1 month! :->
That's when ADFCHK comes into place.
You can either use it by MENU with ONE file (NOTE: there's no shiny file selection
yet) or use the supplied BATCH file(s) (sorry, Windows only for now, a shell script
for bash is in the works!) for  t h o u s a n d s  of files!!
The BAT file took days to finish and lo' and behold, it is not one of your
commonly known run-of-the-mill batch files!!

 WHAT adfchk CAN DO
 - find boot and data block checksum errors on AmigaDOS disks, writing the exact
   location (cylinder, surface, sector) into a log file
   [Also scans NDOS disks, but I'm planning to keep the logging to a minimum
    for this disk type]
-  detect three types of the LAMER virus which randomly infects single sectors,
   destroying them irreversibly by writing its name across the WHOLE sector;
   now also supports a bunch of boot viruses and a small amount of file viruses
   (LINK viruses are in the works, since this is no easy task)

 - avoid bogus "checksum errors" by properly reading the disk's bitmap; only
   errors on blocks which are USED and KNOWN to the AmigaDOS file system
   are reported as actual "checksum errors"

 - scan within ZIP (and since 0.2.0: DMS!) archives for ADFs; even supports
   partly broken ZIPs, e. g. if Disk 1 is an underdump (<880K), it will be
   skipped, but Disk 2 will be checked anyway.

None. Only (albeit important) code fixes and some cosmetic things with command-line output.

- DMS file support!! (please consider this still EXPERIMENTAL)
  (CAUTION: there is a RARE behavior which will sometime lock up ADFCHK with very large
   DMS archives; I still do not know why this happens. It never happened with ZIP trees,
   be they as huge as possible...)

- BOOT block virus detection support:
  Byte Bandit (3 variants supported [NB: encoded ones to come]), Byte Warrior,
  Joshua 1 + 2, Pentagon Circle 1 + 2, Little Sven, Eleni 1 (MessAngel-B),
  Sepultura, Leviathan
- FILE virus detection support:
  Jeff/Butonic (versions 1.31 + 3.10), SADDAM/IRAK
- Detection of special disk formats/signatures:
 -- Rob Northen Copylock disks (DosType = 'RNC')
 -- Quarterback backup sets (DosType = 'Qb'+number or 'QB'+number)

- Format-independent DMS transfer error detection (DMS!!ERR; will also handle NDOS disks)

- Deep-checking (automatic) of DATA blocks; now also detects errors of:
 -- Bad sequence numbers
 -- Bad nextData pointers
 -- Bad validData values (greater than 0x1E8 or less than 0x01)
 (NOTE: Deep checking is auto-disabled for blocks with illegal header key numbers,
  in order to prevent misdetections!)

 - decode SADDAM-infected blocks and optionally write the corrected results
   back to the images
 - proper LINK-virus detection (this will require me to write an extra routine for hunk handling) 

NEW SINCE 0.1.3:
- support for extended ADFs (detection only for now)
- support for over- and underdumps; no more interactive key-pressing in batch mode
- scanner now uses _XXXX suffixes to tag the log files which makes it easier to
  isolate the actually erroneous
- lots of phony reports of "checksum errors in data blocks" eliminated by better
  and deeper checking of data block structures and expected AmigaDOS properties.

- supports block types (file list, header, user directory, formatted, unknown...)
- standard type recognition works now (FFS + INTL/NO INTL, DIRCACHE etc.)
- FFS detection support (it makes no sense to check FFS disks for "checksum errors",
  since FFS does not use checksums for data blocks
- fixed lots of misdetections and phony reports of "checksum errors"
- lots of minor tweaks, code cleanups and fixes.

Nothing to "install" here: only make sure that LiteUnzip.dll is in the
current path!! (when I really feel the need to, I could code it a little
better and force the tool into a crippled mode where you can only test
plain .ADF's whenever the DLL cannot be found, but this is only a "maybe", since
there are much more important things to do first)

Usage is very simple:

adfchk.exe [-f <file name> [-l <log file>][-b(atch mode)]]

./adfchk [-f <file name> [-l <log file>][-b(atch mode)]]

| NOTE: Unlike RC1 and earlier versions, the application will now auto-enter
| menu mode due to a lot of user requests. If and only if the '-b' option is specified
| AND a filename is given, a non-interactive batch mode will be used.
| This also made some changes necessary in the four *.BAT files.
| ADDITIONAL NOTE: Do not be surprised if the batch header gets suppressed if the -l
| option was specified. This is DELIBERATE behavior, since I do not want to have the
| header displayed a few thousand times when unattendedly scanning huge archives.


- Type "adfchk" on command line - a MENU opens:
  (1) Purpose of the program -> get another boring text what the program is for
  (2) Read ADF into buffer -> load ADF from hard disk into memory
  [NOTE: at this stage, file MUST be called DEFAULT1.ADF - a file selection menu
   is planned, though!]
  (3) Check directory structure of ADF in buffer    [DOES NOTHING YET at the moment]
  (4) Check for block checksum errors on disk image->check image, which must now
      be in memory buffer
  (5) Quit

   Results will be in ADFCHK.LOG on the current directory.


 This is the mode you will probably use very frequently, as with 1,000 images
 and more, it would be a very awkward procedure to check those in interactive
 The program detects the -f option, which specifies a filename and then will
 go automatically into batch mode.
 The -l option can also specify a log file instead of the default file "ADFCHK.LOG".
 This is the only reasonable way to get a bunch of logs.

 adfchk -f blah.adf -l blah.log -b

 will log the checking results of 'blah.adf' to the file 'blah.log'.


 Since it will still take a whale of a time to implement a recursive search
 through directories that will work on BOTH Linux and Windows (which is my
 goal!!), I've written a very nifty BAT file (Windows only for now, sorry!)
 which is able to RECURSIVELY scan each and every directory starting from the
 current one. Yes, indeed for 1,000 ADFs, it will be run exactly a thousand
 times in sequence. But since it is so small, it won't take much memory;
 however, CPU usage will go quite high when the script is running through
 thousands of files: this is normal.
 To make use of mass batch mode, do this:

 First of all, you must make sure that save from the appropriate .BAT file,
- LiteUnzip.dll
 must be in the directory from which you want to start the scan.
  CHKADF.BAT  to test ADF files (and only ADF files)
  CHKZIP.BAT  to test ADF files inside ZIP archives (and only ADFs inside)
  CHKALL.BAT  to test both standalone ADF files and ADF files inside ZIP archives

When the .BAT file has finished scanning (which can take easily half an hour with
5,000 files!), it will put lots of ADF????.LOG files into the .\logs\ subdirectory
relative to the directory from where you started the search.
Unfortunately, in the .BAT solution I was forced to do this, because writing
everything to ONE log file would make the file that big so that *most* editors
would call it quits. (500 MB is no joke, but possible! Mind you, this is ten
thousands of lines!!)

 - search recursively by running the tool once, accessing all subdirectories
   recursively from start directory in both Windows and Linux
-  check for in-block errors (wrong sequence numbers with files, illegal header
   keys etc.); however, this will require a ...

-  ... linked list for the directory tree.

-  better handling of NDOS disks (ADFCHK should _no_ longer complain about 1760 checksum errors
   in log file with a DD disk that is completely in alien format.)

- M. Kalms for his invaluable tips and patience during development
- JL Gailly and Mark Adler for zlib (although I'd like to see built-in ZIP support
  without contributor's code)
- Gilles Vollant for coding the 'miniunz(ip)' tool which showed how to unzip contents
  of a ZIP archive to hard disk using zlib
- Jeff Glatt @ CodeProject.COM for his LiteUnzip.DLL which finally made unzipping to MEMORY a walk
  in the park
- 'Oddbod' (EAB) for contributing the Linux Makefile - and for constructive criticism and
  reasonable suggestions
- Someone else for letting me use his private server to get the whole TOSEC collection
  (to have something to play with; you know who you are :))
adfchk is distributed in the hope that it will be useful, but AS-IS, WITHOUT ANY WARRANTY
and without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License v2 (LICENSE / LICENSE.txt in the package) for more

ADFCHK has finally found a new home on SourceForge:


You can contact me under
I will listen to your flames, roars of rage, as well as appreciate any feedback, suggestions, fixes, patches ...

Offline Guillaume

  • Newbie
  • *
  • Posts: 9
Re: ScanDEEP
« Reply #5 on: June 09, 2010, 12:58:26 PM »
Yes but for now they are complementary ....

Offline mai

  • TOSEC Member
  • Full Member
  • ***
  • Posts: 175
Re: ScanDEEP
« Reply #6 on: June 09, 2010, 06:12:03 PM »
"ADF Ren v0.80" by "Felskrone" is my personal favorite.
You can compare as much ADF(DOS) as you want and see where are the differences.

Offline Crashdisk

  • TOSEC Member
  • Sr. Member
  • ****
  • Posts: 254
Re: ScanDEEP
« Reply #7 on: March 11, 2011, 03:18:29 PM »
Very very powerful util ...

little preview:

    - executable file detection
    - ADF disk image detection NORM/EXT1/EXT2, even non bootable NDOS disks
    - Kickstart ROM image detection and integrity check
    - hunk structure validation for executables and linkable object code, supporting all
      known public hunk types (TODO: PPC hunks)
    - romtag finder (detects libraries and devices and lists real lib name and version)
    - version string finder
    - CRC32 calculation
    - virus infection test
    - detection of compressed and linked files (xfd/xpk)
    - detection of file and disk archives and entering them (xad)
    - detection of filesystems and entering them (internal+xad)
    - file type recognition (internal + Idm and FileID library, datamaster disabled due
      to hanging the program too often)

    - ADF type and integrity test
    - dos type detection (internal+xad)
    - bootblock virus infection test (xvs)
    - bootblock checksum test (bootable/data disk)
    - sector virus infection or corruption test of ALL sectors, even unused ones (xvs)
    - integrity test of entire directory tree
    - integrity test of all fields of ALL sector types
    - CRC32 calculation of disk image, bootblock and volume node (name|dostype|date)
    - disk validation test
    - NDOS disks (which are not recognized by xad) are scanned in "recovery mode",
      allowing to find viri in some more NDOS disks.
    - KICKstart disks (also not recognized by xad) are scanned for the ROM image
      which is analyzed and integrity tested then (automatic detection of ROM size,
      kickstart and exec version extraction)

i need ^^