Archive

Posts Tagged ‘Windows’

Analysis of Conficker

February 21st, 2009

SRI have done a very comprehensive and indepth analysis of Conficker including the latest variant boasting fun new features.

Great read, I highly recommend it if stuff like this interests you (malware development, windows internals, reversing malware, etc):

Click here for epix (and the analysis)

Programming, Reverse Engineering, Security, Windows , , , ,

Object Creation. How and where.

February 21st, 2009

This seems to be something that confuses a lot of newbies so I’m going to take the time to explain it properly here.

‘Inspiration’: Example

First off. PE Files. Although we can ignore most of the details of the PE file format for the purposes of this there are still some basics that are important. A PE file has ’sections’. One of those sections is ‘.text’, this is typically where code is stored. Another we need to know about is ‘.data’, this is typically where global variables are stored. The last we need to know about is ‘.rdata’, this is typically where global constants, hardcoded strings, floating point constants, etc are stored.

Nitpicker’s Corner: I said “typically” because packers often abuse intricacies of the PE file format which are irrelevant for this discussion in order to avoid the use of these standard sections and confuses disassemblers and debuggers. I am dealing ONLY with regular PE files created by regular compilers such as MSVC++, Intel, etc.

Second. The stack and the heap. The stack is a LIFO (Last In First Out) data structure typically used for things like passing parameters to functions, temporarily saving or “pushing” values stored in registers to be restored or “popped” back later, storing local variables, saving function return addresses, etc. All threads typically have their own ’stack’ to manage. The heap is a ‘pool’ of dynamically allocated memory typically used to store objects which are dynamically allocated at runtime because there size or other details cannot be known at run time. For more info on either of these subjects please consult any book on computer science, or wikipedia.

Nitpicker’s Corner: I am referring only to the stack/heap structures/concepts in terms of their relevance to this discussion and only the implementations which I have outlined. I am aware that the “stack” is also a common data type.

The following is a “typical” C++ application.

Nitpicker’s Corner: Typical in the sense in which objects are created  in multiple fashions ane the application uses fairly standard C++ concepts.

Nitpicker’s Corner: Application is obviously not thread-safe due to lack of serialization on global objects.

#include <iostream>
#include <string>

std::string MyGlobalString(”Foobar”);
std::string* pMyOtherGlobalString = new std::string(”Foobar2″);

std::string& GetStaticString()
{
static std::string MyStaticString(”Foobar3″);
return MyStaticString;
}

void MyStringSub()
{
std::string MyStackString(”Foobar4″):
std::string* pMyHeapString(”Foobar5″);
// Do something here
}

int main()
{
std::cout << MyGlobalString << *pMyOtherGlobalString
<< GetStaticString() << std::endl;
return 0;
}

Now the question is, which objects are stored where?

MyGlobalString will typically be stored in the ‘.data’ section becaues it is a global object.

pMyGlobalString will typically be stored in the heap, but a pointer to it will be kept in the ‘.data’ section, again because it is a global object.

MyStaticString will typically be stored in the ‘.data’ section because it is also a ‘global’ object. Whats that you say? Its not a global? Well by defining it ’static’ we technically are defining it as ‘global’. Static objects are created when the program first runs and not destroyed until the program quits, they are effectively globals as far as the compiler is concerned, the only differences are at the higher language level. The differences at the lower level are negligible.

MyStackString will be stored on the stack because it is local to a function.

pMyHeapString will be stored in the heap but the pointer to it will be stored in the stack because it is local to a function.

What is interesting though is where all the strings like “Foobar1″, “Foobar2″ etc are stored. They are NOT stored in the ‘.data’ section with our string objects. Hardcoded C-style strings will typically be stored and referenced through the ‘.rdata’ section. This is because std::string objects are created at runtime but the underlying c-style string needs to be stored somewhere. This “somewhere” is usually ‘.rdata’ because the section is designed for constants and will typically be paged as read-only when in memory. Our hard-coded strings never need to be changed so this is the perfect spot to put them.

Programming, Reverse Engineering, Windows , , ,

Module Cloaker

February 13th, 2009

Slight delay on the WoW related post I’m sorry (personal reasons). But in the meantime I figured I may as well post something else which I had already finished.

This is the source code to my module cloaker. The idea is to attempt to hide the presence of a DLL in an exe. My implementation is designed for use in a usermode rootkit (which is my current project) but it is half-way to being complete for use in anti-anti-cheat code (you will need to fix the weaknesses described in the comments along with a bunch of other stuff — also, by complete I mean ‘complete as possible’, there are some things you just can’t disguise at this level).

