Exetools - starforce 4.7 emulation detection tricks explained

Exetools (https://forum.exetools.com/index.php)

- General Discussion (https://forum.exetools.com/forumdisplay.php?f=2)

- - starforce 4.7 emulation detection tricks explained (https://forum.exetools.com/showthread.php?t=10743)

starforce 4.7 emulation detection tricks explained

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:

Code:

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?

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 :)

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.

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

Quote:

Originally Posted by BUBlic

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 :)