KernelMode.info

A forum for reverse engineering, OS internals and malware analysis
https://www.kernelmode.info/forum/

VBoxAntiVMDetectHardened mitigation X64 only

https://www.kernelmode.info/forum/viewtopic.php?f=11&t=3478

Page 2 of 25

Re: VBoxAntiVMDetectHardened mitigation X64 only(03/01/15)

PostPosted:Sun Jan 04, 2015 1:04 pm
by Hunter
Are you considering releasing a x86 version?

Re: VBoxAntiVMDetectHardened mitigation X64 only(03/01/15)

PostPosted:Sun Jan 04, 2015 2:24 pm
by TETYYSs
EP_X0FF wrote:Your VirtualBox version (including build number) and how do you start VM, all steps (how do you run loader etc, is it loaded driver etc).
And I think it's because of this part
This was note to people who want to patch DSDT table manually (for future versions of VBox). Table in 1st post attach already with fixed checksum.
4.3.20 r96997.
Uninstalled VirtualBox, rebooted PC, installed VirtualBox without networking, downloaded attachement, copied data folder to C:\VBoxData, edited C:\VBoxData\hidebox_ide.cmd vboxman, vmscfgdir and changed all data to my random one's, also made sure to serial number string lengths match. Fired up VirtualBox, created new VM called 'malwr' and edited settigns according tut, but deleted this: Image and added VDi file to this: Image. Closed VirtualBox. Launched C:\VBoxData\hidebox_ide.cmd with parameter 'malwr', so "C:\VBoxData\hidebox_ide.cmd malwr". Launched loader.exe from my downloads folder though admin cmd with parameters '-l C:\VBoxData', so "C:\Users\user\Downloads\VBox\loader.exe -l C:\VBoxData". Checked if Tsugumi service is running, it was. Fired up VirtualBox and tried to start my VM.

Re: VBoxAntiVMDetectHardened mitigation X64 only(03/01/15)

PostPosted:Sun Jan 04, 2015 2:29 pm
by EP_X0FF
Great description, thanks.

This
Launched loader.exe from my downloads folder though admin cmd with parameters '-l C:\VBoxData', so "C:\Users\user\Downloads\VBox\loader.exe -l C:\VBoxData".
What is the "C:\VBoxData"?

if it this table
static unsigned char TsmiPatchDataValue[143] = {
0x8D, 0x21, 0x03, 0x00, 0x02, 0x51, 0x52, 0xf4, 0x23, 0x03, 0x00, 0x02, 0x51, 0x52, 0x47, 0x25,
0x03, 0x00, 0x02, 0x51, 0x52, 0x72, 0x28, 0x03, 0x00, 0x02, 0x51, 0x52, 0x14, 0x2a, 0x03, 0x00,
0x02, 0x51, 0x52, 0x48, 0x2b, 0x03, 0x00, 0x02, 0x51, 0x52, 0x30, 0xbf, 0x03, 0x00, 0x02, 0x51,
0x52, 0x98, 0xbf, 0x11, 0x00, 0x08, 0x4D, 0x61, 0x67, 0x69, 0x63, 0x61, 0x6C, 0x52, 0xe7, 0x95,
0x11, 0x00, 0x1B, 0x44, 0x73, 0x64, 0x74, 0x46, 0x69, 0x6C, 0x65, 0x50, 0x61, 0x74, 0x68, 0x00,
0x53, 0x73, 0x64, 0x74, 0x46, 0x69, 0x6C, 0x65, 0x50, 0x61, 0x74, 0x68, 0x00, 0x00, 0xB6, 0xD8,
0x00, 0x00, 0x02, 0xDE, 0x10, 0x26, 0x20, 0x01, 0x00, 0x02, 0xDE, 0x10, 0x0e, 0xF7, 0x01, 0x00,
0x02, 0xDE, 0x10, 0xf1, 0x1e, 0x04, 0x00, 0x02, 0xDE, 0x10, 0x05, 0x1f, 0x04, 0x00, 0x02, 0xAD,
0xDE, 0x01, 0xF7, 0x01, 0x00, 0x02, 0xDE, 0x10, 0x0e, 0xF7, 0x01, 0x00, 0x02, 0xC0, 0xC0
};
then it must be saved as binary file, so you have to convert this to bin. Or use attached.

Edit:

I see you use 96997 build, while we worked with 96996 build. There seems was stealth VBox update. Offsets maybe be broken, that's the reason why it crash.

Re: VBoxAntiVMDetectHardened mitigation X64 only(03/01/15)