Documentation, credits, etc. is all in the source code (sorry but I’m too lazy to copy/paste it here :p):

Download

32-bit only, but a 64-bit version will most likely be coming in the not-too-distant future when I port my usermode rootkit code to x64.

Would love to hear suggestions/criticisms/etc.

Update: Sorry. Fixed link. I forgot to include a header the first time.

Update 2: Just wanted to point out, sorry for the retarded namespace name, its just to avoid collisions.

Reverse Engineering, Windows , ,

File Hiding

February 9th, 2009

I’ve just implemented the first beta of the file hiding feature for my rootkit. As usual, I’ve attached a screenshot:

Usermode Rootkit File Stealth

As you can see, any files with the prefix “__PJB_F” are hidden from view. I’ve implemented it by hooking NtQueryDirectoryFile. Tested and working on both Vista and XP with only minor bugs (which should be smoothed out soon). Once I’ve smoothed out most of the bugs in the project I’m hoping to release portions of the source so if you’re waiting on that then stay tuned, I’ll have more information in the near future.

P.S. WoW related post incoming in the next few days probably.

Reverse Engineering, Windows , ,

Selective Infection

February 7th, 2009

Hey, thought I’d post another progress update on my usermode rootkit project. Mostly it’s bug fixes and stability fixes (no more crashes! yay!). But I’ve also added three new things.

1. Process hiding by name. If the process name starts with “__PJB_H_” it will be cloaked.

2. Selective infection. If the process name starts with “__PJB_S_” it will not be infected and hence will be able to see the system in an uncloaked state.

3. Module stealth. Rather than hook APIs to hide my modules in the processes I inject into I’m manually unlinking it from the linked lists, then nulling out the entire LDR_MODULE structure, and also nulling out the entire PE header.

I’ve attached a screenshot to show off the latest features. To make it easier I’ve put colour coded boxes around what I want to draw attention to.

Latest Rootkit Revision

Purple: My test applications to hide from the system. Just CMD and Wordpad. (I blocked out my username on CMD because I used my full name, whoops. :P)

Blue: The rootkit bootstrapper and the DLL that is injected into processes to do all the dirty work.

Yellow: Process Explorer. Kinda like Task Manager on crack. I used that rather than taskmgr for two reasons. First and foremost is that it’s a lot more powerful and so much more useful when testing my code. Second is that taskmgr won’t open multiple windows unless you hack it to do so. The copy on the left is the ‘clean’ one, the one on the right is the ‘regular’ (infected) one. Sorry, they’re backwards to the placement on the desktop, didn’t notice until now and I’m too lazy to take a new screenshot. You will see that the clean process can see the two test apps yet the infected process can not.

Red: As stated above, the copy of Process Explorer with the window on the left can see our test processes because it has been ignored by the rootkit, the regular copy on the other hand is unaware of the presence of the two processes.

Orange: Both copies of Process Explorer have Explorer.exe highlighted. Because API hooks are not being used and the module is cloaking itself upon being injected the module is invisible even to the ‘clean’ copy of Process Explorer. If I were to disable module cloaking __PJB_x86.dll would appear at the top of both those lists. If I were to modify the cloaking to a less stealthy variant (ie using API hooks), although it would normally mean the clean process would be able to see the module and the infected one wouldn’t it isn’t hard to manually traverse the list and look for the module manually so I decided to go for a more ‘permanent’ but also more stealthy approach.

Whats next? A few extra hooks to increase the security of the process hiding, then I’m moving on to hiding files. I’ve decided rather than doing x64 support incrementally I’ll just finish 80-95% of the x86 code first so I can port most of it across at once.

Update: Whoops, forgot the screenshot. Fixed!

Reverse Engineering, Windows , ,

Process Hiding from Usermode

February 7th, 2009

Hey, just wanted to post a screenshot from the usermode rootkit I’m working on showing off the first ‘proper’ feature of the x86 build. Hiding processes.

Hiding processes from usermode

Sorry about the low quality screenshot (JPEGs suck but PNGs are huge). If you want a higher res screenshot please this link.

Hoping to get the code ported to x64 builds of Windows when the x86 builds are stable. All the code is in usermode so it shouldn’t be too difficult.

Reverse Engineering, Windows , ,

API Changes in Windows 7

February 1st, 2009

