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

_________________
Adatmentés - Data recovery

@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

_________________
Flash Killer - everyday new resources (pinout, XOR, ECC,config) for flash devices

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.

_________________
Adatmentés - Data recovery

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

_________________
Flash Killer - everyday new resources (pinout, XOR, ECC,config) for flash devices

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?

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

_________________
Adatmentés - Data recovery

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

_________________
Adatmentés - Data recovery

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...

_________________
Adatmentés - Data recovery

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...

_________________
VISUAL NAND RECONSTRUCTOR. Since 2014.

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

same xor?

_________________
Adatmentés - Data recovery

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



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

_________________
VISUAL NAND RECONSTRUCTOR. Since 2014.

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

_________________
Adatmentés - Data recovery

Ok, gotcha, sorry.

_________________
VISUAL NAND RECONSTRUCTOR. Since 2014.

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

OK, that great news. Thanks.