2007年7月6日 星期五

netstat 指令匯整

1. 查看 sockets(列出 active/listen connections)
netstat -a


2. 篩選特定協定
netstat -ap tcp
也可利用 windows 內建的 find 指令
netstat -a | find "TCP"
netstat -a | find "UDP"


3. 顯示 Port 號碼而非名稱
netstat -an | find "TCP"
netstat -an | find "UDP"


4. 找出觸發每個 tcp 連線的 process 號碼(PID)
netstat -aop tcp
netstat -aop udp


5. 找出 process 檔案名稱(配合上一步取得的 PID)
在此可採用 netstat 的 -b 參數(比較慢,參考步驟九,XP SP2、2003 SP1)
或是 tasklist (XP 專業版、2003、Vista)


6. 查看通訊協定狀態
netstat -sp tcp
netstat -sp ip
netstat -sp udp
netstat -sp icmp


7. 查看路由表 (同 route print 指令)
netstat -r


8. 查看乙太網路(網卡)狀態
netstat -e


9. 找出觸發每個 tcp 連線的 process 號碼及檔案名稱
與 tasklist 不同的是還多了相關 dll 資訊
netstat -abp tcp


10. 延續上一步,查看更詳盡資訊(速度更慢)
netstat -abvp tcp


11.netstat –na 1 | find "特定IP"
顯示特定 IP 之連線,每隔一秒更新畫面一次 (適用於像是你已鎖定可疑對象,但不知他何時會連過來)
-a 代表列出所有連線
-n 代表僅列出 IP 及 Port,不解析為 hostname 及 service name,速度會快很多


12.netstat –nao 1 | find "特定IP"
加上 -o 參數可顯示觸發該連線之 process ID,
欲知 process name 則可以透過內建的 tasklist 這程式


13.netstat –na 1 | find "4444" | find "ESTABLISHED"
也可以針對特定 Port,不分對象的進行監控,
再透過 find "ESTABLISHED" 篩選掉僅 LISTENING 的部份


http://isc.sans.org/diary.php?storyid=1911&rss


iphone 啟動程序被破解了

iPhone上市不到一周,駭客已經找到破解iPhone啟動程序的方法。只是,目前透過駭客所提供的方法僅能使用 iPhone 的部份功能。此外,還有駭客宣稱可在3到7天內解除iPhone對電信業者的限制。


知名的DVD駭客 Jon Lech Johansen 在他的網站上發表了Phone Activation Server v1.0軟體供使用者下載,使用者安裝該啟動軟體後就能繞過 iPhone 的啟動程序,但現在透過該軟體啟動 iPhone 僅能使用iPod 及 Wi-Fi 功能。


http://nanocr.eu/2007/07/03/iphone-without-att/


另一專門追蹤 iPhone 破解進度的 iPhone Dev Wiki 網站也在本周宣布破解iPhone啟動程序,而且公開了概念性驗證程式碼,不過,使用者要透過該程式啟動iPhone必須要先有一已知的憑證,該憑證則來自於那些經由正式管道經蘋果認證後的iPhone手機。該站說明,一個憑證可用在多隻iPhone上。


iPhone Dev Wiki列出了破解iPhone的計畫表,除了破解啟動程序外,下一步就是讓iPhone可以使用其他電信業者的行動電話服務,另外也包括可執行第三方開發的應用程式。


2007年7月5日 星期四

一次砍掉所有電腦的某個程序

首先要有每一台電腦的管理者權限及密碼


taskkill /s pc-01 /im iexplore.exe /u administrator /p admpasswd


/s pc-01 :遠端電腦名稱為 pc-01 。
/im iexplore.exe :要關閉的應用程式為 iexplore.exe ,即 IE 瀏覽器 ( im 為 image name 的縮寫 ) 。
/u administrator :遠端電腦執行 taskkill 的帳號,用管理員就對了。
/p admpasswd :遠端電腦的管理員密碼。如果只寫 /p 而省略密碼,則會提示輸入。

整間砍掉的用法


for /l %a in (1,1,9) do taskkill /s pc-0%a /im iexplore.exe
for /l %a in (10,1,46) do taskkill /s pc-%a /im iexplore.exe 


