如何讓自己的 Linux 命令列( CLI )功力更上一層樓？讓自己更有效率地工作？這個網站提供了一系列的問題練習，從簡單到困難，還可以在這個網站上直接練習，網站也有提供解答

S1E38 矽谷資深軟體工程師後疫情時代面試心得 Facebook/Robinhood/Coinbase/DoorDash

2020 年是個動蕩不安的一年，因為疫情的關係，很多公司都在年中進行了規模不小的裁員，包含大家耳熟能詳的 Airbnb、Uber、Lyft、Yelp、LinkedIn、Mozilla、Intuit、Salesforce 以及 WeWork 等等族繁不及備載。根據 layoffs.fyi 的統計，這波裁員潮集中在今年的 3 月到 7 月，8 月以後逐漸趨緩。

這對於在這段期間要找工作的絕對不是件好事，因為很多人被裁員，意味著同樣的職缺會有更多競爭者，也因為景氣不好以及疫情不確定性的關係，很多公司開始減緩招人的腳步。不過 7、8 月以後情況逐漸好轉，隨著美國各大城市解除封城，人們意識到必須跟疫情共存好一陣子，於是實體經濟活動恢復了，美國人畢竟是擁有自由的靈魂不能隨便被囚禁的呀！最近是美國各公司的財報季，各大科技公司紛紛發布第 3 季的財報，表現都非常好，也應證了在疫情下經濟轉好的事實。

我在 8 月下旬的時候開始投遞履歷，9 月初開始電話面試，10 月中結束 Onsite 面試 (都是線上進行)，面試了四間公司：Facebook、Robinhood、Coinbase 以及 DoorDash，最後拿了前三間公司的 Offer，級別都是資深工程師。在這篇文章我會分享各公司的面試流程以及體驗、我做了什麼準備、怎麼談薪水以及我最後的決定，希望可以對在美國求職的人有幫助！由於有簽保密協定的關係，我只會提到面試的流程，不會提到具體的題目以及 Offer 數字。

Medium 文章好讀版 https://bit.ly/2Ii9vLc
Apple Podcasts https://apple.co/36fLCMh
Spotify https://spoti.fi/2IcyJdv

#面試的動機
蛤！？面試不就是為了換工作嗎？對大部分的人或許是如此，但對我而言這次並沒有非換工作不可的理由。我在 Square 待了三年多，整體的滿意度一直都很好，公司的股票從我加入以後基本上都是一個上漲的趨勢，最近也來到歷史新高。一年多前從 Android 開發換到後端的 Traffic Infrastructure 組以後，更是一直處在學習的狀態，了解怎麼規模化公司的後端架構，支援更多的應用場景，工作上也需要一直動腦，思考各種方法的優缺點、我們為什麼要這樣做並且撰寫許多技術文件，負責的專案也很有影響力，最近的成果是把公司很重要的 reverse proxy 升級成 Envoy，讓系統的效能更好並且支援更多新的功能。或許因為疫情一直在家工作的關係讓我有點工作倦怠，但這個倦怠並不是源自於工作的不開心，而是真的在家太久了，很需要好好放個長假讓腦袋放空充電一下。

言歸正傳，這次面試的主要目的是測試自己的市場價值，看看自己能否適應資深工程師面試的強度，畢竟上次面試已經是四年前了 (當時的面試心得)，很多當時對於面試的理解也需要進行修正，我的心態是保持開放的態度，如果遇到很好的機會，當然可以考慮換工作，沒有的話待在現在的公司也很好！另外我自己過去的主要經驗都是 Android 行動開發，在後端只有一年多的經驗，也很好奇這些公司會不會讓我面資深後端的缺，還是會將我過去經驗打折？事實證明是我多慮了，我面的這幾間公司都有把我在 Android 的年資完整算進去，最後也給了我資深軟體工程師的 Offer，Facebook 甚至幫我安排 E6 (Staff Level) 的面試，只是因為系統設計表現得不夠好，最後給我的是 E5 (Senior Level) 的 Offer。

我還蠻建議大家即便沒有特別想換工作，也可以定期去外面面試看看，在沒有非換不可的情況下，習慣面試的緊張感跟壓力，這樣會讓你以後的面試更自在，跟面試官可以像是在平常工作時一樣互動，發揮自己的實力。一開始會有這個觀念是在幾年前讀 hello, startup 這本書時看到，作者建議大家每一年定期去外面面試，審視自己的能力，進而補足自己不夠好的地方，當然我覺得每一年對一般人來說可能有點難，畢竟邊工作邊準備面試不是易事，而且還得跟公司請假去面試，但至少每兩三年可以去外面看看，避免自己的能力跟求職市場脫勾太久。在矽谷以專門招收資深工程師聞名的 Neflix 甚至在他們的文化守則裡提到：「員工的薪水取決於他們個人最高的市場價值，我們鼓勵員工去外面面試並且跟他們的主管討論，我們認為這是健康的行為。」

