RE: Cesar Test; Good News. Progress is being made.

[Bethel, Roy E.]

Peak,

It turns out that you were right on all counts and the mistake was mine.

0) My 1st modification of ppprocess.py was correct and the results reported
(same as before and *.pyc not re-compiled) were correct but ...

1) The problem is that there are 2 [print "FAILED ...]'s. Not just 1. The
1st was the only one modified for the 1st round.

2) I put the traceback statements and a line # tag on each one. The actual
*.py is attached.

3) The traceback now works and is what I believe you were looking for.

4) The 1st [print "FAILED ...] never gets called. The 2nd [print "FAILED
...] does get called and prints the error message and triggers the
traceback. The *.pyc time stamp is now the current date and time. I believe
this explains everything.

5) The traceback is in the client window. The other 2 are unchanged. Files
are attached.

6) Traceback summary.
Line 438 FAILED ...
Traceback (most recent call last):
File "C:\HotFuzz\Peach\Agent\ppprocess.py", line 415, in _StartProcess
win32job.AssignProcessToJobObject(self.myJob,hProcess)
error: (5, 'AssignProcessToJobObject', 'Access is denied.')

7) I should have done the search in *.py on the 1st round.

Thanks for your help,

Roy Bethel
The MITRE Corp.  M/S H407
7515 Colshire Drive
McLean, VA  22102-7539
    E-mail: rbe...@mitre.org
SIPRNet: rbe...@wiso.mitre.contractor.army.smil.mil
   MITRE:  (703) 983-5455



-----Original Message-----
From: pe...@paddy.troja.mff.cuni.cz [mailto:pe...@paddy.troja.mff.cuni.cz] On
Behalf Of Pavel Kankovsky
Sent: Wednesday, July 04, 2012 2:48 PM
To: Bethel, Roy E.; hotfuzz-project
Cc: Khairi Habidin; Patterson, James
Subject: RE: [HotFuzz project] RE: [Peach] Re: HotFuzz CesarTest Help

On Wed, 27 Jun 2012, Bethel, Roy E. wrote:

> Inserted the lines in Peach/Agent/ppprocess.py. Saved. Opened
> HotFuzz. Ran CesarTest.
> Exactly the same result. Hmmmmm. (Note: I primarily use MatLab.)
>
> I noticed all the *.py in Peach/Agent had *.pyc counterparts and the
> dates were the same date I installed HotFuzz.

*.pyc files are compiled (sort of) versions of Python scripts. They are
generated and updated automatically by the Python runtime. As Martin wrote,
you can delete them and force Python to recompile corresponding source code
files. But it should never be necessary as Python is supposed to keep them
up to date.

I am at a loss that your changes to ppprocess.py are ignored (despite having
encountered a problem that seemed to be identical to yours as described in
my postscriptum).

You can try the following things:

1. Modify the original error message ("FAILED TO START..."). Run HotFuzz.
Examine ppprocess.pyc and check whether it was updated and whether it
contains the modified message.

2. Make sure all lines are indented correctly because program structures are
determined by indentation in Python and even minute differences (spaces
instead of tabs) are important. You can use an editor included in PythonWin
GUI (bundled with ActiveState Python).


PS: I am sorry it took me so long to respond. Various circumstances
conspired against me; here is a partial list preserved for the benefit,
education, and amusement of posterity:

1. My installation of HotFuzz succumbed to some kind of bitrot and
stopped working. Every time a fuzzing process was started it crashed in
hf_dissect_init (?) until I removed a bunch of various software
packages and did a complete reinstall of HotFuzz and its dependencies.

2. I wanted to reproduce your problem with *.pyc files. I made proposed
changes to ppprocess.py, broke CesarTest configuration (so as to make it
unable to start a program), started fuzzing... and my changes were
ignored. It regenerated ppprocess.pyc every time I deleted it or changed
ppprocess.py and its contents corresponded to the modified source code but
it kept behaving as if the code had not been changed at all. It turned out
I had broke the wrong part of CesarTest (server instead of client) and the
code where an exception occurred was different from the code I modified
(ppmonitor.py instead of ppprocess.py).

Unfortunately, this does not help to explain your problems. I checked the
output you sent earlier and your exception occurred in ppprocess.py.


--Pavel Kankovsky aka Peak

[Pavel Kankovsky]

On Mon, 9 Jul 2012, Bethel, Roy E. wrote:

> 1) The problem is that there are 2 [print "FAILED ...]'s. Not just 1. The
> 1st was the only one modified for the 1st round.

The funny thing is that it occurred to me you might have changed a wrong
part of the code. But I dismissed the idea when I double-checked that my
original message pointed to the right place ("FAILED TO START AGENT
APPLICATION" in _StartProcess; the wrong one is "FAILED TO RUN ACTIVATING
COMMAND" in PublisherCall). :)

> 6) Traceback summary.
> Line 438 FAILED ...
> Traceback (most recent call last):
> File "C:\HotFuzz\Peach\Agent\ppprocess.py", line 415, in _StartProcess
> win32job.AssignProcessToJobObject(self.myJob,hProcess)
> error: (5, 'AssignProcessToJobObject', 'Access is denied.')

It seems Microsoft "innovated and improved". The Internet is full of
complaints about AssignProcessToJobObject failures in recent versions of
MS Windows. The details are not quite clear to me (and I and not going to
dig deeper because the innards of MS Windows are full of things man is not
meant to know) but some sources (*) say one can solve the problem by
adding CREATE_BREAKAWAY_FROM_JOB flag to the invocation of CreateProcess.

Try changing this piece of code in _StartProcess

## Create our process as suspended to prevent raise conditions
(hProcess, hThread, dwProcessId, dwThreadId) = CreateProcess(None, self.command,
None, None, 0, CREATE_SUSPENDED, None, None, STARTUPINFO())

to

## Create our process as suspended to prevent raise conditions
(hProcess, hThread, dwProcessId, dwThreadId) = CreateProcess(None, self.command,
None, None, 0, CREATE_SUSPENDED | CREATE_BREAKAWAY_FROM_JOB, None, None, STARTUPINFO())
^^^^^^^^^^^^^^^^^^^^^^^^^^^

(*) e.g.
<http://patrick-rice.net/daybook/2010/09/16/microsoft-gets-in-my-way-again/>

--Pavel Kankovsky aka Peak