home *** CD-ROM | disk | FTP | other *** search
/ Power-Programmierung / CD1.mdf / lan / spy / spy.doc next >
Text File  |  1989-10-04  |  11KB  |  235 lines
  1. Description
  2. -----------
  3. SPY is a "remote control" program for NetBios compatible networks.  The
  4. current version of SPY is intended as a demonstration of a network
  5. client-server application implemented in a Pascal.  We have found it somewhat
  6. useful for lending remote assistance to some of our network users.
  7.  
  8. SPY and its accompanying documentation and source files are:
  9.  
  10. Copyright (c) 1989 by Edwin T. Floyd
  11. All rights reserved
  12.  
  13. SPY and its accompanying documentation is not "shareware" and I do not request
  14. payment for it.  You may distribute and use it without restriction as long as
  15. you don't sell it and don't hold me liable for any errors or consequential
  16. damages.  If you wish to include this software as part of a commercial
  17. package offered for sale, you must obtain written permission from me, the
  18. author:
  19.  
  20. Edwin T. Floyd [76067,747]
  21. #9 Adams Park Court
  22. Columbus, GA 31909
  23. 404-322-0076 (home)
  24. 404-576-3305 (work)
  25.  
  26. Release History
  27. ---------------
  28. 10-04-89 1.1 - Common functions separated to SPYSUP, recovery improved.
  29.                First public release.
  30. 09-30-89 1.0 - Internal version, never released
  31.  
  32. Operation
  33. ---------
  34. SPY is in two parts: SPY.EXE and SPYTSR.EXE.
  35.  
  36. SPYTSR is a "Terminate and Stay Resident" program that must be running on the
  37. machine to be controlled.  Run like this:
  38.  
  39.   SPYTSR name [adapter]
  40.  
  41. ..where "name" is the network name by which this invocation of SPYTSR is to
  42. be known, and (optional) "adapter" is a numeric network adapter number.  If
  43. adapter is omitted, SPYTSR uses adapter zero.  The network name may be up
  44. to fifteen characters long.  All alphabetic characters in the name are shifted
  45. to upper case.  The name may not contain spaces.  The actual network name that
  46. SPYTSR adds to the adapter is the name specified padded to the right with
  47. spaces to fifteen characters and terminated with 0EFh as the sixteenth
  48. character.
  49.  
  50. SPYTSR occupies about 36k (large for a TSR, but not too bad for one written in
  51. a high-level language), and does very little except listen until it receives a
  52. request from SPY.  SPYTSR handles these types of requests:
  53.  
  54.   SendScreen     - Reads the contents of the video buffer and cursor position
  55.                    into an internal buffer and transmits it to the client.
  56.  
  57.   StuffKeyboard  - Copies Key and Scan Codes from the client's message to an
  58.                    internal table where they are inserted into the keyboard
  59.                    stream by the Int 16h intercept.  To the user, keystrokes
  60.                    simply appear out of nowhere.  It's really spooky.
  61.  
  62.   Boot           - Reboots the system running SPYTSR as if the user had
  63.                    performed a "three finger salute" (Ctrl-Alt-Del).
  64.  
  65.   DieQuietly     - SPYTSR cancels all its sessions and commands, deletes its
  66.                    network name and removes itself from memory.
  67.  
  68.   SendScreenInfo - SPYTSR returns information about it's video screen,
  69.                    including the adapter type, video mode, number of rows
  70.                    and columns, and the maximum size of the buffer that
  71.                    SendScreen may transmit.
  72.  
  73. SPY is a quick-and-dirty remote control program that builds requests for
  74. SPYTSR and displays the screen data returned by the SendScreen request.
  75. Run like this:
  76.  
  77.   SPY name [adapter]
  78.  
  79. ..where "name" is the network name by which an invocation of SPYTSR is known
  80. (see above), and (optional) "adapter" is a numeric network adapter number.
  81. If adapter is omitted, SPY uses adapter zero.  SPY constructs a network name
  82. just like SPYTSR does, and then calls that name in an attempt to establish a
  83. "session" with SPYTSR.  If SPY is unable to establish a session within about
  84. half a minute, it gives up and terminates with an error message.  If SPY is
  85. successful, it requests screen information via SendScreenInfo, allocates
  86. memory for a screen buffer, and then begins its monitor cycle.
  87.  
  88. The monitor cycle has two independent components which are implemented as
  89. subtasks in the SPY program. They are:
  90.  
  91.   Screen-Update cycle - About once every two seconds, SPY sends a SendScreen
  92.   request to SPYTSR, receives the screen data reply and displays the screen
  93.   data on the local screen.  For few seconds after the Keyboard cycle (see
  94.   below) sends a StuffKeyboard request, the Screen-Update cycle requests
  95.   screen data about twice each second.  Screen updates are suspended during
  96.   "Break" processing.  The Screen-Update cycle also attempts to reestablish
  97.   a broken session by calling SPYTSR.
  98.  
  99.   Keyboard cycle - SPY constantly checks for keystrokes by issuing
  100.   Int 16h.  The keyboard cycle moves keystrokes to a StuffKeyboard request
  101.   message transmits to SPYTSR.  The keyboard cycle also examines keystrokes
  102.   for the "Break" key (Alt-0 in this implementation), displays the break
  103.   menu on the screen, and processes the menu selection keystroke.
  104.  
  105. When the SPY user presses Alt-0, the Keyboard cycle displays the following menu
  106. on the screen:
  107.  
  108.     You are connected to remote system <name>
  109.     Break menu:
  110.  
  111.       (E)xit SPY on local system
  112.       (B)oot remote system
  113.       (S)top SPYTSR on remote system
  114.       (Alt-0) Send Alt-0 to remote system
  115.  
  116.     Press a key to choose an action or <Esc> to return...
  117.  
  118. The next keystroke determines the action taken by SPY, as indicated on
  119. the menu.  Allowable keystrokes are indicated in parentheses.  All other
  120. keystrokes are ignored, except Escape which returns the user to the screen
  121. update display.  If the user chooses any option except Alt-0 or Escape, SPY
  122. terminates after restoring the original screen saved when it started.
  123.  
  124. Two other utilities are supplied: SPYSTOP.EXE and SPYBOOT.EXE.  These are
  125. non-interactive commands that simply issue the DieQuietly (SPYSTOP) and
  126. Boot (SPYBOOT) requests to a SPYTSR invocation.  Both utilities accept the
  127. same command line parameters as SPY.EXE.
  128.  
  129. The executable code for SPY is distributed in the SPYEXE.ZIP archive.  This
  130. archive includes the following files:
  131.  
  132.   SPYTSR.EXE   - Resident portion of SPY
  133.   SPY.EXE      - SPY monitor
  134.   SPYSTOP.EXE  - Remote stop utility
  135.   SPYBOOT.EXE  - Remote boot utility
  136.   SPY.DOC      - This file
  137.  
  138. Source Code
  139. -----------
  140. The source code for SPY is distributed in the SPYSRC.ZIP archive.  This
  141. archive includes the following source files:
  142.  
  143.   SPY.PAS      - Source code for SPY
  144.   SPYTSR.PAS   - Source code for SPYTSR
  145.   SPYSTOP.PAS  - Source code for SPYSTOP
  146.   SPYBOOT.PAS  - Source code for SPYBOOT
  147.   SPYSUP.PAS   - Source code for support unit with common declarations for
  148.                  other SPY sources.
  149.  
  150. In addition SPYSRC contains the following support files:
  151.  
  152.   NETBIOS.TPU  - Precompiled unit for NetBios support
  153.   NETBIOS.DOC  - A copy of the Interface section for NETBIOS.TPU
  154.   TSR.TPU      - Precompiled unit for Terminate and Stay Resident support
  155.   TSR.DOC      - A copy of the Interface section for TSR.TPU
  156.   MULTI.TPU    - Precompiled unit for Non-preemptive multitasking
  157.   MULTI.DOC    - A copy of the Interface section for MULTI.TPU
  158.   MULTITSR.PAS - Source code for unit which links MULTI and TSR units
  159.   SCREEN.PAS   - Source code for screen I/O unit
  160.   SCREEN.OBJ   - Preassembled external routines for SCREEN
  161.   SPY.DOC      - This file
  162.  
  163. Because the precompiled units were compiled with Turbo Pascal, v5.5., that
  164. version of the compiler must be used to compile the source code supplied.
  165. Source code for units: NETBIOS, TSR, MULTI, and SCREEN.ASM will be available
  166. from the author at some future date.
  167.  
  168. Limitations
  169. -----------
  170. This version of SPY properly displays text-mode screens only.  It does not
  171. translate attribute bytes when monitoring a screen which displays many colors
  172. on a monitor which displays fewer colors, so your text may look strange when
  173. you "SPY" a CGA, EGA or VGA screen on a monochrome monitor.  Graphics will
  174. simply look like garbage.  Also, no provision is made to monitor off-screen
  175. portions of an EGA or VGA 43 or 50 line mode screen on an adapter which is
  176. currently displaying 80 x 25.  In that case, only the upper-left corner of the
  177. screen would display.  SPY uses the current mode of the screen from which it
  178. is run, so it may be advisable to issue a MODE command before running SPY.
  179.  
  180. The keyboard cycle on both SPY and SPYTSR works entirely with the data
  181. available via Int 16h.  So it will be impossible to trigger programs which
  182. monitor the BIOS shift state flags or the keyboard interrupt (Int 09h). This
  183. includes many TSR's, like SideKick (I haven't actually tried it with SideKick,
  184. but suspect it won't work), LanPup, and some communications programs (ProComm
  185. works nicely; in fact, I use it to run ProComm on a network server from my
  186. office).  Because of the communications delay and the relatively long interval
  187. between screen updates, remote keyboarding appears sort of "jumpy"; the
  188. character keyed may not appear immediately on the monitor.  This can be
  189. disconcerting to some typists (it is to me).
  190.  
  191. In addition to the areas indicated above, a commercial implementation of a
  192. network remote control program should perform data compression on screen data.
  193. This would allow screen updates to occur more often without swamping the
  194. network and might improve the "jumpy" effect.  Perhaps a copy of the screen
  195. last transmitted could be maintained in SPYTSR and only the differences sent
  196. (this gets a little tricky where multiple clients are requesting screens
  197. asynchronously, so to keep the demo simple I didn't attempt it here.).
  198.  
  199. True to it's name, SPY has absolute no security features.  The user of the
  200. remote system running SPYTSR is completely at the mercy of anyone who knows
  201. its network name and has a copy of SPY.  A commercial implementation should
  202. provide some form of password protection and a courtesy warning to message
  203. should appear on the monitored screen whenever SPY connects.  The target
  204. system user should have the option of being or not being monitored.
  205.  
  206. SPY should be rewritten to manage multiple remote screens in separate windows,
  207. and, finally, SPYTSR really should be rewritten in assembler to reduce it's
  208. overhead.
  209.  
  210. Or, you could buy The Network Eye (tm) by Artisoft in Tucson Arizona.  I
  211. hear good things about this product, though, at this writing, I haven't tried
  212. it yet.  I believe it implements most of the "improvements" listed above,
  213. including multiple windows.
  214.  
  215. Other uses
  216. ----------
  217. The SPY and SPYTSR source programs provide a "shell" which may be used to
  218. implement other "client-server" applications in Pascal.  Those portions of
  219. SPYTSR which handle SPY requests may be replaced with code which does just
  220. about anything.  The support units; MULTI and TSR remove most of the
  221. restrictions ordinarily associated with TSR's in high level languages.  In
  222. particular, the server may open files and do disk I/O with standard Pascal
  223. procedures.
  224.  
  225. What's in store
  226. ---------------
  227. I plan to supplement the NETBIOS and MULTI units later this year (89) with
  228. units to handle most of the dirty work of client-server applications through
  229. NetBios; in particular: synchronization and error recovery after interruption
  230. of the network connection.  In the near future I will make available the
  231. source code for the precompiled units.  Please drop me a note (write, please,
  232. don't call) if you want to be notified when these are ready.
  233.  
  234.                           - End -
  235.