The use of booleans hinders readability and maintainability of the code.

The use of booleans also allow potential unwanted parameter reordering mistakes to occur.

Some bold claims. I will explain.

Problem 1: Readability and maintainability

If you saw this function call in your code what do you think it would do?

    ok = attachExceptionTracerToRunningProcess(targetProcessId, TRUE, FALSE, _T("d:\\Exception Tracer"));

To find out we’d need to look at the function prototype, or the documentation. Most likely you’re is going to right click in Visual Studio and ask to see the function definition, or a tooltip is going to tell you what the argument names are. 

Here’s the function definition:

    int attachExceptionTracerToRunningProcess(const DWORD  processId,
                                              const bool   processBitDepth,
                                              const bool   singleStep,
                                              const TCHAR* dir);

To use this function you need to pass a process id, a directory path and two boolean values.

We can guess that passing TRUE for singleStep will start Exception Tracer in single stepping mode. But that’s implied, it’s not explicit.

But processBitDepth, what does that do? You’ll need to read the documentation for that : FALSE starts 32 bit Exception Tracer, and TRUE starts 64 bit Exception Tracer.

Reading documentation is not a problem, but it doesn’t make your code very readable does it? It slows things down. 

Swap booleans for enumerations

If we swap the bools for typedef’d enumerations then we get something more readable for the function definition:

    typedef enum _processBitDepth
    {
        PROCESS_BIT_DEPTH_32,
        PROCESS_BIT_DEPTH_64,
    } PROCESS_BIT_DEPTH;

    typedef enum _doSingleStep
    {
        DO_SINGLE_STEP_NO,
        DO_SINGLE_STEP_YES,
    } DO_SINGLE_STEP;

    int attachExceptionTracerToRunningProcess(const DWORD             processId,
                                              const PROCESS_BIT_DEPTH processBitDepth,
                                              const DO_SINGLE_STEP    singleStep,
                                              const TCHAR*            dir);

Now the function call becomes:

    ok = attachExceptionTracerToRunningProcess(targetProcessId, PROCESS_BIT_DEPTH_64, DO_SINGLE_STEP_NO, _T("d:\\Exception Tracer"));

and the purpose of the function arguments is explicit rather than implied.

Different styles

You don’t need to just use YES and NO, you can use what ever nomenclature feels correct for the situation:

    typedef enum _doSingleStep
    {
        DO_SINGLE_STEP_NO,
        DO_SINGLE_STEP_YES,
    } DO_SINGLE_STEP;

    typedef enum _doSingleStep
    {
        DO_SINGLE_STEP_OFF,
        DO_SINGLE_STEP_ON,
    } DO_SINGLE_STEP;

    typedef enum _doSingleStep
    {
        DO_SINGLE_STEP_DISABLE,
        DO_SINGLE_STEP_ENABLE,
    } DO_SINGLE_STEP;

    typedef enum _doSingleStep
    {
        DO_SINGLE_STEP_STOP,
        DO_SINGLE_STEP_GO,
    } DO_SINGLE_STEP;

If you really feel TRUE/FALSE are appropriate you can do that as well. Which seems a bit odd, until you see Problem 2 and Problem 3.

    typedef enum _doSingleStep
    {
        DO_SINGLE_STEP_FALSE,
        DO_SINGLE_STEP_TRUE,
    } DO_SINGLE_STEP;

Problem 2: Implicit casting

If you are using bools, many types (char, int, enumerations, etc) can implicitly convert to them without you needing to use a cast statement. This can be convenient, but it’s also an avenue for bugs.

If you’re using typedef’d enumerations, these implicit type conversions fail to compile.

You really want to be explicit about any type conversions.

Problem 3: Unwanted parameter reordering

If you are passing parameters through multiple functions before they finally reach the intended function it’s possible that a future edit (such as refactoring a function’s parameters) may reorder some parameters and a mistake is made during the updating of calls to the refactored function which results in parameters passed to the new function definition have been unintentionally reordered.

This happened to us with some boolean parameters in our code instrumentation library. We discovered the mistake when we switched to using enumerations because now each of these parameters has it’s own type.

Incorrect, but compiles

With the old function definition, this example will compile, but the parameters have been incorrectly switched, leading to incorrect behaviour.

    int attachExceptionTracerToRunningProcess(const DWORD  processId,
                                              const bool   processBitDepth,
                                              const bool   singleStep,
                                              const TCHAR* dir);

    int doStartup(const DWORD  processId,
                  const bool   processBitDepth,
                  const bool   singleStep,
                  const TCHAR* dir)
    {
        int ok;

        ok = attachExceptionTracerToRunningProcess(processId, singleStep, processBitDepth, _T("d:\\Exception Tracer"));
    }

Incorrect, but fails to compile

