TransWikia.com

Is there a tool to reverse engineer UWP apps, similar to dnSpy for .NET?

Reverse Engineering Asked by c00000fd on September 30, 2021

I’ve been long fascinated with dnSpy and how easily it can reverse engineer .NET apps into a readable C#. So I was wondering if there’s a similar tool to RE Windows 10 UWP apps?

For instance, I tried Microsoft Settings app from C:Program FilesWindowsAppsMicrosoft.WindowsStore_12002.1001.1.0_x64__8wekyb3d8bbweWinStore.App.exe in dnSpy and it only gave me basic PE structure:

enter image description here

2 Answers

UWP is a container/platform, different reversing techniques are needed depending on the executable content. .NET UWP apps can be compiled to CLR, then you can use standard .NET decompilation techniques i.e. JustDecompile, .NET Reflector, etc. To identify if it is .NET you can use a tool such as CFF Explorer and it will list the file type as Portable Executable 32/64 .NET Assembly if .NET tools will be suitable. You will also see in the import directory mscoree.dll is listed.

However UWP .NET apps can also be compiled to .NET Native In addition UWP apps can be written in C++/CX and compiled directly to native code.

These will show in CFF explorer as Portable Executable 32/64

If we look at WinStore.App.exe in a native code reversing tool such as IDA Pro we can see it imports RHBinder_ShimExeMain from WinStoreApp.dll and it's entry point just jumps to this:

public start
start proc near
jmp     cs:RHBinder__ShimExeMain
start endp

We open this DLL and see this function:

public RHBinder__ShimExeMain
RHBinder__ShimExeMain proc near
push    rbp
mov     rbp, rsp
sub     rsp, 20h
call    sub_1817A55B4
lea     rsp, [rbp+0]
pop     rbp
retn
RHBinder__ShimExeMain endp

Which simply calls this function:

sub_1817A55B4 proc near
; __unwind { // 182523A80
push    rbp
mov     rbp, rsp
sub     rsp, 30h
lea     rax, [rbp-10h]
call    cs:RhpReversePInvoke
call    cs:CreateCommandLine
mov     rcx, rax
call    sub_18173A000
xor     eax, eax
lea     rcx, [rbp-10h]
call    cs:RhpReversePInvokeReturn
lea     rsp, [rbp+0]
pop     rbp
retn
; } // starts at 1817A55B4
sub_1817A55B4 endp

Using a tool like Hex Rays Decompiler you can get pseudocode representation in C:

__int64 sub_1817A55B4()
{
  __int64 v0; // rax
  char v2[16]; // [rsp+20h] [rbp-10h] BYREF

  RhpReversePInvoke();
  v0 = CreateCommandLine();
  sub_18173A000(v0);
  return RhpReversePInvokeReturn(v2);
}

If we look at DllEntryPoint of the DLL we find the following:

BOOL __stdcall DllEntryPoint(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
{
  BOOL result; // eax

  if ( *(_QWORD *)&fdwReason == 1i64 )
    result = sub_1817A5650(hinstDLL, 1i64, lpReserved);
  return result;
}

If we follow sub_1817A5650 and sub functions it calls we end up at:

__int64 sub_1817A55FC()
{
  char v1[16]; // [rsp+20h] [rbp-10h] BYREF

  RhpReversePInvoke();
  RhpSuppressGcStress();
  RhpRegisterModule(&unk_180001000);
  nullsub_1();
  nullsub_1();
  nullsub_1();
  nullsub_1();
  RhpUnsuppressGcStress();
  return RhpReversePInvokeReturn(v1);
}

unk_180001000 points to the following:

enter image description here

Working out the purposes of these API calls and this data structures will help you reverse the UWP apps.

I would use tools such as IDA Pro with Hex Rays Decompiler or Ghidra

However if you are coming from .NET decompilation, do not expect this to be nearly as easy or for automatic tools to produce results that look like nearly compilable code. It is significantly more effort reversing native code.

If we launch the app with WinDbg Preview from Windows store using File -> Launch App Package method we can see this app loads the .NET Native runtime as modules load. This explains why the standard .NET reversing tools will not work on this EXE:

ModLoad: 00007ff9`b6280000 00007ff9`b6306000   C:Program FilesWindowsAppsMicrosoft.NET.Native.Runtime.2.2_2.2.28604.0_x64__8wekyb3d8bbwemrt100_app.dll
ModLoad: 00007ff9`b34f0000 00007ff9`b41bd000   C:Program FilesWindowsAppsMicrosoft.NET.Native.Framework.2.2_2.2.27912.0_x64__8wekyb3d8bbweSharedLibrary.dll

If trying to identify how some specific behavior works it may be easier to use the debugger.

The Windows Metadata (WinMD) files in the app's folder can be browsed with some .NET decompiler tools and allow you to browse interface/type definitions but these don't contain code as far as I know.

Answered by chentiangemalc on September 30, 2021

UWP apps are mostly native code unlike .NET apps which use CLR bytecode. Native code is much harder to analyze and decompile.

Answered by Igor Skochinsky on September 30, 2021

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP