Christopher Smith wrote:
I'm trying to think of reasons why this would be the case.... It would
imply that you can't spawn a process (which would cause problems for
just about any technique) or the executable has been corrupted (in which
case you are screwed anyway). Finally, either way, the "strings" based
approach would *still work*, it's just that you'd have a more convenient
way to grab that information in the event that things are working well
enough to use it.
I'm clearly missing something here.
OK, here's a problem I've run into many times. Too many in fact. Because
of poor design and no thought of testing and debugging during the design
process, it was always *extremely* difficult to get to the root cause of
the problem.
There have been times where a customer would do something to a system
(I'm talking embedded systems now) that would corrupt the flash file
system (FFS), which is a DOS based system - FAT16. Thereafter when the
system booted, it would quickly reboot after loading the OS from the FFS
was loaded. The shell would not work, so no commands could be entered.
The is a mechanism that prints out the version of the code, but the OS
would not even get that far. So, no data available when it booted.
Now sometimes customers have the ability to re-flash the system with a
different version of code. Customers are not trustworthy, so even asking
them what version was in the system is not reliable (usually they are
not sure anyway). So then, how to find out what version of code is in
the system so that it can be tested in the lab, debugged, etc?
The best way would be to have a clear string placed in the executable
image in a place that's known and not touched by the rest of the code.
(Even if it's not readily known, an ASCII string can be picked out
easily enough from the object code surrounding it.) The chances of that
spot in the image being nuked (in the case of the above problem) is very
limited. In order to read the string it's not necessary to have an
active shell for execution of a command. There are other ways to
download the image from the system and view it.
PGA
--
Paul G. Allen, BSIT/SE
Owner, Sr. Engineer
Random Logic Consulting Services
www.randomlogic.com
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