With the new function definition, this example will fail to compile.

    int attachExceptionTracerToRunningProcess(const DWORD             processId,
                                              const PROCESS_BIT_DEPTH processBitDepth,
                                              const DO_SINGLE_STEP    singleStep,
                                              const TCHAR*            dir);

    int doStartup(const DWORD             processId,
                  const PROCESS_BIT_DEPTH processBitDepth,
                  const DO_SINGLE_STEP    singleStep,
                  const TCHAR*            dir)
    {
        int ok;

        ok = attachExceptionTracerToRunningProcess(processId, singleStep, processBitDepth, _T("d:\\Exception Tracer"));
    }

Making the change

It’s a bit more work to create the enumeration and use it.

With an existing code base it can be time consuming work depending on the number of occurrences of the new enumerated type in your code base.

One type at a time

If you are going to make this change I would recommend changing one parameter type at a time and doing a build after each type change.

This seems more time consuming, but in practice we’ve found it’s easier than making multiple new types and then trying to build and dealing with the chaos that results until you’ve fixed up all the function definitions etc.

If, like us, you’ve got many solutions and many projects in each solution then the quickest way to do these builds is to load the solutions/projects into Visual Studio Project Builder then build all projects of a specific configuration. This saves a lot of time.

Should we change our whole codebase?

There are certainly benefits to doing this. You might find some errors where parameters have been passed in the wrong order.

But for large codebases, changing every boolean use is probably impractical (it will take a long time). The best approach is to change them when you’re editing some code that is using them.

Conclusion

As you can see there are multiple benefits to using enumerations rather than booleans in your code.

You get improved readability and improved type safety.

The post Stop using booleans, they’re hurting your code appeared first on Software Verify.

History

April 2002 to May 2014

All actions required by a Software Verify Tool were performed directly by that tool. 

May 2014

SVL Admin Service provides functionality for various Software Verify tools that these tools cannot do running as a standard user application. 

We wrote about this work as “An end to unwanted UAC prompts”.

February 2024

During February 2024 ago we changed all the access controls on files and pipes that our tools and services use to restrict access to just the users that need to use them.

The problem we wanted to solve

We wanted to prevent the SVL Admin Service and the SVL Build Service from being used by bad actors as a means to attack a computer.

To do this we have:

• Encrypted the communication between any Software Verify tool and the SVL Admin Service.
• Encrypted the communication between Visual Studio Project Builder and the SVL Build Service.
• We’ve also replaced any commands that had the potential for abuse with commands dedicated to specific tasks that can’t be changed to something malicious.
• We’ve also added command verification steps to ensure the appropriate digital signatures are present before we execute them or copy them.

Why we’ve made this change

When we implemented the communication scheme between our tools and the SVL Admin Service we didn’t really think about the security implications as to use these pipes you’d need to know what data we send down them and have access to them as a user.

However, recent attacks on various computer systems, plus studying what malware authors are doing led us to conclude that we should encrypt our comms to make it very hard to monitor the comms between our tools and the service, and also make it very hard to send malicious commands to the service. The services now verify the calling application and all parameters and reject any command where the input parameters cannot be safely verified.

Are my computers at risk?

Software Verify’s footprint worldwide is quite small. Our tools are used worldwide, but we’re only used on developer machines and the occasional customer machine. Our tools aren’t like Notepad++ which is distributed massively around the world. Notepad++ is a great tool and that widespread distribution made it a prime candidate for an attack. This was one of the events which prompted us to improve the security of the SVL Admin Service and SVL Build Service.

Because our tools are not massively distributed, and are more than likely distributed on target machines that are not that valuable to a bad actor (not a C-suite machine), the ROI of attacking our tools now that we’ve made it much harder probably means it’s not worth attacking a machine hoping that our tools are installed on that machine. There are easier, more widely available targets for bad actors to go for.

That said, we strongly recommend updating to the most recent version of the tools released after 18/02/2026.

Please note: The Python tools are legacy tools and cannot be updated. We’ll be releasing some Python capable tools to replace these later this year.

When will this change happen?

The SVL Admin Service will be upgraded when you install any of our tools downloaded from our website after 18/Feb/2026.

Consequences

The consequences of securing the comms between our tools and the SVL Admin Service are that once you’ve upgraded the service any already existing Software Verify tool that needs to use the SVL Admin service will be unable to communicate with the service because it will still be communicating with no encryption.

To fix this you will need to update each tool that uses the SVL Admin Service.

You can do this by:

• Running the tool and doing Check for Updates… from the Software Updates menu
• For free tools: Go to the appropriate software tool page and download the tool again, then install it
• For commercial tools: Login to the authorised downloads area and download the tool and install. Check your email for details

What happens if I continue trying to use a tool without updating it?

The tool you are using may work for many of it’s actions, but any action that requires communicating with the SVL Admin Service will fail.

Any tool that tries to communicate with the encrypted SVL Admin Service without being updated will be shown this message.

If you see this dialog, choose No, then update the tool you are trying to use by downloading a new version from the website.

How do I know which tools to update?

All our tool installers ship with a small utility which will check your machine for previous installs of our tools. These will be checked to determine if they can communicate securely with the SVL Admin Service. If they cannot communicate securely the utility will display a dialog box listing the names of the tool you need to update.

What should I do next?

