帮妹子解决一个SAP B1的问题，这个问题是：SAP B1里面有一个公司的数据，这个公司里面有一个用户，如何修改这个用户的名称。。。我已经可以猜到这个到底是要干啥了。

之前没有接触过SAP B1，所以找下载就耗了一点时间，ftp2.sjtu上面只有miniSAP 6.1，太老了，仅次于她们在用的SAP Business One 2005b（中文版7.0）。这个资源貌似网上很难找，最后总算在一个网盘（趣盘）上找到一个。后来我在找参考书籍的时候，意外发现某本书附带的光盘中竟然有一个preloaded version（所谓的预览版），不过功能受限。感谢图书馆的光盘镜像检索系统。

妹子给的是一个64.8MB的没有后缀的备份文件，不知道这个是怎么备份和恢复的，又不好意思去问，只能自己琢磨。在SAP B1中找备份和恢复的功能，觉得不太像。然后尝试用二进制编辑器打开，希望看出点端倪，又是无功而返。

折腾SAP B1的过程中倒是对这个东西有了点了解，这个东西后端存储全靠数据库，前端就是一个壳。安装以后后端SQL Server 2000中多出来的SBO-COMMONS与SBODemo_China两个数据库，分别是SBO全局配置信息与“北京海城电子公司”的信息。

然后就可以很自然地猜到这个文件可能是数据库的一个备份，数据库备份要么备份为SQL文件，要么是私有的二进制格式。测试一下吧，把SBODemo_China备份为一个文件，备份完成的时候我已经知道我猜对了，因为文件大小基本一致。二进制打开，文件头的magic number是TAPE，与原文件一致，猜测基本正确。

然后随便新建一个数据库，恢复备份数据，表结构等与SBODemo_China一致，猜测得到验证。

剩下的问题是如何建立某个公司与这个数据库的联系。直接的猜测是（公司，数据库名）的关系应该是存储在SBO-COMMONS数据库中的，这个库中的表不多，一个个看过去吧。很容易地找到了是存在dbo.SRGC表中。从这些表名的杂乱无章来看，很明显是做过混淆处理的。

这里新建一个（或者修改现有的），就可以从SBO中登录这个公司了，数据库则是恢复的这个数据库。

知道了这个对应关系在哪里管理，就可以各种操作了，比如可以把一个公司的数据倒腾到另一个公司内，只要在两个数据库之间倒腾就行了。

倒腾数据的方法很多，SQL Server自带的“企业管理器”就有数据的导入导出功能，或者可以把一个数据库备份为一个文件（二进制或者sql）然后恢复到另一个数据库中。

下一个问题是修改用户名，可以猜测到的是，既然一个公司的所有信息都存储在这个公司的数据库中，用户信息肯定也是存在某个地方的。继续从SBODemo_China下手吧，展开数据库以后我傻眼了，960个表，表名同样做过混淆处理，没办法像SBO-COMMONS那样一个个检查了。

后来想到的办法是查看SBODemo_China的日志，活该倒闭的微软（嗯，我这么说我前准东家是不是不太厚道。。），ldf文件格式是封闭的。google了一个third party的工具，惨不忍睹。

然后尝试一下新版的sql server是否可以提供类似功能，用的是SQL Server 2008 R2 Express，依然无功而返。顺便记录一下，Management Studio连接的时候，服务器要填入(local)\SQLEXPRESS，即需要同时指定host和sql instance。

再次google，找到SQL Server的一条undocumented的命令，dbcc。吐槽一下，undocumented意味着微软不需要为这些命令提供支持服务，而且可以随便折腾这些命令，包括随时在下一个版本中移除。

语法是 dbcc log (SBODemo_China, 3)，第一个参数是db-name，第二个是info-level，更多dbcc功能请google。

然后，打开SBO，随便用一个用户登录，登录的过程SBO总归要来数据库保存用户的表里面看看么，果然，log的最后几条是access名为dbo.OUSR表的。看到名字就知道找到了。

这个表里的字段名倒是没有做混淆，和之前一样。从字段名和现有的用户信息，很容易就能搞明白各个字段是什么意思。修改用户名么，就直接在这里修改就好了，USER_CODE是登录用户名，U_NAME是显示用户名。

到此为止目的已经达到了，不过看到旁边的PASSWORD字段，咱还是按捺不住折腾一下的心思。PASSWORD字段之后，竟然还有PASSWORD1、PASSWORD2。。也许是历史设计的遗迹吧。SBO内修改密码，这里的值就变掉了，到底是怎么一个对应关系，眼睛看是看不出来的，可能要对SBO的主程序做一下逆向，看看passphrase是如何变换得到这里的密钥串的。这个过程是有标准的（可以参见之前的博文），如PKCS#5。但说实话本人对IT从业者的安全意识与安全能力并不抱太大希望。之前CSDN被暴库，用户密码都是明文保存的；还有之前看到QQ某款产品在产品介绍中声称自己保存的密码是经过MD5“加密”的，一声叹息。

虽然不反向工程就不知道这个变换过程，而且即使是知道了可能也无法破解某用户的密码（例如变换过程某一步使用了cryptographic hash function, 如SHA-1），仍然可以注意到SBO保存的这个（变换过的）密码是仅与用户的passphrase相关的（废话，当然是了），那么，substitution attack（某种意义上的replay attack），就可以替换掉某个用户的密码了。

实际应用中，SBO的这种设计不会引入太大的安全隐患（要修改sbo.OSUR，还不如直接修改想修改的其他库），但仍然可能会在某些场合下会带来问题。比如：某个公司的ERP系统使用的是SBO，但是数据库没有良好防范，攻击者攻破db server以后，就可以修改某用户的密码，然后使用该用户账户登陆，进行各种破坏性操作，然后恢复密码并打扫现场（主要是清理sql server日志）。这种精确打击的陷害，是非常具有杀伤力的。相对于直接修改数据库，这种攻击的好处是可以进行“语义”的修改，即具有SBO意义的修改，譬如修改某个产品的库存。如果想要直接通过数据库修改达到目的，需要先逆向得到库存是如何保存在数据库中的，这样工作量太大。

记录完了再吐槽一下我自个儿，你因为这个妹子心情大起大落，时而忧郁时而狂喜，倒腾这个东西两天，真能赢她一顾么。你迷恋的流转的眼神，可曾有某个瞬间为你停留。岂不闻佛家有言，有求皆苦，无求乃乐。