Hello there,
Today I’ve founded a truly intersing tool for Malware Hunting called Malzilla
You can explore the content of suspicious Website, parse links etc. 🙂
Recommended!
See you to the next post
Hello there,
Today I’ve founded a truly intersing tool for Malware Hunting called Malzilla
You can explore the content of suspicious Website, parse links etc. 🙂
Recommended!
See you to the next post
Hi,
Orer.exe became active, after the first reboot from infection.
To Eliminate orer is necessary to have a copy of explorer.exe
That’s all folks
Hope thi can be useful 🙂
See you to the next post
Hi,
Here the second and last part of my little paper..
First of all, let’s introduce some more specification, to make previous blog entry more clear
The last struct showed, is the _FIREWALL_CONTEXT_T, and as can be seen there is DIRECTION_E that could be a little obscure, so here is reported:
typedef enum _IP_DIRECTION_E {
IP_TRANSMIT,
IP_RECEIVE
} DIRECTION_E, *PDIRECTION_E;
Represents easly a packet is Receiver or Transmitted.
The return values by the filter-routine can be:
FORWARD = 0
DROP = 1
ICMP_ON_DROP = 2
that are proper of FORWARD_ACTION
As previously said, to implement IP_SET_FIREWALL_HOOK_INFO, it’s necessary to write a filter function for \device\IP, so the pointer (to IP) self can be obtained easly by calling IoGetDeviceObjectPointer( )
Now can be installed the filter function, by passing througout IP’s pointer the address of the filtering function self, with IoBuildDeviceIoControlRequest(IOCTL_IP_SET_FIREWALL_HOOK, IpDeviceObject,…..)
It’s important to say also (according to DDK documentation) that IOCTL_PF_SET_EXTENSION_POINTERregisters filter-hook callback to the IP filter driver, to “make known” \device\IP to reroute every packet received or transmitted, and finally this same IOCTL clears the filter function from IP device. All these specifications could be made, by filling up the proper structure of this IOCTL, that will go to constitute the InputBuffer of IoBuildDeviceIoControlRequest:
PF_SET_EXTENSION_HOOK_INFO, that inside have another struct PacketFilterExtensionPtr which specifies the pointer to the filter hook callback, and when ins FALSE clears the filter.
typedef PF_FORWARD_ACTION (*PacketFilterExtensionPtr)(
IN unsigned char *PacketHeader, //Pointer to Ip header of packet
IN unsigned char *Packet, //Points a buffer with informations in the packet
//that filter-hook receives
IN unsigned int PacketLength , //Length of the packet
IN unsigned int RecvInterfaceIndex,//Index number for the interface adapter (InGoing)
IN unsigned int SendInterfaceIndex,//Index number for the interface adapter (OutGoing)
IN IPAddr RecvLinkNextHop, //IP address for the interface adapter that received the packet
IN IPAddr SendLinkNextHop //IP address for the interface adapter that will transmit the packet
);
It’s also important to notice that only on filter function per time can be installed, if others resides functions are stil working this one will not work.
See you to the next post! 🙂
Today I’ve cleared many problems of my Pentium1-166 with IOBit’s Windows Care Suite,
you can download it for free at IOBit
Spyware Immunizing, Registry Cleaner, System Cleaner and other cool features..
Download also SmartDefrag, little and fast 🙂
See you to the next post!!
Hi,
Firewall hooking is a task in major part not well documented, MS doesn’t provides a clear and exaustive documentation about structures and development, so the only mode to have more knowledge is the RCE method.
These filter-hooks obviously works only at kernel mode, installing a callback function, and the driver installs a callback into \device\IP (which can be seen with WinObj) but let’s also parse \system32\Drivers
Fortunately, no extreme binary analysis is needed, we can study directly some header file from DDK, and precisely ipfirewall.h, so let’s take a deeper look to this file. Immediately we can see two intersing structs, the first is IPPacketFirewallPtr that works as a callout routine, and the most interesting _IP_SET_FIREWALL_HOOK_INFO
First Struct:
First Struct: typedef FORWARD_ACTION (*IPPacketFirewallPtr)(
VOID **pData, //can be pMdl or pRcvBuf
UINT RecvInterfaceIndex, //Received Data
UINT *pSendInterfaceIndex, //Index where data is sent
UCHAR *pDestinationType, //Can be Local Network, Remote, Broadcast, Multicast.
VOID *pContext, //Points to _FIREWALL_CONTEXT_T
UINT ContextLength, //sizeof(FIREWALL_CONTEXT_T)
struct IPRcvBuf **pRcvBuf
);
Second Struct:
_IP_SET_FIREWALL_HOOK_INFO {
IPPacketFirewallPtr FirewallPtr; // Packet filter callout.
UINT Priority; // Priority of the hook
BOOLEAN Add; // if TRUE then ADD else DELETE
} IP_SET_FIREWALL_HOOK_INFO, *PIP_SET_FIREWALL_HOOK_INFO;
This is the heart structure necessary to set-up the filter-hook, which can be done by sending a IOCTL to \device\Ip
#define IOCTL_IP_SET_FIREWALL_HOOK \
_IP_CTL_CODE(12, METHOD_BUFFERED, FILE_WRITE_ACCESS)
IP_SET_FIREWALL_HOOK_INFO will be the Input Structure to be filled for the IOCTL.
By observing IPPacketFirewallPtr, we can see _FIREWALL_CONTEXT_T which is:
typedef struct _FIREWALL_CONTEXT_T {
DIRECTION_E Direction;
void *NTE;
void *LinkCtxt;
NDIS_HANDLE LContext1;
UINT LContext2;
} FIREWALL_CONTEXT_T, *PFIREWALL_CONTEXT_T;
After installing the filter-hook, can be powered up a set of rules to FORWARD or DROP a packet.
Thanks to Jesus O.
Hi,
This morning I’ve started as usual my Virtual XP Sp2 Box, but at win’s StartUp Time,
something went Wrong, a Redundancy Check failed..
Aug 25 07:45:18: vmx| VMXAIOMGR: Retry on read "D:My Virtual MachinesWindows XP ProfessionalWindows XP Professional.vmdk" : Errore nei dati (controllo di ridondanza
ciclico). Aug 25 07:45:18: vmx| VMXAIOMGR: system : err=5890 errCode=23 freeSpace=7789461504 Aug 25 07:45:18: vmx| VMXAIOMGR: "D:My Virtual MachinesWindows XP ProfessionalWindows XP Professional.vmdk" : read s=1382023168 n=65536 ne=16 Aug 25 07:45:18: vmx| VMXAIOMGR: v[0]=03FBB000:4096 Aug 25 07:45:18: vmx| VMXAIOMGR: v[1]=03FA5000:4096 Aug 25 07:45:18: vmx| VMXAIOMGR: v[2]=03FA7000:4096 Aug 25 07:45:18: vmx| VMXAIOMGR: v[3]=03FA9000:4096 Aug 25 07:45:18: vmx| VMXAIOMGR: v[4]=03FC7000:4096 Aug 25 07:45:18: vmx| VMXAIOMGR: v[5]=04056000:4096 Aug 25 07:45:18: vmx| VMXAIOMGR: v[6]=03EED000:4096 Aug 25 07:45:18: vmx| VMXAIOMGR: v[7]=040F5000:4096 Aug 25 07:45:18: vmx| VMXAIOMGR: v[8]=040F3000:4096 Aug 25 07:45:18: vmx| VMXAIOMGR: v[9]=02D7D000:4096 Aug 25 07:45:18: vmx| VMXAIOMGR: v[10]=040EF000:4096 Aug 25 07:45:18: vmx| VMXAIOMGR: v[11]=03EE5000:4096 Aug 25 07:45:18: vmx| VMXAIOMGR: v[12]=04170000:4096 Aug 25 07:45:18: vmx| VMXAIOMGR: v[13]=02D75000:4096 Aug 25 07:45:18: vmx| VMXAIOMGR: v[14]=02D3A000:4096 Aug 25 07:45:18: vmx| VMXAIOMGR: v[15]=03FE7000:4096
It’s clear VMXAIOMGR give us an Error (5890) and error code (23), maybe there is a Minidump..
Indeed you can obtain at every VM crash, in the log we can see the following line:
Aug 25 07:50:03: vmx| CoreDump: Writing minidump to C:\Documents and Settings\Proprietario\Dati applicazioni\VMware\vmware-vmx-944.dmp
.:: The Solution ::.
aiomgr.buffered = “TRUE” (this is always suggested, because many times the I/O manager is overcharged of work 😉 )
Sometimes Antivirus Scanners can lock portion portion of file, but no damage is caused to the virtual HD.
But a CRC Error means that the physical hardisk have some damaged cluster so the best solution is to move, in another partition the VM File.
Hope this may help.
See you to the next post
PS: This Post is dedicated to a special person 🙂
Hi,
Here I inserted some link, just to open thi section 🙂 other links and suggestions are welcome..
Latest WDK :
http://www.microsoft.com/whdc/DevTools/WDK/betawdk.mspx
WDK Documentation:
http://www.microsoft.com/whdc/DevTools/WDK/WDKdocs.mspx
A bit different from Vista’s Documentation, cause the DTM stuff that this WDK-Doc don’t have.
Debugging Tools for 32 bits:
http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.7.05.1.exe
Debugging Tools for 64 bits, Native Itanium:
http://msdl.microsoft.com/download/symbols/debuggers/dbg_ia64_6.7.05.1.exe
Debugging Tools for 64 bits, Native x64:
http://msdl.microsoft.com/download/symbols/debuggers/dbg_amd64_6.7.05.1.exe
Virtual Address Space Usage In Windows Game Development
http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/WDDM_VA.doc
Suggestions for new links are welcome
Best Regards,
Evilcry
Good Morning,
Orer.exe is the after-infection result of W32/Huhk.a. It’s name derives from explORER.exe, in other words it cuts explorer’s name.
The Malware, attacks indeed explorer executable by appending itself with the technique of Split Cavity, and makes an infected copy of explorer into Temp directory; so as you can understand is relatively easy to detect (but not to remove), please note that Executable’s date/time will correspond to the original explorer.exe.
Infection Symptoms
Characteristics
Three Threads Created:
- The first one hooks the API function CreateProcessW in order to redirect the execution to the virus code.
- The second one infects files with the extension .exe located on removable disks and on the C drive.
- The last one infects files with the extension .exe on network shares.
.:: First Look Analysis ::.
Executable is not packer or crypted, important to mantain the same explorer size, except some easy and little portion of Self Modifing Code, debug informations are not stripped (remember that orer.exe, derives from explorer.exe) so RCE it’s truly easy.
At a first look of the Dead List, code seems perfectly equal to explorer:
01019634                call   loc_10460D0 ; Entry Point Lands Here..
01019639                sub    esp, 44h
0101963C                push   esi
0101963D                push   edi
0101963E                push   10h            ; nInBufferSize
01019640                push   offset aExplorerstartu ; “ExplorerStartup”
01019645                call   sub_10146D4
0101964A                call   sub_1019708
0101964F                push   1              ; uMode
01019651                call   ds:SetErrorMode
The code listed above corresponds to the Entry Point of orer, and suddlenly we can see a foundamental difference from explorer’s code, the call 010460D0 that contains a RunTime decrypt routine.
Soon the Second part of W32 Hunk.a RCE will be available 🙂
Have a Nice Day
VS C++ 2005Â have a controversal bug, signaled many times in various contexts, but not solved yet.
At compiling time you receive a funny:
Optimizing Profile Crash
An internal error occurred in the compiler, msc1.cpp, line 1392
In the support forum, various strange situation in which the Crash occour was exposed, here I add another situation, not reported anywhere:
Autocad2005 + WinAmp running
If WinAmp is not running, the crash occurrences decrases of the 50%, but if you make some String Casting, the occurrences incrases of the 50%.
Hope that in the new VS2008 this bug will be *Totally* Solved.
Best Regards