Truth about the Personal Firewall

Translation: syspro
Statement: 1. The translation level of syspro is limited. Please understand it if it is inappropriate. If you cannot understand it, you can compare it with the original text.
2. You are welcome to repost it, but do not miss the original author or translator's information.
3. You are welcome to point out the syspro translation errors. Make sure syspro is correct.

There are multiple ways to protect your computer from malware, such as software firewalls, viruses, and Rootkit detection software. All of these protection software are based on well-known and barely improved technologies, and you may already know that security products that inherit these technologies are not perfect. Such consequences are often terrible. However, these security companies naively think that their products are the most advanced and include the latest features, which are essential to users. But as long as you see them through their gorgeous clothes, they have even more bugs and errors than you have designed at school. Although the first thing to produce a product is good and powerful advertising. But can the combination of heavy advertisements and bad tests show users the so-called power of some products, which can lead to a strong desire to buy? Of course not.
It is a good idea to protect your PC from external and internal third party attacks. Some "heuristic" methods to protect your PC from Trojans and spyware seem to be working. If they work, it is really a good idea to get real-time protection and updates at $30 to $50. Unfortunately, they cannot.
First, I want to apologize for my bad English. Our discussion will involve the following products:
ZoneAlarm Firewall 6.x
Outpost Firewall 3.x and 4.x
LooknStop firewall2.0
Kerio firewall4.3
Sygate firewall5.6
Jetico firewall1.0
PortsLock firewall1.9
Tiny firewall6.5
Norton Internet Security 8.0
Comodo firewall2.4
OnlineArmor Firewall 2.1
The personal software firewall provides two basic protection levels: NDIS (Network-driven Interface Specification) and TDI (data transmission interface ). The NDIS level is based on the TCP/IP stack. Protection at this level can prevent attacks based on TCP/IP stack bugs, and you don't even need to update your stack; he can also defend against many electronic spoofing, flood attacks and distributed denial of service attacks. Firewalls without the NDIS Technology naturally become outsiders. Losers include PortsLock firewalls, Norton Internet Security, and Comodo firewalls. Are you sure you want to pay 35 euros for the PortsLock firewall? He cannot even defend against low-level TCP/IP attacks. Or $79 for Comodo? Sorry for your system. The real firewall is based on NDIS. There are two different protection methods based on NDIS. The first is NDIS-hooking protection. The main method is Hooks NdisRegisterProtocol ()/NdisOpenAdapter (). When the NDIS protocol is trying to be registered or is about to bind an adapter, the firewall will receive a notification. When the firewall hooks the handle of NDIS_PROTOCOL_BLOCK and NDIS_OPEN_BLOCK, the firewall will be notified when the system wants to send or receive packets. When the firewall is trying to install their hooks, it is interesting that almost every firewall is a handle to hook NDIS_PROTOCOL_BLOCK, except for Sygate, Kerio, and Jetico. They are handles to HOOK NDIS_PROTOCOL_CHARACTERISTICS, instead of calling the real NdisRegisterProtocol (), they then moved to the original handle. Is it safer? Right? The firewall should work independently, regardless of the number of protocols registered and bound. Yes, each firewall supports this. For example, when ZoneAlarm is hook a handle, it allocates a non-Paging memory and puts the following commands.
Pop eax; 58
Push HookData; 68 XX
Push eax; 50
Jmp HookedHandler; E9 XX
Then, he writes some important information in other memory slices and calls HookData and all the hooks in NDIS_PROTOCOL_BLOCK:
OpenAdapterCompleteHandler
CloseAdapterCompleteHandler
BindAdapterHandler
UnbindAdapterHandler
In NDIS_OPEN_BLOCK:
SendHandler
ReceiveHandler
ReceivePacketHandler
SendPacketsHandler

The NDIS_PROTOCOL_BLOCK is as follows:
VOID HookedOpenAdapterComplete (
PVOID HookData,
IN NDIS_HANDLE ProtocolBindingContext,
IN NDIS_STATUS Status,
IN NDIS_STATUS OpenErrorStatus
);

The real OpenAdapterComplete () handle is placed here: [HookData + 0x770]
VOID HookedCloseAdapterComplete (
PVOID HookData,
IN NDIS_HANDLE ProtocolBindingContext,
IN NDIS_STATUS Status
);

The real CloseAdapterComplete () handle is placed here: [HookData + 0x774]
VOID HookedBindAdapter (
PVOID HookData,
OUT PNDIS_STATUS Status,
IN NDIS_HANDLE BindContext,
IN PNDIS_STRING DeviceName,
In pvoid SystemSpecific1,
In pvoid SystemSpecific2
);
The real BindAdapter () handle is placed here: [HookData + 0x764]
VOID HookedUnbindAdapter (
PVOID HookData,
OUT PNDIS_STATUS Status,
IN NDIS_HANDLE ProtocolBindingContext,
IN NDIS_HANDLE UnbindContext
);
The real UnbindAdapter () handle is placed here: [HookData + 0x768]
For NDIS_OPEN_BLOCK:
VOIDHookedSend (
PVOID HookData,
IN NDIS_HANDLE NdisBindingHandle,
IN PNDIS_PACKET Packet
);
The real Send () handle is placed here: [HookData + 0x1A4]

