Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - noelBlanc

Pages: [1] 2 3 ... 6
Hi slore,
Thank for your feedback. My English is so poor that sometime, someone can't undestrand me.
When i said
And Yes, this solution is not a good idea because with the next version of winpe, the address will be modify.
I speak about "my" solution because address base + 2F9 can change with a new version of windows.
And yes, the WinpeSe team's solution with wind+MsgHook" is the best solution because it doesn't use an "hard" address but implement all the code that explorer.exe doesn't do.
And no, i'm not good in disassembling program. I use Windbg like a beginner.
just write 100 lines code in 1 or 2 hours
Bravo! i don't be able to do that.

You said
I want make a hard patch to switch the default jump, but the explorer.exe cann't startup with the change
- i use a exe and hook.dll to do that "dynamicaly" and put it on early posts
- do you modify the checksum of the file explorer after modify it ? I suppose yes but you don't say that. so i ask ....
- can you see with procmon64 some thing or make a save file .PML ?

note : as i understand the code and my test, it is also the first jne that must be disable not only the second. The flag is base + 2F9 in build 14393. And i don't know the role of Base+2F8. 
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'::`   >>>>>>>>> change jne to je
So, twice 6  "NOP" ( one for each jne ) seems to me to be better because "je" need to calculate the "delta" of offset.

See you later

Actually i work to get mstsc with RemoteDesktop Gateway server.
And i find that my scripts traitement.ps1  can't work with language en-us.
I 'll fix soon.
Constat : scripts not usefull because no one send me that scripts doesn't work.

But who sent this message 0x5BA in the case of a "normal" windows10?

We therefore have a breakpoint in Windows 10 "normal" on the address of the function PostMessage:

BA r 8 explore! _imp_PostMessageW ".if(rdx == 0x5BA) {.echo msg 5BA} .else {gc};"

There are several exceptions that activate Windbg. I do not account. And finally, the breakpoint is triggered with the 0x5BA message.
00007ff9`610dafa0 48895c2410      mov     qword ptr [rsp+10h],rbx ss:00000000`0326ef88=00007ff6a3496890
:010> r
rax=0000000000000000 rbx=00007ff6a3496860 rcx=000000000005021e
rdx=00000000000005ba rsi=0000000000000004 rdi=0000000000000000
rip=00007ff9610dafa0 rsp=000000000326ef78 rbp=000000000326efd0
 r8=0000000000000000  r9=0000000000000000 r10=00000fff28e681da
r11=0000000004010000 r12=00007ff6a3429040 r13=000000000005021e
r14=0000000000000000 r15=0000000000000003
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
00007ff9`610dafa0 48895c2410      mov     qword ptr [rsp+10h],rbx ss:00000000`0326ef88=00007ff6a3496890
0:010> k
 # Child-SP          RetAddr           Call Site
