fiddler4設定**，抓包。發現請求存在簽名值，響應內容加密過。
直接用apktools逆向得到dex，使用jd-gui檢視**。
請求的簽名演算法不可讀，直接看smail檔案。引數存在對應暫存器中。從上下文找到對應引數順序。摸清請求的構成。
相應內容，繼續研究原始碼，發現呼叫so庫進行處理。初步打算將so檔案逆向後，使用別的語言改寫。使用ida研究後，因太過複雜，放棄。
繼續找資料，結合網友的思路，編寫乙個呼叫這個庫的安卓應用，並通過內建httpserver的方式對外提供服務。
因為沒有寫過安卓應用，不知為什麼能在模擬器中執行，但不能在真機中執行。之前懷疑為android高版本後的許可權申明，但先放棄。之後有機會再研究。
覆盤：1、遇到問題，先進行分析，不著急下手
2、當以結果為導向時，不要糾結在某問題。針對問題，設定合理的超時，當在指定時間內無法完成，更換思路。條條大路通羅馬。正是所謂的旁註
3ãâ 空餘時間多了解新技術及新思路。不要陷入自己的舒適區。
記一次好笑的逆向過程
為什麼說是好笑，看到最後就明白了。打xhr斷點並發起請求 檢視呼叫棧，發現了發起request的位置 向上檢視 發現了這個東西 知道ajax請求裡的signature引數和rs引數是從 來的。看一下這部分 可以知道構造url時的u，d，t來自 u，d，t三個引數裡，u和d很容易理解，主要是t引數如何...
記一次oracle 優化過程
可能很多大牛都知道這個方法，但我是頭回遇到，因為專案原因，要寫很多查詢sql，對速度有要求，所以很注重sql語句的優化。像使用left join 速度會快一些等等一些算是比較常見的方法吧。近兩天做自測時發現了乙個問題，同樣一條語句，加了乙個條件竟然速度慢了那麼多，本身是乙個求彙總的sql語句，查全部...
記一次SAP缺料過程
委外訂單乙個子件需求 100個 發料100個，委外庫存100個 刪除委外子件，不能消耗 委外 商家一直是100個。因為廠內和委外是乙個mrp範圍。因此沒有購買需求 導致 廠內缺料，商家也沒庫存 原因分析 為什麼刪除子件，是換料了 商家沒有退回，還是真的誤操刪了，需要了解實際情況 分析2 3月份發現這...