Bobek Virus - Amiga Virus Encyclopedia


Amiga Virus Encyclopedia
Bobek Virus


Entry...............: Bobek!
Alias(es)...........: Bobek 1.01, Bobek 1.05/1.06, Bobek 1.1
Virus Strain........: -
Virus detected when.: -
              where.: internet
Classification......: Linkvirus, memory-resident, not reset-resident
Length of Virus.....: 1. Length on storage medium:          460 Bytes
                      2. Length in RAM:                   65535 Bytes

--------------------- Preconditions ------------------------------------

Operating System(s).: AMIGA-DOS Version/Release..: 2.04 and above (V37+)
Computer model(s)...: all models

--------------------- Attributes ---------------------------------------

Easy Identification.: visible text '[BOBEK!]' in every infected file

Type of infection...: Self-identification method in files:

                      - compares length declared in hunkheader
                        with the real length (this also
                        avoids infection of some crunched files)

                      Self-identification method in memory:
                      - checks for $0 in libOpen address of exec.library.
                        Exec base is available by second
                        longword of memory, so this routine
                        isn't used in normal system. This address is LOST
                        forever (till reboot)!
                        Note that this makes VT-Schutz not work.

                      System infection:
                      -  infects ExNext function of dos.library
                         The paths to infect are made with
                         NameFromLock and filename in returned FileInfoBlock.
                         This gives in some cases wrong paths,
                         so some directories won't be touched by virus.
                         The patch is done in way that prevents VirusZ
                         from inviting user to VectorCheck.

                      Infection preconditions:

                      - File is between 1000 and 32000 bytes
                      - Hunk Code is found
                      - File is not infected already
                      - device is validated

Infection Trigger...: Scanning directories (filemanagers,
                      filerequesters etc.).
                      Not all files that could be infected will
                      be infected at once.

Storage media affected:
                      all DOS-devices

Interrupts hooked...: None

Damage..............: Permanent damage:
                      - none
                      Transient damage:
                      - none
Damage Trigger......: Permanent damage:
                      - none
                      Transient damage:
                      - none

Particularities.....: The virus code is highly optimized and looks
                      like work of very experienced assembler programmer.
                      The linker is made with one Open/Close,
                      so there is no so much noise like with some
                      other viruses.
                      The code isn't crypted and the linked part
                      has always static size 460 bytes.
                      Memory allocation is done only once at start because
                      of checking small range of filesizes.
                      The infected file has always replaced first longword
                      of first code hunk with BSR.W to init code which
                      runs the program and then the virus itself.
                      Due to above there is no problem of GURU
                      after running from Workbench.

                      The programs with reloc entry at the replaced
                      long may crash, but I couldn't find such an example,
                      there is test for $4E at the first LONG,
                      so files with such jumps will be untouched
                      (including the reloc ones: 4EF9 and 4EB9).

Similarities........: Link-method is first hunk increasing.
                      Used known code to check if the Open vector
                      points to ROM.

Stealth.............: The cheating of VirusZ`s VectorCheck is done
                      with patchformat known from MCP and PatchControl.

                      The virus puts the new infected length
                      to FIB. In the other words the ExNext
                      always returns the real size of file.

                      The known from Motaba-3 trick is used
                      to check if Open points to ROM.
                      Due to that no virus action is visible
                      in SnoopDos or DosTrace.

                      There are used two additional techniques to
                      decrease the noise during listing of directories:
                      - buggy check if size is dividible by 4
                      - infect try will be performed depending on
                        state of bit 0 of $dff007
                      IMHO it isn't good enough.

Armouring...........: Nothing special.

Comments............: The virus contains VISIBLE string:


                      1. There is no code to restore filedate
                         after infection.
                      2. Virus is not crypted.
                      Maybe someone forgot to release it few
                      years ago... :-)

--------------------- Acknowledgement ----------------------------------

Location............: Pawlowice, Poland  4.2001
Classification by...: Zbigniew Trzcionkowski
Documentation by....: Zbigniew Trzcionkowski
Date................: 4.2001
Information Source..: Virus disassembly
Copyright...........: This documentation is public domain

===================== End of [BOBEK!] ==================================

Antivirus removal...: Kickstart 1.2 & 1.3 : VT-Schutz v3.17
                      Kickstart all others: VirusZ III with Xvs.library installed

HEX dump of Bobek 1 virus:

Virum Help Team
Denmark & Canada
Copyright © All rights reserved