PostPosted:Sun Jan 04, 2015 2:31 pm
by EP_X0FF
Hunter wrote:Are you considering releasing a x86 version?
No, however you can fork from sources and adapt it for x86, this will require removal of dsefix part and creating patch table for x86 vboxdd.dll.

Re: VBoxAntiVMDetectHardened mitigation X64 only(03/01/15)

PostPosted:Sun Jan 04, 2015 2:41 pm
by TETYYSs
EP_X0FF wrote:Great description, thanks.

This
Launched loader.exe from my downloads folder though admin cmd with parameters '-l C:\VBoxData', so "C:\Users\user\Downloads\VBox\loader.exe -l C:\VBoxData".
What is the "C:\VBoxData"?

if it this table
static unsigned char TsmiPatchDataValue[143] = {
0x8D, 0x21, 0x03, 0x00, 0x02, 0x51, 0x52, 0xf4, 0x23, 0x03, 0x00, 0x02, 0x51, 0x52, 0x47, 0x25,
0x03, 0x00, 0x02, 0x51, 0x52, 0x72, 0x28, 0x03, 0x00, 0x02, 0x51, 0x52, 0x14, 0x2a, 0x03, 0x00,
0x02, 0x51, 0x52, 0x48, 0x2b, 0x03, 0x00, 0x02, 0x51, 0x52, 0x30, 0xbf, 0x03, 0x00, 0x02, 0x51,
0x52, 0x98, 0xbf, 0x11, 0x00, 0x08, 0x4D, 0x61, 0x67, 0x69, 0x63, 0x61, 0x6C, 0x52, 0xe7, 0x95,
0x11, 0x00, 0x1B, 0x44, 0x73, 0x64, 0x74, 0x46, 0x69, 0x6C, 0x65, 0x50, 0x61, 0x74, 0x68, 0x00,
0x53, 0x73, 0x64, 0x74, 0x46, 0x69, 0x6C, 0x65, 0x50, 0x61, 0x74, 0x68, 0x00, 0x00, 0xB6, 0xD8,
0x00, 0x00, 0x02, 0xDE, 0x10, 0x26, 0x20, 0x01, 0x00, 0x02, 0xDE, 0x10, 0x0e, 0xF7, 0x01, 0x00,
0x02, 0xDE, 0x10, 0xf1, 0x1e, 0x04, 0x00, 0x02, 0xDE, 0x10, 0x05, 0x1f, 0x04, 0x00, 0x02, 0xAD,
0xDE, 0x01, 0xF7, 0x01, 0x00, 0x02, 0xDE, 0x10, 0x0e, 0xF7, 0x01, 0x00, 0x02, 0xC0, 0xC0
};
then it must be saved as binary file, so you have to convert this to bin. Or use attached.

Edit:

I see you use 96997 build, while we worked with 96996 build. There seems was stealth VBox update. Offsets maybe be broken, that's the reason why it crash.
data folder is this: Image, which contains Image. I'll try 96996 build.

Re: VBoxAntiVMDetectHardened mitigation X64 only(03/01/15)

PostPosted:Sun Jan 04, 2015 2:45 pm
by EP_X0FF
@TETYYSs

you seems don't understand the purpose of 2nd parameter.

It must point to patch table file, not directory or whatever.
e.g.

C:\Users\user\Downloads\VBox\loader.exe -l C:\VBoxData\output.bin

where output.bin is translated to binary patch table from rinn post (attached in my previous post).

Re: VBoxAntiVMDetectHardened mitigation X64 only(03/01/15)

PostPosted:Sun Jan 04, 2015 2:59 pm
by TETYYSs
Thanks, totally works! Also, used 96996 build, not sure if it'll work on 96997, but who cares now
EP_X0FF wrote:@TETYYSs

you seems don't understand the purpose of 2nd parameter.

It must point to patch table file, not directory or whatever.
e.g.

C:\Users\user\Downloads\VBox\loader.exe -l C:\VBoxData\output.bin

where output.bin is translated to binary patch table from rinn post (attached in my previous post).

Re: VBoxAntiVMDetectHardened mitigation X64 only(03/01/15)

PostPosted:Sun Jan 04, 2015 3:01 pm
by EP_X0FF
TETYYSs wrote:Thanks, totally works! Also, used 96996 build, not sure if it'll work on 96997, but who cares now
I checked VBoxDD from 96997 and it is the same as in 96996.

Re: VBoxAntiVMDetectHardened mitigation X64 only (05/01/15)

PostPosted:Mon Jan 05, 2015 3:18 pm
by EP_X0FF
05/01/15 update

