1

Topic: The program to entry point, at a loading stage

2

Re: The program to entry point, at a loading stage

Hello, CaptainFlint, you wrote: CF> When I for the sake of experiment altered the project on CRT-shnyj, problems stopped, that is the bypass way is found. But I would like to understand: CF> 1) That it for falling? Than it can be caused and how it to avoid? And why it works-works, and then suddenly decides, what from it suffices? CF> 2) What-such magic image the system remembers  programs? I suspect failure in any prefetch, but I do not know how to check up. Renewal of operation after file "update" explicitly hints at any technologies of caching. However in the directory c:\Windows\Prefetch\there is no file with a name, beginning addressed to my executed file. Variants: 1. That that in TLS Callback. Look, whether is  in a file if is, delete to eliminate their influence. 2. If TLS Callback is not present, or after their removal all the same falls, probably, someone  in process (for example, the same Windows Defender or other antivirus). Try to disconnect an antivirus, completely.

3

Re: The program to entry point, at a loading stage

4

Re: The program to entry point, at a loading stage

Hello, CaptainFlint. Judging by contents kernel32! BaseThreadInitThunk in Windows 7, call rdx is a jump on entry point in a start stream function, i.e. it is normal either threadstartex, or main/WinMain. It seems that or any another's flow put in operation exe, or someone unintentionally impaired a little contents of registers at process start (such in the theory can be at the installed antiviruses, , DLP, etc. programs). It is possible to open still kresh-damp in WinDBG and to execute such command: dps @rsp L300 (review of a "crude" stack) or dps began the end (the beginning and the stack end are pulled out by a command! teb, fields StackBase and StackLimit) see. Well and further in a stack to try to find "originator" of a problem, i.e. any indirect unit or function.

5

Re: The program to entry point, at a loading stage

6

Re: The program to entry point, at a loading stage

7

Re: The program to entry point, at a loading stage

Hello, CaptainFlint, you wrote: CF> Caught falling, disconnected , falling anywhere did not get to. CF>... It is possible to try to dig more deeply if there is a desire... Happen at me such problem, I would try to start "the fail" version of application from WinDBG and to deliver break point on ntdll! NtTestAlert. And then, when it works, would look for structure CONTEXT in a stack - it lies normally in the very bottom a stack and values of registers are stored in it for a jump on entry point, i.e. for RtlUserThreadStart and main/WinMain. If on an input in NtTestAlert in structure CONTEXT value RCX already specifies not on main/WinMain, or Rip specifies in something another instead of RtlUserThreadStart, means, with probability of 99.9 %, "the third forces" interfere with process start. If RCX changes already after NtTestAlert, i.e. for example between NtTestAlert and an input in RtlUserThreadStart it means that value changes any asynchronous procedure (APC), since They just also are delivered during this moment. And this mechanism antiviruses and to that a similar software for implementation in processes of the code quite often use. Sometimes and in ""the disconnected"" state too.

8

Re: The program to entry point, at a loading stage

9

Re: The program to entry point, at a loading stage

10

Re: The program to entry point, at a loading stage

11

Re: The program to entry point, at a loading stage

12

Re: The program to entry point, at a loading stage

13

Re: The program to entry point, at a loading stage

CF> I fixed Falling, for the main operation simply copied files under other name, and "fail" left without modifications for the further analysis. Who and how (what function) launches this process?

14

Re: The program to entry point, at a loading stage

15

Re: The program to entry point, at a loading stage

