Monday, October 29, 2012

How to Defeat Windows 8 ASLR in Getting the Address of KPCR


How to Defeat Windows 8 ASLR in Getting the Address of KPCR

by cawan (cawan[at]ieee.org)

on 29/10/2012

In Windows XP or earlier version, KPCR is always located at 0xffdff000.
It is very important for kernel shellcode in getting system process token
in order to duplicate it into another eprocess object which has lower
privilege. This action is normally known as token stealing, and it is
very useful for privilege escalation. However, starting from Windows 7,
it has been ASLRed, and so in Windows 8. This has increased the difficulty
in creating kernel shellcode. However, it is not impossible to defeat it.
First of all, let see how it is ASLRed in Windows 8.

kd> !pcr
KPCR for Processor 0 at 81214000:
    Major 1 Minor 1
NtTib.ExceptionList: 8089612c
   NtTib.StackBase: 00000000
  NtTib.StackLimit: 00000000
NtTib.SubSystemTib: 80879000
     NtTib.Version: 005ab660
 NtTib.UserPointer: 00000001
     NtTib.SelfTib: 00000000

           SelfPcr: 81214000
              Prcb: 81214120
              Irql: 0000001f
               IRR: 00000000
               IDR: 00000000
     InterruptMode: 00000000
               IDT: 8087c400
               GDT: 8087c000
               TSS: 80879000

     CurrentThread: 812230c0
        NextThread: 00000000
        IdleThread: 812230c0

         DpcQueue:

Well, the KPCR is at 0x81214000. This address is valid until next reboot.
Let see which address range of this KPCR located to.

kd> ln 81214000
(81214000)   nt!KiInitialPCR   |  (81218280)   nt!BcpCursor
Exact matches:
    nt!KiInitialPCR =

It is within nt kernel with internal symbol KiInitialPCR. Of course the
KiInitialPCR will not be existed in the list of Export Table of nt PE
header. So, how to get the address? Method 1, by using the fixed offset
of KPCR to a well-known symbol which is included in the Export Table of
nt PE header, let's say HalDispatchTable.

kd> dd nt!HalDispatchTable l1
811def28  00000004

So, HalDispatchTable is at 0x811def28. Let's check the offset to KPCR.

kd> ? 81214000-811def28
Evaluate expression: 217304 = 000350d8

Well, it is 0x00350d8. So, when we need to exploit a device driver, we
can calculate the address of KPCR in user mode first before creating the
kernel shellcode to be run for privelege escalation. To calculate the
KPCR, use the following steps,

1. Use NtQuerySystemInformation() with SystemInformationClass of
   SystemModuleInformation to get nt kernel base
2. Use LoadLibrary() to load nt kernel image file into user space and
   get its base (nt kernel base in user space)
3. Use GetProcAddress() to get the address of HalDispatchTable in user
   space (HalDispatchTable in user space)
4. (HalDispatchTable in kernel base) = (nt kernel base) + (HalDispatchTable
   in user space) - (nt kernel base in user space)
5. KPCR = (HalDispatchTable in kernel base) + 0x350d8

Well, the 0x350d8 is valid for Windows 8 system. Let's verify by rebooting
the machine.

kd> dd nt!HalDispatchTable l1
81039f28  00000004

The HalDispatchTable is at 0x81039f28. So by adding 0x350d8 to 0x81039f28
it suppose to be KPCR.

kd> ? 81039f28+350d8
Evaluate expression: -2130251776 = 8106f000

The KPCR should be located at 0x8106f000 now. Let's check.

kd> !pcr
KPCR for Processor 0 at 8106f000:
    Major 1 Minor 1
NtTib.ExceptionList: 8051612c
   NtTib.StackBase: 00000000
  NtTib.StackLimit: 00000000
NtTib.SubSystemTib: 804f9000
     NtTib.Version: 0001604a
 NtTib.UserPointer: 00000001
     NtTib.SelfTib: 00000000

           SelfPcr: 8106f000
              Prcb: 8106f120
              Irql: 0000001f
               IRR: 00000000
               IDR: 00000000
     InterruptMode: 00000000
               IDT: 804fc400
               GDT: 804fc000
               TSS: 804f9000

     CurrentThread: 8107e0c0
        NextThread: 00000000
        IdleThread: 8107e0c0

         DpcQueue:

