Regular expression，中文又翻作「正規表達式」或是「正規表示式」等等（以下簡稱 regexp），主要是用來做字串的配對，寫好一個模式之後，就可以拿來配對到符合規則的文字。
無論是電話號碼、Email 或是身分證字號等等，都可以運用 regexp 來完成初步的格式驗證，確保字串的格式與特定規則相符合。
Regexp 雖然方便，但沒寫好的話有可能導致一些輸入的驗證被繞過，演變成資安問題；而除了這個之外，還有另外一種也會造成問題，就是這篇要來講的 ReDoS，全名為：Regular expression Denial-of-Service，因為正規表達式所引起的阻斷服務攻擊。
前面幾篇我們講的都是靜態分析的東西，也就是說我們並沒有把 app 跑起來，只是透過反編譯出來的程式碼研究 app 運作的邏輯，並且修改程式碼後重新打包執行。
而動態分析指的就是我們會把 app 跑起來，並透過一些方式讓我們可以 hook 各種方法，去監視某些 method 的輸入以及輸出，甚至是竄改。
這篇就讓我們來學習該怎麼樣使用 Frida 進行動態分析。
我記得在我剛接觸 Android 沒多久的時候，要看 app 到底發了哪些 request 是很簡單的一件事情。只要在電腦上面裝個 Charles，接著設定手機上的 Wifi，讓它 proxy 到電腦上，然後輸入特定網址下載 Charles 提供的憑證，安裝完成以後就搞定了。
但前陣子用了一樣的流程，雖然有聽到一些封包，但從 app 出來的流量卻是空的，上網找了各式各樣的解法之後都行不通。
最後我才知道，原來是 Android 在 6.0 以上改變了安全性的設定，預設就不相信使用者自行安裝的憑證，所以才會攔截不到。有種做法是裝個 local VPN，這樣流量就會全部都過 proxy，但我試過以後發現還是有點麻煩。
在眾多方法之中，我試過最有用的方法，就是把 apk 拆開，改一些設定之後再裝回去，這篇就來記錄一下流程跟心得。
在第一篇當中我們學到了基礎中的基礎，靠著 Apktool 把 apk 拆開，修改資源以後組裝回去，並且把對齊且簽署過的 apk 裝回手機上面。
而接下來的這一篇，我們要來看看如何修改程式碼。
我們的目的是在一台有 root 的手機上繞過檢查，讓 app 顯示沒有 root。如果你是用沒有 root 的手機來測試的話，你可以反過來，將 app 改成會偵測出你有 root。
五年前我有寫過一篇：[Android] 人人都會的 apk 反編譯，那時我還是個寫 Android 的工程師，因為工作上的需求跟同事一起研究了基本的 Android 逆向工程，想達成的目標是全自動的流程，上傳一個 apk 以後自動把 apk 拆開來，塞一些奇怪的東西再裝回去。
而現在同樣是因為工作上的需求，再次回憶並補強了一下對於 apk 反編譯以及修改等等的相關知識，寫成這一系列的文章跟大家分享。
先說在前面，這一系列都只是「入門」而已，利用各種工具把 apk 拆開來再裝回去，對於沒有加殼的 app 應該夠用了，但如果有加殼過的話，需要再更深一點的 binary 相關知識才能夠解開，那又是另一個世界了。
總之呢，這個系列適合沒有接觸過 Android App 逆向，想要玩玩看的人，也適合 Android 工程師，可以把自己寫的 app 拆開來，看看是什麼樣子，我覺得也滿有用的。
近期我以零日文基礎的身份開始唸書並通過了日本的基本情報技術者以及情報セキュリティマネジメント試験，這篇會分享我是怎麼準備的，又運用了哪些考試技巧。
文章大綱如下：
今年 Water Paddler 拿了第二名，總共 9 題 web 解掉了 8 題（我貢獻了 2 題），整體 web 的難度我覺得去年似乎比較難，今年比的人似乎也比較少一點。
話說最近我發現自己的 writeup 筆記沒有以前這麼多了，其中一個原因是最近比較忙，另一個原因是最近有興趣的題目（client side）沒這麼多，或我也有在想搞不好是隊友越變越強，還沒開題就被隊友解掉，我也懶得再去看題目，於是就懶得寫筆記了XD
這次只記幾題有參與或有興趣的，其他就先省略了。
雖然過了快兩個月，但還是來補一下筆記。去年被電得很慘，原本想說過一年了，今年應該會比較好吧，沒想到還是被電爛。
關鍵字：
開頭先貼一下官方的 repo，裡面有程式碼跟解答：https://github.com/dicegang/dicectf-2023-challenges
最近有人在臉書前端交流社群發了一則貼文，內容是他看到了一個問題：請問登入api傳賬號、密碼json明碼會有問題嗎?，想知道大家對這個問題的看法。
而底下的回答大部份都是覺得「有用 HTTPS 就好了，沒必要額外再實作一層加密，沒有什麼太大的意義」
老實說我以前也是這樣認為的，而且過去在社群中就有出現過類似的討論。我那時候想說都已經有 HTTPS 了，而 HTTPS 本身的目的就是為了保障傳輸的安全，為什麼要自己再做加密？
但這一兩年接觸資安以後，我的想法有了改變，我認為前端在傳輸前把密碼加密，是有其意義的，而接下來我會詳細說明我的理由。
今年認真跟著 Water Paddler 打了一整年的 CTF，看到有人整理出了一篇 CTF: Best Web Challenges 2022，發現裡面的題目大多數我都有打過，就想說那不如我來寫一篇整理吧，整理一下我自己打過覺得有學到新東西的題目。
因為個人興趣，所以會特別記下來的題目都跟前端與 JS 相關，像是其他有關於後端（PHP、Java 等等）的我就沒記了。
另外，這題有紀錄到的技巧或解法不代表第一次出現在 CTF 上，只是我第一次看到或是覺得值得紀錄，就會寫下來。
我把題目分成幾個類別：