Windows Service Recovery Action Blob Manglement!

TL;WR: You can make chaotic-neutral customizations to Windows service recovery actions!
(ᴘʟᴇᴀsᴇ ᴅᴏɴ’ᴛ ᴅᴏ ᴛʜɪs)

Shameless plug: I’m going to be using ImHex in this post and. It has an eye-watering featureset and a bunch of existing patterns WerWolv/ImHex-Patterns. Definitely recommend that you check it out for binary data analysis.

You can actually edit the recovery actions of a service to include more steps that the first, second, and subsequent options available in the UI. Before I explain I just want to get the following points out of the way:

1. Don’t do this. It’s a bad idea. No support whatsoever and nobody else will ever think to check for it. This whole post is a concertina wire bundle of edge cases.
2. If you actually need customizable recovery you should do anything else. Alternatives include: watchdog services, wrapper/manager services, scheduled tasks, recovery scripts, hand cranked flashlights, sound powered telephones, or spark-gap radio.

With that out of the way, service recovery actions as described in the services.msc settings are stored as a binary blob in the registry. You’ll find the blob at HKLM:\\SYSTEM\CurrentControlSet\Services\[SERVICENAME] under the FailureActions binary key. I’m going to generate an example blob that does the following so that we can review it in more detail.

1. Restart the Services
2. Run a Program (cmd.exe)
3. Take no Action

Hex View  00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F
00000000  00 00 00 00 00 00 00 00  01 00 00 00 03 00 00 00
00000010  14 00 00 00 01 00 00 00  60 EA 00 00 03 00 00 00
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

Fortunately for us this isn’t as opaque as it seems. It’s a pretty simple instance of SERVICE_FAILURE_ACTIONS with an array of SC_ACTION. We can use the following ImHex pattern code to parse this for us:

enum SC_ACTION_TYPE: u32 {
	NONE = 0,
	REBOOT = 2,
	RESTART = 1,
	RUN_CMD = 3
};

struct SC_ACTION {
	SC_ACTION_TYPE Type;
	u32 Delay;
};

struct SERVICE_FAILURE_ACTIONS {
    u32     dwResetPeriod;
    u32    lpRebootMsg;
    u32    lpCommand;
    u32     cActions;
    SC_ACTION *lpsaActions[cActions] : s32;
};

SERVICE_FAILURE_ACTIONS actions @ 0x00;

Now we pop that blob and the pattern into ImHex and we get a nice, intuitive breakdown of the binary:

With that you should have an idea where we’re going with this. You can change the lpsaActions array to as many as 1024 entries which I find hilarious. All you need to do is change the cActions value and add your new actions. We’re going to change it to 4 entries.