Plan for hotfuzz
Michael Eddington
I wanted to touch base with your team and see what your plans are for
supporting and further development of HotFuzz over the next few years.
Since this is something I've wanted for several years as part of Peach,
I'd be happy to pick up the support and continual development. However
it works out, I'd like to make sure that HotFuzz does not get stuck at v1.
Let me know what you think.
--
mike
Martin Žember
thank you for your e-mail. We discussed our plans among the team and
came to a conclusion that it would be a pity for the project to let it
die and we do not want to leave the development. Although all of us
have some duties to perform, at least some of us plan to get into it
again (starting a few months from now on). We would be willing to
address user requests, but there have been a very rare feedback from
the users (and no requests / bug reports). If you have ideas, can you
introduce them to us?
Thank you,
Martin & the HotFuzz team
Michael Eddington
A few things off the top of my head...
- Updated version of Peach. Dev is 2.3.8, Hotfuzz is 2.3.5?
- Support for Wireshark LUA scripts/dissectors
- Keeping up to date with Wireshark as it revs
- Cleaning up and improving the GUI
- Number of faults displayed from fuzzing page
- Ability to view dumps/faults during fuzzing
- What happens when we want to fuzz an embedded system, so no debugger monitor?
- Support for bucketing of faults
- Might hit same overflow thousands of times
- New features like...
- Trying to identify CRCs
- Trying to identify relations between elements
- Do analyzers work well with hotfuzz??
- Eval if one should be attached automatically
- OS X/Unix support (does it currently?)
mike
Michael Eddington
- Can't actually create a new project, must use existing recording and what not and modify
- Many of the UI settings on the recorder tab don't actually
update the PIT file making them useless (TCP vs. UDP, Ports,
etc). Mostly I have to manually edit the XML.
- Would be very nice to have an installer that did not include all those sample programs
- Investigate py2exe to remove python dependency
- Version # for HotFuzz to people understand which revision they are using
- Enable all mutators by default
- Fix the need to use "\\" in the UI
- Fix that paths show up with wrong slash (c:/ instead of c:\)
- Crashes during recording should be failures, not logged like
other crashes
mike
Michael Eddington
- The GUI loading projects is very fragile, looks to do with xml parsing. Comments in the XML (fuzzing.xml) will cause a project not to load
- Unable to have Relations, Fixups, etc. in the fuzzing.xml or GUI will not load
- This is a significant issue since many protocols will need
to have Fixups added to deal with CRC's.
- No error messages when GUI does not load
- Must have defaultValue, value, isToken, and mutable attributes on each data element or XML will not load
- This seems unreasonable, can't there be defaults?
- Do we need defaultValue and value?
mike
Michael Eddington
mike
Michael Eddington
I'd like to feature HotFuzz in my next Peach training in March. It
would be nice to get some of these issues (especially the GUI/
Installer) resolved by then. Is there any chance your team could get
a release out by then? Or perhaps start using code.google.com or
sourceforge and allow external submitters?
mike
On Jan 18, 12:19 pm, Michael Eddington <medding...@gmail.com> wrote:
> The file glob on the browse for file box. The .exe/.py selection does
> not actually show .exe files. You must select *.*.
>
> mike
>
> On 1/18/2011 11:14 AM, Michael Eddington wrote:
>
>
>
>
>
>
>
> > And more stuff...
>
> > not to load
> > will not load
> > o This is a significant issue since many protocols will need
> > * Must have defaultValue, value, isToken, and mutable attributes
> > o Do we need defaultValue and value?
> > mike
>
> > On 1/18/2011 12:23 AM, Michael Eddington wrote:
> >> Oh I almost forgot... Lots of UI bugs and stuff... The UI bugs in
> >> particular make adoption confusing.
>
> >> etc). Mostly I have to manually edit the XML.
> >> all those sample programs
> >> * Investigate py2exe to remove python dependency
> >> * Version # for HotFuzz to people understand which revision they
> >> are using
> >> * Enable all mutators by default
> >> * Fix the need to use "\\" in the UI
> >> * Fix that paths show up with wrong slash (c:/ instead of c:\)
> >> * Crashes during recording should be failures, not logged like
>
> >> mike
>
> >> On 1/15/2011 5:55 PM, Michael Eddington wrote:
> >>> I think at the very least a quarterly release would be good. I'm
> >>> sure the feedback will grow as the user base does. I'll be talking
> >>> about hotfuzz next week at blackhat dc during my workshop.
>
> >>> A few things off the top of my head...
>
> >>> * Support for Wireshark LUA scripts/dissectors
> >>> * Keeping up to date with Wireshark as it revs
> >>> * Cleaning up and improving the GUI
> >>> o Number of faults displayed from fuzzing page
> >>> o Ability to view dumps/faults during fuzzing
> >>> o What happens when we want to fuzz an embedded system, so
> >>> no debugger monitor?
> >>> * Support for bucketing of faults
> >>> o Might hit same overflow thousands of times
> >>> * New features like...
> >>> o Trying to identify CRCs
> >>> o Trying to identify relations between elements
> >>> o Do analyzers work well with hotfuzz??
> >>> + Eval if one should be attached automatically
> >>> * OS X/Unix support (does it currently?)
theologu
What you did is really great, don`t let it die, this project actually
fills a big blank in fuzzers world.
I think your project needs a little more promoting to the security
people... you will get enough requests and bug reports, but let`s
start telling about Hotfuzz. Maybe presenting it to some security
conferences will get more attention.
Michael reported some important bugs and has good ideas of
improvement, that`s a start for the next release.
Keep it up, you are doing a great thing!
Martin Žember
On Tue, Feb 8, 2011 at 6:59 AM, Michael Eddington <meddi...@gmail.com> wrote:
> ....
> Or perhaps start using code.google.com or
> sourceforge and allow external submitters?
>
we are open to external submitters. Since we do not expect many
volunteers, it can be handled individually. Would you like to have an
access to the SVN? We would be pleased to provide you an account.
Martin
Martin Žember
colleagues Jan and Štěpán have started to resolve issues you sent.
- Definitely do-able (before the CanSecWest training) is this:
# Would be very nice to have an installer that did not include all
those sample programs
- These and some others are done:
# Fix that paths show up with wrong slash (c:/ instead of c:\)
# Version # for HotFuzz to people understand which revision they are using
- Simple GUI-related issues can also be resolved until then.
Unfortunately, "fragile XML parsing" seems to be more complex and will
need more time. Also using py2exe does not seem to work yet...
Martin
Pavel Kankovsky
here is a more or less comprehensive response to your list of HotFuzz
issues. I have wrote it myself because the guys seem to be too shy
*wink wink* to do that. Some issues are omitted because I have had
nothing to say about them.
Feel free to disregard any of my comments or questions if they are
too irrelevant or too stupid. :)
On Sat, 15 Jan 2011, Michael Eddington wrote:
> * Updated version of Peach. Dev is 2.3.8, Hotfuzz is 2.3.5?
Hotfuzz 1.0.0 is based on some pre-2.3.5 SVN revision of Peach from early
2010. Afaik r1990.
> * Support for Wireshark LUA scripts/dissectors
It would need libwireshark with LUA support, LUA runtime and something to
prod libwireshark to load the desired script(s). Anything else?
> * Cleaning up and improving the GUI
> o Number of faults displayed from fuzzing page
It is displayed in the status line at the bottom of the main window,
isn't it?
> o Ability to view dumps/faults during fuzzing
You can use the Dump Viewer tab during the fuzzing phase (assuming you
can wrestle the control of your mouse pointer out of AutoHotKey's hands).
But its contents does not refresh automatically, you need to click the
"Refresh" button.
> o What happens when we want to fuzz an embedded system, so no
> debugger monitor?
It *should* let you to modify the corresponding part of the XML file
manually. But it probably *does not*. Anyway, you can set up a dummy agent
for the GUI and add an extra agent with any monitor etc. you need. It
is awkward but it works.
> * Support for bucketing of faults
> o Might hit same overflow thousands of times
Do you mean to group similar faults when they are displayed by the GUI or
anything else? Would it be ok to group them the same way they are grouped
in "dumps", i.e. PossibleStackCorruption/0x1234/0x4567/...?
> * New features like...
> o Trying to identify CRCs
> o Trying to identify relations between elements
There is already a piece of code (PPRelationFinder) autodetecting
length/size relations.
> o Do analyzers work well with hotfuzz??
They should work well as long as they are willing to augment data models
they get. But afaik the current implementation does not call any analyzers
with the exception of one that is hardcoded and whose interface is very
special (PPTokenAnalyzer).
> + Eval if one should be attached automatically
How would you do that?
> * OS X/Unix support (does it currently?)
Most of the code should be portable but I do not dare to guess how much
work would be needed to deal with the rest.
On Tue, 18 Jan 2011, Michael Eddington wrote:
> Oh I almost forgot... Lots of UI bugs and stuff... The UI bugs in
> particular make adoption confusing.
>
> * Can't actually create a new project, must use existing recording
> and what not and modify
That's strange. It is not easy to create a new project from scratch
but I have been able to do that.
> * Many of the UI settings on the recorder tab don't actually update
> the PIT file making them useless (TCP vs. UDP, Ports, etc).
> Mostly I have to manually edit the XML.
There are two PIT files: one (partial) for the recording phase and another
for the fuzzing phase. Setting in the recorded tab are saved to the first
file and they are not propagated to the second file automatically.
I agree it is rather confusing and I admit I am probably partially to
blame for it because the design of GUI is based on my ideas that were
probably not as thought-out as they should have been.
> * Investigate py2exe to remove python dependency
I guess it is a good thing, at this stage of development, when a software
product is distributed in a form ready for debugging. :)
> * Version # for HotFuzz to people understand which revision they are
> using
It is available from the menu via "Help/About Hotfuzz", and it is printed
every time recording or fuzzing is started (although last time I checked
it still printed "0.9.1" instead of "1.0.0" there). But I guess it would
not hurt if the version was displayed in splash screens and perhaps intro
dialogs too.
> * Enable all mutators by default
The initial selection of mutators depends on the fuzzing(?) template used
to create a project, doesn't it?
> * Crashes during recording should be failures, not logged like other
> crashes
Do you mean that the recording phase should fail when a crash occurs or
that a such crash should be reported as an "application failure"? (Or
anything else?)
"Application failures" are situations when the application stops
responding but it does not crash. (I will not pretend I understand how the
detection works.) Afaik they are logged too but there is no crashdump,
only the record of communication and the Dump Viewer does not show them.
On Tue, 18 Jan 2011, Michael Eddington wrote:
> * The GUI loading projects is very fragile, looks to do with xml
> parsing. Comments in the XML (fuzzing.xml) will cause a project
> not to load
It depends. A comment directly below <Peach> is ok, a comment in a part
that is subject to more thorough processing (data models, state model) is
not ok. The problem is the current implementation is too strict because it
treats comments as unexpected elements.
On the other hand, I do think a 100% solution is possible because GUI can
add, reorder, or remove elements in certain parts of the document (namely
in the list of mutators).
Also, all comments are lost when the file is processed by the recording
phase as its contents is completely deconstructed and rebuilt.
> * Unable to have Relations, Fixups, etc. in the fuzzing.xml or GUI
> will not load
> o This is a significant issue since many protocols will need
> to have Fixups added to deal with CRC's.
The same problem. Data model parsing should be more tolerant to elements
it does not handle.
> * No error messages when GUI does not load
I do not understand. Do you mean "no error messages when GUI does not load
the XML besides laconic 'Edited ... XML failed to load' in the status
line"? Yes, it would be an improvement if it provided a more detailed
explanation.
> * Must have defaultValue, value, isToken, and mutable attributes on
> each data element or XML will not load
> o This seems unreasonable, can't there be defaults?
I think they can. But it would probably need some nontrivial coding.
> o Do we need defaultValue and value?
I think (and I can be wrong) "value" contains the real (hex encoded) data
while "defaultValue" was reused (afaik Dušan wanted to make as few changes
to the parser as possible) to contain their printable representation
displayed by the GUI.
--Pavel Kankovsky aka Peak
Michael Eddington
unmanageable fast :) Comments in lined.
My high priority list:
- Ability to create new project (EASILY!)
- Fix record UI issues (not updating XML, see below for discussion)
- Allow Fixup, Transformer, and Relation in fuzzing XML
- Installer with no sample programs (make this a separate installer)
mike
On 2/28/2011 1:29 PM, Pavel Kankovsky wrote:
>> * Cleaning up and improving the GUI
>> o Number of faults displayed from fuzzing page
> It is displayed in the status line at the bottom of the main window,
> isn't it?
There is a message "Program crashes in 8. iteration!" but no count. And
that message only displays when a crash occurs, so until a fault happens
there is no feedback to the user.
>> o Ability to view dumps/faults during fuzzing
> You can use the Dump Viewer tab during the fuzzing phase (assuming you
> can wrestle the control of your mouse pointer out of AutoHotKey's hands).
> But its contents does not refresh automatically, you need to click the
> "Refresh" button.
No, the dump viewer tab is disabled during fuzzing, at least in the
public version. The only way to see faults is to browse to the logging
folder.
>> o What happens when we want to fuzz an embedded system, so no
>> debugger monitor?
> It *should* let you to modify the corresponding part of the XML file
> manually. But it probably *does not*. Anyway, you can set up a dummy agent
> for the GUI and add an extra agent with any monitor etc. you need. It
> is awkward but it works.
Okay, this will need looking into to make sure it's flexable enough to
handle non-standard cases.
>> * Support for bucketing of faults
>> o Might hit same overflow thousands of times
> Do you mean to group similar faults when they are displayed by the GUI or
> anything else? Would it be ok to group them the same way they are grouped
> in "dumps", i.e. PossibleStackCorruption/0x1234/0x4567/...?
I did notice the log folder had them in buckets, be nice if the GUI
showed things similar.
>> * New features like...
>> o Trying to identify CRCs
>> o Trying to identify relations between elements
> There is already a piece of code (PPRelationFinder) autodetecting
> length/size relations.
>
>> o Do analyzers work well with hotfuzz??
> They should work well as long as they are willing to augment data models
> they get. But afaik the current implementation does not call any analyzers
> with the exception of one that is hardcoded and whose interface is very
> special (PPTokenAnalyzer).
Okay, this will need to be tested to verify. I'd like to make sure
things like the XML analyzer and the string token analyzer work OK.
>> + Eval if one should be attached automatically
> How would you do that?
>
If you end up with a Blob you might as well toss the binary analyzer
on. We should be able to detect a String that holds XML data, etc.
>> * OS X/Unix support (does it currently?)
> Most of the code should be portable but I do not dare to guess how much
> work would be needed to deal with the rest.
Would be nice to get this working on OS X at least. Future improvement :)
>
> On Tue, 18 Jan 2011, Michael Eddington wrote:
>
>> Oh I almost forgot... Lots of UI bugs and stuff... The UI bugs in
>> particular make adoption confusing.
>>
>> * Can't actually create a new project, must use existing recording
>> and what not and modify
> That's strange. It is not easy to create a new project from scratch
> but I have been able to do that.
Lol, this should be SUPER easy! How about a nice big "New Project"
button? This is a high priority item if you want this usable :)
>> * Many of the UI settings on the recorder tab don't actually update
>> the PIT file making them useless (TCP vs. UDP, Ports, etc).
>> Mostly I have to manually edit the XML.
> There are two PIT files: one (partial) for the recording phase and another
> for the fuzzing phase. Setting in the recorded tab are saved to the first
> file and they are not propagated to the second file automatically.
>
> I agree it is rather confusing and I admit I am probably partially to
> blame for it because the design of GUI is based on my ideas that were
> probably not as thought-out as they should have been.
Actually this is not true. If you load up into record tab only *some*
of the fields actually update the record XML, but many of them do not.
This means it is *impossible* to just use the UI to perform a record
session. the user *must* edit the XML directly to set some of the options.
This is a high priority item as it will severely limit adoption of this
tool. When I did a demo at Blackhat DC people loved the tool right up
until they tried to use it and I had to walk them through editing the XML.
I'm guessing this is going to be an "easy" fix.
>> * Investigate py2exe to remove python dependency
> I guess it is a good thing, at this stage of development, when a software
> product is distributed in a form ready for debugging. :)
The main reason for this is to avoid installing python and module
dependencies. It's the only part of the installation that's not very
"smooth." Also when doing demo's or introducing people to the tool it's
nice not to clobber there python install :)
In theory this should be straight forward, it was pretty easy for Peach.
>> * Version # for HotFuzz to people understand which revision they are
>> using
> It is available from the menu via "Help/About Hotfuzz", and it is printed
> every time recording or fuzzing is started (although last time I checked
> it still printed "0.9.1" instead of "1.0.0" there). But I guess it would
> not hurt if the version was displayed in splash screens and perhaps intro
> dialogs too.
>
I'll refine my issue, the installer filename needs a version number.
The program in the start menu needs a version number. Right now the
only way to tell if there is a new release is to re-install and then
help/about...fail! :)
>> * Enable all mutators by default
> The initial selection of mutators depends on the fuzzing(?) template used
> to create a project, doesn't it?
I have not had it select all mutators every, just the limited string for
the ftp repro. Granted, I have not been able to actually create a new
project :)
>> * Crashes during recording should be failures, not logged like other
>> crashes
> Do you mean that the recording phase should fail when a crash occurs or
> that a such crash should be reported as an "application failure"? (Or
> anything else?)
>
> "Application failures" are situations when the application stops
> responding but it does not crash. (I will not pretend I understand how the
> detection works.) Afaik they are logged too but there is no crashdump,
> only the record of communication and the Dump Viewer does not show them.
>
Okay, when your recording we are not fuzzing right? So we should not be
crashing the app. If the app crashes under normal usage something is
very very wrong and the user should be notified.
> On Tue, 18 Jan 2011, Michael Eddington wrote:
>
>> * The GUI loading projects is very fragile, looks to do with xml
>> parsing. Comments in the XML (fuzzing.xml) will cause a project
>> not to load
> It depends. A comment directly below <Peach> is ok, a comment in a part
> that is subject to more thorough processing (data models, state model) is
> not ok. The problem is the current implementation is too strict because it
> treats comments as unexpected elements.
>
> On the other hand, I do think a 100% solution is possible because GUI can
> add, reorder, or remove elements in certain parts of the document (namely
> in the list of mutators).
>
> Also, all comments are lost when the file is processed by the recording
> phase as its contents is completely deconstructed and rebuilt.
My solution to this was to strip all comments from the XML document
before processing. It's A-OK to say comments may get lost, but we
should not break on them.
>> * Unable to have Relations, Fixups, etc. in the fuzzing.xml or GUI
>> will not load
>> o This is a significant issue since many protocols will need
>> to have Fixups added to deal with CRC's.
> The same problem. Data model parsing should be more tolerant to elements
> it does not handle.
This is a high priority item as it really limits the usefulness of the
tool. Unable to update CRCs? FAIL!
>> * No error messages when GUI does not load
> I do not understand. Do you mean "no error messages when GUI does not load
> the XML besides laconic 'Edited ... XML failed to load' in the status
> line"? Yes, it would be an improvement if it provided a more detailed
> explanation.
>
>> * Must have defaultValue, value, isToken, and mutable attributes on
>> each data element or XML will not load
>> o This seems unreasonable, can't there be defaults?
> I think they can. But it would probably need some nontrivial coding.
>> o Do we need defaultValue and value?
> I think (and I can be wrong) "value" contains the real (hex encoded) data
> while "defaultValue" was reused (afaik Du�an wanted to make as few changes
> to the parser as possible) to contain their printable representation
> displayed by the GUI.
Hmmm...
>
> --Pavel Kankovsky aka Peak
>
Pavel Kankovsky
> There is a message "Program crashes in 8. iteration!" but no count. And
> that message only displays when a crash occurs, so until a fault happens
> there is no feedback to the user.
Oh, dammit! You must be using an old version!
The message looked the way you describe before r621 ie. before 14 Aug
2010. You are still using the pre-release version from August (downloaded
from https://peak.nbox.troja.mff.cuni.cz/hf/HF_install.exe rather than
from hotfuzz.atteq.com), aren't you?
The powers that be decided to make Sep 9 a deadline (instead of late
August as expected) and that extra time was used to make lots of
improvements and bug fixes.
[I see my own version is not quite the same as the final release either
but it is much closer to it. It's from the morning of 8 Sep 2010 while the
final 1.0.0 release was assembled in the afternoon of the same day.]
Download the current installer from <http://hotfuzz.atteq.com/>. The file
should be 147671672 bytes long, MD5 f58307e701bc1af348bdda4250e425b8,
SHA1 1f17689bab2681fc37b416aa4e27be5bcc8fe5ac.
> I'll refine my issue, the installer filename needs a version number.
BTW: The file on our CD was called "HF_install_1_0.exe" but its name is
"HF_install.exe" (no version number) when you download it from
hotfuzz.atteq.com. Can anyone change that? Martin?
--Pavel Kankovsky aka Peak
Štěpán Henek
> Be nice to have some issue tracking software, this is going to get
> unmanageable fast :) Comments in lined.
non-english reports. But it's still useable. http://flyspray.atteq.com/
> On 2/28/2011 1:29 PM, Pavel Kankovsky wrote:
> >> * Cleaning up and improving the GUI
> >>
> >> o Number of faults displayed from fuzzing page
> >
> > It is displayed in the status line at the bottom of the main window,
> > isn't it?
>
> There is a message "Program crashes in 8. iteration!" but no count. And
> that message only displays when a crash occurs, so until a fault happens
> there is no feedback to the user.
>
That's the old message. The new should look like this:
self.statusbar.showMessage("Total crash count : " + str(self.crashCount) + "
Last program crash : iteration #" + str(self.lastCrash))
I'm pretty sure that this message was changed at the beginning of September
before the release.
Perhaps you could try to update your current installation by replacing
pppeach/GUI folder by the one from our svn.
> >> o Ability to view dumps/faults during fuzzing
> >
> > You can use the Dump Viewer tab during the fuzzing phase (assuming you
> > can wrestle the control of your mouse pointer out of AutoHotKey's hands).
> > But its contents does not refresh automatically, you need to click the
> > "Refresh" button.
>
> No, the dump viewer tab is disabled during fuzzing, at least in the
> public version. The only way to see faults is to browse to the logging
> folder.
Same issue. Now we are sure we need to create a new installer and update the
web pages.
> >> * OS X/Unix support (does it currently?)
> >
> > Most of the code should be portable but I do not dare to guess how much
> > work would be needed to deal with the rest.
>
> Would be nice to get this working on OS X at least. Future improvement :)
GUI should be platform independent since it wasn't developed on the windows
platform.
But the pppeach part has some platform dependent imports. I'm not sure about
the details. I developed mostly the GUI part.
> >> * Many of the UI settings on the recorder tab don't actually update
> >>
> >> the PIT file making them useless (TCP vs. UDP, Ports, etc).
> >> Mostly I have to manually edit the XML.
> >
> > There are two PIT files: one (partial) for the recording phase and
> > another for the fuzzing phase. Setting in the recorded tab are saved to
> > the first file and they are not propagated to the second file
> > automatically.
> >
> > I agree it is rather confusing and I admit I am probably partially to
> > blame for it because the design of GUI is based on my ideas that were
> > probably not as thought-out as they should have been.
>
> Actually this is not true. If you load up into record tab only *some*
> of the fields actually update the record XML, but many of them do not.
> This means it is *impossible* to just use the UI to perform a record
> session. the user *must* edit the XML directly to set some of the options.
I'm pretty sure that all elements (perhaps except the Iteration count spinbox)
somehow update the recording.xml. I can't tell you whether the modifications
are correct. But each one of them does something.
Do you have a use case of this behavior?
>
> > On Tue, 18 Jan 2011, Michael Eddington wrote:
> >> * The GUI loading projects is very fragile, looks to do with xml
> >>
> >> parsing. Comments in the XML (fuzzing.xml) will cause a project
> >> not to load
> >
> > It depends. A comment directly below <Peach> is ok, a comment in a part
> > that is subject to more thorough processing (data models, state model) is
> > not ok. The problem is the current implementation is too strict because
> > it treats comments as unexpected elements.
> >
> > On the other hand, I do think a 100% solution is possible because GUI can
> > add, reorder, or remove elements in certain parts of the document (namely
> > in the list of mutators).
> >
> > Also, all comments are lost when the file is processed by the recording
> > phase as its contents is completely deconstructed and rebuilt.
>
> My solution to this was to strip all comments from the XML document
> before processing. It's A-OK to say comments may get lost, but we
> should not break on them.
Have you got an example xml, when the comments break the loading?
Cheers,
Stepan Henek
Michael Eddington
Dec/Jan time frame, but sure-nuff the file size is off. Yah, a version
number would be nice :)
Well, at least that means less bugs to fix. I'll take a look at the
newer version, almost downloaded.
mike
Michael Eddington
> On Tuesday 01 March 2011 01:12:00 Michael Eddington wrote:
>> Be nice to have some issue tracking software, this is going to get
>> unmanageable fast :) Comments in lined.
> We use one since the beginning of the project. It is quite outdated, with some
> non-english reports. But it's still useable. http://flyspray.atteq.com/
Rad! Now we are talking :)
mike
Pavel Kankovsky
> - Ability to create new project (EASILY!)
> [...]
> >> * Can't actually create a new project, must use existing recording
> >> and what not and modify
> > That's strange. It is not easy to create a new project from scratch
> > but I have been able to do that.
> Lol, this should be SUPER easy! How about a nice big "New Project"
> button? This is a high priority item if you want this usable :)
I am speaking about the released version here (but I am quite positive it
worked in the prerelease as well).
You can create a new project when you switch to the "New Project" tab in
the welcome screen (tab labels are in the bottom part of the window)
or when you pick "New Project" from the "File" menu.
You are asked to select templates. If you choose "(EmptyTemplate)" for
both phases, you get a fresh new project with no predefined settings.
That's pretty easy.
The not-easy part is to prepare the programs to be tested and to fill in
all blank places necessary to make the new project useful.
I have just verified I can create a new project with empty templates and
reconstruct CesarTest with no manual editing. (I have to say the input
boxes are way too small for any but the most trivial commands...)
--Pavel Kankovsky aka Peak
Jan Stanek
I bring some good news:
1/ Hotfuzz was migrated to sourceforge
https://sourceforge.net/projects/hotfuzz/. Not everything was moved
yet, but the important parts should be there and we hope to make
sourceforge the new home for our project.
2/ New version of HotFuzz installer (version 1.1.0 is up). We have
implemented some of the proposed changes, full list of them will be
added to the release soon. It was not yet thoroughly tested, but it
should work:).
The light version of the installer, without the example projects, will
be available today too. I am now playing with py2exe that is driving
me mad with not finding the right import-chain dependencies...but
hopefully it will surrender soon:).
Best wishes,
Jan
Michael Eddington
I'll check out that new version for sure.
Mike
Michael Eddington
would recommend having the hotfuzz installer and a 2nd bundle with
samples. Then you could have something like the following. Anyways
just a thought :)
HotFuzz-x.x.exe
HotFuzz-Samples.zip
mike
Michael Eddington
HotFuzz-Installer-x.x.exe
HotFuzz-Installer_With_Samples-x.x.exe
mike
Jan Stanek
Files have been renamed.
Jan
Michael Eddington
Just installed the latest off sourceforge and have two bugs, one seems
to be blocking.
1. (not blocking, but pain) Prior install of wireshark seemed to cause a
record failure. This should get looked into, I don't see why two
versions of wireshark can't co-exist on the same machine.
2. (blocking) after a record I kicked off a fuzzing run and got this
from the right most output window. I'm attaching the record.xml and
fuzzing.xml.
z 1.1.0
] Copyright (c) HotFuzz Team
] Product is built on Peach 2.3.5 DEV Runtime (Copyright (c) Michael
Eddington)
[*] Starting run "DefaultRun"
[-] Test: "HotTest" (None)
[1] TestCase
-- Shutting down publisher(s)
-- Done
-- Exiting
Traceback (most recent call last):
File "C:\HotFuzz\peach.py", line 624, in <module>
engine.Run(args[0], None, verbose, watcher, restartFuzzerFile,
noCount, parallel, startNum)
File "C:\HotFuzz\Peach\Engine\engine.py", line 463, in Run
self._runTest(run, test, False, self.testRange)
File "C:\HotFuzz\Peach\Engine\engine.py", line 665, in _runTest
actionValues = stateEngine.run(mutator)
File "C:\HotFuzz\Peach\Engine\state.py", line 168, in run
self._runState(obj, mutator)
File "C:\HotFuzz\Peach\Engine\state.py", line 236, in _runState
Engine.context.hotFuzz.hotEngine.runState(self,mutator)
File "C:\HotFuzz\Peach\Engine\ppaction.py", line 1323, in runState
self.runTcpState(stateEngine,mutator)
File "C:\HotFuzz\Peach\Engine\ppaction.py", line 996, in runTcpState
finishIteration =
self.runAction(stateEngine,mutator,clientSocketStatus.getData(),'input',clientSocket)
File "C:\HotFuzz\Peach\Engine\ppaction.py", line 791, in runAction
finishIteration = self.processDataModel(stateEngine,newAction)
File "C:\HotFuzz\Peach\Engine\ppaction.py", line 658, in processDataModel
if action.template.getValue().find(self.ENDOFITERATION) >= 1:
AttributeError: 'PpAction' object has no attribute 'ENDOFITERATION'
mike
Michael Eddington
also HotFuzz? Is there a specific version I need?
I just installed the latest Wireshark along with HotFuzz 1.1 and python
now crashes when recording... Since the VM's require Wireshark for
other parts of what I'm doing I need both to co-exist if possible.
mike
Jan Stanek
---------- Forwarded message ----------
From: Jan Stanek <jan.s...@rdc.cz>
Date: Fri, Mar 4, 2011 at 9:00 PM
Subject: Re: [HotFuzz project] Wireshark + Hotfuzz
To: meddi...@gmail.com
Well, having more versions of Wireshark is really a pain. The problem
is somewhere with loading the plugins, which it tries to load from the
Wireshark installed the typical way instead of the ones that come with
our modified version of wireshark libs. I was unable to find any way
how to solve it "friendly", however there is a workaround.
If the problem you encountered is the same as we had previously, then
it might help if you rename the plugins directory inside your
wireshark installation into something else (like plugins2). Then the
loader thinks that there are no standard plugins and should not try to
load them -> everything should run just fine.
If this doesn't work, then it might work is you use Wireshark version
1.3.5. Its plugins should be compatible.
Regards,
Jan
Michael Eddington
things to look into.
mike
Martin Žember
On Fri, Mar 4, 2011 at 8:30 PM, Michael Eddington <meddi...@gmail.com> wrote:
...
Uncommenting this line in Peach/Engine/ppaction.py resolves this:
#self.ENDOFITERATION = 'endofiteration'
Fixed in SVN now. Sorry for complications.
Martin
Michael Eddington
to have the main download be b0rk3d :D
mike
Jan Stanek
Just wondering which of my colleagues commented the line and for what
purpose. I do not believe it was some typo so better be careful until
we find out what was it for:).
Jan
Pavel Kankovsky
> Uncommenting this line in Peach/Engine/ppaction.py resolves this:
> #self.ENDOFITERATION = 'endofiteration'
That line had been commented out since r646 (2010-08-15).
The command that failed
if action.template.getValue().find(self.ENDOFITERATION) >= 1:
had been commented out since r344 (2010-07-16) because the mechanism it
implemented (a message terminating the test case being detected by an
appearance of the aformentioned hardcoded string) was considered obsolete.
Martin, it was you who reintroduced the broken command in post-1.0.0
r855 (2011-01-06).
Question #1 Why did you made that change? (And other changes in Jan 6.)
Question #2 WHY THE HELL did you commit a change that would break even
the most trivial smoketest without telling anyone?
BTW: It'd be really swell if released revisions were tagged in SVN.
I guess 1.0.0 corresponded to r853.
--Pavel Kankovsky aka Peak
Martin Žember
sorry again for complications. Sure it was my fault, I know (and
that's why I apologized...)
2011/3/5 Pavel Kankovsky <pe...@mbox.troja.mff.cuni.cz>:
> On Sat, 5 Mar 2011, Martin Žember wrote:
>
>> Uncommenting this line in Peach/Engine/ppaction.py resolves this:
>> #self.ENDOFITERATION = 'endofiteration'
>
> Martin, it was you who reintroduced the broken command in post-1.0.0
> r855 (2011-01-06).
>
> Question #1 Why did you made that change? (And other changes in Jan 6.)
I was using HotFuzz. There were local changes that I wanted to commit.
I am asking another question: why did not I commit both changes to the
file?! I realized soon that it breaks something and fixed it; but it
stayed uncommited. I do not understand it now, it is just silly and
stupid.
The other changes are correcting typos or XML files. I hope they are
commented well in the logs.
> Question #2 WHY THE HELL did you commit a change that would break even
> the most trivial smoketest without telling anyone?
Are you asking, why did not I tell anyone that the commit breaks the
code completely? (Or why commited it.)
Moral of this for me is that I should test any code BEFORE I commit it
to the repository thoroughly. Otherwise disasters can happen...
Regarding the mechanism:
> That line had been commented out since r646 (2010-08-15).
> The command that failed
>
> if action.template.getValue().find(self.ENDOFITERATION) >= 1:
>
> had been commented out since r344 (2010-07-16) because the mechanism it
> implemented (a message terminating the test case being detected by an
> appearance of the aformentioned hardcoded string) was considered obsolete.
Why is it considered obsolete? I cannot find reasons behind this in
the session notes. The mechanism is suggested at the 44th session, but
I do not read why it was obsoleted.
I do not have to insist on the feature, it's been months ago and I do
not use it currently so I do not remember the example scenario.
Sorry again to all.
Martin
Jan Stanek
a purposeful fix for something even more devastating:).
Jan