解決SAP B1用戶名稱修改的問題

幫妹子解決一個SAP B1的問題，這個問題是：SAP B1里面有一個公司的數(shù)據(jù)，這個公司里面有一個用戶，如何修改這個用戶的名稱。。。我已經(jīng)可以猜到這個到底是要干啥了。

之前沒有接觸過SAP B1，所以找下載就耗了一點時間，ftp2.sjtu上面只有miniSAP 6.1，太老了，僅次于她們在用的SAP Business One 2005b（中文版7.0）。這個資源貌似網(wǎng)上很難找，最后總算在一個網(wǎng)盤（趣盤）上找到一個。后來我在找參考書籍的時候，意外發(fā)現(xiàn)某本書附帶的光盤中竟然有一個preloaded version（所謂的預覽版），不過功能受限。感謝圖書館的光盤鏡像檢索系統(tǒng)。

妹子給的是一個64.8MB的沒有后綴的備份文件，不知道這個是怎么備份和恢復的，又不好意思去問，只能自己琢磨。在SAP B1中找備份和恢復的功能，覺得不太像。然后嘗試用二進制編輯器打開，希望看出點端倪，又是無功而返。

折騰SAP B1的過程中倒是對這個東西有了點了解，這個東西后端存儲全靠數(shù)據(jù)庫，前端就是一個殼。安裝以后后端SQL Server 2000中多出來的SBO-COMMONS與SBODemo_China兩個數(shù)據(jù)庫，分別是SBO全局配置信息與“北京海城電子公司”的信息。

然后就可以很自然地猜到這個文件可能是數(shù)據(jù)庫的一個備份，數(shù)據(jù)庫備份要么備份為SQL文件，要么是私有的二進制格式。測試一下吧，把SBODemo_China備份為一個文件，備份完成的時候我已經(jīng)知道我猜對了，因為文件大小基本一致。二進制打開，文件頭的magic number是TAPE，與原文件一致，猜測基本正確。

然后隨便新建一個數(shù)據(jù)庫，恢復備份數(shù)據(jù)，表結(jié)構等與SBODemo_China一致，猜測得到驗證。

剩下的問題是如何建立某個公司與這個數(shù)據(jù)庫的聯(lián)系。直接的猜測是（公司，數(shù)據(jù)庫名）的關系應該是存儲在SBO-COMMONS數(shù)據(jù)庫中的，這個庫中的表不多，一個個看過去吧。很容易地找到了是存在dbo.SRGC表中。從這些表名的雜亂無章來看，很明顯是做過混淆處理的。

這里新建一個（或者修改現(xiàn)有的），就可以從SBO中登錄這個公司了，數(shù)據(jù)庫則是恢復的這個數(shù)據(jù)庫。

知道了這個對應關系在哪里管理，就可以各種操作了，比如可以把一個公司的數(shù)據(jù)倒騰到另一個公司內(nèi)，只要在兩個數(shù)據(jù)庫之間倒騰就行了。

倒騰數(shù)據(jù)的方法很多，SQL Server自帶的“企業(yè)管理器”就有數(shù)據(jù)的導入導出功能，或者可以把一個數(shù)據(jù)庫備份為一個文件（二進制或者sql）然后恢復到另一個數(shù)據(jù)庫中。

下一個問題是修改用戶名，可以猜測到的是，既然一個公司的所有信息都存儲在這個公司的數(shù)據(jù)庫中，用戶信息肯定也是存在某個地方的。繼續(xù)從SBODemo_China下手吧，展開數(shù)據(jù)庫以后我傻眼了，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)，第一個參數(shù)是db-name，第二個是info-level，更多dbcc功能請google。

然后，打開SBO，隨便用一個用戶登錄，登錄的過程SBO總歸要來數(shù)據(jù)庫保存用戶的表里面看看么，果然，log的最后幾條是access名為dbo.OUSR表的�？吹矫志椭勒业搅�。

這個表里的字段名倒是沒有做混淆，和之前一樣。從字段名和現(xiàn)有的用戶信息，很容易就能搞明白各個字段是什么意思。修改用戶名么，就直接在這里修改就好了，USER_CODE是登錄用戶名，U_NAME是顯示用戶名。

到此為止目的已經(jīng)達到了，不過看到旁邊的PASSWORD字段，咱還是按捺不住折騰一下的心思。PASSWORD字段之后，竟然還有PASSWORD1、PASSWORD2。。也許是歷史設計的遺跡吧。SBO內(nèi)修改密碼，這里的值就變掉了，到底是怎么一個對應關系，眼睛看是看不出來的，可能要對SBO的主程序做一下逆向，看看passphrase是如何變換得到這里的密鑰串的。這個過程是有標準的（可以參見之前的博文），如PKCS#5。但說實話本人對IT從業(yè)者的安全意識與安全能力并不抱太大希望。之前CSDN被暴庫，用戶密碼都是明文保存的；還有之前看到QQ某款產(chǎn)品在產(chǎn)品介紹中聲稱自己保存的密碼是經(jīng)過MD5“加密”的，一聲嘆息。

雖然不反向工程就不知道這個變換過程，而且即使是知道了可能也無法破解某用戶的密碼（例如變換過程某一步使用了cryptographic hash function, 如SHA-1），仍然可以注意到SBO保存的這個（變換過的）密碼是僅與用戶的passphrase相關的（廢話，當然是了），那么，substitution attack（某種意義上的replay attack），就可以替換掉某個用戶的密碼了。

實際應用中，SBO的這種設計不會引入太大的安全隱患（要修改sbo.OSUR，還不如直接修改想修改的其他庫），但仍然可能會在某些場合下會帶來問題。比如：某個公司的ERP系統(tǒng)使用的是SBO，但是數(shù)據(jù)庫沒有良好防范，攻擊者攻破db server以后，就可以修改某用戶的密碼，然后使用該用戶賬戶登陸，進行各種破壞性操作，然后恢復密碼并打掃現(xiàn)場（主要是清理sql server日志）。這種精確打擊的陷害，是非常具有殺傷力的。相對于直接修改數(shù)據(jù)庫，這種攻擊的好處是可以進行“語義”的修改，即具有SBO意義的修改，譬如修改某個產(chǎn)品的庫存。如果想要直接通過數(shù)據(jù)庫修改達到目的，需要先逆向得到庫存是如何保存在數(shù)據(jù)庫中的，這樣工作量太大。

記錄完了再吐槽一下我自個兒，你因為這個妹子心情大起大落，時而憂郁時而狂喜，倒騰這個東西兩天，真能贏她一顧么。你迷戀的流轉(zhuǎn)的眼神，可曾有某個瞬間為你停留。豈不聞佛家有言，有求皆苦，無求乃樂。