Flash memory XOR

  • Thread starter Thread starter mscotgrove
  • Start date Start date
M

mscotgrove

I am not sure if this is the correct group - but it is one I know.

I am working with raw memory chips (98D79432) and it looks as if the
data has been processed probably with a an XOR function. Some
references imply it is XOR C5F6_128. Does anyone know what this means
and how I can decode this (by writing a program).

Does anyone a know any good refence to this subject?

Michael
www.cnwrecovery.com
 
I am not sure if this is the correct group - but it is one I know.
I am working with raw memory chips (98D79432) and it looks as if the
data has been processed probably with a an XOR function. Some
references imply it is XOR C5F6_128. Does anyone know what this means
and how I can decode this (by writing a program).
Does anyone a know any good refence to this subject?

My guess would be that you are working on chips from
an encrypted memory stick without having the password.

If this is encryption, XOR is used in stream ciphers.
It works by generation a cryptographically hard to
predict stream of bytes (sometimes called keystream)
and then storing the XOR with the data. For decryption,
you need to original keystream and XOR it again to the
stored data, cannecling the original keystram out
(a xor b) xor b == a.

See also http://en.wikipedia.org/wiki/Stream_cipher

Stream ciphers are as good as the keystream. If the
keystream is generated, e.g., using AES, then the
resulting stream cipher is as hard to break as AES.
(Barring implementation mistakes, which are often
present in commercial products.)

Now, as further pure speculation, C5F6 could be a code
name for a block-cipher and _128 could specify a 128 bit
blocksize. This cipher could be used in generation
of the keystream.

If my spaculation is correct, then your best approach
is analysis of the firmware and hoping that there is
a bug in it. That is of course very, very time consuming.

If you know the device these chips are from, somebody
else may have done a cryptoanalyses and posted it
somewhere on the net.

Arno
 
My guess would be that you are working on chips from
an encrypted memory stick without having the password.

If this is encryption, XOR is used in stream ciphers.
It works by generation a cryptographically hard to
predict stream of bytes (sometimes called keystream)
and then storing the XOR with the data. For decryption,
you need to original keystream and XOR it again to the
stored data, cannecling the original keystram out
(a xor b) xor b == a.

See alsohttp://en.wikipedia.org/wiki/Stream_cipher

Stream ciphers are as good as the keystream. If the
keystream is generated, e.g., using AES, then the
resulting stream cipher is as hard to break as AES.
(Barring implementation mistakes, which are often
present in commercial products.)

Now, as further pure speculation, C5F6 could be a code
name for a block-cipher and _128 could specify a 128 bit
blocksize. This cipher could be used in generation
of the keystream.

If my spaculation is correct, then your best approach
is analysis of the firmware and hoping that there is
a bug in it. That is of course very, very time consuming.

If you know the device these chips are from, somebody
else may have done a cryptoanalyses and posted it
somewhere on the net.

Arno

The chip is from a SDHC memory chip from a Nikon Coolpix S8000
camera. It is therefore very unlikely to have any form of
encryption. I think it will just contain pictures.

I have tried to read with PC-3000 Flash and no joy, hence looking at
the raw data.. I am therefore trying all obvious raw conversions,
such as inversion, reverse bits etc. However, some references refer
to XOR C5F6-128. I agree that the 128 may refer to 16 bytes, so I
will try some manipulation with that in mind.

The problem with memory chips, the controller can do what ever it
wants, and there is no need to publish this information. On this
chip, the controller is under a black blob and it is impossible to
tell what the controller actually is. I am left guessing - good fun,
but very slow.

Michael
www.cnwrecovery.com
 
(e-mail address removed) <[email protected]> wrote:
[...]
The chip is from a SDHC memory chip from a Nikon Coolpix S8000
camera. It is therefore very unlikely to have any form of
encryption. I think it will just contain pictures.

Ah, in that case, no idea. I agree that encryption is unlikely.
I have tried to read with PC-3000 Flash and no joy, hence looking at
the raw data.. I am therefore trying all obvious raw conversions,
such as inversion, reverse bits etc. However, some references refer
to XOR C5F6-128. I agree that the 128 may refer to 16 bytes, so I
will try some manipulation with that in mind.
The problem with memory chips, the controller can do what ever it
wants, and there is no need to publish this information.

Obviously a problem for data recovery.
On this
chip, the controller is under a black blob and it is impossible to
tell what the controller actually is. I am left guessing - good fun,
but very slow.

Hmm. Could you get a second card with the same design,
write something and analyse the changes? Or put in
another flash chip for the same purpose?

Arno
 
Back
Top