Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

TCMD crash after upgrading to Windows 10

dcantor

dcantor

May
607
4
After upgrading to Window 10, when I start TCMD 17.00.77 x64, the TCMD window starts, a TCC session starts in a tab,
then TCMD crashes, and the TCC window remains. I've tried this both elevated and non-elevated, the results are the same.
 
If the crash is in TCMD, you'll have a "TCMD.GPF" file (in the same directory as your TCMD.INI). Please send that file to [email protected].

If you don't have a TCMD.GPF file, then the crash is either in Windows or a third-party dll that is being injected into TCMD. In that case, send the info in the error messagebox that Windows displays. I probably can't fix it in that case, but it might at least point to a workaround.
 
I narrowed it down to an invocation of %@pset[%_ppid,x]. @PSET (from SYSUTILS) barfed with a 32-bit parent process message, but I suspect that error message is erroneous.

I commented the offending line out of my TCSTART.BAT, and the TCMD did not crash.

Vince, please take note. PSET64.EXE works for this purpose.
 
@PSET (or PSET.EXE) definitely won't work between processes of different "bitness" (32 vs. 64, is there a better word?). It starts a remote thread in the target app after injecting code and data which have the same bitness as @PSET itself. Between processes of the same bitness, it should work as long as this succeeds
Code: 
OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_CREATE_THREAD |
             PROCESS_VM_OPERATION | PROCESS_VM_WRITE | PROCESS_VM_READ, FALSE, dwPid);
That's serious access. there's no doubt that it will fail if the target process is at a higher integrity level.

I updated PSET.EXE recently (IIRC, after a post by you) and then made some changes to @PSET but never updated SYSUTILS. I just updated SYSUTILS on lucky. Maybe that will work better.
 
vefatica said:
Code: 
OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_CREATE_THREAD |
             PROCESS_VM_OPERATION | PROCESS_VM_WRITE | PROCESS_VM_READ, FALSE, dwPid);
That's serious access. there's no doubt that it will fail if the target process is at a higher integrity level.
Click to expand...

That will not work on Windows 10 unless you're running elevated (and possibly not even then unless the other process is a child of yours).
 
rconn said:
That will not work on Windows 10 unless you're running elevated (and possibly not even then unless the other process is a child of yours).
Click to expand...
Not even between two ordinary processes (like a tabbed TCC and its parent TCMD)? What's prohibited?
 
vefatica said:
Not even between two ordinary processes (like a tabbed TCC and its parent TCMD)? What's prohibited?
Click to expand...

Not unless you've started the child process with the necessary permissions (i.e., like you were debugging the child). Windows 10 doesn't like these flags unless you're elevated:

PROCESS_ALL_ACCESS
PROCESS_CREATE_PROCESS
PROCESS_CREATE_THREAD
PROCESS_SET_INFORMATION
PROCESS_SET_QUOTA
PROCESS_VM_OPERATION
PROCESS_VM_WRITE

And remember, in Windows 10 you (1) can't completely disable UAC, and (2) administrators do not have all rights.

If you code sign your plugin dll, you are allowed more (but not all) access.
 
rconn said:
Not unless you've started the child process with the necessary permissions (i.e., like you were debugging the child). Windows 10 doesn't like these flags unless you're elevated:

PROCESS_ALL_ACCESS
PROCESS_CREATE_PROCESS
PROCESS_CREATE_THREAD
PROCESS_SET_INFORMATION
PROCESS_SET_QUOTA
PROCESS_VM_OPERATION
PROCESS_VM_WRITE

And remember, in Windows 10 you (1) can't completely disable UAC, and (2) administrators do not have all rights.
Click to expand...
Dave noted that PSET64.EXE worked. It uses the same technique. It's not specifically meant to be used between parent and child, but between any two "peer" processes (same owner, same desktop, same integrity level, ...). I really doubt Windows would forbid that.
 
vefatica said:
Dave noted that PSET64.EXE worked. It uses the same technique. It's not specifically meant to be used between parent and child, but between any two "peer" processes (same owner, same desktop, same integrity level, ...). I really doubt Windows would forbid that.
Click to expand...

Microsoft has a history of disappointing you. :eek:

If the default security didn't block that, it wouldn't be much use.
 
rconn said:
Microsoft has a history of disappointing you. :eek:

If the default security didn't block that, it wouldn't be much use.
Click to expand...
I'll still be surprised.

Dave, if you're following, (or anyone) please try a couple simple tests on Win10/64, one with PSET64 and one with SYSUTILS's @PSET.

Code: 
pset64 %@pid[explorer.exe] path
and
Code: 
echo %@pset[%@pid[explorer.exe],path]
 