Hello, , you wrote: > Something the code looks oddish. Like sub rsp, 28h shows that by a call there will be 5 parameters. But parameters are transferred through RCX, RDX, R8, R9 and the fifth through a stack. > and here it turns out, what the subroutine as 2nd parameter is launched? Not clearly. And hardly there are still any calls more low? Here the full code of function: BaseThreadInitThunk: 0000000076E559C0 sub rsp, 28h 0000000076E559C4 test ecx, ecx 0000000076E559C6 jne BaseThreadInitThunk+16h (076E559D6h) 0000000076E559C8 mov rcx, r8 0000000076E559CB call rdx 0000000076E559CD mov ecx, eax 0000000076E559CF call qword ptr [__ imp_RtlExitUserThread (076EDCE88h)] 0000000076E559D5 int 3 0000000076E559D6 test byte ptr [7FFE02D0h], 10h 0000000076E559DE je BaseThreadInitThunk+4Fh (076E55A0Fh) 0000000076E559E0 mov rax, qword ptr gs: [30h] 0000000076E559E9 mov rcx, qword ptr [rax+60h] 0000000076E559ED mov rcx, qword ptr [rcx+10h] 0000000076E559F1 call qword ptr [__ imp_RtlImageNtHeader (076EDC7C0h)] 0000000076E559F7 test rax, rax 0000000076E559FA je TlsGetValue+178FBh (076E78E9Bh) 0000000076E55A00 mov ecx, 8000h 0000000076E55A05 test word ptr [rax+5Eh], cx 0000000076E55A09 je TlsGetValue+178FBh (076E78E9Bh) 0000000076E55A0F xor eax, eax 0000000076E55A11 add rsp, 28h 0000000076E55A15 ret

16

Re: The program to entry point, at a loading stage

Hello, , you wrote: > Then it is clear. But it can not the reason, and already far consequence At the moment of creation of a subject I of it did not know,  to what a smog itself get to the bottom. > In my opinion this function does two things, depending on 1st parameter 0/1. Whether it or actually launches the program or checks it is possible to launch it (whether i.e. at it the correct title). > Then call rdx is and there is a start of the program. I.e. it only a call of an input point in title EXE. And that is why such address by a call is a question. > by the way, Entry Point in title EXE, probably, not the such? Here in a parallel branch already reached that else before the quoted function the entry point address should lie in RCX (in RDX it it is copied already then), and upon something there lies another (though and ), specifying in nonexistent page. The reasons while are not clear. > can forbid to load EXE to any addresses? Yes, at me too such thought arose. I already  with an appropriate option also interposed this variant for constant usage, but it is necessary to wait, while will be played back (if will be played back). But even if it repairs a problem, it would be desirable to understand that happens. Repair I could also banal reset CRT.

17

Re: The program to entry point, at a loading stage

Hello, CaptainFlint, you wrote: CF>... CF> Eh, as though these "the third forces"  ... is desirable now without a nuclear debugger and without "undressing" of system from all installed programs ... It seems, I start to guess, in what there can be a business. Application does not have section.reloc (), i.e. the executed unit does not support loading to the arbitrary address: (all superfluous )>! dh hideconsole_hdls SECTION HEADER #1.text name 0 file pointer to relocation table 0 number of relocations SECTION HEADER #2.rdata name SECTION HEADER #3.pdata name SECTION HEADER #4.rsrc name But flags ' Dynamic base ' and ' High entropy VA supported ' which operation is based just on  the executed unit in storage on  to addresses are thus specified: OPTIONAL HEADER VALUES 8160 DLL characteristics High entropy VA supported Dynamic base NX compatible Terminal server aware Also it is important that in title the flag ' Relocations stripped ' (see an option/FIXED the linker) on which the system could understand precisely is not specified that application should boot to strictly fixed address: FILE HEADER VALUES 22 characteristics Executable App can handle> 2gb addresses-> there is here more nothing smile Indirectly in a problem specifies it:" When I for the sake of experiment altered the project on CRT-shnyj, problems stopped ". As I understand, CRT adds section.reloc. And one more observation (it is peeped in ). A command! dh produces 13f310000 image base, i.e. 13f310000 - the preferable address of loading of the unit in storage. The unit has been loaded (and ) to 13f720000 address (a command lmv m hideconsole_hdls). And the exception arose at access attempt to 13fb31000 address (see! analyze-v). And so, 13f720000 - 13f310000 = 410000. But that is interesting, 13fb31000 - 13f720000 = 411000. I.e. a difference between the preferable and real address of loading of the unit same, as between the real address of loading and the address where there was an exception. 1000 it is not counted, it  from the beginning of loading of the unit to entry point. Here only I also do not know, whether a bug it in system or in a Visual Studio which allows to set"contradictory"adjustments of configuration...

18

Re: The program to entry point, at a loading stage

