home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / msdos / programm / 9110 < prev    next >
Encoding:
Text File  |  1992-09-08  |  2.8 KB  |  70 lines
  1. Newsgroups: comp.os.msdos.programmer
  2. Path: sparky!uunet!utcsri!geac!zooid!ross
  3. From: Ross Ridge <ross@zooid.guild.org>
  4. Subject: Re: studying executables
  5. Organization: ZOOiD BBS
  6. Distribution: comp
  7. Date: Sun, 6 Sep 1992 23:24:08 GMT
  8. Message-ID: <1992Sep6.232408.11684@zooid.guild.org>
  9. References: <ARA.92Sep6131908@camelot.ai.mit.edu>
  10. Lines: 58
  11.  
  12. ara@zurich.ai.mit.edu (Allan Adler) writes:
  13. >For years I have had an interest in understanding, in the absence of any
  14. >documentation, what a given executable does.
  15.  
  16. Try running it.
  17.  
  18. >I understand that one can simply use a debugger, preferably a smart one,
  19. >and follow it step by step in the hope of discovering what the code does.
  20.  
  21. Boring.  
  22.  
  23. >First, it seems to me that every compiler and every assembler must have its
  24. >own idiosyncratic way of producing the executable. Is that true?
  25.  
  26. For compilers yes, for assemblers no.  With assemblers every byte of
  27. the execuatable is under the programmers control.
  28.  
  29. >If so, then it might be possible to have a database of idiosyncrasies
  30. >that lets one figure out what compiler or assembler produced the executable.
  31.  
  32. For compilers, it's easy just look at the startup code.  Every compiler
  33. and compiler version has there own, pretty much unique start up code.
  34. What makes this even is easier is the fact that this start up code often
  35. contains giveaway copyright strings.
  36.  
  37. >For each compiler, there might be a specific decompiler that takes into
  38. >account the special features of that compiler. Also, if by some miracle
  39. >the code was compiled but not optimized, it seems like it would retain
  40. >more features of the original.  Or if compiled with C and debugging
  41. >information was not stripped from the executable, that would be quite
  42. >helpful. Knowledge of the source language and the specific compiler seems
  43. >like it would be quite helpful.
  44.  
  45. With BASIC you might have some luck, the code probably was a mess of
  46. GOTO's anyways, but with other languages reverse compiling isn't going
  47. to get you anything more intellegible then a simple disassembly.
  48.  
  49. >The second idea is that even if one knows nothing about the source language
  50. >or the compiler, one can still imagine tools that will give an overview
  51. >of the structure of the program. The trouble with debuggers and disassemblers
  52. >is that they work at the lowest level, one instruction at a time. Imagine
  53. >instead an attack on the entire executable.
  54.  
  55. [ much thought on how to "attack" an entire executable deleted ]
  56.  
  57. >Admittedly this does not solve the problem, but I feel that automating what
  58. >I have described would put one in a position to take the next step.
  59.  
  60. You're talking about a whole mess of heuristics, something better
  61. performed by a human than a computer.
  62.  
  63.                             Ross Ridge
  64.  
  65. -- 
  66. Ross Ridge - The Great HTMU                         l/     //
  67.                                     [OO][oo]
  68. ross@zooid.guild.org                            /()\/()/
  69. uunet.ca!zooid!ross                             db     //
  70.