USB Memory Controller AU6985HL

[stevan.vukovic]

Does anyone have any suggestions on how to recover data from this USB memory?
Controller is:

Controller.png (65.48 KiB) Viewed 10854 times

And two memory chips:

Memory.png (54.79 KiB) Viewed 10854 times

There is no SOLUTION that someone has solved with this controller, and I have not even managed to find a solution.

Both memory chips have been identified and read.
I tried with the offered solutions (3 offered) and I did not succeed.
I also did not manage through Recovery via controller from some of the suggested suggestions.
These are my attempts, without success:

PrnScrn_PC3k-Flash.png (17.45 KiB) Viewed 10854 times

Of course, I also tried with the solutions from the Global Solution Center database, which were uploaded.
Without success!

[AJ2008]

Can you find ECC? Can you find appropriate XOR for it?

[stevan.vukovic]

No!
I can't find anything...

I tried several solutions offered from Data Inspection/001 - Complex Analysis Metod/
(when started, I have info):

DataInspestion-ComplexAnalisys.png (17.87 KiB) Viewed 10842 times

After that, when I tried some Rusult of Preparation, FAILD...
... some of them, which I started = unsuccessful.

From TASK log =
- ECC not detected! If the ECC is not corrected before the quality of the result can get worse!
- Autodetecting is impossible. Enter the parameters manually!
- The partition header is incorrect! It is advisable to use table and hard disk analysis
Sometimes:
- ECC not detected! If ECC has not been corrected before the quality of result may be worse!
- Autodetection is impossible. Write parameters manually!
... ... ...
I do not know how and what to do manually!

After the analysis, I tried with these "method",which are offered as solutions = unsuccessfully!

Translator (Type 2) AU6389,AU6980,AU6981,AU6982 : 10 %
Translator (Type 3) Memorystick : 10 %
Translator (Type iCreate i5128-LG : 10 %
Block number (Type 1) [0x0000] : 42 %
Translator (Type 26) PS2232BD(C), PS2237-F : 6 %
id 2526;
Translator (Type 26) PS2232BD(C), PS2237-F : 6 %
id 3132;
Translator (Type 28) PS2134CE : 6 %
Translator (Type 32) PS2136CF : 6 %
Translator (Type 31) PS2134CH(I), PS2136CC : 6 %
Translator (Type 27) PS2136CC : 6 %

[AJ2008]

Data Inspection -> Complex analysis method - I did not even realize this is still available option - what version of software are you using?

Can you make RAW recovery against it to check if RAW files can be found? Maybe is no XOR present. how big is dump?

[Roman_TS]

Dear Stevan, please contact ACELab TS department and we will help you:
http://ts.acelaboratory.com/index.php?/Tickets/Submit

[stevan.vukovic]

OK. Thank you all.
I'll contact you, for 2 days, when I can.
I'm not at work at the moment.

[Multi-COM]

It's AU controller so ECC are probably after XOR... that why you cannot find it - once you will find correct XOR you can follow ECC correction

[AJ2008]

I do not think this case has XOR.
Maybe join by byte?

[stevan.vukovic]

Data Inspection -> Complex analysis method - I did not even realize this is still available option - what version of software are you using?

Can you make RAW recovery against it to check if RAW files can be found? Maybe is no XOR present. how big is dump?

AJ2008 I have here:

Data Inspection - complex analysis.png (22.32 KiB) Viewed 10795 times

My version is a little older...

PC_Flash_About.png (20.66 KiB) Viewed 10795 times

I did not try RAW, I wrote a ticket on Romanov's proposal, so I'll see.
AJ2008 certainly thanks a lot for the effort. I'll let you know how it all went.

UPDATE:
I have 2 dump files of size 4,21 GB (4.529.848.320 bytes), both by 4,21 GB.
Total = 8,43 GB!

[AJ2008]

OK, I am sure Roman will solve this case

I have 7.1.1 and I do not have this option for complex analysis, this is why I wondered what version you had (I have not had this option for such a long time I assumed it was totally removed)

I look forward to hearing how this case goes

[Amarbir[CDR-Labs]]

Well,
Sometimes ECC is Detected after XOR and Sometines you have to do some preparations before ECC detection

[Roman_TS]

The problem in this case is in chip reading. As I understand - they are based on BGA but they were read by green BGA-52 to TSOP adapter with soldering. As the result - one of the chips contain critical number of bit errors. Both chips should be joining by bytes, but if of of them are almost not readable, then recovery will be impossible because every odd byte will be incorrect after joining. We are still working with this case and I hope that we will find the way how to read both chips better.

[stevan.vukovic]

Source of the post The problem in this case is in chip reading. As I understand - they are based on BGA but they were read by green BGA-52 to TSOP adapter with soldering. As the result - one of the chips contain critical number of bit errors. Both chips should be joining by bytes, but if of of them are almost not readable, then recovery will be impossible because every odd byte will be incorrect after joining. We are still working with this case and I hope that we will find the way how to read both chips better.

Yes! As the Roman says. we read the chips through the adapter, which are soldered to the green adapters.
Roman has more than helped and continues to help.

And when I grow up, I would like to be like him!