“Diebold XFS服务”源代码级深入解析

 

这篇文章的目的是记录一下我分析“Diebold XFS服务”软件是怎样实现的过程。当然，我是没有Diebold软件的源代码的，也没看过一句我所分析内容涉及到的代码，其源代码只在国外才有，我手中只有执行程序，不过，一个软件有没有源代码对于我来说是无关紧要的，面对着计算机这个东西，我只看到代表0和1的高低电平在机器里面跳跃着，在总线、硬盘、内存之间不停的忙碌着，其实它们与人类的世界并没有什么分别。

 

    如果你对Diebold XFS服务是怎样实现的感兴趣的话，可以看看，不过估计能够基本看懂这篇文章的人极少。因为本来熟悉ATM平台软件编写的人就少，再者熟悉Diebold软件的人也少，而这两者都熟悉的人在中国不会再找到了。不过，如果你有足够的技术基础和ATM行业知识的话，这篇文章应该对你会有些帮助的。

 

    你要是接触过Diebold的机器，那么对于我在下文中提到的东西应该非常熟悉了，虽然你从来没有去想过在“Diebold XFS服务”背后，它都做了些什么工作。

 

（本文假设大家对ATM的相关标准都比较熟悉，不专门解释文中出现的每个术语）

 

    我这次是分析基于Windows平台下面的符合CEN/XFS标准2.0版（其实3.0基本不变）的Diebold软件，不管以前在OS/2下面常用的TCS 912等系统。下面提到的底层都指Windows平台的底层，一般被迪堡称为Agilis Power平台。

 

因为Diebold在Windows平台下面的软件都是符合WOSA/XFS标准的，所以分为两个大部分，一个属于XFS Manager上面的一层，对应的业界标准一般是ActiveXFS规范，另外一个属于XFS Manager下面的一层，俗称SP，对应业界的WOSA/XFS规范。

 

    “Diebold XFS服务”是XFS Manager上面的一层，但是它却跟其他上层模块没有太大关系。

 

    如果接触过Diebold软件的人都知道，Diebold机器上要想运行ATM软件，首先是启动一个Windows系统服务，叫做Diebold XFS。启动的方式就是打开在“控制面板”里面的“服务”，找到叫做Diebold XFS的一项服务，然后鼠标点击“启动”即可。正常生产上运行的机器，这项服务都被设置为“自动启动”，只要操作系统一起来，服务就会启动了。

 

       Diebold XFS是整个Diebold的程序入口处，是第一个启动的主要程序，由它来启动其他的东西，包括初始化硬件等工作。其实Diebold XFS只是“服务”中的一个名字，对应的程序是“C:/Diebold/xfs/bin/SPIService.exe”，启动了Diebold XFS仅仅是将SPIService.exe执行起来了。

 

    既然SPIService.exe这么重要，我们先从它看起。SPIService.exe依赖几个非操作系统自带的文件分别是“C:/Diebold/XFS/bin/dboldspi.dll”、“C:/Diebold/XFS/bin/dztracr0.dll”，“C:/windows/system32/XFS_Conf.dll”。

 

其中XFS_Conf.dll没什么可说的，是XFS Manager自己的三个DLL之一，主要是用来访问注册表的，包括WFMOpenKey等函数，在这里主要是SPIService.exe要访问注册表中的有关SP配置的项，所以用到了XFS_Conf.dll。

dboldspi.dll是非常重要的dll，它就是导出SPI接口的SP程序，该dll导出了WOSA/XFS规范规定的WFPOpen、WFPClose等SPI。但是除了导出SPI之外，dboldspi.dll还导出了其他Diebold自用的接口，对于SPIService.exe来说，只用了dboldspi.dll的3个接口，分别是StartSPIDevice、StopSPIDevice、AreSPIInitialized。看这三个函数的名字就知道它们是干什么的了，StartSPIDevice是启动SP的，StopSPIDevice是停掉SP的，AreSPIInitialized是判断SP是否已经被启动了。

