Minggu, 27 September 2009

6th Issue of BSD Magazine

The 6th issue of BSD Magazine is available now. This edition has several great articles. I liked Jan Stedehouder's article on Triple booting Windows 7, Ubuntu 9.04 and PC-BSD 7.1, Christian Brueffer's article on FreeBSD Security Event Auditing, and the Questions and Answer Session of the BSD Certification Group Community with Dru Lavigne and Mikel King.

I've been working with the editor at BSD Magazine to publish my articles on keeping FreeBSD up-to-date, so I expect to see them in print within the next few months.

Hakin9 Extended Edition in Stores

Hakin9 published an "extended edition" magazine recently. This "best of" issue is 218 pages long and contains a nice selection of past articles.

Although the writing isn't as uniformly smooth as one would find in the late, great Sys Admin magazine, I continue to find interesting articles in Hakin9. (By "smooth" I mean that articles written by non-native speakers tend to reflect that English isn't their first language. Hakin9 might consider hiring a native English copyeditor to rework articles prior to publication.)

There's really no other printed security periodical like Hakin9. The technical level is higher than that of 2600 magazine, for example. You don't find articles on security management like you might in Information Security Magazine or SC Magazine, either.

Rabu, 16 September 2009

Security Information and Event Management (SIEM) Position in GE-CIRT

My team just opened a position for a Security Information and Event Management professional. This candidate will report to me in GE-CIRT but take daily direction from our SIM leader and our Lead Incident Handler. We're looking for a technical person who can not only administer our SIM, but also help our team implement our detection and response objectives and use cases in our SIM and related infrastructure.

This candidate will sit in our new Advanced Manufacturing & Software Technology Center in Van Buren Township, Michigan.

If interested, search for job 1087025 at ge.com/careers or go to the job site to get to the search function a little faster. I am available to answer questions on the role or forward them to our SIM leader. You can reach me by posting a comment here and providing an email address where I can contact you. Thank you.

Kamis, 10 September 2009

Information Security Position in GE Aviation

My colleagues in GE Aviation are looking for a candidate for a client computing architect. The focus will be Microsoft Windows platforms. According to the hiring manager, the following are desired:

  • 50% leadership / 50% technical mix

  • Strong leadership, program management, and influence skills

  • Strong communication skills; the candidate will work with business and Corporate teams

  • Security and technical skills, such as a strong command of Windows features and defenses


If interested, search for job 1055733 at ge.com/careers or go to the job site to get to the search function a little faster. Please do not contact me directly. Thank you.

Open Source Vulnerability Disclosure with FreeBSD

The purpose of this post is not to bash Microsoft, but I am going to point out why I prefer relying on open source platforms, especially for sensitive systems. One of the advantages of the open source model is that anyone can identify and evaluate changes. This is especially true of open source projects like FreeBSD. Let's look at a recent security advisory in ntpd to demonstrate what I mean.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

=============================================================================
FreeBSD-SA-09:11.ntpd Security Advisory
The FreeBSD Project

Topic: ntpd stack-based buffer-overflow vulnerability

Category: contrib
Module: ntpd
Announced: 2009-06-10
Credits: Chris Ries
Affects: All supported versions of FreeBSD.
Corrected: 2009-06-10 10:31:11 UTC (RELENG_7, 7.2-STABLE)
2009-06-10 10:31:11 UTC (RELENG_7_2, 7.2-RELEASE-p1)
2009-06-10 10:31:11 UTC (RELENG_7_1, 7.1-RELEASE-p6)
2009-06-10 10:31:11 UTC (RELENG_6, 6.4-STABLE)
2009-06-10 10:31:11 UTC (RELENG_6_4, 6.4-RELEASE-p5)
2009-06-10 10:31:11 UTC (RELENG_6_3, 6.3-RELEASE-p11)
CVE Name: CVE-2009-1252

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit .

We very clearly see all affected FreeBSD versions which are not end of life.

I. Background

The ntpd(8) daemon is an implementation of the Network Time Protocol (NTP)
used to synchronize the time of a computer system to a reference time
source.

Autokey is a security model for authenticating Network Time Protocol
(NTP) servers to clients, using public key cryptography.

II. Problem Description

The ntpd(8) daemon is prone to a stack-based buffer-overflow when it is
configured to use the 'autokey' security model.

III. Impact

This issue could be exploited to execute arbitrary code in the context of
the service daemon, or crash the service daemon, causing denial-of-service
conditions.

The Background, Problem Description, and Impact are very clear.

IV. Workaround

