I'm trying to fuzz a proprietary container file format. Part of this
format includes a table of offsets to 'records' within the file. For
the purposes of my test, I'd like to treat each record (other than the
first) as essentially an opaque blob.
The problem I'm facing is that the length of each record is not
explicitly recorded in the file format. To calculate the length of a
given record, you must subtract the record's offset from the
subsequent record's offset, or the total length of the file if it is
the last record.
So your doing to need a length on that blob. You can say lengthtype=calc and then put some pythone code into length that will be used to determin its size. The blob will have a variable called possiblePos or pos with the current offset. The only part i'm not sure about is finding the next offset to calc ur length from.
There are some other possible solutions. I'll think about it and get back later today. (custome types, an analyzer, python tricckery, etc).
-----Original Message----- From: Greg <gfo...@gmail.com> Sent: Monday, October 26, 2009 4:29 PM To: peachfuzz <peachfuzz@googlegroups.com> Subject: [Peach] Complex block length
I'm trying to fuzz a proprietary container file format. Part of this format includes a table of offsets to 'records' within the file. For the purposes of my test, I'd like to treat each record (other than the first) as essentially an opaque blob.
The problem I'm facing is that the length of each record is not explicitly recorded in the file format. To calculate the length of a given record, you must subtract the record's offset from the subsequent record's offset, or the total length of the file if it is the last record.
This sent peach into an infinite loop. The only way I know to work around this issue is to hardcode a guessed length of each record.
Thoughts?
-greg --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "peachfuzz" group. To post to this group, send email to peachfuzz@googlegroups.com To unsubscribe from this group, send email to peachfuzz+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/peachfuzz?hl=en -~----------~----~----~--
I considered the lengthtype=calc solution and soon ran into the problem you
mention; how do you get the offset for the next record? From my reading of
the peach code, that piece of the input has yet to be 'cracked' at the
moment that getLength is called. And I was unable to determine a way to
access the input stream directly.
-greg
On Tue, Oct 27, 2009 at 8:18 AM, Michael Eddington <medding...@gmail.com>wrote:
> So your doing to need a length on that blob. You can say lengthtype=calc
> and then put some pythone code into length that will be used to determin its
> size. The blob will have a variable called possiblePos or pos with the
> current offset. The only part i'm not sure about is finding the next offset
> to calc ur length from.
> There are some other possible solutions. I'll think about it and get back
> later today. (custome types, an analyzer, python tricckery, etc).
> I'm trying to fuzz a proprietary container file format. Part of this
> format includes a table of offsets to 'records' within the file. For
> the purposes of my test, I'd like to treat each record (other than the
> first) as essentially an opaque blob.
> The problem I'm facing is that the length of each record is not
> explicitly recorded in the file format. To calculate the length of a
> given record, you must subtract the record's offset from the
> subsequent record's offset, or the total length of the file if it is
> the last record.
Yup, I think what I would do is write some helper python code that I
load into the pit file using Import that has a method that can calc my
length. It would do the following:
1. Take in the name of the offset array
2. Locate the current end of array, grab the numbers position and read
next next N bytes, unpack and then do the required math.
3. Return value
> I considered the lengthtype=calc solution and soon ran into the
> problem you mention; how do you get the offset for the next record?
> From my reading of the peach code, that piece of the input has yet to
> be 'cracked' at the moment that getLength is called. And I was unable
> to determine a way to access the input stream directly.
> -greg
> On Tue, Oct 27, 2009 at 8:18 AM, Michael Eddington
> <medding...@gmail.com <mailto:medding...@gmail.com>> wrote:
> So your doing to need a length on that blob. You can say
> lengthtype=calc and then put some pythone code into length that
> will be used to determin its size. The blob will have a variable
> called possiblePos or pos with the current offset. The only part
> i'm not sure about is finding the next offset to calc ur length from.
> There are some other possible solutions. I'll think about it and
> get back later today. (custome types, an analyzer, python
> tricckery, etc).
> I'm trying to fuzz a proprietary container file format. Part of this
> format includes a table of offsets to 'records' within the file. For
> the purposes of my test, I'd like to treat each record (other than the
> first) as essentially an opaque blob.
> The problem I'm facing is that the length of each record is not
> explicitly recorded in the file format. To calculate the length of a
> given record, you must subtract the record's offset from the
> subsequent record's offset, or the total length of the file if it is
> the last record.
Thanks for all your help on this, Mike! Great to have you so active in this
group.
I've tried to do this, but it's not clear how the helper function gets
access to the input data. (The 'buff' value used in incoming.py). Is this
exposed as a global variable somehow?
-greg
On Tue, Oct 27, 2009 at 5:07 PM, Michael Eddington <medding...@gmail.com>wrote:
> Yup, I think what I would do is write some helper python code that I load
> into the pit file using Import that has a method that can calc my length.
> It would do the following:
> 1. Take in the name of the offset array
> 2. Locate the current end of array, grab the numbers position and read next
> next N bytes, unpack and then do the required math.
> 3. Return value
> then your length="my_calcLengthHack('xyz')"
> mike
> On 10/27/2009 5:27 PM, Greg Foltz wrote:
> Thanks for your thoughts!
> I considered the lengthtype=calc solution and soon ran into the problem you
> mention; how do you get the offset for the next record? From my reading of
> the peach code, that piece of the input has yet to be 'cracked' at the
> moment that getLength is called. And I was unable to determine a way to
> access the input stream directly.
> -greg
> On Tue, Oct 27, 2009 at 8:18 AM, Michael Eddington <medding...@gmail.com>wrote:
>> So your doing to need a length on that blob. You can say lengthtype=calc
>> and then put some pythone code into length that will be used to determin its
>> size. The blob will have a variable called possiblePos or pos with the
>> current offset. The only part i'm not sure about is finding the next offset
>> to calc ur length from.
>> There are some other possible solutions. I'll think about it and get back
>> later today. (custome types, an analyzer, python tricckery, etc).
>> I'm trying to fuzz a proprietary container file format. Part of this
>> format includes a table of offsets to 'records' within the file. For
>> the purposes of my test, I'd like to treat each record (other than the
>> first) as essentially an opaque blob.
>> The problem I'm facing is that the length of each record is not
>> explicitly recorded in the file format. To calculate the length of a
>> given record, you must subtract the record's offset from the
>> subsequent record's offset, or the total length of the file if it is
>> the last record.
|
