A forum for reverse engineering, OS internals and malware analysis 

 #5613  by EP_X0FF
 Thu Mar 24, 2011 5:53 am
0ffby1 wrote:The only anomaly I know of is the fewer 2500+ native sector difference from the past known sector count.
Current: sectors +488394752
Should be: +488397386
Who told you these numbers? Do you want to say your HDD increased it's size physically?
 #5637  by 0ffby1
 Fri Mar 25, 2011 1:02 am
EP_X0FF wrote:
0ffby1 wrote:The only anomaly I know of is the fewer 2500+ native sector difference from the past known sector count.
Current: sectors +488394752
Should be: +488397386
Who told you these numbers? Do you want to say your HDD increased it's size physically?
I'm saying there is a decrease in Native size from +488397386 to +488394752 as reported by aswMBR.
To validate the current and Native I'll have to find my ubcd and spin it up.
When using ubcd (not 4win) to look at the HDD, I used every tool on it that would run to see what the tools do and report about the HDD, in the past.
Seatools, when reset to "Native Max Size" states +488397386 as my sector count.
The Native size gets altered at a later time after a wipe, though not exactly sure at what point.
 #5640  by EP_X0FF
 Fri Mar 25, 2011 4:24 am
Your problem is hardware related or caused by your own actions. There is no evidence that you have any kind of rootkits.
All your logs are full of false positives.
 #5643  by 0ffby1
 Fri Mar 25, 2011 9:39 am
EP_X0FF wrote:Your problem is hardware related or caused by your own actions. There is no evidence that you have any kind of rootkits.
All your logs are full of false positives.
Thank you for that assessment. I would like to understand the tools a little more though, determine anomalies good or bad intentions.
Are hidden modules good or bad?

Should I put this Address: 0x01120000 for the Winlogon process into Kernel Detective disassembler to take a look or are other tools better?
Is a basic size of 0x4000 OK?
 #5644  by EP_X0FF
 Fri Mar 25, 2011 9:50 am
0ffby1 wrote:Are hidden modules good or bad?
Current tools (any) can't give you an 100% answer because technique they uses to determine "hidden" modules (i mean dll's) is not perfect and produces false positives with dotnet/security software.
What services are running under svchost.exe (PID: 1132) ? (look this with Process Explorer).
 #5651  by 0ffby1
 Fri Mar 25, 2011 9:17 pm
These are the services running:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\audiosrv
DependOnService REG_MULTI_SZ AudioEndpointBuilder\0RpcSs\0MMCSS
RequiredPrivileges REG_MULTI_SZ SeChangeNotifyPrivilege\0SeImpersonatePrivilege\0SeIncreaseWorkingSetPrivilege
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog
RequiredPrivileges REG_MULTI_SZ SeChangeNotifyPrivilege\0SeImpersonatePrivilege
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wscsvc
DependOnService REG_MULTI_SZ RpcSs\0winmgmt
RequiredPrivileges REG_MULTI_SZ SeChangeNotifyPrivilege\0SeImpersonatePrivilege

Strings of audiodg look OK.
 #5660  by EP_X0FF
 Sat Mar 26, 2011 7:20 am
I shall mention that earlier - you use Vista. This mapped images are known issue and caused by dotnet. Not sure why it's doing this but I saw long time ago a lot of drivers mapped to svchost.exe address space.