[ Oversized Filenames And The Windows Shell ]--------------------

I was fuzzing IM file transfers with a friend and we had the idea
to send a file  with a too  long name,  something larger than 255
chars (MAX_PATH). It was not possible to create  such a file with
the  explorer or the cmd shell in windows (both XP SP2 and Win2k3
SP1) so I decided to use raw Win32 API  calls to get around that.
I recalled these few lines from the MSDN library:

  lpFileName 
   Pointer to a null-terminated string that specifies the
   name of the object (file, pipe, mailslot, communications
   resource, disk device, console, or directory) to create
   or open. 
   If *lpFileName is a path, there is a default string size
   limit of MAX_PATH characters. This limit is related to 
   how the CreateFile function parses paths. 

   Windows NT: You can use paths longer than MAX_PATH
   characters by calling the wide (W) version of CreateFile
   and prepending "\\?\" to the path. The "\\?\" tells the 
   function to turn off path parsing. This lets you use 
   paths that are nearly 32,000 Unicode characters long. 
   However, each component in the path cannot be more than 
   MAX_PATH characters long. [...]


32000 chars, huh?  That sounds good to me. The IM fuzzing did not
work out as planned - but what happened in Windows when I created
oversized files was ... disturbing.


[1] [limitations]------------------------------------------------

  The files  I renamed to something  that was 255 chars in length
  would become pretty persistent fucks.  Neither explorer.exe nor 
  the cmd shell could  remove, rename, move or copy the oversized
  files at all.
  This was tested on WinXP SP2 and  Win2003 SP1, with exactly the
  same result respectively. Neither of the 2 shells shipping with
  modern versions of Windows OS support oversized filenames.

  Even worse were oversized directories. Just like files, I could
  not delete/copy/move/rename them at all.  However, it gets even
  better.  They could not  be searched, browsed, or enumerated in 
  any way. There was absolutely  no way to determine the contents
  of an oversized directory by conventional means. 

  You always wanted a way to hide your data without crypt0? Easy!
  Just use xmv (see [3]) to oversize-rename  your porn folder and 
  your mom will be hopelessly lost! \o/

  Now which problems arise out of this?

  - Trojans hiding in oversized directories somewhere on the PC,
    preferably in the %TEMP% directory. The oversized dir inside
    %TEMP% will never be deleted because it cannot be deleted by
    the windows  shell, and the  trojan has very good chances to
    not be found in there.
  - Trojans writng their logfiles or similar information to such 
    locations.
  - Reckless teenagers hiding away their pr0n from their parents
    and the world outside. 


[2] [investigation]----------------------------------------------

  I tinkered with the API a bit to investigate the extent of what
  is possible and what is not. First and foremost, it is strictly
  impossible to set the  working directory of any process to some
  oversized directory. It is possible to do all of the following,
  though (using the right API):

    ° create oversized files and directories
    ° move, copy, rename oversized files and directories
    ° delete oversized files and directories
    ° enumerate contents of an oversized directory

  Thus, the flaw is clearly in explorer.exe and cmd.exe.


[3] [solution]---------------------------------------------------

  Since you might also want to tinker with this phenomenon a bit,
  I coded a small set of commandline tools that can actually deal
  with oversized files and directories:

    ° xmv : move files and directories
    ° xmd : create a directory
    ° xcp : copy files and directories
    ° xls : directory listing
    ° xec : execute a file
    ° xrm : remove files and directories
    ° xio : simple cat-like utility for in/output
   
  source code && binaries of course. enjoy.


-------------------------------------------------[ rattle. eof. ]