I did try. PSET64 seems to work between TCC, elevated or not, and any arbitrary 64-bit process (though I didn't check EVERY 64-bit process I have running).

@PSET causes _whatever_ 64-bit target process you name to crash. I started a TCC from explorer and did
Code: 
echo %@pset[%_ppid,x]
and EXPLORER crashed.
The error message was
Code: 
TCC: (Sys) Only part of a ReadProcessMemory or WriteProcessMemory request was completed.

@Pset[%_ppid] (no 2nd argument) worked, though.
 
dcantor said:
I did try. PSET64 seems to work between TCC, elevated or not, and any arbitrary 64-bit process (though I didn't check EVERY 64-bit process I have running).

@PSET causes _whatever_ 64-bit target process you name to crash. I started a TCC from explorer and did
Code: 
echo %@pset[%_ppid,x]
and EXPLORER crashed.
The error message was
Code: 
TCC: (Sys) Only part of a ReadProcessMemory or WriteProcessMemory request was completed.

@Pset[%_ppid] (no 2nd argument) worked, though.
Click to expand...
What did @PSET with no second argument do? Here, I just get an error.
Code: 
v:\> echo %@pset[%@pid[explorer.exe]]
@PSET error: syntax: @PSET[pid,var[=[value]]]

Is there an "x" variable?

That's an odd error message, especially since the allocation of remote memory must have worked. All the google hits for that error message mention virtual drives, CDs, DVDs.

I'll look at the code very carefully, but a solution may have to wait until I have Win10/64.
 
I see you uploaded another SYSUTILS version after the one I downloaded earlier today. I downloaded the new version (7/30/16), but the results are still the same.

With no second argument, @PSET *USED TO* return the command line of the target process. Until the most recent version, that's how it worked. I think you actually documented that at one point. You must have changed the code for that.

Makes no difference whether there is an x variable or not, as far as I can tell. I do recall that when @PSET worked, it used to give some error message if the target variable did not exist. When you get around to fixing it, it would be better (IMAO) if it just returned an empty string.
 
PSET32/64.exe with no second arg gives the command line. @PSET doesn't (I don't think it ever did).
 
Okay, maybe I'm remembering it incorrectly. It wouldn't be the first time I've been confused.

FWIW, I have code that looks like this:
Code: 
SET NBITS=%@LEFT[2,%@EXEBITS[target.exe]]
PSET%NBITS% %@PID[target.exe] name=value
 
I might also be remembering incorrectly. Once upon a time, SYSUTILS may have contained a full-blown PSET. In any event, PSETnn.EXE works and @PSET doesn't. I ought to be able to figure it out, even without an x64 system.
 
Hmmm! I haven't found a smoking gun but I made a few minor changes (that I don't expect will help) and added some debug progress reporting.

Dave, if your willing, try ftp://lucky.syr.edu/debug/sysutils64.dll with a target process you don't mind crashing, like another TCC. Please post what you see. Here, I see the likes of this:
Code: 
p:\4sysutils\release> echo %@pset[2952,x]
Parameters:
PID: 2952
VarName: x
Equal sign:
Data:

got hKernel32
got address of SEV
got address of GEV
opened process
got target exebits
exebits OK
alloc'd code memory
copied code
alloc'd data memory
copied data
created thread
thread exit: 0
(SYSUTILS) Not in remote environment: "x"
 
Vince, I was away all day, but I'll try this later Monday, and I'll let you know.
 
rconn said:
And remember, in Windows 10 you (1) can't completely disable UAC, ...
Click to expand...

You can, it just requires editing a setting in Group Policy. I would not recommend it though. UAC on workstations really is a good thing and it's better to just get used to it. Plus if you disable UAC completely you won't be able to run metro style apps which now includes things like calc.exe.
 
Vince, I replaced the .dll as you requested. When TCC starts up, it writes a whole bunch of stuff like you posted above, but the window disappears before I can copy it.
PSET %_PPID TZN
works. I know that variable is defined.
ECHO %@PSET[%_PPID,TZN] crashes the parent process.
 
dcantor said:
Vince, I replaced the .dll as you requested. When TCC starts up, it writes a whole bunch of stuff like you posted above, but the window disappears before I can copy it.
PSET %_PPID TZN
works. I know that variable is defined.
ECHO %@PSET[%_PPID,TZN] crashes the parent process.
Click to expand...
That info should be written in the child process, the process executing the ECHO %@PSET. The two processes should be running in different consoles.
 
I started two separate TCC processes without TCMD, and looked up the PID of the first.
In both processes, I did PLUGIN /U SYSUTILS and PLUGIN /L (the test version of SYSUTILS64).
In the second process I did ECHO %@PSET[pid,TZN] and got this:
Code: 
~\Work> echo %@pset[9804,tzn]
Parameters:
PID: 9804
VarName: tzn
Equal sign:
Data:

got hKernel32
got address of SEV
gor address of GEV
opened process
got target exebits
exebits OK
alloc'd code memory
copied code
alloc'd data memory
copied data
created thread
TCC: (Sys) The wait operation timed out.
Then I got an error window saying
Code: 
TCC has stopped working

A problem caused the program to stop working correctly....
 
Thanks, Dave.

I gather your second snippet came from the other TCC, the target, the one that crashed ... yes/no?

Anyway, apparently, everything went as planned, but the remote thread didn't terminate (after 5 seconds). Hmmm! The code for starting and waiting for the thread is exactly the same in @PSET as in PSET64. In fact, PSET64, which you say works, has a much more elaborate remote thread. I'll look further, but without x64, I can't do any testing.
 
Yes, the error box was generated from the target process. After releasing the error box, that process terminated.

Take as long as you need. I appreciate the fact that you're providing support (and for the fact that you supplied the programs to begin with).
I can use PSET64 and PSET32 for now.
 
dcantor said:
Yes, the error box was generated from the target process. After releasing the error box, that process terminated.

Take as long as you need. I appreciate the fact that you're providing support (and for the fact that you supplied the programs to begin with).
I can use PSET64 and PSET32 for now.
Click to expand...
And I appreciate your help.
 
You must log in or register to reply here.
Back
Top