I recently installed the Windows 7 x64 public beta and was having a look for API changes. I have gone through ntdll.dll, kernel32.dll, and user32.dll from the syswow64 folder (I know IA-32 ASM better than AMD64) and compared all the exports to those from Windows Server 2008 in order to pull out any changes. I figured this would be of use to curious people (like me) who are also lazy (like me). The results are posted below.

The lists include both new and new apis, and ones that  have been modified slightly (ie the kernel32.dll calls that are forwarded). 

Kernel32:

AddIntegrityLabelToBoundaryDescriptor

BaseCheckAppcompatCacheEx

BaseDllReadWriteIniFile

BaseFormatObjectAttributes

BaseFormatTimeOut

BaseGetNamedObjectDirectory

BaseSetLastNTError

BaseVerifyUnicodeString

Basep8BitStringToDynamicUnicodeString

BasepAllocateActivationContextActivationBlock

BasepAnsiStringToDynamicUnicodeString

BasepFreeActivationContextActivationBlock

BasepIsRealtimeAllowed

BasepMapModuleHandle

CallbackMayRunLong

CallbackMayRunLong (forwarded to NTDLL.TpCallbackMayRunLong)

CopyExtendedContext

CreateRemoteThreadEx (forwarded to Microsoft-Windows-System-Process-ProcessThreads-L1-1-0.CreateRemoteThreadEx)

DeleteProcThreadAttributeList

DeleteProcThreadAttributeList (forwarded to Microsoft-Windows-System-Process-ProcessThreads-L1-1-0.DeleteProcThreadAttributeList)

FindStringOrdinal

GetActiveProcessorCount

GetActiveProcessorGroupCount

GetCPFileNameFromRegistry

GetCurrentProcessorNumber (forwarded to NTDLL.NtGetCurrentProcessorNumber)

GetCurrentProcessorNumber (forwarded to NTDLL.RtlGetCurrentProcessorNumber)

GetCurrentProcessorNumberEx (forwarded to NTDLL.RtlGetCurrentProcessorNumberEx)

GetEnabledExtendedFeatures (forwarded to MICROSOFT-WINDOWS-SYSTEM-XSTATE-L1-1-0.RtlGetEnabledExtendedFeatures)

GetEraNameCountedString

GetExtendedContextLength (forwarded to MICROSOFT-WINDOWS-SYSTEM-XSTATE-L1-1-0.RtlGetExtendedContextLength)

GetExtendedFeaturesMask (forwarded to MICROSOFT-WINDOWS-SYSTEM-XSTATE-L1-1-0.RtlGetExtendedFeaturesMask)

GetLogicalProcessorInformationEx (forwarded to Microsoft-Windows-System-SysInfo-L1-1-0.GetLogicalProcessorInformationEx)

GetMaximumProcessorCount

GetMaximumProcessorGroupCount

GetNumaAvailableMemoryNodeEx

GetNumaNodeNumberFromHandle

GetNumaNodeProcessorMaskEx

GetNumaProcessorNodeEx

GetNumaProximityNodeEx

GetProcessGroupAffinity

GetProcessPreferredUILanguages

GetProcessorSystemCycleTime

GetSystemInfoInternal

GetThreadErrorMode

GetThreadGroupAffinity

GetThreadIdealProcessorEx

InitializeExtendedContext

InitializeProcThreadAttributeList

InitializeProcThreadAttributeList (forwarded to Microsoft-Windows-System-Process-ProcessThreads-L1-1-0.InitializeProcThreadAttributeList)

K32EmptyWorkingSet

K32EnumDeviceDrivers

K32EnumPageFilesA

K32EnumPageFilesW

K32EnumProcessModules

K32EnumProcessModulesEx

K32EnumProcesses

K32GetDeviceDriverBaseNameA

K32GetDeviceDriverBaseNameW

K32GetDeviceDriverFileNameA

K32GetDeviceDriverFileNameW

K32GetMappedFileNameA

K32GetMappedFileNameW

K32GetModuleBaseNameA

K32GetModuleBaseNameW

K32GetModuleFileNameExA

K32GetModuleFileNameExW

K32GetModuleInformation

K32GetPerformanceInfo

K32GetProcessImageFileNameA

K32GetProcessImageFileNameW

K32GetProcessMemoryInfo

K32GetWsChanges

K32GetWsChangesEx

K32InitializeProcessForWsWatch

K32QueryWorkingSet

K32QueryWorkingSetEx

LoadAppInitDlls

LocateExtendedFeature (forwarded to MICROSOFT-WINDOWS-SYSTEM-XSTATE-L1-1-0.RtlLocateExtendedFeature)

