Topic: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?  (Read 15103 times)

0 Members and 1 Guest are viewing this topic.

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #120 on: February 02, 2017, 07:07:07 AM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 111
@ChrisR
From Session System : files are downloaded well but not display
I find them ( many try before i see in directory) in directory.
See picture...

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #121 on: February 08, 2017, 07:31:17 AM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 111
I continue to play with IE11-64bits in the ADM session. I wanted to use the debugger F12. At first, it miss some files.
Now, i can get the network trace. it use the service "diagnosticshub.standardcollector.service".
I tryed also "fiddler". In my first test, fiddler ask to install its certificat for https. I install it with certutil.exe.
Not a revolution.

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #122 on: March 08, 2017, 07:03:57 AM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 111
Hello,
Today, i play with windbg.exe. I look into the code of Shell_TrayHwd.
As said in some posts before, with SPY, and as it was said in old posts in theoven, the message 0x579 is send to the wndproc Shell_TrayHwd when you want swap to/from the desktop. With windbg, i find a byte in this wndproc which enable the displying of the desktop, and the reverse swap.
I put here some informations from IE in winpe ( yes, it woks enougth but i can't attach a file ).
I translate as soon as possible.

A -Configure the symbol servers and the network for windbg

B - We saw with spy ++ thewindow Shell_TrayHwd receives the message 0 x 579 with wParam = 3

C - identify the handle and address of WndProc to Shell_TrayHwd
   with spy ++ that gives the offset of this window and the handle
   with a bit of PS that gives the Hinstance which we keep the segment
   7ff7`B8714A40

D - so we can attach windbg to process explorer.exe (office administrator)

1 - We put a conditional breakpoint with:
   bp 7ff7`B8714A40 ".if (rcx == 0x2007E  &  rdx == 0x579 &  r8 == 3) {.echo msg ok} .else {gc;}"

E - we click below and to the right of the screen

F - activity of windbg greatly slows the process 'explore': wait

2 - code analysis activity: the wndproc begins with a big "switch" to process messages WM_xxxxxxxx

3 - symbols and step by step allow to navigate in the code
   Explorer!CImpWndProc::s_WndProc      : pour la wndproc
   Explorer!CTray::v_WndProc                    : for the treatments carried out by this wndproc, other messages are sent to "child" windows (I suppose)

4 - the switch is sometimes complex because optimized by the compiler certainly.
   Here the value of the message 0 x 579 is manipulated pure become an index into a table of pointers
   Explorer!CTray::v_WndProc+0x404:
   00007ff7`b8716964 8d83affaffff    lea     eax,[rbx-551h]
   00007ff7`b871696a 83f87d          cmp     eax,7Dh
   00007ff7`b871696d 779c            ja      Explorer!CTray::v_WndProc+0x3ab (00007ff7`b871690b) [br=0]
   00007ff7`b871696f 488d158a96fbff  lea     rdx,[Explorer!std::_Uninit_move<Microsoft::WRL::ComPtr<IBadgeVisualRenderRequest> * __ptr64,Microsoft::WRL::ComPtr<IBadgeVisualRenderRequest> * __ptr64,std::allocator<Microsoft::WRL::ComPtr<IBadgeVisualRenderRequest> >,Microsoft::WRL::ComPtr<IBadgeVisualRenderRequest> > <PERF> (Explorer+0x0) (00007ff7`b86d0000)]
   00007ff7`b8716976 0fb68402607b0400 movzx   eax,byte ptr [rdx+rax+47B60h] ds:00007ff7`b8717b88=0d
   00007ff7`b871697e 8b8c82a87a0400  mov     ecx,dword ptr [rdx+rax*4+47AA8h] ds:00007ff7`b8717adc=0004698a
   00007ff7`b8716985 4803ca          add     rcx,rdx
   00007ff7`b8716988 ffe1            jmp     rcx {Explorer!CTray::v_WndProc+0x42a (00007ff7`b871698a)}

5 - Continuing the step by step, we find a call whose name is evocative
   Explorer!CTray::v_WndProc+0x43d:
   00007ff7`b871699d e88af1ffff      call    Explorer!CTray::_RaiseDesktop (00007ff7`b8715b2c)

6 -Continuing, we find a test that sends in a case of mistaken (my assumption at the time because of there also evocative text)
   Explorer!CTray::_RaiseDesktop+0x29:
   00007ff7`b8715b55 3899f9020000    cmp     byte ptr [rcx+2F9h],bl ds:00007ff7`b88f5b19=01  <<<<<<<<<<<<<<< the byte !!!
   00007ff7`b8715b5b 0f85ab5a0700    jne     Explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor    for 'wrapper''+0x13dcc (00007ff7`b878b60c) [br=1]

G - I leave windbg and the stimulus to place a single breakpoint on this cmp instruction in order to change the value of this byte
   bp 00007ff7`b8715b55 ".if (r8 == 0x579 &  r9 == 3) {.echo msg ok} .else {gc;}"

H - I click at the bottom right of the screen

I - i change the byte

J - toggles the display takes place! It persists as long as I am not leaving the administrator session.

Conclusion: this isn't a huge step forward. But this has occupied my day.
« Last Edit: March 08, 2017, 07:24:01 AM by noelBlanc »

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #123 on: March 21, 2017, 01:17:40 PM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 111
hello,
It was very long, but i get it : with a hook DLL, i can reset the byte "base +2F9".

And now, the touch "Windows + D" is enabled/active. :wink:

Yes, winPeSe got it since a long time with the use of  "wind.exe and MsgHook.dll".
And Yes, this solution is not a good idea because with the next version of winpe, the address will be modify.

But now, with windbg, it become perhaps possible to find why and when this byte is set to 1.

For my memory, the base is given by SPY++ in the "windows Bytes".

I put the tow codes here. I compile them with VSCommunity 2013 in 64bits only. Create a project and add these codes seems simple.
And yes, my code is horrible, i'm not a good developper.

For install : in a cmd,  launch the program, it puts a hook in Shell_TrayWnd and wait, so explorer launch the dll, the dll modify the byte, you can press a touch in the cmd , so the program remove the hook. If explorer is killed ( tscon 1 for sample) the byte decomes set to 1. And it need to do again.
Sorry for my english. I hope someone can understand...

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #124 on: March 22, 2017, 12:46:55 AM »

JFX

  • Code Baker
  • Sr. Chef
  • ****
  • Date Registered: Dec 2010
  • Posts: 830
Great work Noel  :thumbsup:

For x86 it's *CTrayObj + 0x231

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #125 on: March 22, 2017, 01:13:33 AM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 111
@JFX   I am very touched by your words of encouragement.

It's true that I leave completely to one side the 32-bit version. I'm not quite good to manage multiple environments.
Currently, I'm trying to follow the creation of this byte with windbg. The breakpoint "ba r 1 adr" when loading to explore does not fire when setting to 1. Here, I do not understand.
Perhaps not the good method....

PS : Do you think it will be possible to find "automaticaly" the address of this byte for the next versions ?

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #126 on: March 22, 2017, 02:51:34 AM »

JFX

  • Code Baker
  • Sr. Chef
  • ****
  • Date Registered: Dec 2010
  • Posts: 830
Hmm, will be difficult to find it for other version.
Would be easier if we could find the reason why this byte is set in WinPE.

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #127 on: March 23, 2017, 12:21:53 AM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 111
hello,
Not easy to follow the life of this byte. The "ba r 1 adr" breakpoint does not work when this bit is set to 1. But he triggered when readings. The doc makes it clear that the option "r" means "read and write". I tried to "go back" since the RegisterClass call. But this byte is already positioned before the first call.
Quote
0:000 &gt; db 7FF7 '93FC5B19--->>> 00007ff7' 93fc5b19 00
BP USER32! RegisterClassExW
g
ModLoad: 00007ff8 '18840000 00007ff8' 1886e000 X:\windows\System32\IMM32. DLL
ModLoad: 00007ff8 '18f60000 00007ff8' 190bb000 X:\windows\System32\MSCTF.dll
Breakpoint 0 hit
0:000 &gt; db 7FF7 '93FC5B19--->>> 00007ff7' 93fc5b19 01
Seeking a little more (even a long time), I find a loop (n = 0 x 19): call msvcrt! _guard_dispach_icall_fptr. It is located in msvcrt! initterm + 0x3d. Byte changes value between 0xB and 0x16 iterations. I missed a good time.
As it is certainly the initialization of global data, I guess that the default value is 1. And so this byte must certainly change its value by an external action (message or subsequent test).
It seems more sensible to put a breakpoint "ba" on this byte in loading a explore in w10. But I must say that I am a little tired today. :sad:

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #128 on: March 23, 2017, 06:22:48 AM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 111
Today it's raining.
I just follow changes to the byte 2F9 in "explorer.exe" in Windows 10 build 14393.rs1_release_inmarket.170303 - 1614. But I think that would be the same in all versions of this build 14393.
The attached file contains the trace of the windbg and my comments in french.
I translate the most important here.
Getting started: check the address and the 'windows bytes' with spy ++ to the window "Shell_TrayWnd".
Start windbg. Kill Explorer.exe. In windbg, open the program "explorer.exe".
compute the address of the byte: the basis is provided by spy ++ in the 'windows bytes'. Add 2F9 for build 14393.
Note: I don't remember if I explained how to find this address.
Place the breakpoint:
ba w 1 00007ff6'01e76b59
and GO (g in the file)
explore starts and loads more other dll.
If the address is correct then the breakpoint is triggered.
Breakpoint 0 hit
explore! CTray:v_WndProc + 0xfa6:
00007ff6'01c96a86 84c0 test al, al                                     it is the previous instruction which is important!

Now, how to get le code before this instruction ?
Because it's really the previous code that will tell who and how this byte is changed. Try to deassemble going up in addresses, we quickly found that it is not possible to identify the address of the "jmp" that brought on this "move in 00007ff6'01c96a7f" in my case.
Therefore start from the entrance of the WndProc of a window.

But by looking at the values of the registers and in constant statements following the code launch a "PostMessage", I think that the treatment should not be very long and that may be what would be a response to another message and why "0X5BA" contained in the registers "rbx" and r8.

so we go to the WndProc with:
u explore! CTray::v_WndProc
see the code in the file if you need...

I guess that the msg = 5BA like i see in rbx and r8 at the time of the "BA" breakpoint
I need to get the good address :
00007ff6`01c95ef6 0fb68402e0700400 movzx   eax,byte ptr [rdx+rax+470E0h]
00007ff6`01c95efe 8b8c8228700400  mov     ecx,dword ptr [rdx+rax*4+47028h]
00007ff6`01c95f05 4803ca          add     rcx,rdx
00007ff6`01c95f08 ffe1            jmp     rcx
So :
rax = 0x5BA -0x551  = 0x69
rdx = 00007ff6'01c50000? the charging base of the prg according to the logic of loading to a prg in PE format
byte * ptr = [rdx + rax + 470E0h] = 00007ff6'01c50000 + 0x69 + 0x470E0 = 00007ff6'01c97149 = 0x1B
0:010 d 00007ff6'01c97149
00007ff6'01c97149 1b 1c 2d 1d 1e 1f 2d 20-21 22 23 24 25 26 27 2d... -...- !" #$%&'-
DWORD * ecx = [rdx + rax * 4 + 47028 h] = 00007ff6'01c50000 + (0x1B * 4) + 0 x 47028 = 00007ff6'01c97094
0:010 d 00007ff6'01c97094
00007ff6'01c97094 74 6a 04 00 e0 65 04 00-45 6a 04 00 63 04 00 tj b9 e... EJ... c...
                  74 6a 04 00 in memory = 0004674 in address
rcx = 00007ff6'01c50000 + 0x00046A74 = 00007ff6'01c96a74

And jmp     rcx !
And there's the code in 00007ff6'01c96a86 at the breakpoint :smile:

Quote
0:010> u 00007ff6`01c96a74
explorer!CTray::v_WndProc+0xf94:
00007ff6`01c96a74 397d88          cmp     dword ptr [rbp-78h],edi
00007ff6`01c96a77 0f8526660700    jne     explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x15123 (00007ff6`01d0d0a3)
00007ff6`01c96a7d 8bc7            mov     eax,edi
00007ff6`01c96a7f 418887f9020000  mov     byte ptr [r15+2F9h],al >>>>>>>>>>>>>>>>> on retrouve bien l'adresse du ba
00007ff6`01c96a86 84c0            test    al,al
00007ff6`01c96a88 0f851f660700    jne     explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x1512d (00007ff6`01d0d0ad)
00007ff6`01c96a8e 4138bff8020000  cmp     byte ptr [r15+2F8h],dil
00007ff6`01c96a95 0f8512660700    jne     explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x1512d (00007ff6`01d0d0ad)
0:010> u
explorer!CTray::v_WndProc+0xfbb:
00007ff6`01c96a9b 440fb6c0        movzx   r8d,al
00007ff6`01c96a9f 4533c9          xor     r9d,r9d
00007ff6`01c96aa2 ba0c040000      mov     edx,40Ch
00007ff6`01c96aa7 498b8fa0000000  mov     rcx,qword ptr [r15+0A0h]     DESTINATAIRE INCONNU unknow dest but but but .....
00007ff6`01c96aae ff15c4431800    call    qword ptr [explorer!_imp_SendMessageW (00007ff6`01e1ae78)]
00007ff6`01c96ab4 e918f3ffff      jmp     explorer!CTray::v_WndProc+0x2f1 (00007ff6`01c95dd1)
Summarizes:
someone sends the message 0x5BA with Wparam = 0 and lParam = 0 at the window "Shell_TrayWnd"

The final test: winpe into this piece of PS
Code: [Select]
$code=@'
using System;
using System.Runtime.InteropServices; 
namespace Win32_API
{
public class Win32_API_Class
{
[DllImport("user32.dll", SetLastError = true)]
public static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
[DllImport("user32.dll", SetLastError = true)]
public static extern IntPtr FindWindowEx(IntPtr parentHandle, IntPtr childAfter, string className,  string windowTitle);
[DllImport("user32.dll")]
public static extern int SendMessage(int hWnd, int hMsg, int wParam, int lParam);
}
}
'@
add-type -TypeDefinition $code

$handle = [Win32_API.Win32_API_Class]::FindWindow("Shell_TrayWnd", "");
$iRet   = [Win32_API.Win32_API_Class]::SendMessage($handle, 0x5BA, 0, 0);

Et Bingo !

It would be interesting to know who is the sender of this message 5BA.
Is it a method without  windbg?
« Last Edit: March 23, 2017, 06:34:10 AM by noelBlanc, Reason: error in the translation »

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #129 on: March 23, 2017, 07:07:00 AM »

JFX

  • Code Baker
  • Sr. Chef
  • ****
  • Date Registered: Dec 2010
  • Posts: 830
You rock man  :thumbup:

Seems it's explorer himself who send this message.

ila_rendered

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #130 on: March 23, 2017, 07:18:12 AM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 111
@JFX: thanks for the encouragement

I think I recognise a listing generated by IDA. Isn't it ?

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #131 on: March 23, 2017, 07:26:45 AM »

JFX

  • Code Baker
  • Sr. Chef
  • ****
  • Date Registered: Dec 2010
  • Posts: 830
Yes it's IDA 6.8 with loaded x64 explorer.exe version 14393.

I guess the CTray object has it's own function to enable\disable the show desktop functionallity.

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #132 on: March 23, 2017, 07:38:29 AM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 111
is IDA 64bits 6.8  free of charge ?

With windbg i can see explorer!CTray::ModeChanged.
I don't know if i can find some thing if i put a BP.
Perhaps with the crossref....

Merci.

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #133 on: March 23, 2017, 12:24:35 PM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 111
hello,
i open explorer.exe in windbg on my windows10 "normal"
i  put a breakpoint on explorer!CTray::ModeChanged.
And "go" with "g" : No hit !
I try twice.
I don't understand why. Is it possible that there are an other code in explorer that send the 5BA message ?

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #134 on: March 23, 2017, 10:22:19 PM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 111
hello,
I put a "ba w 1 add_2F9" in a explorer on windows10 "normal".
I can't see the transmitter's handle. But i can see the destinataire's handle of the msg 0X40C (send when the byte is reset).
It's "TrayNotifyWnd".
If i suppose transmitter is also the destinataire. Do you think so ?
In this case, can we imagine a handshaking ( i hope it's the good word ) between these 2 windows?
- shell_TrayWnd sets by default the flag 2F9 : witch means that TrayNotifyWnd is not create
- TrayNotifyWnd sends the msg 5BA : that means that TrayNotifyWnd is ok
- shell_TrayWnd  resets the byte and now can operate the events ( keyboard, menu, msg ) about  "display desktop"
If so, why is it different in winpe?
A long way to explore TrayNotifyWnd ....
Sun is shining so i go to cycle :smile:

PS : during the manipulation, in windbg, I used the "p" command to execute the call to postMessage 40 c. Then I let the program continue with "g". And now wanting to shut down the pc, I see that the 'windows' key and click 'mouse' on the window at the bottom left are inactive as in Winpe. Something to follow can be...
« Last Edit: March 23, 2017, 10:29:40 PM by noelBlanc »

 

Powered by EzPortal