In article <4b9e0c1f.9020...@canterbury.ac.nz>,
Gregory Ewing wrote:
>
>It turned out to be a very standard CRC algorithm, complicated
>by the presence of a few extra bytes of data being checked that
>didn't appear explicitly in the file anywhere.
>
>In the process I developed some very general t
En Mon, 15 Mar 2010 07:29:51 -0300, Gregory Ewing
escribió:
I've solved the problem now.
It turned out to be a very standard CRC algorithm, complicated
by the presence of a few extra bytes of data being checked that
didn't appear explicitly in the file anywhere.
In the process I developed s
On Mon, Mar 15, 2010 at 6:29 AM, Gregory Ewing
wrote:
> I've solved the problem now.
>
> It turned out to be a very standard CRC algorithm, complicated
> by the presence of a few extra bytes of data being checked that
> didn't appear explicitly in the file anywhere.
>
> In the process I developed
Hi Greg
Just to say thanks for taking the time to write up your work on
this interesting topic.
Cheers
J^n
--
http://mail.python.org/mailman/listinfo/python-list
I've solved the problem now.
It turned out to be a very standard CRC algorithm, complicated
by the presence of a few extra bytes of data being checked that
didn't appear explicitly in the file anywhere.
In the process I developed some very general techniques for
solving this kind of problem, whi
In article <7vj7fdfnn...@mid.individual.net>,
Gregory Ewing wrote:
>Given some known data/crc pairs, how feasible is it to
>figure out the polynomial being used to generate the crc?
>
>In the case I'm looking at, it appears that the crc
>size may be at least 24 bits, so just trying all possible
>
On 3/12/2010 3:24 AM Gregory Ewing said...
What confused me initially is that it seems to be adding
a few extra bytes to the checked data that aren't present
in the file. Figuring out what they're supposed to contain
is proving to be quite a headache...
Length?
Emile
--
http://mail.python.o
Lawrence D'Oliveiro wrote:
They could be using a strong cryptographic hash and truncating it to 16 bits
or something.
In which case you’ve got your work cut out for you...
Nope, I've determined that it's actually a pretty standard
CRC, and it's even using one of the standard polynomials,
0x8
In message <7vlamef7g...@mid.individual.net>, Gregory Ewing wrote:
> I'm going by the fact that the application reports a
> "CRC mismatch" when it's wrong. I can't be sure that what
> it calls a "CRC" is really a true CRC, but it's more than
> a simple sum, because changing one bit in the file res
In message , Dave Angel
wrote:
> However, if there's anything in there about how to derive the polynomial
> algorithm from (a few) samples I missed it entirely.
Given that CRC is all just a sequence of xor operations, what happens if you
xor various pairs of CRCs together, wouldn’t that cancel
Steve Howell wrote:
Hi Greg. I would at least flip one bit at a time on the first byte of
your data to see if the transformation is bitwise.
I'm actually making good progress on this -- it turns out
there *is* a way of deducing the polynomial by looking at
the effect of single-bit flips. It's
On Mar 7, 7:09 pm, Gregory Ewing wrote:
> Given some known data/crc pairs, how feasible is it to
> figure out the polynomial being used to generate the crc?
>
> In the case I'm looking at, it appears that the crc
> size may be at least 24 bits, so just trying all possible
> polynomials probably is
Dave Angel wrote:
If you assume it's done in a single pass, and you know which byte is the
end of the buffer, I'd think you could learn a lot by just tweaking that
last byte.
I'm sure I would, but unfortunately I can't control the
last byte. The bytes that I can influence are some distance
ba
Gregory Ewing wrote:
Dave
Angel wrote:
If you know so little about the value, how do you even know it's a
CRC ? Could it be a ones-complement sum, such as used in Ethernet?
I'm going by the fact that the application reports a
"CRC mismatch" when it's wrong. I can't be sure that what
it calls
Dave Angel wrote:
If you know so little about the
value, how do you even know it's a CRC ? Could it be a ones-complement
sum, such as used in Ethernet?
I'm going by the fact that the application reports a
"CRC mismatch" when it's wrong. I can't be sure that what
it calls a "CRC" is really a t
Gregory Ewing wrote:
Steven D'Aprano wrote:
Can you just ask the application developer what CRC is being used? Or
look at the source code? Disassemble the binary?
There's no source, and the binary is enormous. I could ask,
but I wouldn't hold out much hope of them being willing to
tell me.
Steven D'Aprano wrote:
Can you just ask the application developer what CRC is being used? Or
look at the source code? Disassemble the binary?
There's no source, and the binary is enormous. I could ask,
but I wouldn't hold out much hope of them being willing to
tell me.
it appears that the cr
Steven D'Aprano wrote:
On Mon, 08 Mar 2010 16:09:12 +1300, Gregory Ewing wrote:
Given some known data/crc pairs, how feasible is it to figure out the
polynomial being used to generate the crc?
Google is your friend:
http://www.woodmann.com/fravia/crctut1.htm
That page was interes
On Mon, 08 Mar 2010 16:09:12 +1300, Gregory Ewing wrote:
> Given some known data/crc pairs, how feasible is it to figure out the
> polynomial being used to generate the crc?
Google is your friend:
http://www.woodmann.com/fravia/crctut1.htm
--
Steven
--
http://mail.python.org/mailman/listinf
On Mon, 08 Mar 2010 16:09:12 +1300, Gregory Ewing wrote:
> Given some known data/crc pairs, how feasible is it to figure out the
> polynomial being used to generate the crc?
Can you just ask the application developer what CRC is being used? Or
look at the source code? Disassemble the binary?
>
Given some known data/crc pairs, how feasible is it to
figure out the polynomial being used to generate the crc?
In the case I'm looking at, it appears that the crc
size may be at least 24 bits, so just trying all possible
polynomials probably isn't doable.
An article I found hints at the possib
21 matches
Mail list logo