Bingo! We win. For your info, in Windows 7, it is 0x92c. I believe it
is service pack dependent, so, if you have chance to verify it in
different Windows version, please let me know.

Now, let's go to method 2, to defeat ASLR with FS register. In user
mode, FS:[0] is always pointing to the current thread object; but in
kernel mode, it is always pointing to KPCR. Let's check.

kd> r fs
fs=00000030

In all current windows system FS always be 0x30. It is easy to get the
base address of this FS value in windbg.

kd> dg 30
                                  P Si Gr Pr Lo
Sel    Base     Limit     Type    l ze an es ng Flags
---- -------- -------- ---------- - -- -- -- -- --------
0030 8106f000 00004280 Data RW Ac 0 Bg By P  Nl 00000493

Since we don't reboot the mechine yet, the KPCR is still at 0x8106f000.
The question now is can we do what dg command did manually? The answer
is yes. Let's go for it. First, lets deconstruct the FS value.

15...3|2   |1 0
index |TI  |RPL
0..110|0  |0 0

RPL=0 means kernel mode
TI=0 means using GDT
index=110 means selector index 6 of descriptors

Now, get the GDT address by using windbg. Of course in creating kernel
shellcode, sgdt instruction should be used.

kd> r gdtr
gdtr=804fc000

The GDT is at 0x804fc000. Let's dump its memory.

kd> dd 804fc000
804fc000  00000000 00000000 0000ffff 00cf9b00
804fc010  0000ffff 00cf9300 0000ffff 00cffb00
804fc020  0000ffff 00cff300 900020ab 80008b4f
804fc030  f0004280 81409306 00000fff 0040f300
804fc040  0400ffff 0000f200 00000000 00000000
804fc050  90000068 81008903 90680068 81008903
804fc060  00000000 00000000 00000000 00000000
804fc070  c00003ff 8000924f 00000000 00000000

Each descriptor is 8 bytes, so, descriptor at index 6 is at 0x804fc030

kd> db 804fc030 l8
804fc030  80 42 00 f0 06 93 40 81

Let's refer the format of descriptor

63...56        |55|54|53|52|51...48        |47|46   |45|44...40  |39...16                   |15...0
Base 31-24 |G |D  |R |U |Limit 19-16 |P  |DPL|S  |TYPE   |Segment Base 23-0|Segment Limit 15-0

R reserved (0)
DPL 0 means kernel, 3 means user
G 1 means 4K granularity (Always set in Linux)
D 1 means default operand size 32bits
U programmer definable
P 1 means present in physical memory
S 0 means system segment, 1 means normal code or data segment.
Type There are many possibilities. Interpreted differently for system and normal descriptors.

So, the base address can be reconstructed as shown below.

LSB  | 80 42 00 f0 06 93 40 81 | MSB
MSB | 81 40 93 06 f0 00 42 80 | LSB

63...56 = 81
39...16 = 06 f0 00

Well, the base address is at 0x8106f000 and it is exactly the KPCR address
that we obtained by using "dg 30" command in windbg. In next paper, I will
discuss about how to build a platform in creating and testing kernel shellcode
in windbg.

pdf version:
http://www.scribd.com/doc/112328778/How-to-Defeat-Windows-8-ASLR-in-Getting-the-Address-of-KPCR


Friday, October 5, 2012

Why I Cannot Ping My USRP2 With 192.168.10.2


Why I Cannot Ping My USRP2 With 192.168.10.2

Once I get my unit of USRP2, then I connect my WBX daughter board onto the
main board. After that, connect the Gigabit Ethernet port of the USRP2 to
the Gi0/1 of my Catalyst 2960, and then power on the USRP2. From the front
panel of USRP2, all six LEDs will flash on for a while and then only LED
with label D and F keep on, all the rest turn off. According to the
official configuration manual as stated below,  

http://files.ettus.com/uhd_docs/manual/html/usrp2.html