#資深工程師的優勢
在一般情況下，5 年以上工作經驗可以面資深工程師 (L5) 的職位，10 年以上工作經驗可以面 Staff level (L6) 以上的職位，我有約 6.5 年的工作經驗 (3 年台灣 + 3.5 年美國)，所有公司都是讓我面資深工程師以上的職缺。

這次找工作我感受最深刻的事情就是：我再也不用海投一大堆公司了！四年前當我還是求職市場裡的菜雞的時候，投了超過 150 間公司，只有 1x 間公司回應我，轉換率不到 10%。這次 Facebook 跟 Robinhood 都是 recruiter 主動從 LinkedIn 聯繫我進行面試邀請，Facebook 的 recruiter 更是從 2019 年初就開始定期聯絡我，到後面我真的不好意思持續拒絕她，於是接受了面試的邀請，真的還蠻感謝她不斷地嘗試，讓我定期思考一下要不要面試。Coinbase 跟 DoorDash 我都是從官網直接投履歷，沒有透過內推，一個禮拜內就收到了 recruiter 的來信，而這也是我唯二主動申請的公司，真的從以前我找工作，到現在變成是工作機會找上我了。

另一個很大的改變是：刷題不再是最重要的一環。隨著你越來越資深，系統設計跟行為面試所佔的比例也會越來越高，而且除了年資以外，這兩種面試的表現基本上就決定了你的職等，Facebook 的 recruiter 也在電話中跟我說，針對比較資深的應徵者，Coding 的要求會比較寬容 (lenient)，所以建議大家不要對刷題過度著迷，一昧的追求題數不是好事，而是應該重質不重量，題目是無限但觀念是有限的。

最後一個體悟是在拿到 Offer 之後，談判的空間變得很大。美國科技業的求職市場一直是呈現一個兩極化的狀態，對於剛畢業的人來說，競爭者多而且職缺少，公司有較高的話語權。但是當你是資深工程師以上的時候，情況就反過來了，大多數公司不管景氣如何，任何時候都在招有經驗的工程師，職缺一直開在那但總是招不滿。上次找工作的時候，能夠讓公司提高年薪 1 ~ 2 萬美金就歡天喜地了，但是這次有兩家公司給我的初始 Offer 跟最終 Offer 都差了好幾萬美金。

#準備過程
軟體工程師的面試主要分成三種：Coding、系統設計以及行為面試。我自己是花比較多時間在系統設計上面，再來是 Coding，最後是行為面試。

關於系統設計的準備，我在軟體工程師系統設計面試準備指南有比較完整的介紹，這邊補充說明一下，準備系統設計最好的方法是來自於工作，最好你工作上就是要去思考怎麼設計系統，各種方法的優缺點以及思考各種 edge case 以及解法，這樣子學到的深度跟廣度都遠多於看那些準備素材。如果工作上沒有碰到也沒關係，可以先從 system design primer 看起，理解系統設計的各種面向。另外我推薦看一些公司的 Tech talk 來了解他們實際上怎麼設計系統，為什麼要這樣做以及不同方法的 Trade-off 又是什麼，理解為什麼要做這個決定是最重要的。如果已經接近面試了，建議可以看 InterviewBit 的系統設計篇，總共有八題，我認為寫的還蠻好的，比 Grokking the System Design Interview 還深入，看個兩次完整理解以後對面試很有幫助。

Coding 的部分我還是要再強調一次，不要過度迷信刷題的數量，應該要重質不重量，重點放在在訓練你的解題思維以及邏輯思考，練習使用常見的資料結構並且把想法轉成可以執行的程式碼。剛開始寫題目的朋友，我會建議相同的題型一起刷，培養對同類型題目的敏銳度，題目難度主要以 Medium 為主，搭配少量的 Hard 題。

很多題目一開始寫不出來，或是寫不出最佳解是很正常的，如果一題你卡超過一個小時，建議可以參考討論區的最佳解，但是切忌直接照抄別人的解答，因為那可能不是最適合你的方式，比較推薦的方式是你去理解背後的演算法，清楚地知道每一個步驟，再用你自己方式寫出來，這樣即使換了一個程式語言，你應該也可以寫得出來。當你開始發現沒看過的題目你也可以自己想出最佳解，並且實作出來，程式碼也很精簡，那代表你已經成功培養出解題的思維了。

