icedump6.txt

Cracker终结者——提供最优秀的软件保护技术

           this is release 6 of the winice dumper.

   -----
   news.
   -----

   - source code included as usual, it's a dynamic VxD now, no need to patch
     winice itself (happens runtime). stuff in static code and data segments
     (_STEXT and _SDATA) can be changed, but you must reboot before loading
     the new version.

   - simpler command syntax, PAGEIN is no longer tweaked. each command must
     start with a character that would normally make winice complain about
     an invalid command, suggested prefix is the '/' (forward slash) since it
     is familiar to IRC users already ;-).

   - certain commands need to call win32 API functions whose addresses are
     looked up by using winice's internal symbol tables. for this to work you
     need to have kernel32 and user32 exports loaded into winice (winice.dat).

   - and you thought it was impossible... so we're proud to present the first
     mp3 decoder/player that runs in kernel mode (of win9x in our case) and
     keeps working even if you enter winice. since all this requires direct
     hardware programming, we support non-PCI based SB compatible cards 'only'
     for now.

     anyway, a BIG thank you goes to fossil, who coded this stuff. and no,
     he's NOT gonna do the vcd player ;-)

   - even though the Procdump32 project has officially been declared dead,
     its achievements won't go down the tube: from now on icedump features
     G-RoM's Phoenix v2.0+ engine, along with a new command which lets you
     dump a full PE file directly from icedump, no external tools are needed
     anymore. i think there's not much else to explain what all this means...
     thanks G-RoM ;-)

   - added a tracer engine which is able to trace most of the currently known
     PE wrappers (bleem/pecrypt/pelocknt/peshield/petite/vbox and the rest
     which is less sophisticated). see separate document for details.

   - added a simple tetris for the homo ludens among you.


   ------
   usage.
   ------

   first of all, you have to run icedump.exe from the directory corresponding
   to your winice version to load the dynamic VxD (it's a self-loading VxD
   before you start to look for a separate *.vxd file ;-). if the VxD cannot
   find winice or recognize its version, it will simply not load, no harm
   will be done. if for any reason you simply want to unload the VxD, you
   should execute 'icedump u' and that's it. note that icedump cannot be
   loaded as a static VxD since it does not act on DEVICE_INIT and the like,
   but you can add support for that if you really need it.

   mp3 playing support requires you to run YogaPlay, the GUI for the VxDs that
   are in mp3\bin and which should be copied into windows\system or left in
   YogaPlay's own directory. YogaPlay lets you choose the mp3 files (which are
   eventually uploaded to the VxDs as a playlist, icedump itself doesn't let
   you do that) to be played, and gives you a basic control over playing them.
   if you need anything fancier, go code it yourself, source code for YogaPlay
   is included (courtesy of fossil). inside winice you have to use the '/MP3'
   command, see the description somewhere below.


   ------------------
   command reference.
   ------------------

        -------------------------------------
        /DUMP <address> [<length> <filename>]
        -------------------------------------

   the good old one, which you should be familiar with. in short, both
   <address> and <length> can be any expressions that winice can evaluate,
   <filename> can specify any drive/path. using <address> alone will simulate
   the old PAGEIN behaviour (i.e. bring in a page, but this one works for all
   possible execution modes unlike the original PAGEIN). attempting to dump
   non-committed memory won't cause a crash, however no other sanity checks
   are made, so be careful, especially when dumping from ring-0 (i.e. when the
   current CS is a ring-0 selector, dumping memory belonging to a ring-0 data
   selector has nothing to do with this). memory read breakpoints over the
   dump area should better be disabled because winice might get confused
   about the re-entry (this holds for all dumping related commands of course).

   for win32 processes you will probably want to use the '/BHRAMA' or '/PEDUMP'
   commands since they will rebuild a working PE image. have a look at the
   '/OPTION' command as well.


        -----------------------------------
        /LOAD <address> <length> <filename>
        -----------------------------------

   load first <length> bytes from <file> at <address>. sort of opposite of
   '/DUMP', same rules apply, except that no write breakpoints should be
   active.


        ------------------------------------------
        /BHRAMA <Bhrama dumper server window name>
        ------------------------------------------

   notify Procdump/Bhrama (yeah, the one by G-RoM ;-) to initiate dumping.
   you have to supply the window name only as you can see it in the caption
   bar. now, to make your own life easier, you should assign this to a F key
   in winice.dat:

        F3="/BHRAMA ProcDump32 - Dumper Server;"

   some parameters/flags can be set by '/OPTION B', look at them somewhere 
   below.

   keep in mind the following when using Procdump/Bhrama:

   1. the Bhrama server's window name can be changed in v1.5.0+ only, this
      raises detectability issues with older versions...

   2. the various Procdump options can be changed in v1.5.0+ only, some of
      them with '/OPTION B', others only in Procdump/Bhrama itself.

      for older versions you have to change then reassemble the source code
      or you can try to change it in memory (advanced users will find their
      way there, i'm not going to explain it here).

   3. EIP (and the entry point in the dumped PE image) cannot be specified
      anywhere, instead the current one is used. however only v1.5.0+ will
      properly calculate the entry point from the EIP, for older versions
      you have to substract the image base from the entry point written by
      Procdump and manually update the PE header.

      this is because v1.4.x expects an RVA and i can supply a VA only.
      v1.5.0+ will try to detect this situation and automagically recompute
      the entry point. note, that the current solution will fail if the
      original entry point falls above 0x800000 or so (i.e. for PE images
      over 4 MBytes this may be a problem).

   4. when you issue a '/BHRAMA' command, winice will temporarily resume
      execution of the entire system (so that you could specify the file
      name for Bhrama), however you are not supposed to (ab)use this fact
      and do anything else besides what you are asked to do (namely, select
      the file name ;-). not observing this simple rule will very easily
      end you up in a system crash... also, try to avoid setting breakpoints
      which may trigger during this period (e.g. those set for APIs, window
      handlers or messages and the like).

   5. the client's stack will be modified since Bhrama is called in the
      client's context, this can potentially be detected by the client...


        ---------------------
        /SUSPENDX <TID>|<PID>
        ---------------------

   suspend specified thread/process AND exit winice. this command is able to
   suspend the current thread or all threads in the current process. note that
   no breakpoints are inserted at the suspended threads' EIPs so when you
   resume such a thread winice will NOT break in. if you want to (and probably
   you do ;-) then you have to manually insert a breakpoint somewhere.

   TID/PID must be valid ring-3 handles, either obfuscated or not (will be
   automagically taken care of). use THREAD/PROC to get them.


        --------------------
        /SUSPEND <TID>|<PID>
        --------------------

   suspend specified thread/process. attempting to suspend the current thread
   or the process owning it will result in an error message but will do no
   harm to the system/winice (in case of a process the other threads will be
   suspended though). note that no breakpoint is inserted at the current EIP
   so when you resume such a thread winice will NOT break in. if you want to
   (and probably you do ;-) then you have to manually insert a breakpoint
   somewhere.

   TID/PID must be valid ring-3 handles, either obfuscated or not (will be
   automagically taken care of). use THREAD/PROC to get them.


        -------------------
        /RESUME <TID>|<PID>
        -------------------

   resume specified thread/process.

   TID/PID must be valid ring-3 handles, either obfuscated or not (will be
   automagically taken care of). use THREAD/PROC to get them.


        -----------
        /KILL <PID>
        -----------

   kill specified process. attempting to kill the current process will result
   in an error message but will do no harm to the system/winice.

   PID must be a valid ring-3 handle, either obfuscated or not (will be
   automagically taken care of). use PROC to get it.


        ------------------------
        /SCREENDUMP [<filename>]
        ------------------------

   dump the winice console to a file. note that only the Universal Video Driver
   mode is supported (i.e. in text mode you will get the DOS window's content
   and not that of winice). generally the same rules apply as for the '/DUMP'
   command. when no <filename> is specified icedump will toggle the
   screendumper between mode 0, 1, 2, 3 and 4 operation.

   in mode 1, the default mode, the attribute byte will be stripped giving
   an ASCII output.

   in mode 0, raw mode, the attribute bytes will also be dumped.

   mode 2 dumps the screen to a HTML file. a utility, ScreenDump clean, is
   provided to convert a raw dump into an ASCII or HTML dump. notes on mode 2:

   - the lines and arrows are replaced with text equivalents.
   - the standalone RAW->HTML converter is in the HTML directory.
   - the Opera browser does not display the dump properly as the table
     elements are too long.

   mode 3 dumps the screen into a LaTeX formatted file. to include the dump in
   your LaTeX document, include the line "\usepackage{icedump}" then either
   copy and paste the dump contents, or include it via an \input command. Note
   that icedump.sty requires you to have the packages: 'amssymb' and 'color'
   (dvips). If these are already in your LaTeX path, then the icedump package
   will use them automatically. You should also put icedump.sty in your LaTeX
   path. An example file can be found in the w9x\latex directory. A standalone
   converter will be available once somebody can be bothered to rip out the
   code from icedump :)

   NOTE: mode 3 is limited to softice console screens with a maximum of 255
   columns.

   mode 4 dumps into an EPS (encapsulated Postscript) formatted file.


        -------------------------
        /PAGEFLAG <addr> pPrWsUcC
        -------------------------

   change page table entry flags for the page specified by <addr>.

        pP: not present/present
        rW: read only/read-write
        sU: supervisor/user
        cC: not committed/committed

   this command directly modifies the PTEs in the page tables, so for the
   virtual address range 0x00000000-0x7FFFFFFF you have to be careful since
   on a context switch the PTEs describing this range will be overwritten and
   won't be restored when the scheduler switches the context back. other PTEs
   describing non-pagelocked pages will suffer the same fate after a page-out
   page-in cycle (or so i think at least). if there's demand for more
   intelligent behaviour, do it yourself ;-).


        ----------------------------------
        /FPU <FPU register number> <value>
        ----------------------------------

   change content of specified <FPU register> to <value>. <FPU register number>
   must be in the range of 0...7 (for ST0...ST7). <value> will be parsed as an
   extended real (80 bits). if there's demand to be able to modify other parts
   of the FPU state (eg. MMX or SSE part), let us know (or do it yourself ;-).


        -------
        /OPTION
        -------

   icedump options menu. allows you to change various icedump parameters. when
   invoked without any parameters it will print out all the options that can
   be set.

        /OPTION N              - toggle screendump expert mode on/off
        /OPTION N F <filename> - alter base filename
        /OPTION N D <number>   - alter current dump number
        /OPTION N V            - show current screendump options

   the expert mode will allow you to perform screendumps with the command
   '/SCREENDUMP' (i.e. no parameters). icedump will name the file for you
   incrementally. by default, it will save them to c:\default.000,
   c:\default.001 etc.

   you can alter the base filename/path using the '/OPTION N F' command,
   the current dump number using the '/OPTION N D' command, view current
   screendump options with '/OPTION N V' and toggle expert mode on and off
   using '/OPTION N'.

   by default, the expert mode allows up to 40 characters for the path and
   filename. if you need more, you can easily modify one of the EQUates in the
   source code. you probably want to modify the default name too. make all the
   modifications you need (they are in one place) and recompile with nasm.

   i (Ghiri) will possibly implement an auto-mode for normal dumps.

        /OPTION D              - toggle memdump expert mode on/off
        /OPTION D F <filename> - alter base filename
        /OPTION D D <number>   - alter current dump number
        /OPTION D V            - show current memdump options

   the above four commands have now been implemented for auto-memdump. to use,
   turn on the expert mode and issue the command:

        /DUMP <address> <length>