修復 moodle 的 log 功能

有時 moodle 的 log 會無法記錄..這時有可能時 log table 壞了..


repair table mdl_log


關於 repair 語法的參考: REPAIR TABLE Syntax


2007年7月4日 星期三

Openings 空檔

Openings 空檔


Please hold while I see if he has any openings today.


請稍等,我看一下他今天還有沒有空檔。


Snapshot-檔案系統快照

File System Snapshots-檔案系統快照,顧名思義就是將當時的檔案系統照一張像,當我們想要用的時候可以在拿出來用,拿來備份也不失為一個好的方法,整個過程大概就是利用指令將指定的分割區(Mount Poing)給快照起來,然後利用 MD (Memory Disk) 把快照檔案模擬成檔案系統讓我們查看當時快照下來的檔案系統,在執行 File System Snapshots 之前注意事項如下:



  • 一個檔案系統中最多只能有 20 個檔案系統快照
  • 快照只能針對獨立的分割區作用 (ex. /dev/ad0s1g /home)
  • 在執行檔案系統快照時檔案只能存放於該檔案系統(ex. /var/snapshot /var)當快照完畢後才可進行搬移
  • 快照出來的檔案你會發現跟分割區大小一樣(若在原分割區是不佔什麼空間的)
  • 若將快照檔案複製到其它分割區就會佔實際空間了
  • 若是快照根目錄 (/),則當 mount 來用時會發現其它分割區內是空的(ex./var、/usr)
  • 可以使用 rm 來刪除快照檔案

詳細內文請看 http://www.weithenn.idv.tw/cgi-bin/wiki.pl?Snapshot-%E6%AA%94%E6%A1%88%E7%B3%BB%E7%B5%B1%E5%BF%AB%E7%85%A7


2007年7月3日 星期二

吃掉資源的 svchost.exe

吃掉CPU資源的 svchost.exe(轉載)




svchost.exe 吃掉所有 CPU 資源的原因很多,不過我的狀況都是在執行 Windwos Update 時發生的(或是自動更新服務 Automatic Updates 執行時)。因此解決方法主要就是把 Windows 的自動更新重設一次,步驟如下:


一、首先檢查系統服務的狀態。
1. 點「開始」–>「執行」,輸入「services.msc」後按「確定」。
2. 在服務「Automatic Updates」上點二下。
3. 點選「登入」頁籤,確定登入身分為「本機系統帳戶」且「允許服務與桌面互動」“沒有”被選取。
4. 確認服務已在目前的「硬體設定檔」中被啟用,如果沒有,按下「啟用」按鈕。
5. 點選「一般」頁籤,確定「啟動類型」為「自動」,然後按下「啟動」按鈕以啟動服務。
6. 對「Background Intelligent Transfer Service (BITS) 」服務重覆 2 ~ 5 的步驟。


二、接著重新註冊 Windwos Update 的元件。
1. 點選「開始」–>「執行」。
2. 輸入「REGSVR32 WUAPI.DLL」後按 Enter。
3. 當看到 “DllRegisterServer 在 WUAPI.DLL 成功” 的訊息後按下「確定」。
4. 重覆上述步驟重新註冊下列元件
REGSVR32 WUAUENG.DLL
REGSVR32 WUAUENG1.DLL
REGSVR32 ATL.DLL
REGSVR32 WUCLTUI.DLL
REGSVR32 WUPS.DLL
REGSVR32 WUPS2.DLL
REGSVR32 WUWEB.DLL


三、最後清除可能已損壞了的 Windows Update 暫存目錄。
1. 點「開始」–>「執行」,輸入「cmd」後按「確定」。
2. 在命令提示字元中鍵入以下指令。(若出現錯誤訊息請先重開機後再報執行一次)
net stop WuAuServ
2. 點「開始」–>「執行」,輸入「%windir%」後按「確定」。
3. 找到「SoftwareDistribution」並更名為「SDold」。
4. 點「開始」–>「執行」,輸入「cmd」後按「確定」,並在在命令提示字元中鍵入以下指令。
net start WuAuServ


四、大功告成!

http://support.microsoft.com/kb/927891/zh-tw


http://blog.yam.com/gavint/article/9852247