Difference between revisions of "Embedded security challenge"
(→Specs and contents) |
(→Initial work) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 38: | Line 38: | ||
http://pdf1.alldatasheet.com/datasheet-pdf/view/250994/SANYO/LE25FU406B.html | http://pdf1.alldatasheet.com/datasheet-pdf/view/250994/SANYO/LE25FU406B.html | ||
| − | =Working materials= | + | =Getting to work= |
| + | |||
| + | ==Working materials== | ||
After reading the printout, we decided to bring in some extra materials to work with | After reading the printout, we decided to bring in some extra materials to work with | ||
| Line 45: | Line 47: | ||
* USB - TTL UART + converter cable for small pitch console connector of disk | * USB - TTL UART + converter cable for small pitch console connector of disk | ||
* SPI ROM reader + cable + clamp | * SPI ROM reader + cable + clamp | ||
| + | |||
| + | ==Initial work== | ||
| + | |||
| + | This being a security challenge, we felt that being paranoid was probably a good thing. | ||
| + | |||
| + | So we decided not to power up the original disk until we know it is safe. | ||
| + | The documentation clearly marked the SPI ROM chip on the controller board, and had a ROM layout, suggesting that the content of the ROM chip is probably rather relevant. So our first goal was to extract a full dump of the ROM, both to study, and to be able to perhaps reflash (?) if it somehow got corrupted. | ||
| + | |||
| + | For this reason, all initial work was done on the additional identical drive we had found in a box of spares. | ||
| + | |||
| + | Using the console, we apparently could extract the ROM, using a custom bit of python code, but it was slow, so not really practical. We gave up on that approach. | ||
| + | |||
| + | Next we tried an SPI ROM reader. Unfortunately, it didn't want to read the ROM. We will need to revisit this with another SPI ROM reader or some such, after verifying pinouts etc. | ||
| + | |||
| + | [More to be published later] | ||
Latest revision as of 17:13, 19 October 2017
| Projects | |
|---|---|
| |
| Participants | Stef, Thomascovenant, Wfk |
| Skills | Embedded, Soldering, Electronics, Coding, Security |
| Status | Active |
| Niche | Electronics |
| Purpose | World domination |
Contents
Disclaimer
Box contents, component photos and solution will be shared when issuer allows it. Challenge box is brought to space from Montreal Recon security conference 2017.
On October 17, 2017 Ang Cui from Red Balloon Security, NY, has approved publishing the contents online, solution will appear once the challenge is retired from use in recruitment process.
Specs and contents
Original contents of the box
- several sheets of A4 printout with vague description, photos of PCB, ROM layout, etc
- hard disk, anonymised, engraved
- USB - SATA converter + Molex PSU + Molex - SATA power cable
- SATA data cable
- lots of sweets
Useful
For now, here you can find some materials we found useful:
Hard disk hacking: https://spritesmods.com/?art=hddhack
https://www.msfn.org/board/topic/128807-the-solution-for-seagate-720011-hdds/?page=44
http://pdf1.alldatasheet.com/datasheet-pdf/view/250994/SANYO/LE25FU406B.html
Getting to work
Working materials
After reading the printout, we decided to bring in some extra materials to work with
- Additional hard disk of exact same type
- USB - TTL UART + converter cable for small pitch console connector of disk
- SPI ROM reader + cable + clamp
Initial work
This being a security challenge, we felt that being paranoid was probably a good thing.
So we decided not to power up the original disk until we know it is safe. The documentation clearly marked the SPI ROM chip on the controller board, and had a ROM layout, suggesting that the content of the ROM chip is probably rather relevant. So our first goal was to extract a full dump of the ROM, both to study, and to be able to perhaps reflash (?) if it somehow got corrupted.
For this reason, all initial work was done on the additional identical drive we had found in a box of spares.
Using the console, we apparently could extract the ROM, using a custom bit of python code, but it was slow, so not really practical. We gave up on that approach.
Next we tried an SPI ROM reader. Unfortunately, it didn't want to read the ROM. We will need to revisit this with another SPI ROM reader or some such, after verifying pinouts etc.
[More to be published later]
