(寫在開頭) 沒有任何具體破解要修改內(nèi)容，只有流程，求過審

文章首發(fā)在我的個人網(wǎng)站

http://841973620.net/index.php/archives/dls-cracked.html

眾嗦粥汁，新版的licserver不再通過驗(yàn)證MAC地址進(jìn)行授權(quán)，而改為上傳本地憑證后從NVIDIA許可門戶生成唯一的授權(quán)文件，堵上了舊版licserver可以多次使用同一個授權(quán)文件的漏洞。那么新版的licserver有辦法破解嗎?

當(dāng)然是有的。新版的授權(quán)分為CLS(云端)和DLS(本地)，其中本地部署的DLS是無需聯(lián)網(wǎng)的，也就是說只要能騙過本地的授權(quán)校驗(yàn)就能注冊授權(quán)服務(wù)器。至于逆向授權(quán)那么復(fù)雜的過程我是不會了，所以我選了更方便(實(shí)際上更麻煩)的方法：直接改數(shù)據(jù)庫

以下皆以Hyper-V下的NLS鏡像做演示

首先是要解決DLS服務(wù)器的密碼問題。由于GRUB也加了密碼，所以只能通過另一個系統(tǒng)來操作，修改DLS系統(tǒng)下 /etc/shadow 文件，刪除下圖中高亮部分字段，以允許root空密碼登錄

由于DLS系統(tǒng)會每隔15分鐘隨機(jī)重置root密碼，所以接著修改 /etc/dls/scripts/rotate_pwd.sh?文件，將下圖中高亮部分字段改為你要設(shè)置的密碼，以確保修改后的密碼是你知道的

接著啟動DLS服務(wù)器虛擬機(jī)，以空密碼登錄root賬戶，你會發(fā)現(xiàn)DLS服務(wù)器實(shí)際上分為應(yīng)用服務(wù)和數(shù)據(jù)庫兩部分，分別運(yùn)行在容器中。其中 appliance?容器是一次性的，每次啟動都會重置，而pgsql?容器不會重置，以防止Web遭到篡改

進(jìn)入 pgsql 容器后連接數(shù)據(jù)庫，會發(fā)現(xiàn)信息存放在名為 nlsdb?的Database下，用戶 dls_writer?具有所有權(quán)限，我們在這里新建一個名為 nvidia?的用戶用來連接數(shù)據(jù)庫而不是修改 dls_writer?用戶的密碼，再向用戶 nvidia 賦予權(quán)限

為了更直觀的操作，我使用 PostgreSQL Maestro 來操作數(shù)據(jù)庫，要修改的內(nèi)容位于 request_routing?和以 si_? 開頭的 Schemas?中 (每個DLS服務(wù)器數(shù)據(jù)庫中的 si_?都不一樣，以確保唯一性)

其中，request_routing?要修改的 Table?為 license_allotment_reference， license_allotment_service_instance，service_instance

si_?要修改的 Table?為 entitlement，entitlement_feature，forced_feature_release，fulfillment_condition，fulfillment_condition_binding，license_allotment，license_allotment_feature，license_allotment_key，license_org，license_pool，license_pool_feature，license_pool_feature_running_counts，public_private_key_pair，selection_rule，service_instance_artifact，virtual_group

(不敢放具體內(nèi)容，1.怕惹麻煩? 2.寫不下，懶)

總之，進(jìn)過修改后的DLS服務(wù)器如下圖，可自定義需要的授權(quán)類型、數(shù)量和可用時間， 除了 Configure High Availability?外的功能均可正常使用 (要是修改了兩臺DLS的話部署高可用性選項(xiàng)也可用)

END