Use IP based restrictions in ntpd(8) itself or in IP firewalls to
restrict which systems can send NTP packets to ntpd(8).

Note that systems will only be affected if they have the "autokey" option
set in /etc/ntp.conf; FreeBSD does not ship with a default ntp.conf file,
so will not be affected unless this option has been explicitly enabled by
the system administrator.

The workaround is NOT the "solution." Using an IP firewall does not make the FreeBSD "unaffected." The vulnerability is present with or without a firewall.

V. Solution

Perform one of the following:

1) Upgrade your vulnerable system to 6-STABLE, or 7-STABLE, or to the
RELENG_7_2, RELENG_7_1, RELENG_6_4, or RELENG_6_3 security branch
dated after the correction date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 6.3, 6.4,
7.1, and 7.2 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

[FreeBSD 6.3]
# fetch http://security.FreeBSD.org/patches/SA-09:11/ntpd63.patch
# fetch http://security.FreeBSD.org/patches/SA-09:11/ntpd63.patch.asc

[FreeBSD 6.4 and 7.x]
# fetch http://security.FreeBSD.org/patches/SA-09:11/ntpd.patch
# fetch http://security.FreeBSD.org/patches/SA-09:11/ntpd.patch.asc

b) Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/usr.sbin/ntp/ntpd
# make obj && make depend && make && make install
# /etc/rc.d/ntpd restart

VI. Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

CVS:

Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_6
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.8.3
RELENG_6_4
src/UPDATING 1.416.2.40.2.9
src/sys/conf/newvers.sh 1.69.2.18.2.11
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.8.1.2.2
RELENG_6_3
src/UPDATING 1.416.2.37.2.16
src/sys/conf/newvers.sh 1.69.2.15.2.15
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.20.2
RELENG_7
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.18.3
RELENG_7_2
src/UPDATING 1.507.2.23.2.4
src/sys/conf/newvers.sh 1.72.2.11.2.5
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.18.2.2.1
RELENG_7_1
src/UPDATING 1.507.2.13.2.9
src/sys/conf/newvers.sh 1.72.2.9.2.10
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.18.1.2.2
- -------------------------------------------------------------------------

Subversion:

Branch/path Revision
- -------------------------------------------------------------------------
stable/6/ r193893
releng/6.4/ r193893
releng/6.3/ r193893
stable/7/ r193893
releng/7.2/ r193893
releng/7.1/ r193893
- -------------------------------------------------------------------------

Administrators and users have multiple options to fix the system. Not listed is using FreeBSD Update to perform a binary update, which I personally prefer. Furthermore, using this information, we can determine exactly what the problem is.

First, we can download http://security.freebsd.org/patches/SA-09:11/ntpd.patch and see the patch itself in clear text.

Second, we can visit the http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/ntp/ntpd/ntp_crypto.c CVS tree for ntp_crypto.c to find the vulnerable code. We can then review changes between vulnerable and patched versions ourselves.

VII. References

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1252

The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-09:11.ntpd.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEARECAAYFAkovjOwACgkQFdaIBMps37KRpwCfaQF9q8KhElv6LqgFv3DX2h9c
hbEAn2Q0X8Qv8r5OySnhlAw2pMxlxkXK
=Mh2u
-----END PGP SIGNATURE-----

Overall, I prefer this level of transparency. If you think that exposing this level of information is "bad for security," consider the following.

  1. First class intruders know about vulnerabilities before anyone else because they are constantly performing funded research to find them. They produce and test their own exploits.

  2. Second class intruders only need a hint to direct their resources towards identifying vulnerabilities. In other words, once they hear of a weakness in a protocol or service, they swing their attention to that target and develop exploits. They produce and test their own exploits.

  3. Third class intruders know how to reverse engineer vulnerabilities from binary patches released by the vendor. They produce and test their own exploits.

  4. Fourth class intruders use exploits leaked from higher classes to determine if systems are vulnerable. They test others' exploits.

  5. Administrators without Blue and Red teaming capabilities have to trust that the vendor is honest and competent. They can't test anything so they don't know if they are really vulnerable or not, pre- or post-patch.


So, keeping source code hidden only really hinders fourth class intruders to a certain degree, and it definitely hinders administrators who lack Blue and Red capabilities.

Microsoft Updates MS09-048 to Show XP Vulnerable to 2 of 3 CVEs

Microsoft published a Major Revision of MS09-048 to show that Windows XP Service Pack 2 and Windows XP Service Pack 3* are now Affected Software.

