Background Data Migration

When creating or editing files, certain Windows 95/98 applications pickup garbage 
from hard drive. They put this garbage into file's unused fragments.

When unexpected user transfer this file to different computer, the content of user's 
hard drive unexpectedly transferred to different computer.
If "different computer" is Windows 95/98 and this file deleted from this computer again, 
then this content becomes part of background and can be spread further.
Let's call such background data migration as BGM and the process of including
of the bagckground data into legitimate file as BGP, Background Poisoning.

If application takes baground stuff in random fasion, then a probability, p, of picking up
of given fragment of information seems p = fragment_ratio = fragment_size/size_of_unused_space.
For example, if fragment_size is 3000 bytes (average page) and size_of_unused_space = 3 Gigabytes, then

However, if computer intensively worked with private information, then probability can be 99%.

If to take into account that, that application takes backroung not in randome fasion,
but first takes clusters closest to filled edge, then if application starts right after
file deletion, then "effective_fragment_ratio"=p can be close to 100% even if most
of HD space is empty and if fragment_ratio is about 0.

BGP unlikely is a "deliberate" feature. It is rather the "performance improvement" 
feature: merely "not cleaning up" the place when putting a file there.
In other words, it is a style of programming. This style can be inadvertently employed
by inexpirenced programmer in Microsoft Visual Basic or Microsoft Visual Studio C++.

Programmer's who uses this style should explicitly warn users or clients about this
feature, but perhaps does not have to do this. Because of every other professional 
programmer must be aware about possibility of this style and must take own precautions.

In other words, if author of Microsoft Outlook or Microsoft Access employs this feature 
and do not inform the millions of user's of this feature, that the author cannot be 
held responsible for massive BDM.

In private content managing companies, using such software, as using software in general,
is a matter of professionalizm of such company employees.

Programmer or business professional who denies existance of BGP, perhaps looks as 
a dentist who denies existance of bacterias and refuses to use gloves. 
We don't judge this behaviour, but would not like to go to such a doctor.

Windows XP

   Windows XP seems is immune to BGP. For example, in all tests by both C and VB programs
   in section "Details" (made on Windows XP Home Edition. Version 2002 Service Pack 2),
   the unused fragment of the files was filled with zeros. To the honor of XP, it 
   must be said that XP fills unused fragments with zeros even one of the test
   partitions is FAT32. In other words, this operating system keeps track of 
   positions where program actually wrote information and where not wrote.
   In other words, XP stood as a guard between Application and FAT32.

   But, amount of tests was to small to make definite conclusion. It is better
   to have some explicit words from Microsoft in this case.

   Some tests: Hard_drive_background_collectors.txt
   Example in C
        Brief code: Make_Probe_C.c
   Example in VB   
      Brief code: MakeBigFile.frm

   Access to Text

Here are some recommendations:
(But, the final responsibility of making a reasearch is on your own.)



  1. If you discovered that the files which you distribute publically, contain
     private information migrated from other sources, and if you cannot stop using
     BGP-programs, then create two segments on your network, one with private data
     "POISONED" and other "CLEAN".

  2. For CLEAN environment, take hard drives from poisoned system,
     erase every byte of information from them starting from MBR.
     Reinstall all operating systems from clean manufacturer distribution media.
     Reinstall all tools which you use in work from clean media.

  3. Thouroghly control data transfer between POISONED and CLEAN segments.
     Do not allow NetBIOS browsing between them.
     Allow only FTP connections.

     Don't view poisoned files on CLEAN sytem by using text editors, Web browsers,
     and remote desctop connecton.
     Don't allow "poisoned" email to reach CLEAN system.

II.  Thouroguly control type of files which you transfer between POISONED and CLEAN
     or which you distribute publically.

     Have intimate knowledge about file formats which can conduct BDM.

     a. know all offsets of unused fragments in file of type

         or any others.
     b.  know well which application works cleanly (cleans unused segments) and 
         which does not.

     c.  formats txt and bas appear as BGP immune, because 
         there is no "invisible" info, so all info is "usable".
         (Of course, it depends on application which created them.
          Negligently written application still can drop a piece of "dirt".)
     d.  formats which you know are written sequentially, so they cannot
         have "gaps". For example, application logs.

     e.  formats jpg, gif, png, should not have a "wasted space" because they
         created for Internet.

III. If you are in NTFS enviroment, but were "lived" on Win9x before and have
     legacy files, you should check or clean up every such file.
     In this case, intimate knowledge of every used format may help or may be

     For example, there is a program which we wrote to clean up Microsoft Access *.mdb
     file. It exports *.mdb database to text file and then this text file can be
     converted to *.mdb database by the same program on CLEAN computer. 
     Of course, there probably is Microsoft db to text converter, but we found ourselfves
     hard to trust this converter: will it use the same drivers which make BGP?

     The same step should be done if you splitted you network to CLEAN and POISONED.

IV.  Finally, if none of above I-III cannot be done, just note that
     in plain words, the more computer works with "clean" files, the cleaner
     it should become. Because writing and deleting "clean" files refill background.
     This can be "improved" by erasing all files with private information and filling 
     the disk with one file with irrelevant infomation and then deleting this file. 

V.   If, unfortunately, you discovered that your company distributed files which
     contains privaite information in some "hidden" spots of the file, then

     1. You can inform an affected person that his/her privaite information
        was distributed and where. This is always ethical.
        This may decrease a risk that this person will sue the company because you
        are honest.
        This may increas a risk that this person will sue the company because
        the person may never known otherwise about the leak.

        Files can live very long live in archives or in different spots in the World.
        You never know when informational-mine can blow up and its better to disarm it

     2. Ask people at destination of your files to erase them.
        This is again a two side risk.
        If you published files on the Web and thousands of unknown users
        downloaded them, that publicly asking them to erase the files may not
        reach the callees and create even more risk of attracting extra attention to
        the files.

This situation can be upleasant for companies who deal with private information:
medicine, lawers, electronic insurance. Not needed to say that company which intensively 
operated with private infomration in Win 9x environment can have literally tonns, 
thousands of private records in "hidden" spots in "innocently" looking files.