Find all Software Verify tools installed on your computers and update all of them to the most recent version.

The post Secure Admin Service appeared first on Software Verify.

OK so it’s 2020 and how many people are developing ISAPI extensions? More than you might imagine. Yeah, Ruby on Rails and Rust are all the rage these days, but some people still need to work with ISAPI for a bunch of business reasons.

I recently had to setup IIS 10 with ISAPI on Windows 10. I read a lot of articles on how to do it. None of them were complete, resulting in reading several articles to get something working, so I put this together, mainly for my own benefit (because I really don’t need to spend that much time doing this again!). I’m sharing it so you don’t have to go through this. 

I was trying to get a simple ISAPI extension to work before trying anything else. My guess is most of you are working on legacy code, but a few of you may have been instructed to write a new ISAPI. Here’s a good starting point for a simple ISAPI extension if you haven’t already written one.

Creating an ISAPI extension: https://www.codeproject.com/Articles/1432/What-is-an-ISAPI-Extension

ASP.Net

I’m also going to very briefly mention installing ASP.Net as well.

32 bit ISAPI

There’s an interesting gotcha if you’re developing a 32 bit ISAPI extension. Don’t worry I cover that at the end.

Windows 10 and Windows 11

The instructions in this article work for both Windows 10 and Windows 11. The process is identical on both operating systems.

Installing IIS components

IIS components are installed via the Windows features dialog.

In the Windows 10 search box type “Turn Windows features on and off”, when windows shows you the result that matches press return (or click it).

The feature selection box is displayed. Select the items highlighted red in the image shown below. Click OK.

