Today, I read a comprehensive article by Nagaraj Venkatesan related to getting a handle on SQL Server Page Splits. If you manage any SQL servers than I strongly recommend that you read this article... simply fantastic!

SQL and SQL only: Identifying Page Splits - by Nagaraj Venkatesan

It seems like more than a decade that I've been going back to that Virginia University page for a copy of lcc-win32. What's more is the fact that I have totally read and nearly memorized the copy of the "Windows API documentation" whose link is now defunct.

The simplicity of the build process was beautiful, the size of the created executables remains still to this day the smallest I've ever seen. If only the compiler and linker utilized better optimizing algorithms, I'd probably still be using it to this day for production coding.

Batch Build process:

lcc -O -unused -c Test.C
lcclnk -s -subsystem:console -o Test.Exe Test.obj

It should be noted, that I still use this compiler for hobbyist applications and still have hundreds of applications that compile flawlessly using both GCC and lcc-Win32!

In case you are not following, I’ll reiterate: This is old code so don’t give me grief. How old is the code?? I’m not sure exactly, but I was in Jr. High at the time. So again, no jabbing me for "crap code"!

Ok, the main() function has been fudged to show the purpose and functionality of the vulnerable procedure: "ParseRequest(...)"

The idea was to search for different parameters that were being passed over from an anonymous TCP/IP connection and then parse off the parameter text which would always be terminated by a line feed character (or optional carriage return character).

Can you spot the vulnerabilities? This code makes many assumptions about the "perfectly trustworthy" and "completely bug free" remote peer. This is a prime example of bad code.

We have potential underflows, overflows, and injection possibilities, potential out-of-bounds memory reading and writing, ect, ect... or to put it in layman's terms: this application would only have been "safe" if it were run on a machine with no networking capabilities period!

//-----------------------------------------------------------------------
char *ParseRequest(const char *sInput, char *sOutput)
{
 size_t iLen = strlen(sInput);
 size_t r = 0; //Read position.
 size_t w = 0; //Write position.
 
 //Skip the parameter marker.
 while(r == 0 || sInput[(r == 0 ? 1 : r) - 1] != ' ')
 {
  r++;
 }
 
 //Parse the parameter value.
 while(r < iLen && sInput[r] != '\r' && sInput[r] != '\n')
 {
  sOutput[w++] = sInput[r++];
 }
 
 sOutput[w] = 0; //NULL terminator.
 
 return sOutput;
}
 
//-----------------------------------------------------------------------
 
int main(int argc, char *argv[])
{
 char input[1024];
 char output[255];
 
 strcpy(input,
  "/P1 Param text 1\n"
  "/P2 Param text 2\n"
  "/P3 Param text 3\n"
  "/P4 Param text 4\n");
 
 for(size_t i = 0; i < strlen(input); i++)
 {
  if(input[i] == '/')
  {
   ParseRequest(input + i, output);
   printf("%s\n", output);
  }
 }
 
 return 0;
}
 
//-----------------------------------------------------------------------

Hints:

1. What would happen if the input wasn’t null nor carriage-return / line feed terminated?
2. What would happen if the input or any one of the parameter values were greater than 255 characters?
3. What would happen if the input contained no spaces between the parameter name (/P1) and its value (Param Text 1).
4. What if there were no spaces in the param text in conjunction with a missing space between the parameter name and its value?

The answer to all four questions? Hopefully a program crash! Otherwise malicious code could easily be injected for your happy application to execute!

Interestingly enough, just a week after I posted to my blog about the possibility of an entry about exploits, I receive an email about an exploit of one of my oldest (and most embarrassing) socket applications: "Finger Server". If you're under 20 years old at the time of this posting then you may need to perform a search for the term "finger Protocol".

I do not really care much for this application anymore but I'm not going to leave a utility with a known vulnerability available via a security website. That wouldn't seem right.

So, what's the exploit? What might one gain from exploiting the server? How can I fix it?

Fortunately, these are all pretty easy to answer when it comes to this application, mainly, because I have the source code and secondly because the heart of the program is only roughly 50 lines of C code. Yea, that'll be easy to patch up!

The replication issues may be comming to a close. Errors are now being skipped as well as erroneous LSNs.

I have already started on my next technical post so it shouldn't be long now.

I've written applications that were bad and I’ve written some that were perfect, though it took me years to figure out why a few of the perfect applications were chewing 75% of my RAM. No matter, their still perfect to me...
 
On a serious note, have you ever written any C or C++ code? Yes? Good - Then you are already familiar with memory leaks!
 
Memory leaks occur when you allocate RAM and do not free it. On modern OS's these memory leaks are only potentially detrimental for the lifetime of the running application, that is, the badly managed resources are cleaned up after the leaky application is closed (or unexpectedly terminated). That said, memory leaks really begin to haunt you when writing long running applications or more specifically: services.
 
These leaks can be more than frustrating, I've turned my back on applications that I've dedicated years to because the manor of the memory's escaped was just too elusive (e.g. I've written bad applications).
 
How can we solve such a problem? Well, you can either attempt to be perfect and (on near certain failure) dump five times the development time into debugging or… use some manner of memory tracker.
 