Hello, okman, you wrote: O> It seems, I start to guess, in what there can be a business. O> application does not have section.reloc (), i.e. the executed unit does not support loading to the arbitrary address: Here so a find! The enormous thanks, I will understand with options. Meanwhile only had time to try/FIXED:NO, but he  did not add (that is expected, for it and so  value for programs), and on  time yet it was not possible to find. Plus arose , than options/FIXED:NO and/DYNAMICBASE ... generally differ

19

Re: The program to entry point, at a loading stage

Hello, CaptainFlint, you wrote: CF> Meanwhile only had time to try/FIXED:NO, but he  did not add (that is expected, for and CF> so  value for programs), and on  time yet it was not possible to find it.  here it is not added, because the code very compact and without CRT. Probably, it turned out completely  and the section  simply is not necessary to it. CF>... Than generally options/FIXED:NO and/DYNAMICBASE ... differ When the flag ' FIXED:NO ' is specified, the section  is generated, but the system all the same will try to load first of all the unit to the preferable address, and only if it is impossible, for example the address is already occupied by other unit, will move it. When the flag ' DYNAMICBASE ' is specified, the system tries to load at once the unit to the arbitrary address (, see technology ASLR). HIGHENTROPYVA adds even more  in this process. A difference, as far as I understand, only in it. By the way, on the last Windows it is possible to forbid program an applications launch,  without support  + ASLR, see SetProcessMitigationPolicy + ProcessASLRPolicy.

20

Re: The program to entry point, at a loading stage

21

Re: The program to entry point, at a loading stage

Hello, CaptainFlint, you wrote: O>> Relokatsy here is not added, because the code very compact and without CRT. O>> it is visible, it turned out completely  and the section  simply is not necessary to it. CF> but after all if it turned out  the problem would not arise? It was told earlier:>> application does not have section.reloc (), i.e. the executed unit does not support loading to the arbitrary address: it seems To me, the problem arises that DYNAMICBASE and-or HIGHENTROPYVA cannot work correctly if at the unit is not present . Even if there completely  the code and to it these  are not necessary. Creation of the unit without CRT is in itself rare enough scenario and hardly Microsoft tests it so carefully as it is required. Probably, it is any bug in the system loader of units. There is nothing while to add Probably more, I generally am mistaken and actually the problem 0xC0000005 is covered somewhere in perfect other place.

22

Re: The program to entry point, at a loading stage

Hello, CaptainFlint, you wrote: CF> But after all if it turned out  the problem would not arise? It was told earlier: the Problem arises at launching process: parent process should specify entry point in the first thread of process. At a problem file what image base it is specified in file title on a disk? Casually not 000000013fb30000 == 000000013fb31000 (a falling point) - 1000 (entry point)?

23

Re: The program to entry point, at a loading stage

Hello, okman, you wrote: CF>> Eh, as though these "the third forces"  ... is desirable now without a nuclear debugger and without "undressing" of system from all installed programs ... O> It seems, I start to guess, in what there can be a business. O> application does not have section.reloc (), i.e. the executed unit does not support loading to the arbitrary address:  for call EntryPoint are not necessary! P.S.  and apparently process 64 bit where with probability of 99.9 %  are not necessary also to all remaining (to smoke manuals about RIP addressing).

24

Re: The program to entry point, at a loading stage

Hello, drVan, you wrote: V> Reloki for call EntryPoint are not necessary! Theoretically, yes, should not be necessary. But, probably, it is any bug in the loader which cannot correctly process entry point offset at absence . Anyway, other hypotheses explaining the stored facts, was not yet. V> P.S.  and apparently process 64 bit where with probability of 99.9 %  are not necessary also to all remaining (to smoke manuals about RIP addressing). Nevertheless, when I collect with CRT, the table  appears.

25

Re: The program to entry point, at a loading stage

Hello, EreTIk, you wrote: CF>> But after all if it turned out  the problem would not arise? It was told earlier: ETI> the Problem arises at launching process: parent process should specify entry point in the first thread of process. At a problem file what image base it is specified in file title on a disk? Casually not 000000013fb30000 == 000000013fb31000 (a falling point) - 1000 (entry point)? Image base: 0000000140000000