dztracr0.dll是用来记录日志的。整个迪堡的底层都是用这个dll来实现记录日志的。Diebold的平台还配置了一个工具叫做DzTrace.exe，它是用来配置各个SP模块记录的日志级别、是否把日志记录到硬盘等内容，相当于一个日志配置工具。DzTrace.exe还属于一个日志查看显示工具，因为如果没有将日志配置为记录到硬盘的时候，SP的日志都不会保存，但是在SP运行的时候，你打开DzTrace.exe，它有个文本框（DzTrace.exe就是个MFC向导建的单文档视图程序）会实时显示SP的日志内容。

dztracr0.dll导出了大概10几个API，其中比较常用的是OpenTrace、GetTraceLevel、SendTraceMsg和SendErrorMsg，SPIService.exe也就用到了这4个函数。SPIService.exe调用SendTraceMsg和SendErrorMsg时只要把日志内容传给该函数就可以了，至于记录日志的事情都是dztracr0.dll自己完成。

 

    好了，到现在为止我们已经看了SPIService.exe所涉及到的几个dll及其相应的作用，下面开始看看整个程序是怎样运转起来的。

 

    因为SPIService.exe是一个Windows“服务”，所以它的启动是通过系统服务控制器来实现的。我们需要熟悉“服务”是怎样调用起来的才能理解SPIService.exe。在Windows的“服务”中针对每个服务都有“启动”、“停止”、“暂停”、“恢复”几个按钮。当你选中Diebold XFS那项服务，然后按“启动”时，实际上是操作系统调用了“SPIService.exe  / Install”，相应的“停止”就是“SPIService.exe  / UnInstall”。所以SPIService.exe运转是这样的：点击Diebold XFS服务的“启动”按钮，Windows进行一系列处理，最终将SPIService.exe装载起来，并且以参数Install调用。

 

    接着看看SPIService.exe里面的程序。SPIService.exe的程序入口就是个命令行解析处理，如果发现操作系统启动服务时传入的命令行字符是“Install”，就走一个分支；如果是“UnInstall”就走另外一个分支。

 

    当传入“Install”时，表示有人要启动Diebold XFS服务了。SPIService.exe首先将传入的字符串与“Install”比较，如果相同则继续。接着

SPIService.exe以字符串“XFSService”为参数调用了dztracr0.dll的OpenTrace函数，可见整个SPIService.exe的日志应该记录到对应于“XFSService”的那个日志文件了。

    日志启动完成后，程序接着调用StartServiceCtrlDispatcher函数，传入参数包含要操作的服务名字：“dbdxfs”（Diebold XFS的实际名字是dbdxfs，Diebold XFS只是显示名字而已），要求连接到操作系统的service control manager，如果连接失败，调用SendErrorMsg记录“Unable to StartServiceCtrlDispatcher”，整个程序直接返回。如果打开成功，记录“Register Service for  …...”，接着调用OpenSCManager打开服务控制的数据库，失败则记录“Unable to OpenSCManager”。接着调用CreateService函数将dbdxfs服务启动起来，如果调用失败，则记录日志，调用CloseServiceHandle关闭刚才打开的句柄。

 

    上面是一个标准的Windows下面的服务启动过程，当传入“UnInstall”参数其处理也差不多，只是最后要调用DeleteService把自己从系统服务中删除，而上面是CreateService把自己创造出来。

 

    服务起来后，记录日志“Starting Service”，接着调用RegisterServiceCtrlHandler将服务的处理函数注册进去，以后针对Diebold XFS的调用都转到该被注册的函数中去处理。接着调用SetServiceStatus函数，在服务控制管理器里面将数据库的状态更新了下，表示与操作系统服务打交道的这块已经准备完毕了。

   到这里，SPIService.exe本身的处理已经差不多了，它接着就开始调用dboldspi.dll导出的AreSPIInitialized函数，看看是否SP已经被起来过，如果已经起来了，调用SetServiceStatus函数更新下，然后就直接返回。

    如果是第一次起程序，继续向下。先记录“Before AreSPIInitialized”，接着记录“Waiting for device to initialize…..”，然后调用SetServiceStatus函数更新下，接着调用了Sleep函数将主线程挂起来一段时间。

      

   接着记录“SPIServiceInitialization”，直接调用WOSA的函数WFMOpenKey打开注册表的HKEY_LOCAL_MACHINE/SOFTWARE/Diebold/Diebold XFS SPIs键，该键里面有一项叫做“installGDriver”，如果发现其不为0，则找到另外一项“path”，这里面是GDriver相关的文件目录，一般path这一项里面的内容是“C:/Diebold”，接着调用strcat将该路径与字符串“XFS/AxiohmPrinter/GDriverInst.cmd”合并，最后的结果是“C:/Diebold /XFS/AxiohmPrinter/GDriverInst.cmd”，然后就直接调用fopen打开文件了，其参数就是刚组合好的GDriverInst.cmd 文件。我看了一下这个cmd文件，内容如下：

 