loader changes
+ Resolved few startup issues;
+ Support for new Microsoft versioning;
+ Built in tables for 4.3.16, 4.3.18 and 4.3.20 versions, so you no longer need to load them as external file (however you still can do that supplying patch table filename as second parameter to the loader);
+ "VirtualBox Host-Only Network" connection no longer needs to be disabled for starting this loader, it will disable and reenable it automatically;
+ New presets for EFI (IDE/AHCI) VirtualBox machines (see hidevm_efiahci.cmd, hidevm_efiide.cmd). Note: EFI supported by VirtualBox only from 4.3.20;
+ Updated all bios data and ACPI tables up to current 4.3.20 version;
+ More source included, source that wasn't changed (driver) is not included in this pack.

edit:

attach removed, use current version http://www.kernelmode.info/forum/viewto ... 245#p25245

Re: VBoxAntiVMDetectHardened mitigation X64 only (05/01/15)

PostPosted:Tue Jan 06, 2015 4:24 pm
by rinn
Hello.
EP_X0FF wrote:Also latest rinn posted table contain 1 duplicate entry (last one) :)
:oops:

For guys who want to construct table yourself, we used this code to build it easily
Code: Select all
typedef struct _BINARY_PATCH_BLOCK {
	ULONG	VirtualOffset;
	UCHAR	DataLength;
	UCHAR	Data[1];
} BINARY_PATCH_BLOCK, *PBINARY_PATCH_BLOCK;

typedef struct _BINARY_PATCH_BLOCK_INTERNAL {
	ULONG	VirtualOffset;
	UCHAR	DataLength;
	UCHAR	Data[32];
} BINARY_PATCH_BLOCK_INTERNAL, *PBINARY_PATCH_BLOCK_INTERNAL;

#define NUMBER_OF_PATCHES 15

static BINARY_PATCH_BLOCK_INTERNAL TempDataArray[NUMBER_OF_PATCHES] = {
	{ 0x3218d, 2, { 0x51, 0x52 } },
	{ 0x323f4, 2, { 0x51, 0x52 } },
	{ 0x32547, 2, { 0x51, 0x52 } },
	{ 0x32872, 2, { 0x51, 0x52 } },
	{ 0x32a14, 2, { 0x51, 0x52 } },
	{ 0x32b48, 2, { 0x51, 0x52 } },
	{ 0x3bf30, 2, { 0x51, 0x52 } },
	{ 0x11bf98, 8, { 0x4D, 0x61, 0x67, 0x69, 0x63, 0x61, 0x6C, 0x52 } },
	{ 0x1195e7, 0x1b, {
		0x44, 0x73, 0x64, 0x74, 0x46, 0x69, 0x6C, 0x65, 0x50, 0x61, 0x74, 0x68, 0x00, 0x53,
		0x73, 0x64, 0x74, 0x46, 0x69, 0x6C, 0x65, 0x50, 0x61, 0x74, 0x68, 0x00, 0x00}
	},
	{ 0xd8b6, 2, { 0xDE, 0x10 } },
	{ 0x12026, 2, { 0xDE, 0x10 } },
	{ 0x1f70e, 2, { 0xDE, 0x10 } },
	{ 0x41ef1, 2, { 0xDE, 0x10 } },
	{ 0x41f05, 2, { 0xAD, 0xDE } },
	{ 0x1f701, 2, { 0xDE, 0x10 } }
};

VOID BuildTable()
{
	int i;
	PUCHAR Table;
	DWORD dwTableSize, dwEntrySize;
	TCHAR szOutputFileName[MAX_PATH * 2];

	Table = (PUCHAR)LocalAlloc(LPTR, 0x1000);
	if (Table == NULL) return;

	dwTableSize = 0;
	for (i = 0; i < NUMBER_OF_PATCHES; i++) {
		dwEntrySize = sizeof(ULONG) + sizeof(UCHAR) + (sizeof(UCHAR) * TempDataArray[i].DataLength);
		if (dwTableSize + dwEntrySize > 0x1000) break;
		RtlCopyMemory(&Table[dwTableSize], &TempDataArray[i], dwEntrySize);
		dwTableSize += dwEntrySize;
	}
	GetCurrentDirectory(MAX_PATH, szOutputFileName);
	lstrcat(szOutputFileName, TEXT("\\output.bin"));
	WriteBufferToFile(Table, dwTableSize, szOutputFileName);

	LocalFree(HLOCAL(Table));
}
Best Regards,
-rin
All times are UTC
Page 2 of 25
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/