LocateLegacyContext (forwarded to MICROSOFT-WINDOWS-SYSTEM-XSTATE-L1-1-0.RtlLocateLegacyContext)

NlsConvertIntegerToString

NotifyMountMgr

PowerClearRequest

PowerCreateRequest

PowerSetRequest

QueryIdleProcessorCycleTimeEx

QueryThreadpoolStackInformation

QueryUnbiasedInterruptTime

RaiseFailFastException

ResolveLocaleName

RtlCaptureContext

RtlCaptureContext (forwarded to NTDLL.RtlCaptureContext)

RtlCaptureStackBackTrace

RtlCaptureStackBackTrace (forwarded to NTDLL.RtlCaptureStackBackTrace)

RtlFillMemory

RtlFillMemory (forwarded to NTDLL.RtlFillMemory)

RtlUnwind

RtlUnwind (forwarded to NTDLL.RtlUnwind)

SetExtendedFeaturesMask (forwarded to MICROSOFT-WINDOWS-SYSTEM-XSTATE-L1-1-0.RtlSetExtendedFeaturesMask)

SetProcessPreferredUILanguages

SetSearchPathMode

SetThreadErrorMode

SetThreadGroupAffinity

SetThreadIdealProcessorEx

SetThreadpoolStackInformation

SetWaitableTimerEx (forwarded to Microsoft-Windows-System-ThreadPool-L1-1-0.SetWaitableTimerEx)

SortCloseHandle

SortGetHandle

TryAcquireSRWLockExclusive (forwarded to NTDLL.RtlTryAcquireSRWLockExclusive)

TryAcquireSRWLockShared (forwarded to NTDLL.RtlTryAcquireSRWLockShared)

UpdateProcThreadAttribute

UpdateProcThreadAttribute (forwarded to Microsoft-Windows-System-Process-ProcessThreads-L1-1-0.UpdateProcThreadAttribute)

WerRegisterRuntimeExceptionModule

WerUnregisterRuntimeExceptionModule

 

User32:

CalculatePopupWindowPosition

ChangeWindowMessageFilterEx

CheckImeHotKey

CloseGestureInfoHandle

CloseTouchInputHandle

ConsoleControl

ControlMagnification

DisplayConfigGetDeviceInfo

DisplayConfigSetDeviceInfo

DwmGetDxRgn

DwmGetDxSharedSurface

DwmHintDxUpdate

GestureCommand

GetDisplayConfigBufferSizes

GetGestureCommandInfo

GetGestureConfig

GetGestureExtraArgs

GetGestureInfo

GetImeHotKey

GetInputLocaleInfo

GetMagnificationDesktopColorEffect

GetMagnificationDesktopMagnification

GetMagnificationLensCtxInformation

GetServicesProcess

GetTopLevelWindow

GetTouchInputInfo

GetWindowCompositionAttribute

GetWindowCompositionInfo

GetWindowDisplayAffinity

IsTopLevelWindow

IsTouchWindow

NotifyOverlayWindow

QueryDisplayConfig

RegisterGestureHandlerWindow

RegisterTouchWindow

SetConsoleReserveKeys

SetDisplayConfig

SetGestureConfig

SetMagnificationDesktopColorEffect

SetMagnificationDesktopMagnification

SetMagnificationLensCtxInformation

SetWindowCompositionAttribute

SetWindowDisplayAffinity

SfmDxBindSwapChain

SfmDxGetSwapChainStats

SfmDxOpenSwapChain

SfmDxQuerySwapChainBindingStatus

SfmDxReleaseSwapChain

SfmDxSetSwapChainStats

UnregisterGestureHandlerWindow

UnregisterTouchWindow

VRipOutput

VTagOutput

Win32PoolAllocationStats

gSharedInfo

gapfnScSendMessage

 

Ntdll:

AlpcRundownCompletionList

EtwEventWriteEx

EtwEventWriteNoRegistration

EvtIntReportAuthzEventAndSourceAsync

EvtIntReportEventAndSourceAsync

LdrGetDllHandleByMapping

LdrGetDllHandleByName

LdrResGetRCConfig

LdrRscIsTypeExist

LdrpResGetRCConfig

NtAllocateReserveObject

NtCancelDeviceWakeupRequest

NtCreateProfileEx

NtDisableLastKnownGood

NtDrawText

NtEnableLastKnownGood

NtNotifyChangeSession

NtOpenKeyEx

NtOpenKeyTransactedEx

NtQuerySecurityAttributesToken

NtQuerySystemInformationEx

NtQueueApcThreadEx