This is an important development. It is significant to acknowledge that an operating system is vulnerable despite the potential to add a countermeasure. In other words, countermeasures do not remove vulnerabilities.

The company also updated the FAQ:

If Windows XP is listed as an affected product, why is Microsoft not issuing an update for it?

By default, Windows XP Service Pack 2, Windows XP Service Pack 3, and Windows XP Professional x64 Edition Service Pack 2 do not have a listening service configured in the client firewall and are therefore not affected by this vulnerability. The denial of service attacks require a sustained flood of specially crafted TCP packets, and the system will recover once the flood ceases. This makes the severity rating Low for Windows XP. Additionally, Windows XP Service Pack 2 and later operating systems include a stateful host firewall that provides protection for computers against incoming traffic from the Internet or from neighboring network devices on a private network.

Windows XP is not affected by CVE-2009-1925.


As you can see, Microsoft is sticking with the "firewall" defense (and they forgot to remove the "not affected by this vulnerability" language from version 1.0 of the bulletin. This is still not acceptable.

Microsoft did clarify that CVE-2009-1925, TCP/IP Timestamps Code Execution Vulnerability, does not apply to Windows XP. That is good news.

So, what can you do? I would like to hear from anyone who is testing XP SP2 or SP3 for TCP/IP Zero Window Size Vulnerability - CVE-2008-4609 and TCP/IP Orphaned Connections Vulnerability - CVE-2009-1926. How does XP respond? Thus far @jkrage mentioned blue screens for the two DoS conditions. Can anyone else reproduce this? If yes, how?

Thank you.

Rabu, 09 September 2009

MS09-048 on Windows XP: Too Hard to Fix

This is a follow-up to MS09-048 is Microsoft's Revenge Against XP in the Enterprise. Everyone is talking about how Windows 2000 will not receive a patch for MS09-048:

If Microsoft Windows 2000 Service Pack 4 is listed as an affected product, why is Microsoft not issuing an update for it?

The architecture to properly support TCP/IP protection does not exist on Microsoft Windows 2000 systems, making it infeasible to build the fix for Microsoft Windows 2000 Service Pack 4 to eliminate the vulnerability. To do so would require rearchitecting a very significant amount of the Microsoft Windows 2000 Service Pack 4 operating system, not just the affected component. The product of such a rearchitecture effort would be sufficiently incompatible with Microsoft Windows 2000 Service Pack 4 that there would be no assurance that applications designed to run on Microsoft Windows 2000 Service Pack 4 would continue to operate on the updated system.


Let's think about that for a minute. Vista's TCP/IP stack is the Next Generation TCP/IP Stack. This means XP shares at least some of the TCP/IP stack of Windows 2000. Microsoft (as noted in my last post) didn't patch XP because it said the client firewall mitigated the problem, as long as you don't expose any ports -- not because XP is invulnerable. From what we can gather, XP is at least vulnerable to the two DoS flaws (TCP/IP Zero Window Size Vulnerability - CVE-2008-4609 and TCP/IP Orphaned Connections Vulnerability - CVE-2009-1926).

In other words, patching Windows XP is also architecturally "infeasible."

This appears to be more than a theory. Just about the only straight answer I could get from a Microsoft rep this evening was the answer that MS09-048 is too hard to fix on XP, just like it was too hard to fix on 2000.

I think it's time to tell Microsoft this situation is not acceptable.

MS09-048 is Microsoft's Revenge Against XP in the Enterprise

MS09-048 worries me.


Non-Affected Software

Operating System

Windows XP Service Pack 2 and Windows XP Service Pack 3*

How are default configurations of Windows XP not affected by this vulnerability?

By default, Windows XP Service Pack 2, Windows XP Service Pack 3, and Windows XP Professional x64 Edition Service Pack 2 do not have a listening service configured in the client firewall and are therefore not affected by this vulnerability. For the denial of service to succeed, an affected system must have a listening service with an exception in the client firewall. Windows XP Service Pack 2 and later operating systems include a stateful host firewall that provides protection for computers against incoming traffic from the Internet or from neighboring network devices on a private network.


Someone please tell me I am misinterpreting this. It looks to me like this is bad news for the enterprise that operates any listening services on their Windows XP systems. Oh, I don't know, maybe something like Microsoft SMB/CIFS? In other words, if you expose a service within the enterprise, and you allow other systems to connect to it, then you are vulnerable to MS09-048 -- and Microsoft isn't publishing a patch for XP SP2 or XP SP3?

What's worse is that I can't tell if XP SP2 or SP3 is vulnerable to this vulnerability in MS09-048:


TCP/IP Timestamps Code Execution Vulnerability - CVE-2009-1925

A remote code execution vulnerability exists in the Windows TCP/IP stack due to the TCP/IP stack not cleaning up state information correctly. This causes the TCP/IP stack to reference a field as a function pointer when it actually contains other information. An anonymous attacker could exploit the vulnerability by sending specially crafted TCP/IP packets to a computer that has a service listening over the network. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.


So, at best we have an unpatched vulnerability that lets anyone in the enterprise remotely crash any XP SP2 and XP SP3 system with at least one listening service (139, 445 TCP) that the attacker can reach. At worst we have an unpatched vulnerability that lets anyone in the enterprise remotely exploit any XP SP2 and XP SP3 system with at least one listening service (139, 445 TCP) that the attacker can reach.

Does anyone know if TCP/IP Timestamps Code Execution Vulnerability - CVE-2009-1925 applies to XP SP2 or XP3?

Incidentally, running Microsoft Update on a Windows XP SP3 system does not show a patch for MS09-048 as available.

Senin, 07 September 2009

The Network Monitor API: Part II

The LoadCapAndFilter example from Network Monitor Examples from Codeplex allows you to specify a particular filter from Network Monitor API. Some fragments from the code are below. Note how the string is escaped (e.g. \"GET\") :

[LoadCapAndFilter.cpp]
/Add filter
ret = NmAddFilter(myFrameParserConfig, L"http.request.command == \"GET\"", &myHTTPFilterID);
...
//Add field
ret = NmAddField(myFrameParserConfig, L"http.request.uri", &myHTTPFieldID);
....
// Obtain the value of http.request.uri from frame. We
// know that strings are passed as word pointer to unicode string in the variant.
..
ret = NmGetFieldValueString(myParsedFrame, myHTTPFieldID, 256, (LPWSTR)value);

Sample output:

LoadCapAndFilerHTTP.exe Miscellaneous_001.cap
sparser.npb:001.000 Successfully unserialized NPL parser 'C:\Users\Admin\AppData\Local\Microsoft\Network Monitor 3\sparser.npb.
Frame 14: HTTP: /crls/globalca1.crl
Frame 100: HTTP: /crls/globalca1.crl
Frame 227: HTTP: /crls/globalca1.crl
Frame 547: HTTP: /crls/globalca1.crl
....

I can modify the LoadCapAndFilter Network Monitor example to parse as needed. For example, Microsoft has a global load balacer that it contacts both before and after secondary authorization for Wireless Network Connections. It functions by contacting http://nssi.glbdns.microsoft.com/ncsi.txt and checking to see is a successful http request is returned. If it can't do so, the returned payload shows no http status code:

HTTP HTTP:Response, HTTP/1.0, Status Code = , URL: /ncsi.txt

If it gets a hit, this request shows:

HTTP:Response, HTTP/1.1, Status Code = 200, URL: /ncsi.txt

By changing the top code to (far) below, I can cycle through all my wireless sniffs to see how many times my Vista laptop tries to get: http://nssi.glbdns.microsoft.com/ncsi.txt with :

for /f %i in ('dir /b *.cap') do LoadCapAndFilterGet_NCSI.exe %i

[output]:
LoadCapAndFilterGet_NCSI.exe Test.cap
sparser.npb:001.000 Successfully unserialized NPL parser 'C:\Users\Admin\AppData\Local\Microsoft\Network Monitor 3\sparser.npb.
Frame 8012: HTTP: /ncsi.txt
Frame 8452: HTTP: /ncsi.txt
Frame 8815: HTTP: /ncsi.txt
Frame 9178: HTTP: /ncsi.txt
Frame 9560: HTTP: /ncsi.txt
...

[LoadCapAndFilterGETNCSI.cpp]:

//Add filter
ret = NmAddFilter(myFrameParserConfig, L"HTTP.Request.URI == \"/ncsi.txt\"", &myHTTPFilterID);
...
//Add field
ret = NmAddField(myFrameParserConfig, L"http.request.uri", &myHTTPFieldID);
....


Another example:

This code ...


//Add filter
ret = NmAddFilter(myFrameParserConfig, L"TCP.Port == 443", &myHTTPFilterID);
if(ret != ERROR_SUCCESS)
{
wprintf(L"Fail to load Add fitler, error: \n", ret);
}

//Add field
ret = NmAddField(myFrameParserConfig, L"SSL.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.ClientHello.Extns.ClientHelloExtension.ServerNameList.ServerName", &myHTTPFieldID);
if(ret != ERROR_SUCCESS)
{
wprintf(L"Fail to load Add field, error: \n", ret);
}

produces this output:

C:\Users\Admin\Documents\Network Monitor 3\Captures>LoadCapAndFilterTCP001.exe Test.cap
sparser.npb:001.000 Successfully unserialized NPL parser 'C:\Users\Admin\AppData\Local\Microsoft\Network Monitor 3\sparser.npb.
Frame 7160: TCP443: www.google.com
Frame 16097: TCP443: signin.evri.com
Frame 16341: TCP443: signin.evri.com
Frame 16577: TCP443: www.connect.facebook.com
Frame 16591: TCP443: www.connect.facebook.com
Frame 16599: TCP443: www.connect.facebook.com
Frame 16631: TCP443: www.connect.facebook.com

..

To make LoadCapAndFilter work, the correct return types for NMGetFieldValue must be assigned. I had quite a few problems making other queries work, seemingly because of this.


// Obtain the value of http.request.uri from frame. We
// know that strings are passed as word pointer to unicode string in the variant.
WCHAR value[256];
ret = NmGetFieldValueString(myParsedFrame, myHTTPFieldID, 256, (LPWSTR)value);
if(ret == ERROR_SUCCESS

Review of Windows Forensic Analysis 2nd Ed Posted

Amazon.com just published my five star review of Windows Forensic Analysis, 2nd Ed by Harlan Carvey. From the review:

I read and reviewed the 1st Ed of this book in July 2007, and I just finished reading Windows Forensic Analysis 2nd Ed (WFA2E) this weekend. If your job involves investigating Windows systems, you must read this book. It's as simple as that. There is no substitute for this book. It also perfectly complements other solid forensics works already published.

Great work again, Harlan!

Bejtlich Speaking at Information Security Summit

My boss Grady Summers, GE CISO, and I will be presenting one of the keynotes at the Information Security Summit, 29-30 October, in Warrensville Heights, Ohio. Our topic is "CISO + CIRT = Success."

In 2007, the CISO of General Electric decided to invest in a dedicated program to detect and respond to intrusions, as a centralized, global function within GE. Since then, GE has built a Computer Incident Response Team (CIRT), deployed dozens of sensors acorss the company, aggregated billions of log records, and institutionalized its detection and response processes. In this presentation, the CISO of GE (Grady Summers) and GE's Director of Incident Response (Richard Bejtlich) will describe their experience with this process.

I am really excited about the pre-conference training at this event. I will participate in Introduction to Malware Dissection by Tyler Hudak, GE-CIRT's reverse engineer. This is a two day course for less than $500. You cannot beat the quality of this training at that price, period!

You can follow @Summit2009 for updates on the conference.

Bejtlich Speaking at DojoCon

I will be presenting one of the keynotes at DojoCon, 6-7 November in Maryland. This should be a good event. Follow @dojocon for updates. Marcus Carey is organizing it.

Jumat, 04 September 2009

Extreme Asymmetry in Network Attack and Defense

As usual, Gunter Ollmann posted a great story on the Damballa blog titled Want to rent an 80-120k DDoS Botnet? He writes:

[T]his particular operator is offering a botnet of between 80k and 120k hosts capable of launching DDoS attacks of 10-100Gbps – which is more than enough to take out practically any popular site on the Internet. The price for this service? $200 per 24 hours – oh, and there’s a 3 minute try-before-you-buy.

Someone please tell me how much it costs to provision equipment and services sufficient to sustain network operations during a 10-100 Gbps DDoS attack. I bet it is much more than $200 per day. This extreme level of asymmetry demonstrates another reason why intruders have the upper hand in network attack and defense.

Situations like this remind me that an insurance model might work. Insurance works when many contribute but few suffer simultaneous disasters. Perhaps organizations could buy insurance policies to cover losses due to DDoS, rather than provision for the disaster? Or do organizations already do that? I know some work with companies like Prolexic specifically to mitigate DDoS, but how about with insurers?

Kamis, 03 September 2009

Registration for VizSec 2009 Open

The program for VizSec 09 has been posted. It looks like a great event. I served on the program committee. Bill Cheswick's keynote looks excellent. I'm not sure if I will be attending or not, but check it out if you're looking for ways to integrate visualization into your security operations. I am most interested in 1) handling large data sets and 2) visualizing something other than layer 3 and 4 information.

Selasa, 01 September 2009

The NetworkMonitor API: Part I

I've spent the last three weeks building the Network Monitor Examples from Codeplex: http://nmexperts.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=27988. Sniffers have been pretty black box to me before this project. I was prompted to do this because Network Monitor 3.3 on 64 bit systems doesn't produce captures that can be analyzed by logparser.exe. This is good and bad. Logparser only dumped out 20 fields from netmon *.cap files. Despite the struggle, it was worth installing the latest versions (VS2008, VS2009 Express ), configuring VS C++ to work with the WDDK and the Netmon API and compiling the examples on both 32 and 64 bit systems. Microsoft has released the Netmon SDK and API to the web at codeplex.com. Network Monitor itself is a free download and the lib and header files come along for the ride. Open Parsers are part of the project, allowing the coder to create his own parsers; filters; experts.

The samples allow you to build open, close, save, filter and parse captures files and parsers. Some examples are below. This project is best done by someone unafraid of Visual Studio and the WDDK.

IterateFields.exe Test.cap 500
sparser.npb:001.000 Successfully unserialized NPL parser 'C:\Users\Admin\AppData\Local\Microsoft\Network Monitor 3\sparser.npb.
Iterate the fields of frame #500
Frame.WiFi (WiFi) - Offset: 0, Size: 1536
WiFi.WiFi.MetaData (WiFiMetadata) - Offset: 0, Size: 32
WiFi.WiFi.MetaData.Version (UINT8) - Offset: 0, Size: 1
WiFi.WiFi.MetaData.Length (UINT16) - Offset: 1, Size: 2
WiFi.WiFi.MetaData.OpMode (UINT32) - Offset: 3, Size: 4
WiFi.WiFi.MetaData.OpMode.StationMode (UINT32) - Offset: 3, Size: 0
WiFi.WiFi.MetaData.OpMode.APMode (UINT32) - Offset: 3, Size: 0
WiFi.WiFi.MetaData.OpMode.ExtensibleStationMode (UINT32) - Offset: 3, Size: 0
WiFi.WiFi.MetaData.OpMode.Unused (UINT32) - Offset: 3, Size: 3
WiFi.WiFi.MetaData.OpMode.MonitorMode (UINT32) - Offset: 6, Size: 0
WiFi.WiFi.MetaData.Flags (UINT32) - Offset: 7, Size: 4
WiFi.WiFi.MetaData.PhyType (UINT32) - Offset: 11, Size: 4
WiFi.WiFi.MetaData.Channel (UINT32) - Offset: 15, Size: 4
WiFi.WiFi.MetaData.lRSSI (INT32) - Offset: 19, Size: 4
WiFi.WiFi.MetaData.Rate (UINT8) - Offset: 23, Size: 1
WiFi.WiFi.MetaData.TimeStamp (FILETIME) - Offset: 24, Size: 8 ....

IterateFieldsWithDisplayFormat.exe Test.cap 500
sparser.npb:001.000 Successfully unserialized NPL parser 'C:\Users\Admin\AppData\Local\Microsoft\Network Monitor 3\sparser.npb.
Iterate the fields of frame #500
Field count = 92
WiFi: [Unencrypted Data] .T...., (I)

Error 1168 tryin to retreive display name for frame 499 element 1. Version: 2 (0x2)
Length: 32 (0x20)
OpMode: Extensible Station Mode
StationMode: (...............................0) Not Station Mode
APMode: (..............................0.) Not AP Mode
ExtensibleStationMode: (.............................1..) Extensible Station Mode
Unused: (.0000000000000000000000000000...)
MonitorMode: (0...............................) Monitor Mode
Flags: 4294967295 (0xFFFFFFFF)
RemData: Outbound
TimeStamp: 08/18/2009, 05:41:19 PM

FrameControl: .T.... (0x0801)
Version: (..............00) 0
Type: (............10..) Data
SubType: (........0000....) Data
DS: (......01........) STA to DS via AP
MoreFrag: (.....0..........) No
Retransmission: (....0...........) No
PowerMgt: (...0............) Active Mode
MoreData: (..0.............) No
Encrypted: (.0..............) No
Order: (0...............) Unordered....

GetFrameComments 100secwithComments.cap
Frame 1 Comment Info:
TitleByteLength: 34, Title: Test Comment 001
DescriptionByteLength: 137, Description: {\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fcharset0 MS Shell D
\viewkind4\uc1\pard\f0\fs17 testing...\par
}

Frame 2 has no comment info
Frame 3 has no comment info
Frame 4 has no comment info
Frame 5 has no comment info....