我自己還會做一件事，就是想辦法分辨好的題目跟壞的題目，有一些題目的答案很明顯就只適用於這一題，用一些很特殊且不好理解的方法、實際上工作也不可能用到，這類型的題目我就不會花太多心思在上面，如果真的被考到，我會認為這是面試官的不用心。相反地，有一些好的題目：在觀念上很實用、有好幾種解法、工作上有機會用到或是系列題，這種就很值得練習，比方說 Graph 或是 Design 題就是我很喜歡的類型。

雖然說題數不重要，還是提供我的數據給大家參考，我在寫了 50 題的時候開始安排電話面試，最後一個 Onsite 結束時寫了約 120 題，我是以比較新的題目以及高頻題為主。

最後是行為面試，要再細分的話可以分成兩種，一種是 Project Deep Dive，你選一個你最近做過的專案，解釋一下專案內容、解決了什麼樣的問題、你的角色是什麼、最後的成果以及中間遇到的困難，另一種面試是來判斷你是否符合公司的文化以及價值，衡量你過去解決衝突跟溝通的能力。不管是哪一種面試，只要你好好回顧你過去做過的事情，能夠完整講述前因後果，把自己的故事清楚地講給面試官聽，輔佐一些例子，基本上就不會有太大的問題。

#遠距面試 #VirtualOnsite
因為疫情的關係，大家都在家工作，所以所有的面試包含電話面試都改成線上視訊進行，這個情況至少要到 2021 年的夏天。遠端面試的好處就是你不需要舟車勞頓，時間安排上也比較彈性，但是壞處是跟面試官的溝通比較沒那麼順暢，線上的交流絕對是沒有實體見面來得好，而且有的面試官網路很差，我甚至有遇到差到面試官需要把影像關掉的情況。

另一個要注意的點是，系統設計的面試會需要用到線上白板來畫圖，我自己覺得沒有實體的白板順暢，主要有兩種方法，你可以使用 iPad 搭配 Apple pen，或是用鍵盤滑鼠直接拉，選一個自己習慣的方式，面試前稍微熟悉一下白板軟體的使用，面試也會比較順利。

#DoorDash
第一輪是一個小時的電話面試，前 20 分鐘聊過去的工作經驗以及這個組在做的事，後 40 分鐘 Coding。題目是一道經典的 Hard 題，我對於該題印象很模糊，於是在面試中慢慢想，最後是有跌跌撞撞的寫出來，當時自我感覺良好，面試官給我的感覺也蠻算滿意的，但是隔天還是收到了拒信。事後回想應該是因為這是經典題，所以標準相對高，我並不是一次就寫對，而是慢慢修正，所以相對於其他應徵者表現不算太突出。

#Robinhood
他們家固定有兩輪各一個小時的電話面試，第一輪前 15 分鐘給你一段程式碼，要找到潛在的 bug 並且問你要怎麼修正，後面 45 分鐘 coding，題目比較偏向 Robinhood 工作上會遇到的演算法題。第二輪是系統設計，這是我第一個系統設計面試，微緊張，原本以為表現不夠好，但從 recruiter 那得到的反饋是還蠻好的。

Onsite 出乎我意料只有三輪，一輪 45 分鐘 coding，一輪一小時的系統設計，以及 45 分鐘的 Project Deep Dive，Coding 也比較偏向實作工作上會遇到的問題，面試官提到不用特別在意效能，以實作出來並且跑過測資為主，最後 10 個測資我只過了 9 個，不算完美。接下來兩輪跟面試官都聊得蠻開心的，並且有蠻不錯的討論，最後順利拿到 Offer！面 Project Deep Dive 有個小插曲，面試官到一半網路突然掛了，他後半段只能打電話加入簡直尷尬。

#Coinbase
Coinbase 的面試體驗是所有公司裡最讚的！從面試的流程跟題目都可以感受到他們的用心，面試官的平均素質也很好，你可以感受到他們是真心想要認識你這個人，面試過程中對於很多問題都有深入地討論，對於我問的問題他們往往也能給出很好很真誠的答案。

不過他們的面試過程也是最累的，電面是一小時的 Coding，Onsite 總共有五輪，其中居然有兩輪各 90 分鐘的 Coding！你可以在自己的電腦使用平常的開發環境，並且分享螢幕，題目不是傳統的演算法題，而是要你實作一個小型專案，其中一輪是實作一個小遊戲，另一輪則是實作一個系統，最後要 call Coinbase 的 API，所以對於送出網路請求並且處理 JSON 要有一定的熟悉度才行。整體的面試過程還蠻好玩的，面試官也會幫你，但一輪 90 分鐘真的有點太久。另外有一輪一小時的系統設計，以及各 30 分鐘的行為面試跟 Hiring Manager 面試。總共五輪五小時，中間休息一小時，面完真的氣力放盡了。我對整體的表現還算滿意，沒有一輪有感覺明顯不好，最後順利拿到了 Offer。

