		project - iisAPE
		version - beta 0.2
		download from - www.elaboration.f2s.com


  Usage
 
 java iisAPE

  Expected output
 

 	iisAPEvb0.2 by elab (www.elaboration.f2s.com)
	Usage:	java iisAPE


 @ iisAPE started at DATE

 @ Client xxx.xxx.xxx connected.....


  Changes from version beta 0.1 to 0.2
 
 There was a bug in the way iisAPE was writing the exploit strings to the socket.
 Converting the carriage return characters that you find at the end of a HTTP
 header argument resulted in converting four characters instead of two.  This
 was recitfied in classes: iisAPE & http200okWrapper.  Now both use the characters
 hex 0x0d,0x0a , dec 13,10 to indicate end of line.

 Above fixes result in the IIS server respdonding correctly to the commands loaded
 post HTTP/1.1 200 OK detection.

  Problems 

 The code that blocks the worms from reconnecting doesn't function properly.  
 Already exploited worms DO reconnect.

 Command load post HTTP 200 OK TRUE detection takes longer becuase a thread
 was added.  Worm infected IIS servers reach high CPU usage rates and can
 sometimes take longer than normal to respond - potential flaw in the automated
 part of the application - IIS server may NOT respond fast enough - disrupt
 command sequence...

  Solutions
 
 Now writes commands POST HTTP 200 OK TRUE detection as an array of bytes - 
 passes the data to TCP software faster and is written to the wire faster - 
 helps with possible poor IIS response.

 Added thread.  Now the program pauses after sending data and declaring an 
 inputstream for the socket.  Then it sends another two carriage returns for
 encouragement.

 Timestamping added.  Now stamps client connection and disconnection and iisAPE
 start.

  Aims for vb1.0

 Fix blocking class - stop already tested worm clients reconnecting

 Add loggin feature - should log client connect, disconnect and APE start time.

 Add method that checks blocked lsit from test file also



	
  
