I am trying to read a 98D79432 chip. PC-3000 cannot decode it. Looking at details of recovery most examples suggest Xor C5F6-128.

Can anyone explain what type of XOR routine this is. I am happy to write a program to implement this, but each attempt I try does not bring up valid sectors of data. Is there a standard algorithm for this?

Michael

If you have the same device you can write pattern to it and remove NAND to try decode yourself. PC3K will allow use of external XOR files.

Alternatively outsource to someone with Soft Center or Dumppicker

Also, XOR is dependant on controller not chip. Your controller will be PHISON.

Hi hddguy

Is C5F6 a pattern and 128 the bit length that it applies to, ie 16 bytes

How do XORs normally work. ie is the first byte/word XORed with a value, the result stored, and that result is XORed with the next byte/word? Or is the process different?

I want to try and understand where to start working. Yes finding an identical 8GB SDHC chip could be a solution - but ideally I would like to work it out before doing that.

I have soft centre tools and can work with this XOR

Feel free to send it up

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

The controller contains a XOR pattern, length of it can vary so not sure exactly how big it is. All data is XOR'd against this pattern sequentially. For example, if first byte in XOR pattern is '11' and first byte of real data is 'A5' XOR'd data will show 'B4'.

128 I'm pretty sure refers to the page size of the chip.

Not an easy job to solve yourself even with an identical device.

I know PCImage can handle these, I think your best (and fastest) solution here would be to ship it to him.

Apart from offers to do the job for me, so far I have not received any useful info on how XOR is typically used with Flash memory.

Is the whole buffer XORed with a single value, or a complete string?

If it is a single value one would expect to see a pattern. eg the start of a JPEG is 0xff 0xd8 0xff and so one would see a pattern with the first and third characters being the same. Also, a directory entry of '. ' would be one character followed by 10 the same.

If it was a complete string, one would expect to see patterns visible at the end of a file which has been padded with zeros.

Or is it a moving XOR, eg

input string A B C XOR value X

Then I would expect the following to be saved

byte0 = A ^ X
byte1 = byte0 ^ B
byte2 = byte1 ^ C

or is there a different method?

The only way to find XOR is that :

You cannot try them all !

_________________
Lemmy

Is never a single value.

To give you example, I have XOR file for SSS6690 controller which is 1,646,592 bytes and another XOR file for different SSS6690 series which is 68,608 bytes long.

As I mentioned above all data written to the chip is periodically XOR'd against the values in the XOR pattern. There is no possible way to identify the XOR pattern and its length without knowing 100% what the data is both before and after XOR. As mentioned in my first post this is possible with an identical device, but still is not a simple task.

Realistically you are not going to solve this yourself unless you invest in alternative tools with more support for such XOR cases.

I still believe the best option you have here is to outsource this to somebody who can deal with it for you.

Thank you for the response that it is not a single byte. This now makes sense.

On the chip I am looking at I can see areas of repeating data, 0x42e bytes long. This is almost certainly over a trailing area of slack data, that one finds at the end of a JPEG or the end of a directory entry.

I will try this string and apply to the chip and let you know what happens.

The challenge is to find these strings automatically - this is more than a 10 minute job.

As I already said it is impossible without knowing how data looks both before and after is XOR'd.

I personally think this is beyond your capabilities with the tools you have.

I don't understand how it can be done whitout the same functionning device .???

_________________
Lemmy

It cant...

I have spent 30 years working on undocumented storage media. HDDGUY - I know what tools I have and what abilities I have, just currently limited with flash devices. Data manipulation is something I have done for a very long time.

The chip is from a camera and so will have FAT32 directories and JPEG files. These are known structures. They are also runs of zeros. I will let you know within a few days if this is possible.

This chip as I mentioned does have repeating patterns of 0x42e bytes, ie two sectors plus control bytes. Currently I think it is possible.

I think the primary goal of XOR is to prevent reverse engineering.

I assume you are aware of additional SA bytes in NAND memory which modify sector structures. Also data mixes are present which removes the consistency in these known structures.

Also, how can you identify these common structures when they will not be in fixed position? And because XOR pattern will be long string of different values will be very difficult to a relevant find repeating pattern even in places where there are many zeros.

I admire your persistence and I really hope you can find a solution. But it is far from an easy task and my personal opinion is that you will not be able to crack it...

I don't think that XOR is to prevent reverse engineering. A flash memory chip is a very enclosed environment, and not part of any form of accessible data exchange. I think it is so data is presented as 'random' data and so help reduce wear levels. Typically only 50% of the bits will be set at any time. However, this is only my thoughts, does anyone know the truth?

If the XOR string is as long as a page, or logical block, then detection will be difficult/impossible. If, as I think it is in this case just 2 sectors long, then finding the strings is straight forward. A directory always starts '. ' and then 0x20 bytes later '.. ' Often directories are shorter than a block and so are padded - however, on a camera this is less likely to be the case.

IMHO, that's right!

_________________
Lemmy

Progress report.

I am on the correct track - but a very long way to go.

I took one of the 'blank' areas and extracteda the 0x42e XOR pattern. I then applied it to the chip image and I can now see several instances of a valid JPEG header - with camera information etc for at least 8 sectors (0x200 byte sectors).

There are other areas with what I took to be a blank pattern. However, the values for these patterns is different. I will try extracting an XOR for these patterns and see what results I get, and how they are implimented.

I have seen enough to think that there may be a solution, but it looks as if there may be several XOR patterns.

The service area info will then need investigation.

I have now found about 300 XOR patterns and am matching a lot of them to the correct location.

Still a long way to go, but I think I will beable to extract some photos before long.

Fingers crossed

PHISON XOR is simple find, SA not xored and assemble with block nomer.
Assemble and FIND where must be FAT and ZERO area. Save some blocks and analyze them.

My analysis so far looks like the following

Pages 8 x blocks of 0x42e bytes. ie 2 * 0x200 of sector data plus 0x2e of ecc?

This is followed by 0x10 bytes of data, of which the final 8 bytes are always 0xff


Each page same xor string for the 8 x 0x42e byte block

I get the impression that the the XOR patter repeats every 0x80 pages. My 300 possible strings is therefore detecting false positives - next job is to eliminate these. I have managed to find some thumbnails, and some directory structures. I have also found over 1300 photo starts, based on JPEG signature.

I cannot currently make sense of the service area