#Facebook
雖然 Facebook 都是進去以後再經過 Bootcamp 新生訓練選組，但是應徵的時候就要分不同的 Track，主要的分類有 Product、Infrastructure、Android、iOS 以及 Machine learning，Coding 的部分應該都差不多，而系統設計會根據你選的 Track 而有所不同。recruiter 一直建議我選 Android ，畢竟我的履歷上 Android 還是佔了一大部分，她提到 Facebook 現階段非常缺 Android 的人，不過她也補充說明這不代表面試的標準會比較低就是了。我最後還是堅持選擇面 Infrastructure，這樣對我來說準備起來比較方便，不用再額外花心思準備 Android。

我的 recruiter 覺得我可能也適合面另一個職缺 Production Engineer，於是就介紹了另一個 recruiter 給我，我可以選擇同時面兩個缺，最後如果拿到兩個 Offer 可以到時候再決定。實際聊過以後我還是婉拒了，因為不想花時間準備 Linux System 面試。
我們也聊到了預期的級別，她說以我的經驗我可以選擇面 E5 或 E6，這讓我感到蠻意外的啦，平心而論我認為不管是年資和能力我都還沒有到 Staff Engineer 的水準，不過既然 E6 只比 E5 多一輪系統設計面試，我就大膽地挑戰 E6 了！

Facebook 除了系統設計是一小時以外，其餘的面試都是 45 分鐘，電話面試是一輪 coding，Onsite 總共有五輪，兩輪 coding、兩輪系統設計以及一輪的行為面試。最後 Facebook 給了我 E5 的 Offer，原因是兩輪系統設計一輪還不錯另外一輪普普，沒有達到 E6 的標準。

雖然我最後有拿到 Offer，但我還是必須說 Facebook 的面試體驗蠻差的，面試官給我的感覺是他們不在乎我這個人，只想趕快在有限的時間內盡可能地蒐集一些訊號來判斷我有沒有通過，我並不反對有效率地蒐集一些訊號，但是面試是雙向的，作為應徵者的我們同樣也在面試這間公司，面試時我也在看未來我會不會想要跟這個面試官一起工作？而 Facebook 在我的標準裡顯然是不及格的。當然也有可能是我運氣不好，剛好遇到這樣子的面試官，但這也代表 Facebook 對於面試官的訓練不夠嚴謹，導致素質參差不齊，又或者是面試體驗並不在 Facebook 優先考慮的事情，不管是什麼原因，這都是一個警訊。

這個現象在 Coding 面試尤其明顯，面試官就是在看你能不能在有限的時間快速寫出最佳解。不過我倒是沒想到在行為面試也會遇到一樣的問題，我的面試官就按著他預先準備好的問題一個一個問，大部分的時間他的眼睛都盯著螢幕在做筆記，我實在是不確定他有沒有在聽我說話，有時甚至還會問我剛剛已經回答過的內容。

除此之外，Facebook 要求在 45 分鐘內解出兩道程式題，通常都是 LeetCode 原題並且要求最佳解，即使這種面試或許對我是有利的 (其中一輪我只花了 30 分鐘就寫出兩題的最佳解，然後我們閒聊了 15 分鐘)，但我認為這種填鴨式的面試方式完全不能反應一個人的工作表現，這或許可以招到一定聰明程度以上的人，但是他們不一定是個好的工程師或是很好合作的人。我認為維持這種大考式的 Coding 面試也是一種偷懶的表現，但這個面試形式卻會深深地影響招進去的人的類型，是我的話我會盡量避免跟這類型的人合作，因為我認為思考過程跟溝通比你能不能快速寫出最佳解還要重要。

如果這段文字有冒犯到在 Facebook 工作的朋友的話，我在這邊先說聲抱歉，但這確實是我面試完以後真實的感受。

#談薪水
近年來由於 levels.fyi 的關係薪水變得越來越透明，這對求職者來說是個好事，你可以知道某公司的某個級別合理的薪資範圍在哪裡。如果你對談薪水這個主題有興趣的話，可以參考這兩篇經典文章：
1. Ten Rules for Negotiating a Job Offer https://haseebq.com/my-ten-rules-for-negotiating-a-job-offer/
2. How Not to Bomb Your Offer Negotiation https://haseebq.com/how-not-to-bomb-your-offer-negotiation/