that means my USRP2 is running well now. Again, according to the manual,
I suppose to get ping reply from the USRP2 with default IP 192.168.10.2,
however, I can't get it. I think I should did something wrong to the USRP2,
and I need something to figure out the problem. Well, according to the
manual again, I can use an USB to serial connector to monitor the boot
message of the USRP2. By simply connecting RX and GND pins of my USB-Serial
connector to the serial port (TX and GND) of USRP2 (located at the
rear side of the mainboard), then I use SecureCRT to connect onto it with
baudrate 230400, 8-N-1. Now, turn it on again, and I get following message,

///////////////////////////////////////////////////////////////////////////

Tx dbid: 0x52
No daugherboard code for dbid = 0x52
Rx dbid: 0x53
No daugherboard code for dbid = 0x53

TxRx-NEWETH
00:50:C2:85:3B:15
ethernet flow control: NONE
Speed set to 1000

eth link changed: speed = 1000

///////////////////////////////////////////////////////////////////////////

Then everything stop here. It seems my WBX daughter board can't be detected
also. So, it might be something wrong to my firmware here. After some
searching works, I get some firmwares here,

http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries

So, I suspect my current firmwares do not support the WBX daughter board.
Well, I then download u2_rev3-20100603.bin as FPGA image and
txrx_wbx_raw_eth_20100608.bin as firmware image. On the other hand, according
to the manual, my USRP2 will detect for FPGA and firmware images from SD
card in the boot process. In other words, wihtout the SD card, my USRP2 will
not boot at all. Now, I need to find a way to burn those 2 new images into
the SD card. I found a good reference here,

http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/loading_sd_card_image.pdf

So, I need to get a python file with the name of usrp2_card_burner_gui.py.
By running the python file, I need to specify 3 things: FPGA image, firmware
image, and SD card device. I was using my Sony Vaio which has built-in SD slot.
However, since I was running my linux environment in VMware, I can't access
to my built-in SD slot. So, I tried with USB based SD card reader instead.
How to determine which device belong to SD card? Of course, you can use
sg_scan or sg_map to do the job, but why waste time? From the UI of
usrp2_card_burner_gui.py you can see a list of devices that detected
automatically. Then, simply plug in the SD card reader and click
"Rescan for Devices" button, the new item generated in the list should be the
SD card device. In my case, it is "sdb". To make thing safer, I tried
"cat /dev/sdb", and I get some related words about "ettus" or "usrp". So,
after specifying the FPGA image and firmware image, select the newly detected SD
card device as writing device, and click "Burn SD Card". After the process done,
I get a proper report prompted out. Now, I put the SD card into the USRP2 again,
and power it on, from serial port terminal, I get,

///////////////////////////////////////////////////////////////////////////

Tx dbid: 0x52
Rx dbid: 0x53

TxRx-NEWETH
00:50:C2:85:3B:15
ethernet flow control: NONE
Speed set to 1000

eth link changed: speed = 1000

///////////////////////////////////////////////////////////////////////////

Well, my WBX card is finally detected. However, when I tried to ping it again
with its default IP's 192.168.10.2, I still get no reply. From my 2960 switch,
I tried with "show mac-address-table", but Gi0/1 was not listed with USRP2's
MAC address (00:50:C2:85:3B:15). So, the USRP2 might not running IP stack at
all now. After some searching works, it seems I can use 2 tools of GNUradio
to find the USRP2 device. Let's install GNUradio,

# apt-get install gnuradio
.........
.........

# dpkg -l | grep gnuradio
......... 3.2.2
......... 3.2.2

Well, the installed version of GNUradio is 3.2.2. Let's assume the default
IP of USRP2 as 192.168.10.2, so, I set my ethernet interface as 192.168.10.1.
Then I run "find_usrps" and waiting for surprise. Again, I was still out of
luck, with the return message of,

eth0: SIOCGIFINDEX: No such device
No USRP2 found.

Wait, my ethernet interface is eth2, not eth0. I can change the scanning
interface of find_usrps with -e option. So, I run "find_usrps -e eth2" again.
Wow, I get this,

00:50:c2:85:3b:15 hw_rev = 0x0400

Then, I tried again with "usrp2_fft.py -e eth2", it work well also. Now, I
understand what's the meaning of "raw ethernet" as stated in the firmware
download page before. Let's check the ethernet packets with wireshark.
"find_usrps" completed with 2 packets interaction. The host send a broadcast
packet to the network as shown below,

