bug in "The Algorithm Design Manual", Second Edition ?

Сitation from subchapter 8.7.2 When are Dynamic Programming Algorithms Efficient? on page 315:

Let LP' [i, j, S] denote the longest simple path from i to j, where the intermediate vertices on this path are exactly those in the subset S. Thus, if S = {a, b, c}, there are exactly six paths
consistent with S: iabcj, iacbj, ibacj, ibcaj, icabj, and icbaj. This state space is at most 2**n, and thus smaller than enumerating the paths

Wait, if this is exponent we must have 2 ** 3 = 8 paths. But actually this is factorial ! Why Skiena claims that this is exponent ?

WNF notifiers

It seems that windows 8 has some new (undocumented as usually) mechanism to call user-mode code from kernel - WNF
There are several new exported functions in ntdll.dll related to it:

• RtlAllocateWnfSerializationGroup
• RtlEqualWnfChangeStamps
• RtlPublishWnfStateData
• RtlQueryWnfMetaNotification
• RtlQueryWnfStateData
• RtlQueryWnfStateDataWithExplicitScope
• RtlRegisterForWnfMetaNotification
• RtlSubscribeWnfStateChangeNotification
• RtlTestAndPublishWnfStateData
• RtlUnsubscribeWnfNotificationWaitForCompletion
• RtlUnsubscribeWnfNotificationWithCompletionCallback
• RtlUnsubscribeWnfStateChangeNotification
• RtlWaitForWnfMetaNotification
• RtlWnfCompareChangeStamp
• RtlWnfDllUnloadCallback
• RtlpWnfNotificationThread - this one really called from kernel mode

Also several new functions in SSDT:

• NtWaitForWnfNotifications
• NtUnsubscribeWnfStateChange
• NtUpdateWnfStateData
• NtSubscribeWnfStateChange
• NtQueryWnfStateData
• NtQueryWnfStateNameInformation 
• NtDeleteWnfStateName
• NtDeleteWnfStateData
• NtCreateWnfStateName

I`ll describe here only user-mode structure which holds pointers to notifiers

wincheck rc8.24

Download
Changelog:

• update udis86 with lots of new intructions
• -k option now able to correctly kill "critical processes" (there are too many smarties around who use RtlSetProcessIsCritical)
• add dumping of debug port for each process
• add dumping of ntdll!g_dwLastErrorToBreakOn
• some bugs was fixed

AVX structure

It seems that AVX has crazy structure. Obvious first step is order on opcode byte. Then for each opcode we need yet 4 tables for pp. Next for 66 prefix we need yet 3 tables for 0f, 0f38 & 0f3a. And anyway we have ambiguity:

• for W field: vmovd - 128.W0 vs vmovq - 128.W1
• for vvvv field: vmovss - NDS.LIG.WIG vs vmovss - LIG.WIG
• for L field: vzeroall - 256.WIG vs vzeroupper - 128.WIG

Wrote simple perl script for instructions parsing and simple ordering

AVX instructions

List was ripped from "Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2". AMD extensions and instructions with XOP prefix are not included

Gray Hat Python

I have finished reading of this slim book and I am really disappointed:

• python sucks. The only reasons why I am still using it are NetworkX and PyKd
• CreateRemoteThread doesn`t work since vista times and I am sure this was known in 2009. Actually whole book is full of such little irritating things which just don`t work
• Immunity debugger & idapython were described very laconically
• PyEmu is sooooo sloooooow...

[sarcasm mode on]
Why we still don`t have excellent books like "gray hat assembler", "bloody and dirty perl" or "haskell quantum physics lean and mean for dummies in 24 hours" ?
[sarcasm mode off]

udis86 update

I added today support for tzcnt + new code page for 0f 7a opcodes from sse5a:

• frczps
• frczpd
• frczss
• frczsd
• cvtph2ps
• cvtps2ph
• phaddbw
• phaddbd
• phaddbq
• phaddwd
• phaddwq
• phadddq
• phaddubw
• phaddubd
• phaddubq
• phadduwd
• phadduwq
• phaddudq
• phsubbw
• phsubwd
• phsubdq

New version can be downloaded here