我自己談薪水的策略沒有那兩篇文章寫得那麼複雜，我認為最重要的原則是誠實，不要假裝你拿到其他公司的 Offer，也不要虛報你其他 Offer 的數字 (即便這個數字是合理的)，你可以選擇性揭露你的資訊，對方問到你不想揭露的資訊時，你可以禮貌地說你不方便透露，但絕對不要說謊。

公司在給你 Offer 的時候會考慮到很多因素：年資、面試表現、現在的薪水以及職等、其他公司 Offer 以及其他的面試者等等。這其中大部分資訊我們是不會知道的，比如說每個因素佔的比重、總共有多少面試者、我們在所有面試者裡面的表現如何，而且年資跟面試表現基本上已經確定了，所以實際上你能夠用的資訊就是其他公司的 Offer 或是你現在的薪水以及職等 (當然是要比較高才有用)。

當然最有用的談判手段，就是你拒絕掉這個 Offer 也沒關係。公司招人需要成本，從一開始收履歷、電話面試到 Onsite 面試，他們已經在你身上花了這麼多時間，也給你 Offer 了，所以在這個階段公司也很希望你能加入，除非這是你夢想中的公司，你很怕談薪水所帶來的風險，不然一般來說求職者在這個階段是有比較大的話語權。

另一個建議是請把 recruiter 當成你的夥伴，通常他們是要看業績給獎金的，所以她是跟你站在同一陣線，要幫助你跟公司談出更好的薪水說服你加入。Facebook 的 recruiter 這方面做得很好，她很多資訊都很透明地分享給我，包含這個級別可以拿到最好的 Offer 以及我的面試表現，一開始給我初始 Offer 的時候還告訴我這只是標準包裹，她不預期我會接，整個很 Real！後來給我的 Offer 也比原來的高出了不少，並且我如果下定決心要加入 Facebook 的話，她可以幫我要到這個級別的頂包。

Robinhood 也對我蠻有誠意的，在過程中不斷溝通，安排我跟主管以及同事聊天，有必要的話還可以讓我跟上面的 VP 聊聊，解答我對於 Robinhood 所有的疑惑。後來在得知我有 Facebook 跟 Coinbase 的 Offer 以後，給了一個很有誠意而且超過 Facebook 的 Offer，真的是受寵若驚。Coinbase 給的 Offer 相對前兩家低了不少，而且往上談的空間不高，他們給的理由是他們現在使用的估值是兩年前募資的數字，所以實際上的股票價值遠高於那個數字，而且他們 Refresh 也會給的比較大方，讓你在四年以後薪水不會降。

#最後的決定
我在選擇公司時，通常會考慮三個點，第一個是這個職位本身，我在什麼組、負責的產品、使用的技術、發展的機會以及同事跟主管的做事風格等等，盡可能知道每天工作的樣貌，判斷自己未來的開心程度。第二個是關於公司，我會問自己兩個問題：
1. 公司的文化跟價值我是否認同？人生很短，千萬不要浪費時間在幫跟自己核心價值不合的公司賣命。
2. 我是否相信公司所描述的願景，公司在未來的 5 ~ 10 年內能持續成長並且有好的發展嗎？

第三個是薪資結構，包含了底薪、股票、簽約金、獎金以及 Refresh 等等，來預期未來幾年的薪資。

除了以上三點以外，還得考量到現在都是遠距上工，跟同事以及主管建立感情也相對比較困難，所以在新公司的適應難易度也得列入考慮。在綜合考量之下，我這次還是選擇先留在 Square，或許明年再看看有沒有更好的機會！

如果這篇文章有幫助到你，歡迎按讚拍手，有任何問題也可以在底下留言，或是私訊給我們也行！

https://www.facebook.com/photo.php?fbid=10216019118603397
分享資安前輩 Kuon大大文

剛好上禮拜收到了一座 WD DUO 3TB*2 Raid 1
用戶說沒有設定密碼
就算沒有設定用戶密碼 一樣有eDEK密鑰
預設就是全扇區AES硬體加密
拿起昂貴資料救援設備來分析.
PC3000 跟MRT,從韌體Module 25,38讀出來
WTF?Keyblock (eDEK不正確)解密錯誤...
好 OSSLab Geek Lab還算看得懂論文跟原始碼
eDEK除了韌體外,在硬碟Lba也有備份
https://github.com/andlabs/reallymine/issues/45…
不同晶片的 Keyblock LBA位置
3 TB 5860528160
3 TB 5860529539
3 TB 5860533120
都翻過了 都是00 都沒有eDEK...
學前文Kuon大大查簽名
57 44 76 31
53 59 4D 57
53 49 6E 45
57 44 01 14 都失敗.
https://github.com/andlabs/reallymine/issues/15…