If you’ve already got partway through configuring IIS Manager and have realised you don’t have all the required components installed that’s OK, just install them and then close IIS Manager and reopen it (I found that if I didn’t do that not all the component parts would show in IIS Manager, making finding (for example) ISAPI and CGI Restrictions impossible.

ASP.Net

If you’re working with ASP.Net, enable the items above that are identified as ASP.NET and the .Net Extensibility options as well.

Configuring IIS Manager

Start Internet Information Services Manager.

In the Windows 10 search box type “Internet Information Services Manager”, when windows shows you the result that matches press return (or click it).

Website

First of all we need a website to work with. If you’ve already got one skip the next few lines.

1. Add a test website. Right click on “Sites” in the left hand menu and choose “Add Website…”

   
   

2. The Add Website dialog is displayed.

   

3. Choose a website name. For example: “test”.
4. Choose a location for the website. For example: C:\testISAPIWebsite
5. Change the port number (just for testing) so that it doesn’t conflict with any other sites you have. For example: 81.
6. Modify the security permissions for the directory you specified in step 4 to allow write and/or execute permissions if you need these permissions. 

Handler Mappings

1. Select the server node on the left hand side and double click click on Handler Mappings on the right hand size.

   

2. The handler mappings are displayed.

   
   
   

3. Right click in empty space and choose “Edit Feature Permissions…”.

   

4. The Edit Feature Permissions dialog is displayed. Enable Read, Script and Execute permissions. When you select the execute check box you’ll notice the entry for ISAPI dlls is added to the displayed Handler Mappings. Click OK.

   
   
   

ISAPI and CGI Restrictions

1. Select the server node on the left hand side and double click click on “ISAPI and CGI Restrictions” on the right hand size.

   

2. Right click in empty space and choose “Add…”.

   

3. Add the path to your ISAPI dll, a description and select the check box so that it is allowed to execute. Click OK.

   
   
   

4. This will place a web.config in the directory that contains the DLL. It will look something like this:

   <?xml version="1.0" encoding="UTF-8"?>
   <configuration>
       <system.webServer>
           <handlers accessPolicy="Read, Execute, Script">
               <remove name="ISAPI-dll" />
               <add name="ISAPI-dll" path="*.dll" verb="*" modules="IsapiModule" scriptProcessor="C:\testISAPIWebsite\validate.dll" resourceType="File" requireAccess="Execute" allowPathInfo="true" preCondition="bitness32" />
           </handlers>
       </system.webServer>
   </configuration>
   

32 bit ISAPI extensions

If your ISAPI is 32 bit you’ll need to enable them. Go to application pools (under the server node), select the application pool that your website is in, right click, choose “Advanced Settings…”.

Change the “Enable 32-Bit Applications” setting to True.

64 bit ISAPI extensions

If your ISAPI is 64 bit you’ll need to ensure that you haven’t got 32 bit extensions enabled. Go to application pools (under the server node), select the application pool that your website is in, right click, choose “Advanced Settings…”. Change the “Enable 32-Bit Applications” setting to False.

Trying out the website

If we assume your ISAPI is called validate.dll you should be able to test your ISAPI in a browser using http://localhost:81/validate.dll?12345678

Authentication problems

If when trying to view your web pages you get strange error messages, select the server node on the left then go to “Feature Delegation” and turn any entries that are “Read only” to “Read/Write”. Then restart the server (top of the right hand bar).

Note that I’m assuming you’re working on a Dev machine. If you’re working on a production machine you might want to be a bit less cavalier than just turning all settings to Read/Write – work through them one at a time to find out what you need and change only that.

Directory Permissions

If you’re having problems with directory permissions that aren’t managed by IIS Manager you should read this article about changing directory permissions for IIS_IUSRS.

Server Errors

If you’re getting error pages from the server describing various server errors you should take a look at Common IIS Server Errors.

The post Setting up ISAPI (and ASP.Net) on IIS 10 appeared first on Software Verify.

This was caused by a failure with an upstream DNS provider.

After waiting for them to fix the problem for far too long we changed DNS providers. 

We started receiving email again during late Sunday evening / early Monday.

If you tried to contact us and got a bounce message, this is the reason why.

Sorry for any inconvenience.

The post Failing email appeared first on Software Verify.

In this article, I’m going to show you how to extract the same data using the Win32 API for use in your application at runtime.

To extract data from a resource in an executable we need some information:

• Executable name.

• Custom resource name.

• Custom resource type name.

In our previous example, the executable name was mvJavaDetective.dll, the custom resource type name was “CLASSFILE” and the custom resource name was “myJavaSpy”.

The API

FindResource

    HRSRC FindResource(HMODULE hModule,
                       LPCTSTR lpName,
                       LPCTSTR lpType);

Call FindResource() to find a resource in an executable and return a resource handle.

The executable is specified using a module handle that represents a module loaded in the current program. If the module is currently loaded you can get a handle to it using GetModuleHandle(). If the module is not currently loaded you can load it with LoadLibrary().

The resource is identified by its custom resource name and custom resource type.

LoadResource

    HGLOBAL LoadResource(HMODULE hModule,
                         HRSRC   hResInfo);

Call LoadResource() to load the resource passings the module handle and the resource handle from FindResource() as parameters.

The returned handle should not be passed to any Global memory function for deallocation.

LockResource

    LPVOID LockResource(HGLOBAL hResData);

Call LockResource() to lock the resource in memory. Pass the handle returned by LoadResource() as the input parameter.

If the call succeeds a pointer to the data represented by the handle is returned.

SizeofResource

    DWORD SizeofResource(HMODULE hModule,
                         HRSRC   hResInfo);

Call SizeofResource() to determine the size of a resource. Pass the module handle and the handle returned from FindResource() as input parameters.

The return value specifies the size of the resource.

Putting it together

In the previous example our example DLL myJavaDetective.dll had a class myJavaSpy.class embedded into a resource with the type “CLASSFILE” and name “myJavaSpy”. I will now show you how to extract the myJavaSpy.class byte codes from the resource.

First we need to get the module handle of the executable (myJavaDetective.dll) containing the myJavaSpy.class. For this example we will assume that myJavaDetective.dll is already loaded into memory.

Call GetModuleHandle() with the name of the DLL holding the resource (“myJavaDetective.dll”). The return value is the module handle.

	HMODULE	hModJavaDetective;

	hModJavaDetective = GetModuleHandle("myJavaDetective.dll");

Once we have the module handle we can attempt to find the resource in the executable. We don’t need to check for a NULL module handle as FindResource() handles that and will return a NULL resource handle (just as it will if the resource is not embedded in the executable).

	jbyte	*classBytes = NULL;
	DWORD	classBytesLength = 0;
	HRSRC	hResource;

	hResource = FindResource(hModJavaDetective,
							 _T("myJavaSpy"),
							 _T("CLASSFILE"));
	if (hResource != NULL)
	{

If FindResource() returns a non NULL handle the resource has been found. Now we must load the resource using LoadResource().

		HGLOBAL	hResourceMemory;

		hResourceMemory = LoadResource(hModJavaDetective, hResource);
		if (hResourceMemory != NULL)
		{

If LoadResource() returns a non NULL handle the resource has been correctly loaded from the executable. This returns a handle of type HGLOBAL. Caution you must not pass this handle to any HGLOBAL related functions such as GlobalFree() or GlobalRealloc() as this handle does not represent a memory allocation. This type is used for backward compatibility with earlier versions of the Windows API.

Before we can use the data we must convert the returned handle into a pointer to the data by calling LockResource(). We also want to know the size of the data in the resource so we call SizeofResource() to determine the size. The pointer returned by LockResource() must not be passed to any memory deallocation functions – it does not need to be deallocated or unlocked.

			void	*ptr;
			DWORD	size;

			ptr = LockResource(hResourceMemory);
			size = SizeofResource(hModInjectedJVMTI, hResource);
			if (ptr != NULL)
			{

If LockResource() returns a non NULL pointer the pointer represents the data embedded in the executable.

Now we have the data we make a copy for our own use and continue as normal. This step is optional, you can use the data directly from the returned pointer if you wish.

				classBytes = new jbyte [size];
				if (classBytes != NULL)
				{
					memcpy(classBytes, ptr, size);
					classBytesLength = size;
				}
			}
		}

		// CAUTION! LoadResource() and LockResource() DO NOT allocate handles or locks, 
		// read the documentation
	}

Now that we have extracted the data from the resource embedded into the executable we can use the data as normal. For this example I will conclude by using the extracted Java class bytescodes to define a Java class in a Java Virtual Machine.

	if (classBytes != NULL)
	{
		// define our class, must have same name as class file bytes
		// pass NULL for the class loader - use default class loader

		jclass		klass = 0;

		klass = jniEnv->DefineClass(SVL_COVERAGE_CLASS, NULL, classBytes, classBytesLength);
		if (klass != 0)
		{
                    // class defined correctly
		}

		// tidy up

		delete [] classBytes;
	}

Wrap up

Now you know how to embed data in an executable at runtime (and after the fact with the utility presented in the previous article) and how to extract data from an executable at runtime. The techniques are quite straightforward to master and allow you to easily embed data for you to use at runtime without worrying about distributing and locating extra data files with your application.

The post How to read embedded data from a resource appeared first on Software Verify.

The Problem – Inaccessible Locations

But what if the crash happens in somewhere that’s hard for you to debug, for example deep inside ExitProcess() or millions of instructions after the last location that you know about that is in your code?

The Solution – Automation

The solution to this problem is a dedicated tool that will single step through your code automatically without requiring you to tell the debugger to single step the next instruction. 

Exception Tracer has a dedicated single-step mode that you can use for this.

However, using Exception Tracer from it’s user interface you can attach to your program, but that doesn’t guarantee single stepping will happen in the right place for you. You could end up single stepping through tens of thousands of lines of code (millions of instructions) that you don’t need to before you get to the part of the program that you know is interesting. You could spend hours waiting for the trace to get to the part of the code that you think is going to be interesting for the purposes of understanding the bug. I know, I’ve waited overnight for single stepping results.

What if you could be more specific about when you choose to attach Exception Tracer you could save hours of time, increasing your productivity?

The solution is to add a single call to your application to launch exception tracer from within your program so that Exception Tracer starts single stepping your application from that exact location.

attachExceptionTracerX64(GetCurrentProcessId());

The function looks like this:

 
static const TCHAR *ET_X86_PATH = _T("C:\\Program Files (x86)\\Software Verify\\ExceptionTracer\\exceptionTracer.exe");
static const TCHAR *ET_X64_PATH = _T("C:\\Program Files (x86)\\Software Verify\\ExceptionTracer\\exceptionTracer_x64.exe");

void attachExceptionTracer_internal(const TCHAR*    pathToExceptionTracer,
                                    DWORD           processId)
{
    int                    b;
    DWORD                  dwCreateFlags;
    STARTUPINFO            startupInfo;    // put info about startup here for CreateProcess()
    PROCESS_INFORMATION    procInfo;        // info about the process is placed here
    CString                theCmdLine;

    theCmdLine.Format(_T("%s /process %d /singleStepRequired:On"), pathToExceptionTracer, processId);

    startupInfo.cb = sizeof(STARTUPINFO);
    startupInfo.lpReserved = NULL;
    startupInfo.lpDesktop = NULL;
    startupInfo.lpTitle = NULL;
    startupInfo.dwX = 0;
    startupInfo.dwY = 0;
    startupInfo.dwXSize = 400;
    startupInfo.dwYSize = 400;
    startupInfo.dwXCountChars = 40;
    startupInfo.dwYCountChars = 25;
    startupInfo.dwFillAttribute = 0;
    startupInfo.dwFlags = STARTF_USESHOWWINDOW;
    startupInfo.wShowWindow = SW_SHOW;
    startupInfo.cbReserved2 = 0;
    startupInfo.lpReserved2 = NULL;
    startupInfo.hStdInput = NULL;
    startupInfo.hStdOutput = NULL;
    startupInfo.hStdError = NULL;

    procInfo.hProcess = NULL;
    procInfo.hThread = NULL;
    procInfo.dwProcessId = NULL;
    procInfo.dwThreadId = NULL;

    dwCreateFlags = NORMAL_PRIORITY_CLASS;

    b = CreateProcess(NULL,                                  // program
                      (TCHAR *)(const TCHAR *)theCmdLine,    // command line
                      NULL,                                  // process attributes (use default)
                      NULL,                                  // thread attributes (use default)
                      FALSE,                                 // inheritance (don't)
                      dwCreateFlags,                         // how to create the process
                      NULL,                                  // environment (use parent's, ie this)
                      NULL,                                  // current directory (same as this process if NULL)
                      &startupInfo,                          // startup info
                      &procInfo);                            // process info (return value)
    if (b)
    {
        WaitForInputIdle(procInfo.hProcess, INFINITE);

        CloseHandle(procInfo.hProcess);
        CloseHandle(procInfo.hThread);
    }
}

void attachExceptionTracerX86(DWORD	processId)
{
    attachExceptionTracer_internal(ET_X86_PATH, processId);
}

void attachExceptionTracerX64(DWORD	processId)
{
    attachExceptionTracer_internal(ET_X64_PATH, processId);
}

There’s also some helper functions to calculate the path to Exception Tracer based on values stored in the registry. All you need to do is:

1. #include attachExceptionTracer.inl into the source file where you want to start Exception Tracer
2. call attachExceptionTracerX86 or attachExceptionTracerX64 as appropriate to start Exception Tracer

Exception Tracer will attach to the application with single stepping enabled and run until the program exits. After the program exits the trace will be processed and then displayed for you to analyse.

The trace shown below shows single stepping into a buffer overrun crash being detected.

The post Debugging a crash with single stepping appeared first on Software Verify.

Why does the SVL Admin Service inject into processes?

We were recently asked this question by a customer because their security team was concerned that this behaviour was unexpected and might be malicious.

In this article I’m going to describe every Software Verify process that injects into another process and explain why it is doing that.

Summary

Before I do that, here’s the summary:

• We inject into other processes mainly to set environment variables that will allow .Net and .Net Core processes to load our .Net profiler. 
• We inject into other processes mainly to delete environment variables that will allow .Net and .Net Core processes to load our .Net profiler.
• We inject into other processes sometimes to attach to a native process to allow profiling of that process. This is the Inject into running process… option on the Launch menu.
• We can also eject a DLL from a target process.

Setting Environment Variables

We set environment variables in a target process – used to set .Net Profiler environment variables.

• We allocate some memory in the target process and setup the environment variables values we want to set.
• We then create a remote thread in the target process and call the SetEnvironmentVariable() function (found in kernel32.dll in the target process) with a pointer to the memory setup previously.

Deleting Environment Variables

We delete environment variables in a target process – used to reset .Net Profiler environment variables.

• We allocate some memory in the target process and setup the environment variables values we want to delete.
• We then create a remote thread in the target process and call the SetEnvironmentVariable() function (found in kernel32.dll in the target process) with a pointer to the memory setup previously.

Injecting a DLL into a target process

We inject Software Verify DLLs into a target process – used to attach to processes that are already running.

• • We create a remote thread in the target process.
  • The thread loads the Software Verify DLL we want loaded.
  • The thread calls the function we want called in that DLL. There are two use cases for this.

Injecting a profiler into an application that is about to start

This is the Launch Application… option on the Launch menu.

We start the target application in a suspended state, then modify the entry point code to run our code that will load the native profiler before any other code gets executed. This allows us to monitor more of your application’s behaviour than any other method. It is also more reliable and doesn’t suffer from the risk of deadlocks that Injecting a profiler into a running application has.

Note that for this method we do not create a remote thread, it is not required.

The function called is “startProfiler” or “startProfilerEx”.

The DLL that will be injected depends on the software tool being used.

Injecting a profiler into a running application

This is the Inject into running process… option on the Launch menu.

There is a risk of deadlock with this method because it is impossible to know the state of locks and critical sections that are already active before you inject to a running application (not the same as attaching a debugger to a running application – the debugger is a separate process). We do note in the software documentation that you should always prefer Launch Application to Inject into running process.

The function called is “startProfiler” or “startProfilerEx”.

The DLL that will be injected depends on the software tool being used.

Injecting a DLL that sets some environment variables

Injecting a DLL that sets some environment variables via the DllMain() function.

There is no risk of deadlock injecting these DLLs, they do so little work you can’t trigger that sort of problem.

The DLL unloads immediately because once the environment variables are set it has no more work to do. 

The above are used when working with ASP.Net. The processes injected into are:

The reasons these processes are injected into is because these are the processes that may launch other processes, and those processes inherit their environment variables from the process launching them.

The applications that may initiate this are:

• bugValidator.exe
• coverageValidator.exe
• coverageValidator_x64.exe
• memoryValidator.exe
• memoryValidator_x64.exe
• performanceValidator.exe
• performanceValidator_x64.exe
• threadValidator.exe
• threadValidator_x64.exe

The services that may initiate this are:

• svlAdminService.exe via svlInject.exe
• svlAdminService.exe via svlInject_x64.exe
• svlAdminService_x64.exe via svlInject.exe
• svlAdminService_x64.exe via svlInject_x64.exe

These may also be called indirectly via the resetDotNetProfiler.exe tool which will reset all .Net Profiler environment variables.

Why do Bug Validator and Thread Validator set .Net profiler environment variables when these profilers only profile native code?

The reason for this is mixed mode .Net processes that execute both .Net and native code. If BV and TV are to profile the native code in these mixed mode processes we still need to load a .Net profiler into these processes so that the native profiling code can be loaded into the target process.

Why do x86 processes inject into x64 processes?

The reason for this is that on 64 bit systems it is most likely that a 64 bit process will start a 32 bit process that may be the target for the software tool you are using. We need to set the .Net profiling environment variables appropriately for that task. This is why svlAdminService.exe calls svlInject_x64.exe to inject 64 bit DLLs into 64 bit target processes.

Ejecting a DLL into a target process

We remove Software Verify DLLs from a target process – used to remove DLLs from a process that we have previously inject into a process.

• We create a remote thread in the target process then call FreeLibrary() with the base address of the DLL in the target process.

Conclusion

Some of Software Verify’s software tools inject DLLs into other processes.

This is done to manage .Net Profiler environment variables, or to profile already running native applications when instructed to do so by the user of the software.

There is nothing malicious about this behaviour. It is by design, and is necessary for the correct functioning of the software when working with .Net, .Net Core and debugging applications that are already running.

The post Why does the SVL Admin Service inject into processes? appeared first on Software Verify.

What does it look like?

The warning message looks like this:

Why does this message get shown?

This message is shown because although the software installer is signed by Software Verify, the code signing certificate has changed, and our checks for the new code signing certificate fail because the certificate contains slightly different information compared to the previous certificate.

Some history: After a security breach where some code signing keys were stolen from nVidia and Github (and others, no doubt) the people that oversee code signing decided that the new regime for code signing would be different. No longer would you be able to purchase a code signing certificate for about $100, over the internet, then have the certificate on your own machines. The new regime is that you need to code sign via an online service, or purchase a USB token that holds your code signing certificate securely. This would prevent certificates from being stolen.

The USB token needs to be present to perform any code signing. It’s not a USB stick that you can read, so although you own the USB token and the certificate it holds, you can’t directly access the certificate. The USB token comes with some software that presents a password protected gateway between you and signing, and will lock itself forever if you present a bad password 10 times.

Why didn’t we test with the old certificate and the new certificate?

Our code signing certificate expired on 26 Jan 2024. We started the process of obtaining a USB token code signing certificate months ago. This process is time consuming, requires 3rd parties to vouch for our legitimacy, and costs about 20 times as much the previous method. Progress through the various stages of vetting and the releasing the certificate is, er, opaque. You have no idea what is happening, unless you ask, and even then you may not get a useful answer. You just have to wait. Not ideal :-).