00 00000000`0326ef78 00007ff6`a32ba651 USER32!PostMessageW
01 00000000`0326ef80 00007ff6`a32b76d0 explorer!CTray::_RegisterForNotifications+0xf5
02 00000000`0326f000 00007ff6`a32f2b27 explorer!CTray::StartTaskbar+0xf4
03 00000000`0326f050 00007ff6`a32b7880 explorer!CTray::_StartTaskbarApiSurface+0x37
04 00000000`0326f080 00007ff6`a32b7a79 explorer!CTray::_StartParallelTasks+0xd8
05 00000000`0326f0c0 00007ff6`a32b6425 explorer!CTray::_HandleStartupProgress+0x155
06 00000000`0326f100 00007ff6`a32b4112 explorer!CTray::v_WndProc+0x945
07 00000000`0326f630 00007ff9`610d1c24 explorer!CImpWndProc::s_WndProc+0xe2
08 00000000`0326f680 00007ff9`610d156c USER32!UserCallWinProcCheckWow+0x274
09 00000000`0326f7e0 00007ff6`a32bac69 USER32!DispatchMessageWorker+0x1ac
0a 00000000`0326f860 00007ff6`a32f7ae3 explorer!CTray::_MessageLoop+0x149
0b 00000000`0326f8f0 00007ff9`5eef5aad explorer!CTray::MainThreadProc+0x43
0c 00000000`0326f920 00007ff9`60e88364 SHCORE!Microsoft::WRL::Details::RuntimeClass<Microsoft::WRL::Details::InterfaceList<CRandomAccessStreamBase,Microsoft::WRL::Details::InterfaceList<Windows::Storage::Streams::IRandomAccessStreamWithContentType,Microsoft::WRL::Details::InterfaceList<Windows::Storage::Streams::IContentTypeProvider,Microsoft::WRL::Details::InterfaceList<Microsoft::WRL::Implements<Microsoft::WRL::RuntimeClassFlags<3>,Microsoft::WRL::CloakedIid<IRandomAccessStreamMode>,Microsoft::WRL::CloakedIid<IRandomAccessStreamFileAccessMode>,Microsoft::WRL::CloakedIid<IObjectWithDeferredInvoke>,Microsoft::WRL::CloakedIid<IObjectWithFileHandle>,Microsoft::WRL::CloakedIid<IUnbufferedFileHandleProvider>,Microsoft::WRL::CloakedIid<IRandomAccessStreamPrivate>,Microsoft::WRL::CloakedIid<ITransactedModeOverride>,Microsoft::WRL::CloakedIid<CFTMCrossProcServer>,Microsoft::WRL::Details::Nil>,Microsoft::WRL::Details::Nil> > > >,Microsoft::WRL::RuntimeClassFlags<3>,1,1,0>::~RuntimeClass<Microsoft::WRL::Details::InterfaceList<CRandomAccessStreamBase,Microsoft::WRL::Details::InterfaceList<Windows::Storage::Streams::IRandomAccessStreamWithContentType,Microsoft::WRL::Details::InterfaceList<Windows::Storage::Streams::IContentTypeProvider,Microsoft::WRL::Details::InterfaceList<Microsoft::WRL::Implements<Microsoft::WRL::RuntimeClassFlags<3>,Microsoft::WRL::CloakedIid<IRandomAccessStreamMode>,Microsoft::WRL::CloakedIid<IRandomAccessStreamFileAccessMode>,Microsoft::WRL::CloakedIid<IObjectWithDeferredInvoke>,Microsoft::WRL::CloakedIid<IObjectWithFileHandle>,Microsoft::WRL::CloakedIid<IUnbufferedFileHandleProvider>,Microsoft::WRL::CloakedIid<IRandomAccessStreamPrivate>,Microsoft::WRL::CloakedIid<ITransactedModeOverride>,Microsoft::WRL::CloakedIid<CFTMCrossProcServer>,Microsoft::WRL::Details::Nil>,Microsoft::WRL::Details::Nil> > > >,Microsoft::WRL::RuntimeClassFlags<3>,1,1,0>+0x135
0d 00000000`0326fa10 00007ff9`61a470d1 KERNEL32!BaseThreadInitThunk+0x14
0e 00000000`0326fa40 00000000`00000000 ntdll!RtlUserThreadStart+0x21
The PostMessage call came from the "explore! CTray::_RegisterForNotifications".
00007ff6`a32ba622 488b4df0        mov     rcx,qword ptr [rbp-10h]
00007ff6`a32ba626 488b01          mov     rax,qword ptr [rcx]
00007ff6`a32ba629 488d5538        lea     rdx,[rbp+38h]
00007ff6`a32ba62d 488b4018        mov     rax,qword ptr [rax+18h]
00007ff6`a32ba631 ff15b1191800    call    qword ptr [explorer!_guard_dispatch_icall_fptr (00007ff6`a343bfe8)]
00007ff6`a32ba637 85c0            test    eax,eax
00007ff6`a32ba639 7817            js      explorer!CTray::_RegisterForNotifications+0xf6 (00007ff6`a32ba652)
00007ff6`a32ba63b 4c634538        movsxd  r8,dword ptr [rbp+38h]
0:010> u
00007ff6`a32ba63f 4533c9          xor     r9d,r9d
00007ff6`a32ba642 baba050000      mov     edx,5BAh >>>>>>>>>>>>>>>>>>>>> breakpoint
00007ff6`a32ba647 488b4b08        mov     rcx,qword ptr [rbx+8]
00007ff6`a32ba64b ff158f071800    call    qword ptr [explorer!_imp_PostMessageW (00007ff6`a343ade0)]
00007ff6`a32ba651 90              nop
00007ff6`a32ba652 488d4df0        lea     rcx,[rbp-10h]
00007ff6`a32ba656 e80534fcff      call    explorer!Microsoft::WRL::ComPtr<Windows::Foundation::IAsyncOperation<Windows::Foundation::Collections::IVectorView<Windows::ApplicationModel::StartupTask * __ptr64> * __ptr64> >::InternalRelease (00007ff6`a327da60)
00007ff6`a32ba65b 4c897540        mov     qword ptr [rbp+40h],r14
Found the code to send the 0x5BA message
The call to explore! CTray::_EnsureImmersiveShellPointer in Winpe will certainly pose a concern.
00007ff6`083eb005 e8dea6ffff      call    explorer!CTray::_EnsureImmersiveShellPointer (00007ff6`083e56e8)
0:010> p
00007ff6`083eb00a 85c0            test    eax,eax
0:010> r
rax=0000000080040154 rbx=00007ff6085c5820 rcx=0000000000000000
rdx=0000000080040154 rsi=0000000000000004 rdi=0000000000000000
rip=00007ff6083eb00a rsp=000000000361eeb0 rbp=000000000361ef00
 r8=000000000361e9c8  r9=00000000000021f5 r10=0000000000000000
r11=000000000361ec30 r12=00007ff608550d20 r13=0000000000030114
r14=0000000000000000 r15=0000000000000003
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
00007ff6`083eb00a 85c0            test    eax,eax
00007ff6`083eb00c 0f8860010000    js      explorer!CTray::_RegisterForNotifications+0x196 (00007ff6`083eb172) [br=1]
Code return rax = 0000000080040154 = class not registered.
The jump prohibits sending the msg 5BA.
The function "explore! CTray::_EnsureImmersiveShellPointer"use DCOM.
0:010> u explorer!CTray::_EnsureImmersiveShellPointer
00007ff6`083e56e8 4883ec38        sub     rsp,38h
00007ff6`083e56ec 4881c158030000  add     rcx,358h
00007ff6`083e56f3 33c0            xor     eax,eax
00007ff6`083e56f5 483901          cmp     qword ptr [rcx],rax
00007ff6`083e56f8 0f84fc5c0700    je      explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x13bba (00007ff6`0845b3fa)
00007ff6`083e56fe 4883c438        add     rsp,38h
00007ff6`083e5702 c3              ret
00007ff6`083e5703 cc              int     3
explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x13bba:
00007ff6`0845b3fa 48894c2420      mov     qword ptr [rsp+20h],rcx
00007ff6`0845b3ff 4c8d0d92381100  lea     r9,[explorer!GUID_6d5140c1_7436_11ce_8034_00aa006009fa (00007ff6`0856ec98)]
00007ff6`0845b406 488d0d139c1100  lea     rcx,[explorer!GUID_c2f03a33_21f5_47fa_b4bb_156362a2f239 (00007ff6`08575020)]
00007ff6`0845b40d 33d2            xor     edx,edx
00007ff6`0845b40f 41b804040000    mov     r8d,404h
00007ff6`0845b415 ff159dee1000    call    qword ptr [explorer!_imp_CoCreateInstance (00007ff6`0856a2b8)]
00007ff6`0845b41b 90              nop
00007ff6`0845b41c e9dda2f8ff      jmp     explorer!CTray::_EnsureImmersiveShellPointer+0x16 (00007ff6`083e56fe)
rcx = explorer!GUID_c2f03a33_21f5_47fa_b4bb_156362a2f239 -->> HKCR/c2f03a33_21f5_47fa_b4bb_156362a2f239/default=Immersive Shell, APPID={316cded5-e4ae-4b15-9113-7055d84dcc97} ( appid/runas=Interactive User )
rdx = NULL
r8  = 404h -->>> CLSCTX_LOCAL_SERVER = 0x4   CLSCTX_NO_CODE_DOWNLOAD = 0x400,
r9  = explorer!GUID_6d5140c1_7436_11ce_8034_00aa006009fa --------------->>>>>>>>>>>>> ?????????????

@="Immersive Shell"
@="Immersive Shell"
"RunAs"="Interactive User"
@="C:\\Windows\\System32\\OneCoreCommonProxyStub.dll" ------------------------------>>>>>>>>>>>>> ?????????????

How to go further?

Good thing !
I must say that i don't know the wm_taskbarcreated message before you speak about it.
Thanks for sharing the information

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...

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 ?

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....


@JFX: thanks for the encouragement

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

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:

0:010> u 00007ff6`01c96a74
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
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)
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]
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);
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?

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.
0:000 &gt; db 7FF7 '93FC5B19--->>> 00007ff7' 93fc5b19 00
BP USER32! RegisterClassExW
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:

