額外的Debug資訊，e.g.thread資訊

6月

好累= =

嘿~It’s my birthday

 

不管是用什麼方式
謝謝那些祝福我生日快樂的人: )

be happy too

roomie-So Long
還不錯聽

PDF惡意編碼分析

Challenge 6 of the Forensic Challenge 2010 - Analyzing Malicious Portable Destructive Files
(英文網頁說明)
https://www.honeynet.org/challenges/2010_6_malicious_pdf

 

鑑識分析挑戰 6：分析惡意編碼 PDF 檔案
(中文網頁說明)
http://www.honeynet.org/node/584

 

開wireshark File>Export>Objects>HTTP 把全部物件Export出來
會得到惡意PDF文件"fcexploit.pdf"和其他一些東西

--
1.
惡意文檔分析技巧及工具快速參考(Cheat Sheet)
http://jay-fva.blogspot.com/2011/05/cheat-sheet.html
2.
神父神棍
http://wordintoro.wordpress.com/2011/08/
3.
010 Editor
4.
http://blog.didierstevens.com/2008/04/09/quickpost-about-the-physical-and-logical-structure-of-pdf-files/

C# 利用IP查詢Hostname問題

Dns.Resolve 與 GetHostByAddress(String)
在.net 2.0後版本都會顯示已過時

但M$DN 所建議的替代方案Dns.GetHostEntry
輸入IP並不能有效取得Hostname ,我遇到和下面一模一樣問題
http://bytes.com/topic/net/answers/453896-dns-gethostentry


外國人討論此問題也有不少討論串
(1).
http://bytes.com/topic/net/answers/829960-dns-gethostentry-not-working-same-dns-resolve-dns-gethos

(2).
這個討論串值得一看，有說明了出問題原因，雖然無法解決，但大家爭相表達不滿XDDD?
http://social.msdn.microsoft.com/Forums/da-DK/netfxnetcom/thread/e2059b78-3493-457b-b632-0500be197478

The issue is the reverse lookup. Traditionally DNS Servers are supposed to resolve the names to addresses. The reverse of that - looking up a host name based on IPAddress is not reliable and in Ipv6 it is not supported. So my recommendation is to not to write apps that rely on reverse lookup.

(3).
最慘的是，M$ connect上有人發文指出這個問題，MS的回覆ˊˋ
System.Net.DNS.GetHostByAddress(<IP>) doesn't resolve host names on remote nodes

由 Microsoft 在 2006/2/23 於 下午 01:50 所公佈
The issue here lies in the OS implementation of DNS which System.Net utilizes. A bug has been filed against the OS. This issue is fixed in Windows Vista.

https://connect.microsoft.com/VisualStudio/feedback/details/97815/system-net-dns-gethostbyaddress-ip-doesnt-resolve-host-names-on-remote-nodes

爬了一小時文，沒什麼結論
GetHostEntry能支援IPv6
IP反查HostName要不就靠DNS Server幫忙(若GetHostEntry必須重設DNS 反向查詢功能)

不然舊版Resolve也不保證一定查得到??ˊ3ˋ

所以Dns.Resolve與Dns.GetHostEntry究竟用哪個好(汗)

五月天 - 純真

 

五月天的純真
歌詞如下:
作詞：阿信　作曲：阿信　編曲：五月天
長長的路上我想我們是朋友
如果有期待我想最好是不說
你總是微笑的你總是不開口
世界被你掌握
月亮繞地球地球繞著太陽走
我以為世界是座寧靜的宇宙
今晚的天空有一顆流星劃過
在預言著什麼
在無聲之中你拉起了我的手
我怎麼感覺整個黑夜在震動
耳朵裡我聽到了心跳的節奏
星星在閃爍　 你(會)怎麼說
你心中一定有座濃霧的湖泊
任憑月光再皎潔照也照不透
你眼中閃爍湖面無邊的溫柔
那波光在　誘惑
你已經有他就不應該再有我
世界的純真此刻為你有迷惑
我想我應該輕輕放開你的手
我卻沒有力氣這麼做

狂被出版社退件的過年

 

就像是再磨練我的心智(汗)

心臟不大顆還撐不下去=ˇ=||

JM18裡的MB_Type

(1).MB_TYPE
//  Available MB modes
enum {
  PSKIP        =  0,
  BSKIP_DIRECT =  0,
  P16x16       =  1,
  P16x8        =  2,
  P8x16        =  3,
  SMB8x8       =  4,
  SMB8x4       =  5,
  SMB4x8       =  6,
  SMB4x4       =  7,
  P8x8         =  8,
  I4MB         =  9,
  I16MB        = 10,
  IBLOCK       = 11,
  SI4MB        = 12,
  I8MB         = 13,
  IPCM         = 14,
  MAXMODE      = 15
} MBModeTypes;

(2).NALU的bits配置
http://brytsai.blogspot.com/2010/02/h.html

H.264中如何判斷某一段是否為SPS(Sequence Parameter Set)或PPS(Picture Parameter Set)

在H.264中，無論是SPS、PPS或者是slice data，都是由一個NAL unit所組成。一個NAL unit的開始皆為00 00 00 01，下一個byte的值將決定這個NAL unit是屬於SPS或者是PPS還是slice data。
事實上下一個byte的值是由三個部份所組成，包括forbidden_bit、nal_reference_idc和nal_unit_type。其中 forbidden_bit佔1bit，一般來說其值為0。而nal_reference_idc佔2bit，其值用來表示此NAL在重建過程中重要程度。至於佔了5bit的nal_unit_type就比較重要了，用來表示該NAL unit是屬於何種類型。
下表是H.264標準中定義所有NAL的類型
#define NALU_TYPE_SLICE 1
#define NALU_TYPE_DPA 2
#define NALU_TYPE_DPB 3
#define NALU_TYPE_DPC 4
#define NALU_TYPE_IDR 5
#define NALU_TYPE_SEI 6
#define NALU_TYPE_SPS 7
#define NALU_TYPE_PPS 8
#define NALU_TYPE_AUD 9
#define NALU_TYPE_EOSEQ 10
#define NALU_TYPE_EOSTREAM 11
#define NALU_TYPE_FILL 12
因此當nal_unit_type值為7時，則這個NAL unit即為SPS。而值為8時，這個NAL unit為PPS。
舉例來說，若擷取某一段H.264 bitstream為00 00 00 01 67 42 e0 14 da 05 82 51。
因為67 = 0 11 00111，nal_unit_tye = 00111 = 7，所以這一段為SPS。
又另一例00 00 00 01 68 ce 30 c4 80 00 00 00 00 00 00 00
68 = 01000，nal_unit_tye = 01000 = 8，所以這一段為PPS。