We only received our USB token 3 days prior to the old code signing certificate expiring. We didn’t have enough time to test the new USB token, understand the differences in how the new digitial signatures differed from the previous digitial signatures and get a new software release out that would know the differences and not display the warning message above.

What can you do to resolve this?

Login to your user account at software verify (look at a recent software update email for details) and download the software from there.

Once installed you can start using software updates again as the new version knows what the new digital signatures look like.

The post Potential misleading digitial signature warning with automatic updates appeared first on Software Verify.

Automating the building of a Visual Studio project can save significant time and reduce errors, especially when dealing with large projects or frequent updates. One common approach is to use a build command from the command prompt on Windows, which allows you to build project files directly without opening the Visual Studio IDE.

Manually opening Visual Studio and building each project or solution is tedious and inefficient. 

Visual Studio Project Builder is a tool designed to help automate these tasks. Additionally, build commands can be executed from the command prompt or batch files on Windows, making it easier to integrate automated builds into your development process.

The problem

I needed an easy way to automate the building of a Visual Studio project from the command line.

It needed to work regardless of which Visual Studio the project file was from. Visual Studio 2022 through Visual Studio 6. That’s three different project file formats (.dsp, .vcproj and .vcxproj) and three different Visual Studio command line styles (msdev.exe, devenv.exe and msbuild.exe).