@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 ?

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...

Hello ZEE
On the one hand there is the need efficiency in the work: a GUI as proposed by Lancelot, is a very good solution. Or an administration mode "command line" with "remote PowerShell", etc.
On the other side, there is the fun. As I do in MicroWinpeBuilder. where I mainly use the session administrator. I can say that, in the current state of knowledge shared in this forum, RDC/RDP entering winpe connections do not work, and regardless of the account. The Termservice service starts fine but refuse incoming connections. It does not listen on the TCP 3389 port as confirmed by "netstat - ano". And I assume that only the modification of binary code could work around this limitation.

Kind regards

Sorry for my bad english (bing.translator only)

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

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

hi ZEE,
Sorry for my bad English.
With MicroWinpeBuilder, I play with "Remote Desktop" and Winpe, as i say in the doc PDF.
I put all files and keys. I launch "net start termservice". And service is ok.
But i see this text with eventvwr.msc in  the log  "Windows/TerminalServiceslocalSesionManager" :
 "Remote Desktop Services do not logon because the Setup program is running".
And also, i see that the "TermService" service is not listening on port 3389 with "netstat – ano".
RDP is ok because i can launch mstsc in winpe and open a remote desktop on an other windows10 ( with NLA or not )
I'm not a guru, but, actually, i don't think an RDC incoming winpe can works.
For the fun, i replace it with PowerShell and wsman. i think psexec works. But the two tools are "console mode".
I'm curious, can you say to me why you want use a RDC into winpe?
if  my reply is out of your subject, forget me.

