HDD GURU FORUMS

How do you deal with cases where the standard SM XOR 17FE/E801 is modified by BB positions and their number? Previously, Flash-extractor prepared such layouts marked as "Xor 17fe bb" and there was no problem, now there is a problem if we do not have a clean XOR in the dump. The VNR AI-powered XOR key synthesis tool cannot handle this. PC3K added something like "Dynamic XOR by Plane" - but this probably applies only to planes with a different XOR but without BB. Maybe someone will share their experiences on how to deal with such custom SM32xx XORs.

Thanks.

i remember a case (SM3271Q, same xor sig) where i had to build xor taking shifts into account on one plane. At first i was told by Arvika it is a simple case and to use FE to do it. First i read it on pc3k. and tried to build FS which largely failed due to the badly deXORed pages, but by using FE and VNR i got precisely same results. He could not do it simply either, so i was left with building shifted xor. Or something like that. After that the recovery was perfect.


pepe

@pepe Case was solved very fast. Dump quality was not so good, you not uploaded better dumps, as I asked. After several days (or weeks, not noted this) you solve it. Just for clerance

dump was almost perfect, corrected, the problem was the xor, if we are talking about the same case. There was no quick solution. It looked like it was done after assembly, but the FS was corrupt in many ways. After the new xor it was perfect.
yeah, after several days i wrote some sw that built the full xor out of the pieces, that fixed the whole thing.

As I see there is no model. I will add tomorrow to Flash Killer DB.

I can unxor sectors without BB and first bytes of sectors where are BB, for example: sector with BB 1034b length where 10b are BB after apply 17fe xor and cut have unxored first 1014 bytes but this 10 bytes that was shifted have diffrent XOR 40 99 82 (bf 66 7c). Have you seen such an XOR?

Gregory wrote:XOR 40 99 82 (bf 66 7c)

Sorry mistake should be: 40 99 83.

i had to create a full block of xor for data AND ecc area and cut the bb-s (the offset element), then pair with the orig xor for the other plane and xor the orig dump with that.
I could not find a prebuilt xor for data + ECC, so i had to build it.
It's not that the ecc was xored, but by cutting bbs from data area, these bytes caused shifting the last bytes of the sectors to be shifted from the ecc, which was not present in the orig xor file. Of course it xored the ecc in the orig dump but it was irrelevant, coz i applied it after ecc correction.
In fact, now that i re-think this project, the 2 elements on the bottom was probably unnecessary, i could have connect the 'xor with ecc area' right to the bottom input of Unite...

pepe

OK, everything is clear to me, I understand, I did the same, but I filled the ECC area with zeros, but you probably used some XOR in the ECC area - which one?

I have a problem with the XOR that you placed in the ECC area, standard XOR does not fit for me.

If I had the correct XOR and put it into the ECC area, the solution you presented would work.

Now I am manually rebuilding this XOR - I have 2 blocks with MBR/FAT with have partially clean XOR for this missing area. I think I will find the rest of the pages in the dump.

Thanks pepe for your answer.

contact me at 'info at adatmentes dot net' and i will send you the xor i built

pepe wrote:contact me at 'info at adatmentes dot net' and i will send you the xor i built

Thanks pepe, I have already rebuilt the XOR manually and have proper data so XOR is OK, the truth is that for each case of a modified BB XOR you need to create a new custom XOR, I already know how this XOR is assembled so I will probably write a small program that will automate this process in future cases.

btw, you don't need to generate the modded xor for each case, the full xor is universal, just need to cut the proper bytes, matching the BBs of the actual flash.
But... since the block size is large, building it manually is at least as time consuming as writing a prog, so...

I just noticed it's sort of a hot topic here.
We already coded the algo for the AI-based SM XOR element with auto shifts for bad cols.
It'll work by single click, but we need a time to "Polish" it
Michal/Arvika keeps finding little bugs in it...

Sasha Sheremetov wrote:I just noticed it's sort of a hot topic here.
We already coded the algo for the AI-based SM XOR element with auto shifts for bad cols.
It'll work by single click, but we need a time to "Polish" it
Michal/Arvika keeps finding little bugs in it...

When relese ? Have another case SMxx XOR Mod by BB.

same xor?

Gregory wrote:

Sasha Sheremetov wrote:I just noticed it's sort of a hot topic here.
We already coded the algo for the AI-based SM XOR element with auto shifts for bad cols.
It'll work by single click, but we need a time to "Polish" it
Michal/Arvika keeps finding little bugs in it...

When relese ? Have another case SMxx XOR Mod by BB.

Planned next week I think. Hope your client can wait several days, because doing it manually is terrible and extremely time consuming.

pepe wrote:same xor?

Essentially those "expanded" XORs on bad columns are same as normal ones.

Essentially those "expanded" XORs on bad columns are same as normal ones.

yeah, i know, i wrote prog to build such thing.
I meant if his new case uses the same pattern or different one.

pepe wrote:I meant if his new case uses the same pattern or different one.

Ok, gotcha, sorry.

pepe wrote:same xor?

Yes, Sometimes there are different variants depending on the planes but this same family 17fe

Sasha Sheremetov wrote:Planned next week I think. Hope your client can wait several days, because doing it manually is terrible and extremely time consuming.

OK, that great news. Thanks.