We have Visual Studio Project Builder, which is an interactive tool that can build large collections of Visual Studio projects and solutions, but I couldn’t use it to automate this task because I needed to interact with the user interface a few times during the process.

A few months back we upgraded Visual Studio Project Builder to build all projects in a solution from the command line. I thought adding the same functionality to handle projects would be a good idea.

Time for an upgrade for Visual Studio Project Builder.

/buildProject

To build a project with Visual Studio Project Builder we’ve added the /buildProject option.

Specify /buildProject path-to-project.vcxproj, and use quotes to surround any path containing spaces.

Examples:

visualStudioProjectBuilder.exe /vcxproj /buildProject e:\om\c\testApp\testApp.vcxproj

visualStudioProjectBuilder.exe /vcxproj /buildProject “e:\om\c\dev workspace\testApp\testApp.vcxproj”

The Visual Studio Project Builder user interface is shown during the build process so that you can see the progress of the build.

There is no need for you to interact with the user interface, it will close automatically at the end of the build.

Settings

You’re going to want to use the appropriate settings file when building your projects. Load the settings file with /loadSettings.

Specify /loadSettings path-to-settings.vspbs, and use quotes to surround any path containing spaces.

Examples:

Alternatively, you can use/resetSettings to use the default settings to build the solution.

You can also specify the same project file types as the project. Choose one of:

