PC-3000 Forum

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

And two memory chips:


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:




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

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

No!
I can't find anything...

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

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 %

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?

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

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

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

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

AJ2008 wrote: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:


My version is a little older...


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!

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

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

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.

Roman_TS wrote: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!