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

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

3
@JFX: thanks for the encouragement

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

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

5
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 > 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 > 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:

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

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

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

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

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

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

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

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

14
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 : https://msdn.microsoft.com/fr-fr/library/windows/hardware/ff557429(v=vs.85).aspx
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

15
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, perhaps....in romania also, good thing. But in french : nothing. No politic, yes, it's not the good site.

16
Win10PE SE HomePage / Re: In the boot Said: loading files...
« on: February 06, 2017, 01:47:02 AM »
i forget, you boot on a computer : uefi or bios ?

17
Win10PE SE HomePage / Re: In the boot Said: loading files...
« on: February 05, 2017, 11:37:05 PM »
hello teik,
Sorry for my bad english... i'm newbie with winpeduilder. I play to dicover winpe with it and play with microwinpebuilder and PS. So ....

Can you put the result of this command : bcdedit /store y:\boot\bcd where y: is the root of your key usb?
( command line is often better because it give more/full informations for the remote people, not only a piece of bcd ... )
I modify my bcd with bcdedit /store myRoot:\boot\bcd /set {bootmgr} locale en-US and i receive the text "Loading files...." at the begining of boot, when a big white progress bar comes. And come back to fr-FR with "Chargement des fichiers".
Does "yourRoot:\boot\es-ES\" directory not empty and contain bootmgr.exe.mui ?

For "please wait...", i found in my X:\windows\system32\pecmd.ini ( i product a winpese with session ADM ):
TEXT System configuration, Please Wait...#0xFFFFFF L59 T39 $20* <<<-------- is it "your" text ?
Can you say when and, better, where it appear on the screen, color, size, etc?
Do you know to read/modify the sequence to track it? (read/modify the system hive, setup\cmdline ? )
Are you sure it's not a third program that display it? if you select one or other feature/addon, scripts played in directories build/target are différents. Too many combinaisons. Can you product a basic winpese?
Many questions but you can forget it if you think it's not in the scope.

Hope this help.

18
Win10PE SE HomePage / Re: Remaining watermark
« on: February 05, 2017, 12:59:41 PM »
i think the text is "test mode" in English.
In your file BCD, there is a parameter "TESTSIGNING". Delete it with bcdedit. See documentation in ADK from ms site.
rem to see your bcd
bcdedit /store "your root\boot\bcd"
rem if {default} is good for you
bcdedit /store "your root\boot\bcd" /delete {default} TESTSIGNING
I think you use a checkbox "mode test for drivers" ( i don't remember the good text ) in winbuilder.
Hope this help

19
Win10PE SE HomePage / Re: In the boot Said: loading files...
« on: February 05, 2017, 11:59:34 AM »
Sorry for my English....

"Loading files" is displaying during the boot phase. The language is found in the file "root of your usb key\boot\BCD" on the active partition.
See the  presence of the directory"root of your usb key\boot\es-ES for spanish.

Winbuilder create the good directory fr-fr and the good bcd for me in the directory "target". Winbuilder make also my .ISO good. I see with 7Z.
After that, i copy all files in my key. Perhaps you create your bootable usb key with a tool that create a bcd in English.
How do you make your booting usb key ?

But you can easely modify your "bcd" with bcdedit. You can do that from winpe or from an active windows 10.
Assume you want to do from winpe.
Assume you boots on your key usb with only one partition. Winpe is active.
I don't remember that letter is affected by winpe to the "boot key usb". Assume it's Y:
Assume your usb key ( or usb disk) in not write protected
From a console in winpe  :
Code: [Select]
rem display actual parameters
bcdedit /store y:\boot\bcd
rem modify bootmgr
bcdedit /store y:\boot\bcd /set {bootmgr} local es-ES
rem modify the menu default if it the good for you
bcdedit /store y:\boot\bcd /set  {default} local es-ES
rem display the modifications
bcdedit /store y:\boot\bcd
rem And don't forget : copy the directory "your reference\boot\es-ES\*.*" in your usb key

I don't remember in which phase is displaying the message "Please, waiting...", perhaps in pecmd.ini or other .ini

In my memory ( i don't have winbuilder at this time ), there is a checkbox for catch regional parameters in the reference or in the host computer.
Did you see this checkbox?

Hope this help.

Ps : the winpe documentation in ADK from MS is good to read, command line tools ....




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

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