/vcxproj
/vcproj
/dsp
/csproj
/fsproj
/vbproj
/vjsproj

Batch file usage

To work with batch files you’ll need to specify the type of project file and the project file name, plus any optional arguments.

/vxproj Use a modern Visual Studio file format

/buildproject path-to-project-name load project file

/wait instruct the batch file to wait until Visual Studio Project Builder has closed

/resetSettings resets the settings to default

/loadSettings “e:\my settings\settings.vspbs” load settings from a file

Example 1:

start /wait “Build TestApp” “C:\Program Files (x86)\Software Verify\Visual Studio Project Builder\visualStudioProjectBuilder.exe” /resetSettings /vcxproj /buildProject “e:\om\c\testApp\testApp.vcxproj”

This line in the batch file does this:

• starts Visual Studio Project Builder
• resets the settings to the default /resetSettings
• loads the Visual Studio project e:\om\c\testApp\testApp.vcxproj (you can specify other project types)
• builds all configurations of the project (which configurations are controlled by the settings – you can change this by using /loadSettings)
• closes Visual Studio Project Builder
• the batch file waits for Visual Studio Project Builder before executing the next statement in the batch file /wait

Example 2:

start /wait “Build TestApp” “C:\Program Files (x86)\Software Verify\Visual Studio Project Builder\visualStudioProjectBuilder.exe” /loadSettings “e:\my settings\settings.vspbs” /buildProject “e:\om\c\testApp\testApp.vcxproj”

