是否有任何希望的閃客，將轉換成一個可執行程序的C / C + +代碼？
這種常見問題的答案是摘錄片段由Bob斯圖特。
不要屏住呼吸。 想想看， ... 對於閃客正常工作，無論是1 ）每個編譯器會產生大量相同的代碼，即使有充分的優化打開，或2 ）它必須承認個別輸出的每個編譯器的代碼生成器。
如果第一個案件是正確的，就不會有更多的需要編譯的基準，因為每個人都將相同。 對於第二個案例是真實的，需要極為複雜的程序，不得不改變與每一個新的編譯器釋放。
因此，如何具體decompilers為具體的編譯器-說，閃客旨在只有工作所產生的代碼，也就是說，公元前+ + 4.5 ？這讓我們回到正確的優化問題。 編寫的代碼的清晰度和理解往往是效率低下。 編寫的代碼實現了最佳的性能（速度或大小）往往是隱蔽（最好！ ）添加到這一個事實，即所有現代編譯器有多種優化開關控制優化技術，使這避免。 底線是，對於一個合理的大型，複雜的源模塊，你可以編譯器產生了一些不同的對象模塊只需更改您的優化開關，使您的閃客也將是一個deoptimizer可以自動承認這優化戰略，在編譯時啟用。
讓我們進一步簡化和明確規定，您只需要支持一個具體的編譯器和你要破解的最合乎邏輯的源代碼沒有試圖解釋優化。 然後呢？ 一個很好的優化工具可以將大大改寫內部的代碼，所以你離開你的閃客將，不僅隱蔽，但在許多情況下，充滿了轉到報表和其他沒有任何的良好的編碼實踐。 在這一點上，你有反編譯源代碼，但有什麼好處呢？
我還注意到仔細參考源模塊。 一個特點C是，它在很大程度上成為不可讀除非分為易於維護的源代碼模塊（ 。 C文件） 。 如何閃客處理呢？ 它可以嘗試破解整個計劃的一些龐大的Main （ ）函數，失去所有的模塊，也可以嘗試將每個稱為功能納入自己的檔案。 第一種方法會產生混亂和無法使用的第二個會遇到問題的原始來源哈德檔案多種功能使用靜態數據和/或一個或多個職能要求的一個或多個靜態的職能。 阿閃客可以使靜態數據和/或職能全球只有犧牲或可讀性（這已經是不能接受的） 。
最後，請記住，商業應用的代碼往往是最困難或時間緊迫的職能彙編可以證明幾乎是不可能的反編譯成一個C同等學歷。
就像我說的，不要屏住呼吸。 隨著科技不斷發展下decompilers可能變得更為可行，優化和語言（ C + +的，例如，將是一個顯著更嚴厲的語言來解譯比c ）又陰謀使他們不太可能。
多年Unix應用程序中已經分發籠罩來源形式（機器可讀的，但不是人-所有的意見和空格去掉，所有的變量名字的形式OOIIOIOI等） ，一直是一個非常適當的手段來保護作者的權利。 這是非常不可能的閃客輸出甚至是為可讀的籠罩來源。
更新：閃客技術仍然非常困難，但已取得重大進展，因為這是書面。
閱讀什麼是閃客？的最新資料，閃客項目。
 |
時間是否有任何希望的閃客 ， 將轉換成一個可執行程序的C / C + +代碼？