0000  ff ff ff ff ff ff 00 0c  29 f6 c9 f4 be ef 00 00   ........ ).......
0010  00 00 00 00 f8 00 00 00  ff ff ff ff 01 04 00 00   ........ ........
0020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........

and the USRP2 reply the host with packet as shown below,

0000  00 0c 29 f6 c9 f4 00 50  c2 85 3b 15 be ef 00 00   ..)....P ..;.....
0010  00 00 00 00 f8 00 00 00  c6 01 95 19 81 2c 00 00   ........ .....,..
0020  00 50 c2 85 3b 15 04 00  00 00 00 00 00 00 00 00   .P..;... ........
0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0040  00 00 00 00 00 00 00 00  00 04 00 00 00 00 00 00   ........ ........

Well, ettus has redefine the ethernet type to "beef" instead of common type
such as "0800" for UDP. On the other hand, for "usrp2_fft.py -e eth2",
based on the result of packet analysis, it needs some interaction of
"configuration" phase to the USRP2, as show below,

(I only show the first 2 interaction steps of USRP2 configuration by host)


0000  00 50 c2 85 3b 15 00 0c  29 f6 c9 f4 be ef 00 00   .P..;... ).......
0010  00 00 00 00 f8 00 00 00  ff ff ff ff 07 04 00 00   ........ ........
0020  00 04 00 00                                        ....          


0000  00 0c 29 f6 c9 f4 00 50  c2 85 3b 15 be ef 00 00   ..)....P ..;.....
0010  00 00 00 00 f8 00 00 00  e7 f1 e1 ad 87 04 00 01   ........ ........
0020  00 04 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0040  00 00 00 00                                        ....          


0000  00 50 c2 85 3b 15 00 0c  29 f6 c9 f4 be ef 00 00   .P..;... ).......
0010  00 00 00 00 f8 00 00 00  ff ff ff ff 09 04 01 00   ........ ........
0020  00 04 00 00                                        ....          


0000  00 0c 29 f6 c9 f4 00 50  c2 85 3b 15 be ef 00 00   ..)....P ..;.....
0010  00 00 00 00 f8 00 00 00  e8 07 5d b3 89 3c 01 01   ........ ..]..<..
0020  00 00 00 52 00 00 41 90  ab 00 00 00 00 08 32 15   ...R..A. ......2.
0030  60 00 00 00 00 00 0c 80  00 0c 00 00 00 00 00 53   `....... .......S
0040  00 00 41 90 ab 00 00 00  00 08 32 15 60 00 00 00   ..A..... ..2.`...
0050  00 00 0f c0 00 40 00 00  00 04 00 00 00 00 00 00   .....@.. ........

After the "configuration" phase, the USRP will keep sending data, I believe
it is "measurement data" to the host continuously. I show one sample packet
here.

