starforce 4.7 emulation detection tricks explained

[niom]

sf uses atleast 2 checks to figure out if its real deal or mounted.

check 1 - device stack:

basically, it checks if the topleveldeviceobjects of 2 devices are identically.
are they identically, its a real dvdrom, arent they, its daemontools. why this works
can be easily seen in tools like DeviceTree.

the code goes like this:

first it queries the toplevel deviceobject for the current drive:
	UNICODE_STRING driveName;
	RtlInitUnicodeString(&driveName, L"\\DosDevices\\d:");
	FILE_OBJECT *driveFO;
	DEVICE_OBJECT *driveDO;
	IoGetDeviceObjectPointer(&driveName, STANDARD_RIGHTS_READ, &driveFO, &driveDO);

then it loops over all attached cdrom devices:
	wchar_t *deviceNames;
	IoGetDeviceInterfaces(&GUID_DEVINTERFACE_CDROM, NULL, 0, &deviceNames);
	for (wchar_t *deviceNamesPos = deviceNames; *deviceNamesPos; deviceNamesPos += wcslen(deviceNamesPos) + 1)
	{

and queries the matching deviceobject for each device:
		UNICODE_STRING deviceName;
		RtlInitUnicodeString(&deviceName, deviceNamesPos);

		OBJECT_ATTRIBUTES attributes;
		InitializeObjectAttributes(&attributes, &deviceName, OBJ_CASE_INSENSITIVE, NULL, NULL);

		HANDLE device;
		IO_STATUS_BLOCK status;
		ZwCreateFile(&device, SYNCHRONIZE | FILE_READ_DATA, &attributes, &status, NULL, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ | FILE_SHARE_WRITE, FILE_OPEN, FILE_SYNCHRONOUS_IO_NONALERT, NULL, 0);

		FILE_OBJECT *deviceFileObject;
		ObReferenceObjectByHandle(device, FILE_READ_DATA, *IoFileObjectType, KernelMode, (void **)&deviceFileObject, NULL);

then it gets the stack top of that deviceobject
		DEVICE_OBJECT *deviceTop = IoGetAttachedDeviceReference(deviceFileObject->DeviceObject);

and compares it to the drive toplevel devobj, if they are identically, its a real cdrom
		if (deviceTop == driveDO)
			DbgPrint("hi, im a real cdrom\n");
		else
			DbgPrint("hi, im fake actually\n");
	}

check 2 - DPC:
starforce raises the IRQL to super high, then it queues a DPC. the DPC proc is pretty simple: it just writes 1
to some memoryaddr. then starforce starts an atapi read command. the trick is: the IRQL gets never lowered
when its a real cdrom and without lowering the IRQL, the DPC gets never executed, so the 1 gets never written.
but if daemontools was used, the IRQL drops sooner or later and the DPC gets executed, so the 1 gets written...

Thats quite interesting, but do you know if Securom does the same thing to identify Daemon-tools?

[deroko]

no, securom doesn't use driver.
And for all listed operations driver is required.

@niom: tnx for sharing this info. I really like DPC trick

[evlncrn8]

doubt it, securom doesnt go ring 0 anymore...

Sorry, I'm not fully into that reversing area (currently reading introductions into wriing drivers), but I thought Securom uses its SIntf.dll or CmdLineExt.dll and it is not possible to get as deep as it does without drivers.
But still I wonder how Securom gets its dirty job done.

[souz]

is it possible to get StarForce SDK?

souz :: YOu should buy SF to get SDK, or.. I dont know another way. Btw, v0ldemar posted one files from SF's SDK on this forum

[evlncrn8]

Originally Posted by BUBlic

Sorry, I'm not fully into that reversing area (currently reading introductions into wriing drivers), but I thought Securom uses its SIntf.dll or CmdLineExt.dll and it is not possible to get as deep as it does without drivers.
But still I wonder how Securom gets its dirty job done.

what does cmdlineext.dll sound like its for?
commandline context menu maybe for the 'launch analysis' ?
sintf.dll is way old too

if you wonder how it gets its job done, then start debugging and not making assumptions