這案子搞到頭有點痛..看起來是都沒有人對WD DUO JMS561做過完整加解密分析.如果如同前文只是主控版損壞那就簡單..晚點再從與Usb to Bridge EEPROM內找看看eDEK

看不懂前文請先看這篇
https://www.osslab.com.tw/wd-usb-aes-recovery/
資料救援真的不一定會100%成功,只是我們會盡力研究與處理.

#OSSLab

咚！

#資料救援

這兩天剛好有朋友資料掉了，也是 WD 外接硬碟系列，來分享我今年的處理過程。

這篇會是個長篇，各位看倌要有心理準備 XD

也因為早就預期是個長篇，所以想了很久卻一直沒有開動。

====

[為什麼需要救援]

7 月份辦公室事故，樓下的高溫粒子沿著 1) 管道間 或 2)玻璃帷幕與牆壁中間的夾縫 亂竄，管道間旁，除了窗戶冷氣外，還堆了一堆易燃雜物 (紙 & 塑膠包材)，這些雜物熔點一到自燃，所以我在路邊吃冰淇淋的時候，可以看到火苗從窗戶冒出。

吃冰淇淋的同時，我念茲在茲的只有硬碟(裡面的資料)，因為備份用的幾十 TB 硬碟平常是離線儲存，擺在鐵櫃裡，而鐵櫃離火源非常接近....

幸好火源在窗戶旁邊，所以很快被發現並被撲滅。

到我可以進入現場，第一件事情就是開鐵櫃，手摸到鐵櫃的第一感覺，更，鐵櫃是溫熱的 :(

最重要的那顆 16TB 硬碟，是鐵櫃內最靠近火源的角落，連外包裝的紙盒都是燙的...，而且紙盒的底部，黏在鐵櫃上，我用力拔出來...

熔化了 :( 心都涼了！(拍一下驚堂木)

由於 1) 當時已經晚上 6 點左右，雖是夏日但天色已晚，室內當然因為事故無光源 2) 事故中間，開放進入現場不到 5 分鐘又撤離，二次燃燒

所以，為了避免可能的三次燃燒(?)，當下我就把 16TB 隨手一扔，連放進可以上鎖的鐵櫃都沒有，先搶救其他設備，逃離現場。

因為我以為沒救了。物理毀損ㄟ...

====

[取出硬碟]

事後回想，把那顆硬碟隨便一丟，是個 #潛在的錯誤，因為如果後來建築物又發生什麼狀況，那硬碟可能就真的找不回來了。

我使用的外接硬碟，是 WD My Book Duo 16TB，USB 3.0，外觀可以參考 [1]，是亮銀色的外觀。

事故第一晚，我想來想去，都覺得我太心急了，雖然那個外接盒，看起來快要 1/6 的比例熔掉，像是面積用 3x2 六等份排列時缺了一個角，是真的熔了一些東西。

硬碟外接盒，外包裝是紙盒，紙盒內還有一組保麗龍用來固定硬碟外接盒，紙盒在鐵櫃內，鐵櫃還在，紙盒和鐵櫃接觸面僅有焦掉，代表熔點低於這兩者，Google 查了一下保麗龍和塑膠熔點，研判是保麗龍和塑膠被(鐵櫃傳導熱度)熔掉，溫度僅需要 50C~60C，也查了硬碟工作時溫度，大概還撐得住 70C 高溫。

覺得應該慎重點，隔天就去把那顆熔掉的外接盒帶出來研究。

這個外接盒是自帶 2 顆硬碟的，買來插電就可以使用，所以原本也不知道裡面長什麼樣。

前面所提到的，亮銀色部分，研判是熱塑型塑膠，遇熱整個都軟化變形了，變形完一冷，就又固定住了，也就變得很難拆。

我在拆解的時候，很怕塑膠去黏到硬碟的軟板或是堵住氣孔，那就麻煩了，幸好沒有。原來，塑膠裡面是一個(有各種小孔呈網狀的)鐵盒子，硬碟和控制電路板，都在鐵盒子裡面，變形過的塑膠只有黏在鐵盒子外圍。

鐵盒子打開後，硬碟除了有碳粒附著和焦味外，外觀看起來都沒有受損。硬碟拆下來，我就把鐵盒子和塑膠丟掉了。

====

[資料救援前置作業]

