SAP Business One 修改使用者名稱

幫妹子解決一個SAP B1的問題，這個問題是：SAP B1裡面有一個公司的資料，這個公司裡面有一個使用者，如何修改這個使用者的名稱。。。我已經可以猜到這個到底是要幹啥了。

之前沒有接觸過SAP B1，所以找下載就耗了一點時間，ftp2上面只有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全域配置資訊與“北京海城電子公司”的資訊。

然後就可以很自然地猜到這個檔案可能是資料庫的一個備份，Database Backup要麼備份為SQL檔案，要麼是私人的二進位格式。測試一下吧，把SBODemo_China備份為一個檔案，備份完成的時候我已經知道我猜對了，因為檔案大小基本一致。二進位開啟，檔案頭的magic number是TAPE，與原檔案一致，猜測基本正確。

然後隨便建立一個資料庫，恢複備份資料，表結構等與SBODemo_China一致，猜測得到驗證。

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

這裡建立一個（或者修改現有的），就可以從SBO中登入這個公司了，資料庫則是恢複的這個資料庫。

知道了這個對應關係在哪裡管理，就可以各種操作了，比如可以把一個公司的資料倒騰到另一個公司內，只要在兩個資料庫之間倒騰就行了。

倒騰資料的方法很多，SQL Server內建的“企業管理器”就有資料的匯入匯出功能，或者可以把一個Database Backup為一個檔案（二進位或者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.OUSR，還不如直接修改想修改的其他庫），但仍然可能會在某些場合下會帶來問題。比如：某個公司的ERP系統使用的是SBO，但是資料庫沒有良好防範，攻擊者攻破db server以後，就可以修改某使用者的密碼，然後使用該使用者賬戶登陸，進行各種破壞性操作，然後恢複密碼並打掃現場（主要是清理sql server日誌）。這種精確打擊的陷害，是非常具有殺傷力的。相對於直接修改資料庫，這種攻擊的好處是可以進行“語義”的修改，即具有SBO意義的修改，譬如修改某個產品的庫存。如果想要直接通過資料庫修改達到目的，需要先逆向得到庫存是如何儲存在資料庫中的，這樣工作量太大。

 

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