Win10PE SE HomePage / Re: Difference between WinBuilder an Win10PE SE?
« on: February 12, 2017, 12:43:49 AM »
For me, and it's just me (a beginner in the field):

-winbuilder is a shell evolved command contained in scripts located in the directory... \projects\win10PeSE.
Scripts describe the content of each screen. See section "[Interface]" in a script.  Entries of the operator are stored in variables.
The scripts also describe the actions that will be undertaken after the action on the "go" button. So, scripts traite entries of the operator. See section [Process] in a script.
- WinpeSE is therefore intelligence filed in scripts and therefore is also the name of the product that represents the final ISO .
In french, we say: i drink a glass. Glass, this is the way (winbuilder), we drink the content (using the scripts developed by a competent team), feels the pleasure of drinking or drunkenness (it has an advanced winpe).

Of course, I'll let product managers explain better.

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.

Win10PE SE HomePage / Re: In the boot Said: loading files...
« on: February 07, 2017, 01:15:47 AM »
Sorry, i miss UEFI.
For UEFI, the BCD is here : yourRoot\EFI\Microsoft\boot\bcd.
It's this file you can try to edit and verify the parameter "locale = Es-ES".
Perhaps the best way is the tool BCDBOOT.exe. It manage correctly  UEFI.
Hope this help.

Win10PE SE HomePage / Re: In the boot Said: loading files...
« on: February 06, 2017, 07:33:17 AM »
not a good news.
You modify boot.wim and only boot.wim (pecmd.ini only ) on the media usb. Can you describe how you do? witch tool?
Can you verify in boot.wim the presence of the file yourRoot\windows\system32\boot\winload.efi.
And the presence of yourRoot\windows\system32\boot\es-ES\winload.efi.mui
can you more describe the text error?

i find this :
So perhaps you can redo from scratch your Usb key ( FAT system File it seem ), format, initialize, active the partition, copy all files and boot
see you soon

Win10PE SE HomePage / Re: In the boot Said: loading files...
« on: February 06, 2017, 03:43:54 AM »
my pc is not uefi and i use vm in bios mode. I hope our masters and big chefs can bring a reply. I think i can test with hyperv and uefi, but later in the day.
I speek effectively about this bar : is it at this time that comes the text ?

For the line in pecmd.ini "TEXT System configuration, Please Wait...#0xFFFFFF L59 T39 $20* ", it's easy and at least two ways.
- one shot method : modify your boot.wim in the usb key ( not good for a disk DVD/CD ):
     - assume your usb disk/key is writable ( you can copy yourRoot\sources\boot.wim in a directory c:\mytest\ but not mandatory
     - mount the file boot.wim with DISM or mount-diskimage in PowerShell, as you like, in a new directory c:\mytest\mount
     - modify the file pecmd.ini in this directory c:\mytest\mount\windows\system32\pecmd.ini
     - unmount this directory with "DISM ... /commit" or "Dismount-DiskImage ... -save" in PowerShell, as you like
     -  copy back to usb key if need
With this method, you need to make each time this modification if you create a another instance of winpese

- second way : modify a script used by winpebuilder but too complex for me, i'm newbie in winpese

A bientôt

PS : many people in the street in catalogne. Good thing, romania also, good thing. But in french : nothing. No politic, yes, it's not the good site.

Pages: [1] 2 3 ... 6
Powered by EzPortal