Hey guys,

First of all I'd like to thank to all of you who shared knowledge around, as little as it can be for a noob. It seems that because of my laptop crash I plunged into a new world.

My task is simple: to recover my precious data from my old WD (WD2500BEVS) drive being on a cash shortage for now - it seems like one depends on another .
Of course I'm not so stupid to loose the key to my only fortune (except my gf), but after I swore I'll never touch an Acer anymore and bought a new ASUS laptop, I realized that the Aspire 5520G, as expected, scrambled my password to some double-size binary half-null sausage which I cannot use in any way. It basically replaced each ASCII code with another value, inserting NULLs between each two. My user password was 6 characters and now it's 11 including the interleaved NULLs, but excluding the ones until 32. I could only recognize it because of its size and two identical letters in the expected order.

What I did not:
- resurrect my old laptop - it seems dead for good and the repair would probably cost more than a new one
- try to unlock it on another Acer - no one in town offered to help so far.

What I did:
- used hdparm with cat on Linux without success, as long as I keep receiving an input/output error on two computers.
- used MHDD with Alt+Numpad but: some characters don't want to appear (eg 0x13 afaik) but anyway there's no chance to input NULL characters to the prompt.
- used atapwd and zu with no luck - I have no floppy and cannot use the locked drive as the only HDD, it seems that I can't make the programs acknowledge it.

What I ask:
- is there any way to make MHDD to use a binary file for the password? How?
- is there any other way I could replace this binary password?

Thank you in advance!

Hi,

it is possible that the ACER uses extended keyboard codes as the PWD.
U can create a file in a hex editor containing the PWD, and write a little script in MHDD to send the file as password.

pepe

_________________
Adatmentés - Data recovery

Thanks pepe for your answer. I was thinking about that, but I'm afraid to mess with the regs.

Here's what I would try:


where pass.bin contains: 00 [hexa pass] 00 00 ... - as far as I found out, the first byte in the bin should be 00 for user and 01 for master.

Is this correct?

Hi,

To be honest I never used MHDD scripting, so I cannot guide you with that precisely. I just gave the idea how it can work.
I usually programmed things in C and assembly when I needed.
BTW how did u find out how the password was stored?

Pass.bin WORD 0 has to contain 0x0000, that means the first 2 bytes has to be zero, then comes the password.
Also as far as I see regs are set from 0x01..0x07.
Command register is reg7, so 0xF2 should be put into the last reg.

regs = $00 $00 $00 $00 $00 $a0 $F2

probably...

_________________
Adatmentés - Data recovery

I'm surprised to see that the command is the last reg instead of the first, although I did not try to enter such detail about MHDD.

I managed in the end to do it by hacking hdparm source, hard-code the binary password in it and then build it on my Arch. hdparm gave me i/o errors before, probably because of the lock state of the HDD , but with the good password it worked flawlessly.

I thank to: maysoft for his work and forum, Nirvanowiec for his scripts, greyshores for his example - I would not have managed without any of these! And thanks pepe for your replies. I can't describe my happiness!!!

See ya!

_________________
Adatmentés - Data recovery

Dear mihai and everyone else,

I would very much like to reverse engineer the transformation that Acer applies. Based on the example that you extracted, do you have any idea what exactly it did to the ASCII codes of your original password? Perhaps the corresponding keyboard scan code?

To summarize:
the short "pwd" would become "f(p) 0x00 f(w) 0x00 f(d)" where f() represents the transformation that Acer does, as a hexadecimal byte.

Thank you very much for any pointers that you might give!

Based on mihai's experiments, the user password seemed to have been a transformed version of the password that he actually entered.

It also looks like the ATA master password is sometimes set to h2oinsyde (well-known backdoor on Acers).

My strategy now is to set a normal ATA master password with hdparm on a different machine, as well as the Acer-transformed password as ATA user password, also with hdparm. At least then I know exactly what they both are, and can hopefully use the disk in my Acer laptop.

(BTW, I have PM'd him on the Arch Linux forum where he also posted.)

Oh man, that would be irritating.

At least I will be able to confirm all of this with hdparm, and then we'll know.

I find it extremely unfortunate of Acer / Insyde to have implemented it this way.