You could try JTAG or worst case chip off reading…
Completely irrelevant, the data is accessible on the drive, the issue is that the data on the drive is not in a readable format, eg it's ENCRYPTED.
Completely irrelevant, the data is accessible on the drive, the issue is that the data on the drive is not in a readable format, eg it's ENCRYPTED.
As a matter of fact the JTAG or direct chip reading jhup mentioned is NOT necessarily aimed to the chip(s) on the disk…. roll
jaclaz
Completely irrelevant, the data is accessible on the drive, the issue is that the data on the drive is not in a readable format, eg it's ENCRYPTED.
As a matter of fact the JTAG or direct chip reading jhup mentioned is NOT necessarily aimed to the chip(s) on the disk…. roll
jaclaz
Then would you like to clarify what it is aimed at?
Then would you like to clarify what it is aimed at?
The encryption is "linked" to some hardware (now failed) on the actual computer.
Some information is stored in one (or more) chip(s) on the physical laptop.
The general idea is
- find a replacement hardware (motherboard) identical to the failed one
- "transplant" either "physically" i.e. by desoldering and re-soldering the relevant chip(s) or "logically" by reading the contents of the chip(s) on the failed motherboard and writing these contents to the chip(s) on the working one
[/listo]
If you prefer, it is a matter of perfectly "cloning" the failed hardware.
jaclaz
I am only speaking about my own experience - I have had third party recover BitLockered SSD through JTAG.
It was an enterprise implementation, so we recovered the key from the AD, irrelevant of TPM.
Once an image of the SSD was recreated, a MS VHD was crafted and mounted. BitLocker asked for the key and all was beautiful.
The solution I am describing removes the hardware issue - I understand the loss of the key/TPM, and the hope in my previous post was that it is a proper corporate implementation. That would create a backup of the recovery key in the AD.
In my opinion, if imaging, even using JTAG or chip-off is feasible, it is simpler than attempting to find a replacement hardware. I believe this because finding a matching hardware is much more cumbersome and technically complicated than using JTAG/chip-off solutions.
When I had replaced controllers in drives, even revision numbers were significant. I admit I have only done about half dozen this way. The delay, cost of the hardware, finding out that there are other issues besides the PCB made it too expensive for me.
What is the risk and success rate of using a JTAG clip, reading the data, and reconstructing it into an image?
What is the risk and success rate of finding the controller, then attempting to recover the data through original ports?
I am also wondering, my JTAG solution would not work if the PCB is damaged in an SSD. I have seen SSDs where the control card and the memory storage are on a single board (I also seen daughter board configuration). If that is the case, and the board is damaged, what are the changes of "swapping" anything? That leaves chip-off as the only solution.
If you prefer, it is a matter of perfectly "imaging" the failed hardware. mrgreen
Again, your mileage may vary.
Then would you like to clarify what it is aimed at?
The encryption is "linked" to some hardware (now failed) on the actual computer.
Some information is stored in one (or more) chip(s) on the physical laptop.
The general idea is
- find a replacement hardware (motherboard) identical to the failed one
- "transplant" either "physically" i.e. by desoldering and re-soldering the relevant chip(s) or "logically" by reading the contents of the chip(s) on the failed motherboard and writing these contents to the chip(s) on the working one
[/listo]
If you prefer, it is a matter of perfectly "cloning" the failed hardware.
jaclaz
I believe you're talking about the TPM. Have you or anyone you know ever performed a successful TPM transplant?
I am only speaking about my own experience - I have had third party recover BitLockered SSD through JTAG.
It was an enterprise implementation, so we recovered the key from the AD, irrelevant of TPM.
Once an image of the SSD was recreated, a MS VHD was crafted and mounted. BitLocker asked for the key and all was beautiful.
The solution I am describing removes the hardware issue - I understand the loss of the key/TPM, and the hope in my previous post was that it is a proper corporate implementation. That would create a backup of the recovery key in the AD.
In my opinion, if imaging, even using JTAG or chip-off is feasible, it is simpler than attempting to find a replacement hardware. I believe this because finding a matching hardware is much more cumbersome and technically complicated than using JTAG/chip-off solutions.
When I had replaced controllers in drives, even revision numbers were significant. I admit I have only done about half dozen this way. The delay, cost of the hardware, finding out that there are other issues besides the PCB made it too expensive for me.
What is the risk and success rate of using a JTAG clip, reading the data, and reconstructing it into an image?
What is the risk and success rate of finding the controller, then attempting to recover the data through original ports?
I am also wondering, my JTAG solution would not work if the PCB is damaged in an SSD. I have seen SSDs where the control card and the memory storage are on a single board (I also seen daughter board configuration). If that is the case, and the board is damaged, what are the changes of "swapping" anything? That leaves chip-off as the only solution.
If you prefer, it is a matter of perfectly "imaging" the failed hardware. mrgreen
Again, your mileage may vary.
\
Was the Bitlocker implementation using any form of pre-boot authentication? I bet it wasn't, I'll bet just about anything. I'll bet you it was loading the encryption keys right into memory at boot.
Who is your 'third party'? I'm really curious because my understanding is that (recent?) SSDs use AES (128 or 256) to encrypt the actual contents of the chips, so if you perform a chipoff extraction or dump their raw contents via JTAG, you'll need to reassemble multiple chips worth of raw AES-encrypted data, extract the key from the SSD's onboard processor. There's a pretty significant amount of technical expertise required to do all that, if you know someone who can do all that, please pass on their contact information because I'd love to pick their brain.
I believe you're talking about the TPM. Have you or anyone you know ever performed a successful TPM transplant?
Cannot say about the rest of the world.
Personally I haven't, but I cannot see why it cannot be "normally" done as you would transplant a hard disk or a phone chip, obviously you need some tools and some experience but I see nothing particularly difficult in it.
BTW some laptops have it on a separate module, example
http//
it is obvious that the OP mileage may (and will) vary.
jaclaz
Was the Bitlocker implementation using any form of pre-boot authentication? I bet it wasn't, I'll bet just about anything. I'll bet you it was loading the encryption keys right into memory at boot.
Who is your 'third party'? I'm really curious because my understanding is that (recent?) SSDs use AES (128 or 256) to encrypt the actual contents of the chips, so if you perform a chipoff extraction or dump their raw contents via JTAG, you'll need to reassemble multiple chips worth of raw AES-encrypted data, extract the key from the SSD's onboard processor. There's a pretty significant amount of technical expertise required to do all that, if you know someone who can do all that, please pass on their contact information because I'd love to pick their brain.
. . . Wouldn't a JTAG dump go through FTL and firmware?
Here you go
г. Ростов-на-Дону
пр-кт. Михаила Нагибина 40
ООО НПП "АСЕ" (основной офис)
индекс 344068
Телефон/факс
+7(863) 278-50-30
+7(863) 278-50-40
+7(863) 278-50-90