пятница, 25 января 2013 г.

wincheck rc8.38

Download mirror
Changelog:
  • add checking of old mfc42 CRuntimeClasses in .data section
  • fixed bug in PE exports reader
  • add checking of AppHelp.dll encoded handlers in kernel32.dll. Sample of output:
    gApphelpGlobals: 1
     Apphelp.ApphelpCheckRunAppEx: c:\windows\system32\apphelp.dll (000007FEFDBF5B70)
     Apphelp.ApphelpQueryModuleDataEx: c:\windows\system32\apphelp.dll (000007FEFDC0A4A8)
     Apphelp.ApphelpCreateAppcompatData: c:\windows\system32\apphelp.dll (000007FEFDBF1090)
     Apphelp.SdbInitDatabaseEx: c:\windows\system32\apphelp.dll (000007FEFDBF5084)
     Apphelp.SdbReleaseDatabase: c:\windows\system32\apphelp.dll (000007FEFDBF4F10)
     Apphelp.SdbUnpackAppCompatData: c:\windows\system32\apphelp.dll (000007FEFDBFE540)
     Apphelp.SdbQueryContext: c:\windows\system32\apphelp.dll (000007FEFDBFD18C)
  • some other bugs were fixed

четверг, 17 января 2013 г.

bug in Malware and Rootkits Secrets and Solutions

Code from appendix of this book:
 pModuleList=ExAllocatePoolWithTag(NonPagedPool,bufsize,MY_TAG);
 //oops, out of memory...
 if (pModuleList == NULL)
 {
    DbgPrint("\nExamineDriverIrpTables():  [0] Out of memory.\n");
    return;
 }
 nt=ZwQuerySystemInformation(SystemModuleInformation,
                             pModuleList,
                             bufsize,
                             returnLength);
 if (nt != STATUS_SUCCESS)
 {
       DbgPrint("\nExamineDriverIrpTables():  [0] Error:
             ZwQuerySystemInformation() failed\n.");
       return;
 } 

Yeah, memory leak - when authors prepare for memory freeing if call to ZwQuerySystemInformation was unsuccessful ?

вторник, 15 января 2013 г.

hidden processes in wincheck log

It`s easy to make cross-scan of processes and threads from scheduler (run wincheck with -sched or -full options) and analyze produced log
Simple perl script for this tedious task:

понедельник, 14 января 2013 г.

пятница, 11 января 2013 г.

crashdmp.sys & CrashdmpCallTable

I noticed in cool presentation "Regaining Control of Your Disk in the Presence of Bootkits" that DriverEntry of crashdmp.sys has strange prototype:

  mov   ebx, [ebp+arg_4] ; DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath). Do we really write to RegistryPath here ?
  test  ebx, ebx
  cmp   dword ptr [ebx], 1
  jz    short loc_19038
  cmp   dword ptr [ebx+4], 4
  jz    short loc_19038

loc_19038:
  ...
  mov   dword ptr [ebx], 1
  mov   dword ptr [ebx+4], 4
  mov   dword ptr [ebx+8], offset _CrashdmpInitialize@16
  mov   dword ptr [ebx+0Ch], offset _CrashdmpLoadDumpStack@20
  mov   dword ptr [ebx+10h], offset _CrashdmpInitDumpStack@8
  mov   dword ptr [ebx+14h], offset _CrashdmpFreeDumpStack@4
  mov   dword ptr [ebx+18h], offset _CrashdmpDisable@0
  mov   dword ptr [ebx+1Ch], offset _CrashdmpNotify@12
  mov   dword ptr [ebx+20h], offset _CrashdmpWrite@8
  mov   dword ptr [ebx+24h], offset _CrashdmpUpdatePhysicalRange@4
  mov   dword ptr [ebx+28h], offset _CrashdmpResumeCapable@4
  mov   dword ptr [ebx+2Ch], offset _CrashdmpGetTransferSizes@8
  mov   dword ptr [ebx+30h], offset _CrashdmpLogStatusData@16
  mov   dword ptr [ebx+34h], offset _CrashdmpReady@0


Lets check crashdmp.sys loading mechanics in kernel:

ida 6.4

Changelog
[sarcasm mode on]
PC: added decoding of AVX, AVX2, FMA, BMI1, BMI2, F16C, ADX, RDSEED, SMAP, INVPCID, RTM x86 extensions
I just cant believe it, he-he

UI: moved to Qt 4.8.3
I foresee another bloody quest to build pyside in nearest couple of weeks (for example bcs pyside for qt 4.8.3 is still missed in IDA download center)

DWARF: detect and apply Dwarf debug info for ELF and Mach-O files
Why I don`t see mingw here ?

IDS: add IDT files for mfcNN.dll and msvcrNN.dll for VC9/10/11
Oh yeah baby, he-he

IDAPython: wrap obsolete IDA API functions too, so that old scripts continue to work
And there is still no support for functions from include\intel.hpp like x86_scale. Perhaps bcs this functions are not enough "obsolete", he-he

[sarcasm mode off]