当前位置:
  1. 魔豆IT网
  2. 系统教程
  3. SAP
  4. 正文

解决SAP B1用户名称修改的问题

帮妹子解决一个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意义的修改,譬如修改某个产品的库存。如果想要直接通过数据库修改达到目的,需要先逆向得到库存是如何保存在数据库中的,这样工作量太大。

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

相关阅读

《解决SAP B1用户名称修改的问题》由网友“入他心”推荐。

转载请注明:http://www.modouwifi.com/jiaocheng/0520111LR021.html