Wednesday 25 August 2021

Visual Studio function address different in watch window from code

 In my code I had:

void function2()

{

    std::cout << "Malware payload that should never be run!\n";

}

and

void (*pFun)() = &function2;

When I inspect pFun it returns the address 

0x0092141f {BufferOverrunExample.exe!function2(void)}

But in the watch window it is



Why the difference?

If we inspect 0x0092141f  in the dissasembly window:


You can see it simply jumps to the same address as shown in the watch window. This is a jump table.

Why?

This explains about incremental linking
c++ - Why doesn't VS2015 debugger show the function address correctly in the watch window? - Stack Overflow

"This behavior seems to be because of incremental linking. When it is enabled, the function is assembled in one memory address and another address contains a jump table entry with one jump instruction to the 'real' address. The function is always called by calling the jump table. If you disable incremental linking, the 'detour' via the jump table goes away and also your example case shows just one address.

Everything else seems to show the address to the jump table, but the 'printStuff' and '&printStuff' watch expressions show the actual address where the function code is located."



Linkers & Jump tables

Canary bytes, prologues and epilogues

Stack Guard

Address layout randomisation

CC bytes

Mitigate threats by using Windows 10 security features (Windows 10) - Windows security | Microsoft Docs



Friday 6 August 2021

Terraform fails to import App Service Plan: ID was missing the `serverfarms` element

 When importing an Azure App Service Plan, using the resource ID copied from Azure Resource Explorer:

terraform import azurerm_app_service_plan.app "/subscriptions<mysubscriptionId>/resourceGroups<myresoureegroup>/providers/Microsoft.Web/serverFarms/<myAppServicePlan>"

I got the error:

Error: parsing Resource ID "XXX": ID was missing the `serverfarms` element

Note serverfarms is case sensitive and should all be lower case, wherease Azure Resource Explorer is camelCase.

Monday 2 August 2021