This line in the batch file does this:

• starts Visual Studio Project Builder
• loads settings from e:\my settings\settings.vspbs
• loads the Visual Studio project e:\om\c\testApp\testApp.vcxproj 
• builds all configurations of the project (which configurations are controlled by the settings – you can change this by using /loadSettings)
• closes Visual Studio Project Builder
• the batch file waits for Visual Studio Project Builder before executing the next statement in the batch file/wait

The post How to build all configurations of a Visual Studio project from the command line? appeared first on Software Verify.

There are many ways to start collecting data with a Validator: Launch, Inject, Wait, Service, IIS, WDS.

But sometimes the methods we’ve provided won’t work because the scenario you’re trying to track is too complex for the GUI driven options we’ve provided.

So, in that scenario how do you detect memory leaks, or collect code coverage, etc?

API

This is where the API comes in handy, and in particular a convenience function we’ve written to make life easy.

If you look in the API subdirectory in your Validator’s install directory you find two files:

loadValidatorIntoAnApplication.c
loadValidatorIntoAnApplication.h

Building a .exe

1. Add both files to the project that builds the .exe you want to monitor.
2. For loadValidatorIntoAnApplication.c you’ll need to disable precompiled headers.
   1. Right click on loadValidatorIntoAnApplication.c and choose Properties…
   2. Change the Configuration combo to All Configurations.
   3. Expand C/C++ then choose Precompiled Headers.
   4. On the right hand side next to Precompiled Header change this to Not Using Precompiled Headers.
   5. Click OK
3. Add #include “loadValidatorIntoAnApplication.h” to the file that contains main().
4. In the main() function, add a call to loadValidatorIntoApplication(); as the first thing that main() does.

Building a .dll

If you are building .exe and .dll used by the .exe, ignore this section, follow the instructions for Building a .exe.

1. Add both files to the project that builds the .dll you want to monitor. Ideally this should be the first DLL of yours that gets called (this assumes you are building more than one DLL).
2. For loadValidatorIntoAnApplication.c you’ll need to disable precompiled headers.
   1. Right click on loadValidatorIntoAnApplication.c and choose Properties…
   2. Change the Configuration combo to All Configurations.
   3. Expand C/C++ then choose Precompiled Headers.
   4. On the right hand side next to Precompiled Header change this to Not Using Precompiled Headers.
   5. Click OK
3. Add #include “loadValidatorIntoAnApplication.h” to the file that contains the first function of your DLL that will be called.
4. In the first function of your DLL that will be called, add a call to loadValidatorIntoApplication(); as the first thing that function does.
5. If you don’t know which function in your DLL will be called first, add the function call to DllMain() when (fdwReason == DLL_PROCESS_ATTACH).

   We don’t recommend this approach because Microsoft state that doing complex work inside DllMain() can lead to undefined behaviour. Our experience is that starting Validators from here usually works, but that could change with future operating system releases.

   #include "..\..\..\..\coverageValidator\API\loadValidatorIntoAnApplication.h"
   
   BOOL APIENTRY DllMain(HMODULE   hModule,
                         DWORD     ul_reason_for_call,
                         LPVOID    lpReserved)
   {
       switch (ul_reason_for_call)
       {
       case DLL_PROCESS_ATTACH:
           loadValidatorIntoApplication();
           break;
   
       case DLL_THREAD_ATTACH:
           break;
   
       case DLL_THREAD_DETACH:
           break;
   
       case DLL_PROCESS_DETACH:
           break;
       }
       return TRUE;
   }
   

Usage

If Validator is installed on your computer

If Validator is running, when you start your .exe (or load your DLL and call functions in it) it will automatically communicate with the Validator GUI and start reporting memory leaks, or collecting code coverage, etc.

If Validator is not running, it will be started automatically.

If Validator is not installed on your computer

If Validator is not installed on the computer, nothing happens. This allows you to leave this code in your product because you know your customers will never have Validator on their machine.

Dependencies

There are no DLL dependencies.

Once you’ve built your .exe/.dll with the included code you can deploy your .exe/.dll anywhere.

The post Loading Validator into a process appeared first on Software Verify.