VOID HookedReceive (
PVOID HookData,
IN NDIS_HANDLE ProtocolBindingContext,
IN NDIS_HANDLE MacReceiveContext,
In pvoid HeaderBuffer,
In uint HeaderBufferSize,
In pvoid LookAheadBuffer,
In uint LookaheadBufferSize,
In uint PacketSize
);

The real Receive () handle is placed here: [HookData + 0x4D0]

VOID HookedReceivePacket (
PVOID HookData,
IN NDIS_HANDLE ProtocolBindingContext,
IN PNDIS_PACKET Packet
);

The real volume epacket () handle is placed here: [HookData + 0x570]

VOID HookedSendPackets (
PVOID HookData,
IN NDIS_HANDLE MiniportAdapterContext,
IN PPNDIS_PACKET PacketArray,
In uint NumberOfPackets
);
The real SendPackets () handle is placed here: [HookData + 2E4h]

Poor ZoneAlarm, this is so simple for getting the real handle and restoring it.
As I said, each firewall supports a majority of registration protocols. In fact, not every one. Sygate believes that it is sufficient to keep all information about the protocol and public package in its. data Segment. Unfortunately, this is a bad idea. Its handle HOOK method is simpler than ZoneAlarm, but it shows which memory commands will be allocated to the drive Teefer. sys of Sygate:

Pop eax; 58
Push HookData; 68 XX
Push eax; 50
Jmp FakeHandler; E9 XX

HookData is also stored in. data. Sygate provides a total of HOOK576 handles (including protocol and open block handles ). Therefore, about 40-50 NDIS_PROTOCOL_BLOCK and NDIS_OPEN_BLOCK can be hooked (do not forget that several open blocks can be attached to a protocol block ). About 40-50 pieces are enough, but such code is really a bad design, and I say hello to the buffer overflow.

I have another good example about how much you need to know about Hook and hook. Those from the Kerio firewall team do not know this. As a good firewall, you can set functions and HOOK handles in NdisRegisterProtocol (), NdisDeregisterProtocol (), NdisOpenAdapter (), and NdisCloseAdapter. As I said, Kerio only hooks the handle of NDIS_PROTOCOL_CHARACTERISTICS and only calls the NdisRegisterProtocol () function, but does not move the handle back to NDIS_PROTOCOL_CHARACTERISTICS. What will happen? Undisclosed features? I do not think so, it is just careless coding and misunderstanding of kernel standards and architecture. Another good example is that the Kerio team does not know any about NDIS development. In fact, they do not even know how to HOOK. The Kerio firewall HOOK is in NDIS_PROTOCOL_CHARACTERISTICS:
OpenAdapterCompleteHandler
CloseAdapterCompleteHandler

And hook NDIS_OPEN_BLOCK as follows:
SendHandler
SendPacketsHandler

Not too many? Exactly. He can be used to bypass his NDIS protection and send a packet to the TCP/IP stack. Although you have already pressed the "block all" button, you can still see the incoming data package in the local sniffer. I don't like to sniff packets when I pretend to be protected as the Kerio firewall pretends. In another aspect, the Outpost firewall prefers to hook more handles in NDIS_PROTOCOL_BLOCK:

OpenAdapterCompleteHandler
SendCompleteHandler
TransferDataCompleteHandler
RequestCompleteHandler
ReceiveHandler
StatusHandler
ReceivePacketHandler
BindAdapterHandler
UnbindAdapterHandler

In NDIS_OPEN_BLOCK:
Outpost 4.0:
SendCompleteHandler
TransferDataCompleteHandler
ReceiveHandler
ReceivePacketHandler
StatusHandler

Outpost 3.x:
SendHandler
TransferDataHandler
SendCompleteHandler
TransferDataCompleteHandler
ReceiveHandler
RequestCompleteHandler
ReceivePacketHandler
SendPacketsHandler
StatusHandler

The code between his handle call and the firewall is very interesting:
Call ImCode; E8 XX
<Some specific data>

For Outpost 3.x:

Pop eax; 58
Push [eax]; FF 30 Pushing the real handler
Pushad; 60
Push [eax + 4]; FF 70 04
Push [esp + 28 h]; FF 74 24 28 Pushing return address
Jmp [eax + 8]; FF 60 08

For Outpost 4.0:

Pop eax; 58
Add eax, 3; 83 C0 03 Missing three zero bytes after call
Push [eax]; FF 30 Pushing the real handler
Pushad; 60
Push [eax + 4]; FF 70 04
Push [esp + 28 h]; FF 74 24 28 Pushing return address
Jmp [eax + 8]; FF 60 08
As we can see, it is not a problem for detaching all the hooks and obtaining system control immediately. If you get bored with the intermediate assembly code, they can usually be converted to common C code. I can show you some interesting information from the Tiny firewall team.