@echo off

call c:/diebold/xfs/bin/prtsetup.exe -v -i -p THRML1 -n "Axiohm 2002" -d "Axiohm 2002" -f rasdd.dll -e 2002.dll -c rasddui.dll -b rasddui.hlp -o c:/diebold/xfs/log/thermallog.txt

 

 

实际上是安装一个热敏打印机的驱动程序。看来这个设备很重要，以至于在程序里面专门处理一下。

该cmd文件调用完后，接着调用WFMSetValue将“installGDriver”的值置为0。

 

这样看来，只会安装这个驱动一次。

 

接着，又看看注册表里面的HKEY_LOCAL_MACHINE/SOFTWARE/Diebold下面有没有“start_css”这个配置，如果有，接着调用InitializeSecurityDescriptor初始化一个新的安全描述符，接着SetSecurityDescriptorDacl一下，然后CreatePipe建了个管道。

      

下面就看“css_path”配置的路径是什么，然后直接调用CreateProcess新建了个进程，该进程执行css_path路径下面的“css.exe    /AE  /IN  /TR”程序。Css.exe是Diebold用来网络通讯用的通讯子模块。

 

上面提到的一堆东西，都不是关键部分，下面该关键部分出场了。因为是WOSA/XFS2.0的程序，所以有关SP的配置是在HKEY_CLASSES_ROOT/WOSA/XFS_ROOT 下面，这个熟悉WOSA/XFS的人都知道的。

 

首先直接调用WOSA的函数WFMOpenKey打开注册表的LOGICAL_SERVICES键，接着对该键下面的所有子键使用WFMEnumKey函数进行枚举，找到每个子键的项Provider，然后根据Provider的值找到对应的SERVICE_PROVIDERS所在的子键，然后看这些子键的项是否有一项叫做“autostart”的，如果该项被配置为“1”，表示需要自动重启，则会调用dboldspi.StartSPIDevice，将该SP启动起来。此时各个硬件设备开始做初始化动作，如果熟悉Diebold机器的人都会知道，当“Diebold XFS服务”被启动时，等几秒钟ATM机器的读卡器、出钞机芯、流水等会做动作，就是在这个时候开始的，因为“Diebold XFS服务”会调用每个被配置为autostart的设备SP的导出函数StartSPIDevice，从而硬件设备会做初始化动作。

 

提到autostart，熟悉的人都会想起，Diebold提供的一个工具叫做“XFS Configuration Editor”，里面打开后一般要求把机器上要使用的设备设为autostart，其他不用的设备设为not autostart，其作用就是在这里提供给“Diebold XFS服务”用的。

 

到了这里整个“Diebold XFS服务”要做的工作都已经基本完成，剩下的一件事就是启动CSS的日志记录功能，让其单独去记录日志去。

 

好了，“Diebold XFS服务”已经启动完毕，在Windows的服务列表中，也显示服务状态变为“已启动”。

 

(http://www.docin.com/p-19860912.html)