0000  00 0c 29 f6 c9 f4 00 50  c2 85 3b 15 be ef 00 00   ..)....P ..;.....
0010  00 00 00 00 00 00 00 00  ee 31 51 2e 00 00 00 00   ........ .1Q.....
0020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0040  00 00 00 00 00 01 00 00  00 01 00 01 00 00 00 00   ........ ........
0050  00 00 00 00 00 00 00 02  00 02 00 00 ff ff 00 02   ........ ........
0060  00 00 00 00 00 01 00 02  00 00 00 01 ff fe 00 00   ........ ........
0070  00 00 00 02 00 00 00 00  ff ff 00 00 00 00 00 00   ........ ........
0080  00 00 00 00 00 00 00 00  00 01 ff ff 00 00 00 03   ........ ........
0090  00 00 00 01 00 00 00 00  00 00 00 01 00 00 00 00   ........ ........
00a0  00 00 00 01 00 00 00 00  00 01 ff fe 00 00 00 00   ........ ........
00b0  00 01 00 00 ff ff 00 01  00 00 00 00 00 00 00 00   ........ ........
00c0  ff fd 00 00 00 00 ff ff  00 01 ff fe 00 00 00 00   ........ ........
00d0  ff ff 00 00 00 00 00 01  00 00 00 02 00 00 00 00   ........ ........
00e0  00 00 00 01 ff ff 00 00  00 01 00 00 00 00 00 00   ........ ........
00f0  00 00 00 01 00 00 00 01  00 00 00 00 00 00 00 01   ........ ........
0100  00 00 00 00 00 00 00 01  00 00 00 00 00 00 00 02   ........ ........
0110  ff ff ff ff 00 00 ff fd  00 00 00 00 00 00 00 00   ........ ........
0120  00 01 00 01 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 01   ........ ........
0140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 02   ........ ........
0150  ff ff 00 00 00 00 00 00  00 00 00 00 00 00 00 01   ........ ........
0160  00 00 00 01 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0170  00 00 00 01 ff ff 00 00  00 00 00 01 00 00 00 00   ........ ........
0180  00 00 00 00 00 00 00 02  00 00 00 00 00 00 ff ff   ........ ........
0190  00 01 00 00 ff ff 00 00  ff ff 00 00 00 00 00 00   ........ ........
01a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 ff ff   ........ ........
01b0  00 00 00 00 ff ff 00 00  00 00 00 00 00 00 00 00   ........ ........
01c0  00 00 00 00 00 01 ff ff  00 00 00 00 ff ff 00 00   ........ ........
01d0  00 01 00 00 00 00 00 01  ff ff 00 00 00 00 00 00   ........ ........
01e0  00 00 00 01 00 00 00 01  00 00 00 00 00 00 00 00   ........ ........
01f0  00 00 00 00 00 00 ff fd  00 00 ff ff 00 01 00 01   ........ ........
0200  ff ff 00 00 00 00 ff ff  00 00 ff ff 00 01 ff ff   ........ ........
0210  00 00 00 00 00 00 00 01  00 00 00 00 00 00 00 00   ........ ........
0220  00 00 ff ff 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0230  00 00 00 00 00 00 00 00  ff ff 00 00 00 00 00 00   ........ ........
0240  ff ff 00 01 00 00 00 00  00 01 00 00 00 00 00 00   ........ ........
0250  00 00 00 00 00 00 00 00  00 00 00 00 ff ff ff ff   ........ ........
0260  00 00 00 00 00 00 00 01  00 00 00 00 00 00 ff ff   ........ ........
0270  00 00 ff ff 00 00 00 00  00 00 00 00 00 00 ff ff   ........ ........
0280  00 00 00 00 00 01 ff fe  00 01 ff fe ff ff ff ff   ........ ........
0290  00 00 ff ff 00 00 ff ff  00 00 00 00 00 00 00 01   ........ ........
02a0  00 00 00 00 00 00 00 02  00 00 00 00 00 00 ff ff   ........ ........
02b0  00 00 ff fe 00 00 00 00  ff ff ff ff 00 00 00 00   ........ ........
02c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 01   ........ ........
02d0  ff ff ff ff 00 00 00 00  00 00 00 00 ff ff ff ff   ........ ........
02e0  00 00 00 00 00 00 00 01  00 00 00 00 00 00 00 00   ........ ........
02f0  00 00 00 01 00 00 00 00  00 00 00 00 00 01 00 00   ........ ........
0300  ff ff 00 00 00 00 00 00  00 00 ff ff 00 00 00 00   ........ ........
0310  00 00 00 00 ff ff ff ff  00 00 00 00 00 00 00 00   ........ ........
0320  00 00 ff ff 00 00 00 01  00 00 00 02 00 02 00 00   ........ ........
0330  00 00 00 00 00 00 00 00  00 00 00 01 00 00 ff fe   ........ ........
0340  ff ff ff fe ff ff 00 00  00 00 00 01 00 00 00 00   ........ ........
0350  00 00 00 00 ff ff 00 00  00 00 ff fe 00 00 00 00   ........ ........
0360  00 00 00 00 00 00 00 00  00 00 00 00 00 00 ff fe   ........ ........
0370  00 01 00 00 00 00 00 00  00 00 00 01 ff ff 00 00   ........ ........
0380  00 00 00 00 00 01 00 00  00 00 00 00 00 00 00 00   ........ ........
0390  00 00 00 01 00 00 00 01  00 00 00 00 00 00 00 01   ........ ........
03a0  00 00 ff fe ff ff 00 00  00 01 00 00 00 00 00 00   ........ ........
03b0  ff ff ff fe ff ff 00 00  00 01 00 00 00 00 00 00   ........ ........
03c0  00 00 ff ff 00 00 ff ff  00 02 00 01 00 00 00 01   ........ ........
03d0  00 01 00 01 00 00 00 01  00 00 ff ff ff ff 00 00   ........ ........
03e0  00 00 ff ff 00 00 00 00  00 00 00 01 00 00 00 01   ........ ........
03f0  00 00 00 00 00 00 00 00  ff fe ff ff ff fe ff ff   ........ ........
0400  00 00 00 02 00 00 00 01  ff fe 00 00 00 00 00 01   ........ ........
0410  00 01 00 01 00 00 00 00  ff ff 00 00 00 00 00 00   ........ ........
0420  00 00 00 02 00 00 00 00  00 01 00 00 00 00 00 00   ........ ........
0430  00 00 00 00 00 00 00 01  00 00 00 00 00 00 00 00   ........ ........
0440  00 00 00 00 00 01 00 00  ff ff ff ff 00 00 ff fe   ........ ........
0450  00 00 00 00 00 00 00 00  00 01 00 00 00 00 00 01   ........ ........
0460  00 00 ff ff 00 00 ff ff  00 00 00 00 00 00 00 00   ........ ........
0470  00 00 00 00 00 00 00 00  00 00 ff ff 00 00 00 01   ........ ........
0480  00 00 00 00 00 00 00 00  00 01 ff ff 00 01 00 02   ........ ........
0490  ff fe 00 01 00 00 00 00  00 01 00 00 00 00 00 00   ........ ........
04a0  00 00 00 00 00 00 00 00  ff ff ff ff 00 00 00 00   ........ ........
04b0  00 00 00 00 00 00 ff ff  00 00 00 00 00 00 ff ff   ........ ........
04c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 ff ff   ........ ........
04d0  00 00 ff fe 00 00 00 01  ff ff 00 03 ff ff ff fe   ........ ........
04e0  00 00 ff ff 00 00 00 00  00 00 00 00 ff fe 00 00   ........ ........
04f0  00 00 ff ff 00 00 ff ff  00 00 00 00 ff ff ff ff   ........ ........
0500  00 00 ff fd 00 00 00 00  00 00 ff fe 00 02 ff fe   ........ ........
0510  00 01 00 00 ff ff 00 00  00 00 00 00 00 00 00 00   ........ ........
0520  00 00 00 00 00 00 00 00  ff ff 00 01 00 00 00 01   ........ ........
0530  00 00 00 01 00 00 00 00  00 00 00 01 00 00 00 03   ........ ........
0540  00 00 00 01 ff ff 00 00  00 01 00 00 00 00 00 00   ........ ........
0550  00 00 00 00 00 00 ff ff  ff ff 00 00 00 00 00 00   ........ ........
0560  00 00 ff fe 00 00 00 00  00 00 00 00 ff ff ff fe   ........ ........
0570  00 00 ff ff 00 00 00 02  00 00 00 00 00 00 00 00   ........ ........
0580  00 00 00 00 00 00 ff ff  00 00 00 02 00 00 00 02   ........ ........
0590  ff ff ff ff 00 00 00 00  00 01 00 00 00 00 00 01   ........ ........
05a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 ff ff   ........ ........
05b0  00 00 ff ff 00 00 00 00  ff ff 00 00 ff fe ff ff   ........ ........
05c0  00 01 ff ff ff ff ff fe  00 02 ff ff 00 00 00 00   ........ ........
05d0  00 00 00 02 00 01 00 03  00 00 00 02 00 00 00 00   ........ ........
05e0  ff ff 00 00 00 00 00 00                            ........      

So, it seems I definitely cannot ping my USRP2 with its default IP of
192.168.10.2. It runs in raw ethernet. Then how I can ping it? I emailed
to ettus support. The answer is simple, I need to update my USRP2's FPGA and
firmware images into UHD version, which I can get it from,

http://files.ettus.com/binaries/uhd_stable/latest_release/

From the archive, I can see usrp2_fpga.bin and usrp2_fw.bin. So, I need to
update my SD card again. Besides, from the host side, I need to update the
driver and GNUradio also. Still got no time to work on it, but will do it
soon and update to this blog again.

pdf version:
http://www.scribd.com/doc/112331187/Why-I-Cannot-Ping-My-USRP2-With-192-168-10-2