readsig.txt 3.4 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697
  1. READSIG
  2. 1 What is ReadSig?
  3. 2 How do I use ReadSig?
  4. 3 What are duplicate signatures?
  5. 4 How can I make sense of the signatures?
  6. 1 What is ReadSig?
  7. ------------------
  8. ReadSig is a quick and dirty program to read signatures from a DCC
  9. signature file. It was originally written as an integrity checker for
  10. signature files, but can now be used to see what's in a signature
  11. file, and which functions have duplicate signatures.
  12. 2 How do I use ReadSig?
  13. -----------------------
  14. Just type
  15. readsig <sigfilename>
  16. or
  17. readsig -a <sigfilename>
  18. For example:
  19. readsig -a dcct2p.sig
  20. Either way, you get a list of duplicate signatures, i.e. functions
  21. whose first 23 bytes, after wildcarding and chopping, (see section 3
  22. for details), that have the same signature.
  23. With the -a switch, you also (before the above) get a list of all
  24. symbolic names in the signature file, and the signatures themselves
  25. in hex. This could be a dozen or more pages for large signature
  26. files.
  27. Currently, signatures are 23 bytes long, and the symbolic names are
  28. truncated to 15 characters.
  29. 3 What are duplicate signatures?
  30. --------------------------------
  31. Duplicate signatures arise for 3 reasons. 1: length of the signature.
  32. 2: wildcards. 3: chopping of the signature.
  33. 1: Because signatures are only 23 bytes long, there is a chance that
  34. two distinct signatures (first part of the binary image of a
  35. function) are identical in the first 23 bytes, but diverge later.
  36. 2: Because part of the binary image of a function depends on where it
  37. is loaded, parts of the signature are replaced with wildcards. It is
  38. possible that two functions are distinct only in places that are
  39. replaced by the wildcard byte (F4).
  40. 3: Signatures are "chopped" (cut short, and the remainder filled with
  41. binary zeroes) after an unconditional branch or subroutine return.
  42. This is to cope with functions shorter than the 23 byte size of
  43. signatures, so unrelated functions are not included at the end of a
  44. signature. (This would cause dcc to fail to recognise these short
  45. signatures if some other function happened to be loaded at the end).
  46. The effect of duplicate signatures is that only one of the functions
  47. that has the same signature will be recognised. For example, suppose
  48. that sin, cos, and tan were just one wildcarded instruction followed
  49. by a jump to the same piece of code. Then all three would have the
  50. same signature, and calls to sin, cos, or tan would all be reported
  51. by dcc as just one of these, e.g. tan. If you suspect that this is
  52. happening, then at least ReadSig can alert you to this problem.
  53. In general, the number of duplicate signatures that would actually be
  54. used in dcc is small, but it is possible that the above problem will
  55. occur.
  56. 4 How can I make sense of the signatures?
  57. -----------------------------------------
  58. If you're one of those unfortunate individuals that can't decode hex
  59. instructions in your head, you can always use DispSig to copy it to a
  60. binary file, since you now know the name of the function. Then you
  61. can use debug or some other debugger to disassemble the binary file.
  62. Generally, most entries in signature files will be executable code,
  63. so it should disassemble readily.
  64. Be aware that signatures are wildcarded, so don't pay any attention
  65. to the destination of jmp or call instructions (three or 5 byte
  66. jumps, anyway; 2 byte jumps are not wildcarded), and 16 bit immediate
  67. values. The latter will always be F4F4 (two wildcard bytes),
  68. regardless of what they were in the original function.