之前沒有接觸過SAP B1，所以找下載就耗了一點(diǎn)時(shí)間，ftp2.sjtu上面只有miniSAP 6.1，太老了，僅次于她們在用的SAP Business One 2005b（中文版7.0）。這個(gè)資源貌似網(wǎng)上很難找，最后總算在一個(gè)網(wǎng)盤（趣盤）上找到一個(gè)。后來我在找參考書籍的時(shí)候，意外發(fā)現(xiàn)某本書附帶的光盤中竟然有一個(gè)preloaded version（所謂的預(yù)覽版），不過功能受限。感謝圖書館的光盤鏡像檢索系統(tǒng)。
妹子給的是一個(gè)64.8MB的沒有后綴的備份文件，不知道這個(gè)是怎么備份和恢復(fù)的，又不好意思去問，只能自己琢磨。在SAP B1中找備份和恢復(fù)的功能，覺得不太像。然后嘗試用二進(jìn)制編輯器打開，希望看出點(diǎn)端倪，又是無功而返。
折騰SAP B1的過程中倒是對這個(gè)東西有了點(diǎn)了解，這個(gè)東西后端存儲(chǔ)全靠數(shù)據(jù)庫，前端就是一個(gè)殼。安裝以后后端SQL Server 2000中多出來的SBO-COMMONS與SBODemo_China兩個(gè)數(shù)據(jù)庫，分別是SBO全局配置信息與“北京海城電子公司”的信息。
然后就可以很自然地猜到這個(gè)文件可能是數(shù)據(jù)庫的一個(gè)備份，數(shù)據(jù)庫備份要么備份為SQL文件，要么是私有的二進(jìn)制格式。測試一下吧，把SBODemo_China備份為一個(gè)文件，備份完成的時(shí)候我已經(jīng)知道我猜對了，因?yàn)槲募笮』疽恢�。二進(jìn)制打開，文件頭的magic number是TAPE，與原文件一致，猜測基本正確。
然后隨便新建一個(gè)數(shù)據(jù)庫，恢復(fù)備份數(shù)據(jù)，表結(jié)構(gòu)等與SBODemo_China一致，猜測得到驗(yàn)證。
剩下的問題是如何建立某個(gè)公司與這個(gè)數(shù)據(jù)庫的聯(lián)系。直接的猜測是（公司，數(shù)據(jù)庫名）的關(guān)系應(yīng)該是存儲(chǔ)在SBO-COMMONS數(shù)據(jù)庫中的，這個(gè)庫中的表不多，一個(gè)個(gè)看過去吧。很容易地找到了是存在dbo.SRGC表中。從這些表名的雜亂無章來看，很明顯是做過混淆處理的。
這里新建一個(gè)（或者修改現(xiàn)有的），就可以從SBO中登錄這個(gè)公司了，數(shù)據(jù)庫則是恢復(fù)的這個(gè)數(shù)據(jù)庫。
知道了這個(gè)對應(yīng)關(guān)系在哪里管理，就可以各種操作了，比如可以把一個(gè)公司的數(shù)據(jù)倒騰到另一個(gè)公司內(nèi)，只要在兩個(gè)數(shù)據(jù)庫之間倒騰就行了。
倒騰數(shù)據(jù)的方法很多，SQL Server自帶的“企業(yè)管理器”就有數(shù)據(jù)的導(dǎo)入導(dǎo)出功能，或者可以把一個(gè)數(shù)據(jù)庫備份為一個(gè)文件（二進(jìn)制或者sql）然后恢復(fù)到另一個(gè)數(shù)據(jù)庫中。
下一個(gè)問題是修改用戶名，可以猜測到的是，既然一個(gè)公司的所有信息都存儲(chǔ)在這個(gè)公司的數(shù)據(jù)庫中，用戶信息肯定也是存在某個(gè)地方的。繼續(xù)從SBODemo_China下手吧，展開數(shù)據(jù)庫以后我傻眼了，960個(gè)表，表名同樣做過混淆處理，沒辦法像SBO-COMMONS那樣一個(gè)個(gè)檢查了。
后來想到的辦法是查看SBODemo_China的日志，活該倒閉的微軟（嗯，我這么說我前準(zhǔn)東家是不是不太厚道。。），ldf文件格式是封閉的。google了一個(gè)third party的工具，慘不忍睹。
然后嘗試一下新版的sql server是否可以提供類似功能，用的是SQL Server 2008 R2 Express，依然無功而返。順便記錄一下，Management Studio連接的時(shí)候，服務(wù)器要填入(local)\SQLEXPRESS，即需要同時(shí)指定host和sql instance。
再次google，找到SQL Server的一條undocumented的命令，dbcc。吐槽一下，undocumented意味著微軟不需要為這些命令提供支持服務(wù)，而且可以隨便折騰這些命令，包括隨時(shí)在下一個(gè)版本中移除。
語法是 dbcc log (SBODemo_China, 3)，第一個(gè)參數(shù)是db-name，第二個(gè)是info-level，更多dbcc功能請google。
然后，打開SBO，隨便用一個(gè)用戶登錄，登錄的過程SBO總歸要來數(shù)據(jù)庫保存用戶的表里面看看么，果然，log的最后幾條是access名為dbo.OUSR表的。看到名字就知道找到了。
這個(gè)表里的字段名倒是沒有做混淆，和之前一樣。從字段名和現(xiàn)有的用戶信息，很容易就能搞明白各個(gè)字段是什么意思。修改用戶名么，就直接在這里修改就好了，USER_CODE是登錄用戶名，U_NAME是顯示用戶名。
到此為止目的已經(jīng)達(dá)到了，不過看到旁邊的PASSWORD字段，咱還是按捺不住折騰一下的心思。PASSWORD字段之后，竟然還有PASSWORD1、PASSWORD2。。也許是歷史設(shè)計(jì)的遺跡吧。SBO內(nèi)修改密碼，這里的值就變掉了，到底是怎么一個(gè)對應(yīng)關(guān)系，眼睛看是看不出來的，可能要對SBO的主程序做一下逆向，看看passphrase是如何變換得到這里的密鑰串的。這個(gè)過程是有標(biāo)準(zhǔn)的（可以參見之前的博文），如PKCS#5。但說實(shí)話本人對IT從業(yè)者的安全意識(shí)與安全能力并不抱太大希望。之前CSDN被暴庫，用戶密碼都是明文保存的；還有之前看到QQ某款產(chǎn)品在產(chǎn)品介紹中聲稱自己保存的密碼是經(jīng)過MD5“加密”的，一聲嘆息。
雖然不反向工程就不知道這個(gè)變換過程，而且即使是知道了可能也無法破解某用戶的密碼（例如變換過程某一步使用了cryptographic hash function, 如SHA-1），仍然可以注意到SBO保存的這個(gè)（變換過的）密碼是僅與用戶的passphrase相關(guān)的（廢話，當(dāng)然是了），那么，substitution attack（某種意義上的replay attack），就可以替換掉某個(gè)用戶的密碼了。
實(shí)際應(yīng)用中，SBO的這種設(shè)計(jì)不會(huì)引入太大的安全隱患（要修改sbo.OSUR，還不如直接修改想修改的其他庫），但仍然可能會(huì)在某些場合下會(huì)帶來問題。比如：某個(gè)公司的ERP系統(tǒng)使用的是SBO，但是數(shù)據(jù)庫沒有良好防范，攻擊者攻破db server以后，就可以修改某用戶的密碼，然后使用該用戶賬戶登陸，進(jìn)行各種破壞性操作，然后恢復(fù)密碼并打掃現(xiàn)場（主要是清理sql server日志）。這種精確打擊的陷害，是非常具有殺傷力的。相對于直接修改數(shù)據(jù)庫，這種攻擊的好處是可以進(jìn)行“語義”的修改，即具有SBO意義的修改，譬如修改某個(gè)產(chǎn)品的庫存。如果想要直接通過數(shù)據(jù)庫修改達(dá)到目的，需要先逆向得到庫存是如何保存在數(shù)據(jù)庫中的，這樣工作量太大。
記錄完了再吐槽一下我自個(gè)兒，你因?yàn)檫@個(gè)妹子心情大起大落，時(shí)而憂郁時(shí)而狂喜，倒騰這個(gè)東西兩天，真能贏她一顧么。你迷戀的流轉(zhuǎn)的眼神，可曾有某個(gè)瞬間為你停留。豈不聞佛家有言，有求皆苦，無求乃樂。
下載 
下載 
下載 
下載 
下載 
下載 
喜歡 
頂
難過
囧
圍觀
無聊
