4 Responses to “Firmware Forensics: Best Practices in Embedded Software Source Code Discovery”

1. Nick says:

   September 27, 2011 at 12:32 pm

   Good article. Coming from an avionics background this stuff sounds like common sense. Maybe the wider software community should consider some of the guidance in e.g. DO-178B? I’d not advocate a slavish adherence to it for non-aerospace code as the costs will kill you, but it offers good food for thought…

   Reply
2. Mike near SYR says:

   September 28, 2011 at 10:03 am

   >>”NASA failed to find a firmware cause of unintended acceleration—but their review also fails to rule out firmware causes entirely”

   Of course!

   Tweaking a quote from Edsger W. Dijkstra,
   “Code review (Program testing) can be used to show the presence of bugs, but never to show their absence”

   Reply
3. John Tarbotton says:

   October 13, 2011 at 3:17 pm

   Building the source can only prove the source is the correct source. It can not prove that it is not the correct source. We use a compiler which apparently links object together in the order they are found in the directory or something as it has been shown the using the same source and building multiple times does not produce outputs which compare the same, the modules are rearranged. To eliminate this we have had to ensure we do a clean and complete rebuild when we make release versions.

   Reply
   • Michael Barr says:

     October 13, 2011 at 3:19 pm

     Agreed.

     Reply