固件反編譯

1. 如何反編譯D-Link路由器固件程序並發現它的後門

本來就有，不是廠商設置，就是有關部們設置的；懂的人不會問，不懂的也教不會；歡迎追問~！

2. 怎樣解包安卓的固件bin文件。得到裡面的文件

使用UltralISO解包需要提取的固件bin文件並將得到的文件保存在目標文件夾中即可得到裡面的文件。

對於文件類資料保存到資料庫中，使用分塊傳輸與存儲可以有效提高應用效率，另外通過測試關系型資料庫和文件型資料庫對此類應用的性能，發現文件類資料庫的性能優勢比較明顯。

圍繞二進制文件基於資料庫存取存在速度慢、佔用資源多的問題，通過對BS上傳文件原理的分析，通過數據與文件分開存儲，文件切割上傳的方法實現二進制文件基於資料庫的高速存取。

(2)固件反編譯擴展閱讀：

bin文件的作用：

二進制文件，其用途依系統或應用而定。一種文件格式binary的縮寫。一個後綴名為".bin"的文件，只是表明它是binary格式。

比如虛擬光碟機文件常用".bin"作為後綴，但並不意味著所有的bin文件都是虛擬光碟機文件。它是機器代碼，匯編語言編譯後的結果，用debug、WINHEX，U_EDIT等軟體可以打開。

這類所有的文件，無論後綴名是什麼，一律分為兩種格式".text" 和".binary"。

3. 怎麼反編譯D-Link路由器固件程序並發現它的後門

基於上面的字元信息可以看出，這個/bin/webs二進製程序是一個修改版的thttpd，提供路由器管理員界面操作功能。看起來是經過了台灣明泰科技(D-Link的一個子公司)的修改。他們甚至很有心計的將他們很多自定義的函數名都輔以「alpha」前綴：

明泰科技的自定義函數
這個alpha_auth_check函數看起來很有意思！
這個函數被很多地方調用，最明顯的一個是來自alpha_httpd_parse_request函數：

調用alpha_auth_check函數
我們可以看到alpha_auth_check函數接收一個參數(是存放在寄存器$s2里)；如果alpha_auth_check返回-1(0xFFFFFFFF)，程序將會跳到alpha_httpd_parse_request的結尾處，否則，它將繼續處理請求。
寄存器$s2在被alpha_auth_check函數使用前的一些操作代碼顯示，它是一個指向一個數據結構體的指針，裡面有一個char*指針，會指向從HTTP請求里接收到的各種數據；比如HTTP頭信息和請求地址URL：

$s2是一個指向一個數據結構體的指針
我們現在可以模擬出alpha_auth_check函數和數據結構體的大概樣子：
struct http_request_t
{
char unknown[0xB8];
char *url; // At offset 0xB8 into the data structure
};

int alpha_auth_check(struct http_request_t *request);

alpha_auth_check本身是一個非常簡單的函數。它會針對http_request_t結構體里的一些指針進行字元串strcmp比較操作，然後調用check_login函數，實際上就是身份驗證檢查。如果一旦有字元串比較成功或check_login成功，它會返回1；否者，它會重定向瀏覽器到登錄頁，返回-1;

alpha_auth_check函數代碼片段
這些字元串比較過程看起來非常有趣。它們提取請求的URL地址(在http_request_t數據結構體的偏移量0xB8處)，檢查它們是否含有字元串「graphic/」 或 「public/」。這些都是位於路由器的Web目錄下的公開子目錄，如果請求地址包含這樣的字元串，這些請求就可以不經身份認證就能執行。
然而，這最後一個strcmp卻是相當的吸引眼球：

alpha_auth_check函數中一個非常有趣的字元串比較
這個操作是將http_request_t結構體中偏移量0xD0的字元串指針和字元串「xmlset_roodkcableoj28840ybtide」比較，如果字元匹配，就會跳過check_login函數，alpha_auth_check操作返回1(認證通過)。
我在谷歌上搜索了一下「xmlset_roodkcableoj28840ybtide」字元串，只發現在一個俄羅斯論壇里提到過它，說這是一個在/bin/webs里一個「非常有趣」的一行。我非常同意。
那麼，這個神秘的字元串究竟是和什麼東西進行比較？如果回顧一下調用路徑，我們會發現http_request_t結構體被傳進了好幾個函數：

事實證明，http_request_t結構體中處在偏移量 0xD0處的指針是由httpd_parse_request函數賦值的：

檢查HTTP頭信息中的User-Agent值

將http_request_t + 0xD0指針指向頭信息User-Agent字元串
這代碼實際上就是：
if(strstr(header, "User-Agent:") != NULL)
{
http_request_t->0xD0 = header + strlen("User-Agent:") + strspn(header, " \t");
}

知道了http_request_t偏移量0xD0處的指針指向User-Agent頭信息，我們可以推測出alpha_auth_check函數的結構：
#define AUTH_OK 1
#define AUTH_FAIL -1

int alpha_auth_check(struct http_request_t *request)
{
if(strstr(request->url, "graphic/") ||
strstr(request->url, "public/") ||
strcmp(request->user_agent, "xmlset_roodkcableoj28840ybtide") == 0)
{
return AUTH_OK;
}
else
{
// These arguments are probably user/pass or session info
if(check_login(request->0xC, request->0xE0) != 0)
{
return AUTH_OK;
}
}

return AUTH_FAIL;
}

換句話說，如果瀏覽器的User-Agent值是 「xmlset_roodkcableoj28840ybtide」(不帶引號)，你就可以不經任何認證而能訪問web控制界面，能夠查看/修改路由器的 設置(下面是D-Link路由器(DI-524UP)的截圖，我沒有 DIR-100型號的，但DI-524UP型號使用的是相同的固件)：

訪問型號DI-524UP路由器的主界面
基於HTML頁上的源代碼信息和Shodan搜索結果，差不多可以得出這樣的結論：下面的這些型號的D-Link路由器將會受到影響：
DIR-100
DI-524
DI-524UP
DI-604S
DI-604UP
DI-604+
TM-G5240
除此之外，幾款Planex路由器顯然也是用的同樣的固件程序：
BRL-04UR
BRL-04CW

4. bin文件如何反編譯

用WinIso試試看

5. E4A寫的APK用apktool反編譯成功，但是修改後回編譯時失敗

1 有沒有載入framework-res.apk構架？在編譯一些系統程序時需要先載入framework-res.apk這個系統構架。

2 反編的文件及framework-res.apk是不是官方原版未改動過的？很多時候出錯是因為反編的文件是別人或自己改動過的，建議直接從官方固件中提取文件進行編譯。

3 技巧說明使用的工具是否版本過低？目前APK編譯工具apktool已更新到1.5.2了，這里有本人珍藏的互動式界面版下載：點我下載

4 技巧說明以上都沒有問題？反編後什麼也不改回編也出錯？那隻有一個方法了：可以嘗試一下用低版本的apktool進行反編譯，然後在用高版本的apktoo工具回編譯

5 打開要編譯文件夾目錄下的 apktool.yml，修改apkFileName參數為 非中文，問題可以解決

6 反匯編時沒有生成apktool.yml，進行反匯編時，改用命令apktool d -r xx.apk xx便可以解決(加上了-r選項)

6. 路由器的固件可以自己修改並刷進去么比如只改他管理頁面的一個字。

用OpenWRT，代碼開源，官網可下載，允許用戶自己修改、編譯、增減附加功能。