NtRequestDeviceWakeup

NtRequestWakeupLatency

NtSerializeBoot

NtSetIoCompletionEx

NtSetTimerEx

NtUmsThreadYield

NtWow64GetCurrentProcessorNumberEx

NtWow64InterlockedPopEntrySList

RtlAcquireReleaseSRWLockExclusive

RtlAddIntegrityLabelToBoundaryDescriptor

RtlContractHashTable

RtlCopyExtendedContext

RtlCreateHashTable

RtlCreateProcessReflection

RtlCreateVirtualAccountSid

RtlDeleteHashTable

RtlDetectHeapLeaks

RtlDisableThreadProfiling

RtlEnableThreadProfiling

RtlEndEnumerationHashTable

RtlEndWeakEnumerationHashTable

RtlEnumerateEntryHashTable

RtlEthernetAddressToStringA

RtlEthernetAddressToStringW

RtlEthernetStringToAddressA

RtlEthernetStringToAddressW

RtlExpandHashTable

RtlFillMemoryUlonglong

RtlGetCurrentProcessorNumberEx

RtlGetEnabledExtendedFeatures

RtlGetExtendedContextLength

RtlGetExtendedFeaturesMask

RtlGetFullPathName_UEx

RtlGetLocaleFileMappingAddress

RtlGetNextEntryHashTable

RtlGetProcessPreferredUILanguages

RtlInitEnumerationHashTable

RtlInitWeakEnumerationHashTable

RtlInitializeExtendedContext

RtlInsertEntryHashTable

RtlInterlockedClearBitRun

RtlInterlockedSetBitRun

RtlIsNameInExpression

RtlKnownExceptionFilter

RtlLoadString

RtlLocateExtendedFeature

RtlLocateLegacyContext

RtlLookupEntryHashTable

RtlQueryPerformanceCounter

RtlQueryPerformanceFrequency

RtlQueryThreadProfiling

RtlReadThreadProfilingData

RtlRemoveEntryHashTable

RtlReplaceSidInSd

RtlReportSilentProcessExit

RtlReportSqmEscalation

RtlSetExtendedFeaturesMask

RtlSetProcessPreferredUILanguages

RtlTryAcquireSRWLockExclusive

RtlTryAcquireSRWLockShared

RtlUTF8ToUnicodeN

RtlUnicodeToUTF8N

RtlWeaklyEnumerateEntryHashTable

SbExecuteProcedure

SbSelectProcedure

TpAllocAlpcCompletionEx

TpAlpcRegisterCompletionList

TpAlpcUnregisterCompletionList

TpCallbackIndependent

TpDbgGetFreeInfo

TpDisablePoolCallbackChecks

TpPoolFreeUnusedNodes

TpQueryPoolStackInformation

TpSetDefaultPoolMaxThreads

TpSetDefaultPoolStackInformation

TpSetPoolStackInformation

WerCheckEventEscalation

WerReportWatsonEvent

WinSqmAddToAverageDWORD

WinSqmAddToStreamEx

WinSqmCheckEscalationAddToStreamEx

WinSqmCheckEscalationSetDWORD

WinSqmCheckEscalationSetDWORD64

WinSqmCheckEscalationSetString

WinSqmCommonDatapointDelete

WinSqmCommonDatapointSetDWORD

WinSqmCommonDatapointSetDWORD64

WinSqmCommonDatapointSetStreamEx

WinSqmCommonDatapointSetString

WinSqmGetEscalationRuleStatus

WinSqmGetInstrumentationProperty

WinSqmIncrementDWORD

WinSqmIsOptedInEx

WinSqmSetDWORD

WinSqmSetDWORD64

WinSqmSetEscalationInfo

WinSqmSetIfMaxDWORD

WinSqmSetIfMinDWORD

ZwAllocateReserveObject

ZwCancelDeviceWakeupRequest

ZwCreateProfileEx

ZwDisableLastKnownGood

ZwDrawText

ZwEnableLastKnownGood

ZwNotifyChangeSession

ZwOpenKeyEx

ZwOpenKeyTransactedEx

ZwQuerySecurityAttributesToken

ZwQuerySystemInformationEx

ZwQueueApcThreadEx

ZwRequestDeviceWakeup

ZwRequestWakeupLatency

ZwSerializeBoot

ZwSetIoCompletionEx

ZwSetTimerEx

ZwUmsThreadYield

ZwWow64GetCurrentProcessorNumberEx

ZwWow64InterlockedPopEntrySList

Reverse Engineering, Windows ,