If you were looking at uncommented C with meaningless variable and function names, do you think you'd be faster? I think part of what makes it seem daunting is being familiar enough with the disassembly to read it quickly and easily.
If you already knew roughly how a HDD controller would need to work - what kind of I/O it would need to do, both at the controller end and the head movement end, couldn't you work backwards from there?
Reversing something like GC as needed in an SSD I can see as being harder, but again, wouldn't it largely be a matter of knowing that a certain number of parts of particular shapes - whether it's marking, tracing, copying / compacting, etc. - need to exist, and and finding them?
I think that if you really got stuck into the problem, it wouldn't take as long as you think. A lot of it is familiarity and fluency with the disassembly, I reckon.
(The closest I've gotten to this professionally was in reversing the Windows kernel and related user-side DLLs to debug a particularly thorny issue we had with the Delphi compiler, when I was at Borland. Not quite the same, but still a lot of staring at disassembly with not a huge amount of help. Ultimately, it only took a few hours of effort, in large part because there's so much tooling support, and things like messages and public symbols were available.)
Being more familiar with assembly would definitely help. The only time I look at assembly is when I'm using a JTAG debugger, which is not my primary activity.
Our firmware has a lot of ASIC pathways that are only accessible through register reads/writes, and in some circumstances only statuses are available through the registers, so I believe reverse engineering an SSD would be more difficult than it first appears.
If you already knew roughly how a HDD controller would need to work - what kind of I/O it would need to do, both at the controller end and the head movement end, couldn't you work backwards from there?
Reversing something like GC as needed in an SSD I can see as being harder, but again, wouldn't it largely be a matter of knowing that a certain number of parts of particular shapes - whether it's marking, tracing, copying / compacting, etc. - need to exist, and and finding them?
I think that if you really got stuck into the problem, it wouldn't take as long as you think. A lot of it is familiarity and fluency with the disassembly, I reckon.
(The closest I've gotten to this professionally was in reversing the Windows kernel and related user-side DLLs to debug a particularly thorny issue we had with the Delphi compiler, when I was at Borland. Not quite the same, but still a lot of staring at disassembly with not a huge amount of help. Ultimately, it only took a few hours of effort, in large part because there's so much tooling support, and things like messages and public symbols were available.)