事後回想，那個鐵盒子上面還有控制電路版，我在沒有確認電路板(或上面的 ROM)是壞掉的狀況下，就把它丟掉(因為塑膠碎片整個卡在上面，不想聞那個味道)，是個 #潛在的嚴重錯誤。萬一外接盒的 1)控制晶片 2) I/O 演算法 3) 金鑰產生方式，依賴硬體，那我就真的救不回來了！！

獲得硬碟之後，因為外接盒(殘骸和那個鐵盒子)被我丟了，所以要再買一組新的。

當我上去 PCHome 看時 (原本的也是 PCHome 買的)，我找到的是 [2]，同樣都是 WD My Book Duo 16TB，[1] 和 [2] 的區別在一個是 USB 3.0，新的是 USB 3.1。

舊款 USB 3.0 的在別的購物平台有賣，牌價要 2 萬多，新款 3.1 的只要 1 萬 6。

#第一個抉擇來了，要買新款還是舊款？新款便宜個好幾千元，I/O 傳輸速度還比較快 ...

後來我決定打電話，問 WD 的代理商聯強，我還記得是在高鐵接駁車回台南市區的路上。舊款各種容量它們庫存都還有貨，但 16TB 的只剩一台。

#第二個抉擇來了，如果控制晶片都一樣，要買最小容量 6TB 就好，還是要跟原本一樣，買到 16TB？這關乎到 $$$$$$ 啊 ...

我後來決定買舊款，因為我怕新款的控制晶片不同顆，而且買了一樣容量 16 TB，因為在跟聯強工程師通話過程中，得知一個資訊，我覺得我得 Sector-by-Sector 複製了 ....

聯強：「WD 這個系列有 AES 加密」
我 ：「我知道，但我沒有開啟，我也沒設過密碼」
聯強：「#就算你沒有設密碼_它還是有一組預設金鑰_而且是硬體加密」
我 ：「...」(我瞬間知道這代表的意義，以及對救援難度的增加！！)

SATA-to-USB 轉接線，由於我手上原本的線材也在辦公室，當然得重買新的，跑去北門路買了 2 條。

====

[第一次救援]

在真的討論救援前，讓大家瞭解一下目前的資料架構。

軟體 -- USB -- 硬體

軟體： Data -- Linux EXT4 -- Linux LUKS -- USB
硬體： USB -- Firmware -- HDD

其中，LUKS 作了一次加密，Firmware 層又作了一次加密。也就是將硬碟拔出外接盒的時候，是 2 層加密，LUKS 的密碼是我設的，外接盒 Firmware 設的密碼，#我不知道！！

舊的外接盒中的硬碟，稱為舊硬碟，新的類推。

由於不知道新的控制晶片，會不會偷偷寫入 metadata 到舊硬碟，我不敢貿然的將舊硬碟插入新的外接盒，所以，我直接用 2 條 USB-to-SATA 傳輸線，採用 Linux dd 整顆對拷。

對了，我在拆舊硬碟的時候，有特別注意硬碟的順序。