I developed one of these "memory trackers" that I now include in all of my C++ projects – yes, even the small ones – you never know what they’ll grow into.
 
I call this magic tool: CMemoryPool (though, it's not really a memory pool).
 
How's it work? Well it’s simple really - it has 4 modes which are set by defining preprocessors.
 
Modes of Operation:

Disabled
In disabled mode, the memory tracker code is collapsed down to calls to your native malloc(), calloc(), and realloc(). Fully optimized - this mode is for the final release of your product.
 
General
In general mode, the memory tracker will keep track of the allocations that your program makes and raise a debug break when the class is deconstructed if all of the allocations that it witnessed were not cleaned up properly. This mode is faster than the following modes and that's pretty much the end of its advantages.
 
Advanced
In advanced mode (which should have been called "default mode"), the memory tracker will keep track of each allocation that your application makes as well as the number of bytes per allocation and the source code file name and the line number in the source file that the allocation originated from. Much like the previous mode, the class will trigger a debug break when the class is deconstructed if your application has not been well behaved.
 
Verbose
Verbose mode is slow. It's actually more than slow but I don’t want to appear dramatic by telling you that it's "insanely slow" or "near unusable" - despite the fact that these statements would be true. This mode functions exactly like the previous mode (Advanced) but it additionally opens a console (if you didn’t already open one) and prints verbose information about every memory allocation, reallocation and free to the console. Yea, you think memory allocation is slow now – try Verbose mode!
 
One last thing that should be noted about the memory tracker is that it is multi-thread safe – very multi-tread safe. It’s even safe to use with non-multi-thread safe standard libraries. This functionality can be disabled when running in the final "disabled" mode for your final release by ensuring that the "Sequential When Optimized" preprocessor is not defined in the class header.
 
You're not still reading are you? ....I call B.S.
 
Well, if your that interested, grab a copy of the CMemPool and start saving time!!

This month, 11 years ago I began working on a web server called "The NetworkDLS HTTP Server". The basic idea was to copy the functionality of a little-known web server of the time written by a company called iMatix – their product name was "Xitami". I liked this little server - it was clunky, riddled with holes and could be "hacked" by any elementary school kid with a working knowledge of batch files – but its weaknesses aside – it was my first web server and worked very well over my dial-up connection (anyone remember FreeWWWEB?).
 
Back to my point!
 
Along-side the release of one the shining products of NetworkDLS (the long-awaited "Fortitude HTTP Server" for windows Vista, Windows 7 and Windows 2008 Server x64) – I am releasing the oldest stable version of the server software here, far, far, away from the business end of the NetworkDLS home page.
 
For you emboldened few, I present to you: NetworkDLS HTTP Server 1.0.0.2
 
Please enjoy, and feel free to play with this antique server off-line! It was a modeled after Xitami after all...

For far too long I have listened to the likes of those who believe that the volatile modifier is the end-all answer to multi-threaded development.
 
Parallelism is complex! Given its complexity, it should not be "screwed with" by any person not understanding the difference between "mutual-exclusion synchronization" and "volatile variables" (CPU cache optimization exclusion).
 
Take the example below, read it, study it, compile it and run it. Once you have satisfied yourself that it will always print the number 5,000,000 to the console as its only output, I would then like you to remove the [EnterCriticalSection] / [LeaveCriticalSection] pair and give the application another run - amazed yet?
 
How can this be, I mean I'm using the volatile modifier? (please note the knee deep puddle of sarcasm)

//-------------------------------------------------------------------------------
#include "windows.h"
#include "stdio.h"
//-------------------------------------------------------------------------------

volatile unsigned int iGlobalCounter = 0;
CRITICAL_SECTION CS;

//-------------------------------------------------------------------------------

DWORD WINAPI threadProc(LPVOID pData)
{
 HANDLE hEvent = (HANDLE) pData; //The synchronization object handle.

 //Increment [iGlobalCounter] 1 million times.
 for(unsigned int i = 0; i < 1000000; i++)
 {
  //Comment out [EnterCriticalSection] and [LeaveCriticalSection],
  // which control access to iGlobalCounter to see this
  // multi-threaded example go awry.

  EnterCriticalSection(&CS);
  iGlobalCounter++;
  LeaveCriticalSection(&CS);
 }

 //Set the synchronization object to let the calling
 // thread know that this workload is complete.
 SetEvent(hEvent);

 return 0;
}

//-------------------------------------------------------------------------------

void IncrementGlobalCounter(void)
{
 int iThreadCount = 5; //Create 5 threads.
 char sEventName[255];
 HANDLE *hEvent = NULL;

 //Allocate enough RAM to hold "wait event" handles for each thread.
 if(!(hEvent = (HANDLE *) calloc(sizeof(HANDLE), iThreadCount)))
 {
  printf("Memory allocation error.\n");
  return;
 }

 //Initialize a critical section object.
 memset(&CS, 0, sizeof(CS));
 InitializeCriticalSection(&CS);

 for(int iThread = 0; iThread < iThreadCount; iThread++)
 {
  //Create a unique event name for a synchronization object.
  sprintf(sEventName, "Thread_Event_%d_%d", GetTickCount(), iThread);

  //Create a synchronization object.
  hEvent[iThread] = CreateEvent(NULL, FALSE, FALSE, sEventName);

  //Create a thread, passing it the handle to the synchronization object.
  CreateThread(NULL, 0, threadProc, hEvent[iThread], 0, NULL);
 }

 //Wait on all threads to complete.
 WaitForMultipleObjects(iThreadCount, hEvent, TRUE, INFINITE);

 //Clean up the allocated RAM and the critical section object.
 free(hEvent);
 DeleteCriticalSection(&CS);
}

//-------------------------------------------------------------------------------

int main(int argc, char *argv[])
{
 //CPU Count and CPU Affinity validation
 SYSTEM_INFO SI;
 memset(&SI, 0, sizeof(SI));
 GetSystemInfo(&SI);

 if(SI.dwNumberOfProcessors < 0)
 {
  printf("Your must have more than one CPU core for this example.\n");
  return 1;
 }

 //Lets perform the whole test 10 times.
 for(int iTestNumber = 0; iTestNumber < 10; iTestNumber++)
 {
  iGlobalCounter = 0; //Reset the counter to zero.
 
  IncrementGlobalCounter(); //Increment the global counter.

  //Output the totaled global counter. It should
  // be 5,000,000 ([5 threads] * [1 million increments]).
  printf("iGlobalCounter: %d\n", iGlobalCounter);
 }

 system("Pause");
}

//-------------------------------------------------------------------------------

Have you been thinking about porting that existing 32-bit application to a native 64-bit application?
 
There are things to consider before jumping in head first and I’ll go over some of my experiences in this seemingly daunting endeavor.
 
First things first, mental preparation! In the spirit of preparation and a sprinkling of encouragement, I’ll say this despite information found elsewhere: "Porting existing applications to 64-bits really isn’t all that difficult as long as you start your journey with a project that at least loosely followed nearly any recognized coding practice".
 Things to keep in mind:
 
Registry:
 
On a 32-bit machine your registry entries should go into "HKEY_LOCAL_MACHINE\Software\" or "HKEY_CURRENT_USER\Software\". However, if the same 64-bit application is installed on a 64-bit machine (running a 64-bit version of Windows) then your registry entries will automaticly be placed into "HKEY_LOCAL_MACHINE\Software\ Wow6432Node\" or "HKEY_CURRENT_USER\Software\Wow6432Node\". In addition, your application will also be directed at this key when it reads from the registry.
 
This is all handled for you automatically by the underlying windows API and is (for the lack of a better term)... child’s-play. Unless you happen to have an product which contains multiple executables of which are a mix of 32 and 64-bit components - accessing the same common registry key can become challenging in this case.
 
Program Files:
 
The same principal that applies to the registry also applies to the "C:\Program Files\" directory with the exception that the naming convention what no adhered. On a 64-bit version of windows 64-bit applications will access the "C:\Program Files\" directory, while 32-bit applications will automatically be directed to "C:\Program Files (x86)\".
 
This also applies to the "Common Files" location which is traditionally stored under the program files directory. 64-bit versions of Windows will contain two "Common Files" in two separate locations: One under "C:\Program Files\" and one under "C:\Program Files (x86)\" – respectfully.
 
Other Folders:
 
You find this method of directlry redirection being applied across the OS in many different locations, such as "C:\Windows\System32" to "C:\Windows\SysWOW64". Yes! Thats right, the 64bit files are under "C:\Windows\System32", while the 32-bit files are under "C:\Windows\SysWOW64". - It makes perfect sense to me too!
 
Integers:
 
Or size_t to be specific. Once you switch your compiler over to 64-bit, you find that any standard function that returns the size of anything is now 64-bits. This includes functions like strlen(). However, while you can now pass strings with 18 quintillion characters to strlen(),I highly recommend that you keep track of the length of excessively long strings using other methods.
 Think about this for a minute. Are you going to change that existing use of strlen() to now set a 64-bit integer or are you going to typecast the return value to a 32 bit integer.
 
Pointers:
 
Pointers are now 64-bits. This means larger addressable spaces but could also mean that you have to change some existing bad code. For example, a dialog call back as follows works greate in 32-bit environments but is catastrophic in 64-bit environments.

//Works great in 32-bit but explodes when compiled as 64-bit
// because it returns a 32-bit value and the result can be truncated.
int CALLBACK dialogProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
. . .
}

DialogBox(GetAppInstance(), MAKEINTRESOURCE(IDD_TEMPLATE), NULL, dialogProc);

//This works great in both 32-bit and 64-bit
// because it returns a 64-bit value.
INT_PTR CALLBACK dialogProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
. . .
}

DialogBox(GetAppInstance(), MAKEINTRESOURCE(IDD_TEMPLATE), NULL, dialogProc);

 Shell Integration and Explorer Context Menus:
 
You cannot load a 64-bit shell extension into Windows Explorer using a 32-bit OS (for painfully obvious reasons), but you also cannot load that 32-bit shell extension into Windows Explorer when using a 64-bit OS. Why? Because the explorer executable is 64-bits and cannot load a 32-bit DLL.