每一次 copy 前，我都會檢查 3 次命令列參數和磁碟資訊，看看 if 和 of 有沒有設反 (設反就會把舊硬碟資料覆蓋過去....）

#三十小時過去，16 TB 總算拷完

拷完將新硬碟插回新的外接盒 (儘量不使用舊硬碟)，這樣就搞定收工了。

.
.
.
.
.
.
.
.
.
.
.
.
.

(USB 接上電腦) ＷＴＦ！！！Linux 認不到 LUKS Header，這樣代表在 Firmware 那層的解密就有問題了！我可是 Sector-by-Sector 對拷，怎麼會這樣？

#啟動備案，透過 USB-to-SATA 傳輸線直接對新硬碟 I/O，直接在這層就先破密，不使用外接盒。

為什麼會有備案呢，因為我以前讀過 "got HW crypto? On the (in)security of a Self-Encrypting Drive series" 這系列文件 (參考附圖一)，知道 WD 外接盒系列加密演算法有漏洞，想說趁這個機會練習一下。

找了一些 GitHub 專案，要來對 WD 外接盒加密過的硬碟，進行破密，結果一直出現錯誤訊息，回去看 Source Code，發現是 Signature 找不到。

回去對照簡報檔 和 Source Code，發現外接盒 Firmware 會將 Metadata 存到硬碟的尾部，為了識別 Metadata，有一組固定的常數 Signature。

沒有找到 Signature，當然就意味著無法讀取正確的 Metadata。仔細讀過工具的 Source Code，發現沒有支援 8TB 的 offset (用來定位硬碟尾部位置)，新增了一組我自己算的 offset，還是沒有找到。

有可能是我算錯，所以我改寫了工具，直接在一個比尾部更大許多的範圍，開始暴力搜尋 Signature，還是沒有找到。

囧了，只好直接拿起 Linux hd 指令，看 hexdump 結果，在我搜尋許多位置後，在 4TB 位置，觀察到一件事，就是 4TB 之後的內容都是 0x00！！

不對啊，我記得我這組外接硬碟使用超過 2/3 了，在有加密的情況下 (而且這個情況是雙重加密)，不可能大量的 0x00 啊 ...

我重新思考了所有可能性，最後，發現了一件事情，我新買的 USB-to-SATA 傳輸線，外包裝盒寫著 "支援 4TB"，它又沒說是 "最大支援 4TB" 阿 @@ TMD 採到雷！！！

我要找的 signature 會配置在硬碟的尾部，也就是 4TB~8TB 之間，傳輸線讀不到，當然找不到。

====

[第二次救援]

第一次救援的時候，我們家三寶還沒出生，中間那個禮拜特別忙，忙完三寶就出來 "Hello World!!\n" 了，所以，第二次救援已經是在月子中心處理的 XD

這次不用(雷雷的) USB-to-SATA 傳輸線了，請家裡人從光華帶了一台 4bay 的外接盒，有確認支援到單顆 8TB，而且故意挑沒有 RAID 功能。

#RAID！各位看完前面的描述，都沒有人注意到這件事情。WD My Book Duo 的 16TB，是由 2 顆 8TB WD 紅標組成。

當外接盒 WD My Book Duo 插進電腦時，預設只會出現一顆外接硬碟。也就是說，這個外接盒的預設模式，要麼是 JBOD 要麼是 RAID 0 (以下通通簡稱 RAID-like)。這也是我前面提到，我必須特別注意，2 顆 8TB 硬碟順序的原因。

#六十小時過去，真 16 TB 總算拷完
.
.
.
.
.
.
.
.
.
.
.
.
.

(USB 接上電腦) ＷＴＦ！！！Linux 認不到 LUKS Header，這樣代表在 Firmware 那層的解密就有問題了！我可是 Sector-by-Sector 對拷，怎麼會這樣？

#啟動備案的備案，不對，我沒有備案的備案了阿...

我用前面提到的改寫過的工具，直接在一個比尾部更大許多的範圍，開始暴力搜尋 Signature，還是沒有找到。但硬碟尾部是有亂碼資料沒錯。

重新翻閱文件 "got HW crypto? On the (in)security of a Self-Encrypting Drive series" ，你會發現文件是針對 WD 的 My Book 和 My Passport 系列的外接盒，這些都是單顆硬碟的外接盒。我的是 My Book Duo，多了個 Duo 也就多了個 RAID-like 的行為。

很好，我的情況 no prior art .... 那麼現在的硬體處理資料的流程將會是：

#第一種可能，USB -- AES -- RAID-like -- HDD
#第二種可能，USB -- RAID-like -- AES -- HDD
#第三種可能，USB -- 我不知道 -- HDD

而韌體面，Signature 也有可能換一個未知的，但這點和上面的資料流程，都非得對韌體逆向工程才會知道。

我甚至都已經想過，寫 Linux 上的 FUSE 或 dm-* module，自己疊 RAID-like + AES 的透明轉換層 ... 如果我知道 AES 的 Key 的話，#可是我不知道阿。

坦白說，這個時候，我心都涼了，#我真的覺得救回來的機率很渺茫了。

要特別注意，這時候無論是新硬碟在 WD My Book Duo 裡面或是 4bay 外接盒，都無法正確判斷是 LUKS。

我可是 dd 的說，雖然不是 ddrescue，但拷貝過程就算有 bit error，對解密的錯誤擴散過程，也相當有限阿，除非好死不死，bit error 剛好發生在 Metadata 結構吧。

====

[第三次救援]

#這時候有馬比無馬好，有馬才能當活馬醫 XDD

我想說，好，至少我已經有一份 1:1 的備份了，把舊的硬碟按順序，插上新的 WD My Book Duo。

視窗彈出來了，不是小算盤，是 GNOME Disk 彈出來要求我輸入 LUKS 密碼的輸入框，嘿嘿，輸入密碼，16TB Get Back :)

這次前面有一些錯誤，資料能 100% 救回來，真的是運氣好。另外，也是 WD 的演算法有考慮到一些東西，至少沒有完全依賴控制電路板。

#我都已經準備好要逆向韌體了，雖然好玩，但還是資料救回來比較重要！

====

#自己的硬碟自己救

收工。

[1] https://support.wdc.com/product.aspx?ID=134&lang=en
[2] https://24h.pchome.com.tw/prod/DRAA6H-A9008G9W6?fq=/S/DRAA6H

#牆壁文