Open mgeeky opened 2 years ago
I think the armory is a path handling bug, tbh we don't test the windows client as well as the others. The shell
issue looks like it may be separate bug, are you using the Windows Terminal / a terminal that supports PTYs?
Yes, I'm using windows terminal.
So, any idea what to do about that armory case?
We'll probably have to patch the armory installation code, looks like it's something related to Windows' relative paths not behaving like Unix-like paths. WSL+Linux client should work as an interim quick fix.
The code is implemented using cross platform filepath
but Windows usually still finds a way to break.
Also, I didn't open the bug report for this, but there are plenty of issues around handling of backslashes - where for instance:
generate c:\test\sample1.exe
will produce:
ctestsample1.exe
Other affected commands are execute-assembly
, upload
and so on - it's a global problem really.
You will need to use \\
for backslashes, this isn't a bug but the way our shell interpreter works.
I'd consider this as an UX annoyance. Is there anything that can be done about it?
Not really without switching the entire shell repl library we use (this is used to encoding lots of things), we are working on a GUI that will be out ... when it's ready, which of course won't have this behavior.
same problem
I think I just ran into the can't spawn shell bug when I installed a windows vm to test another patch on.
Server is running linux, implant is windows8. My implant is in debug mode, the shell pops but on the open terminal on the windows box that is showing the debug.
I could type exit on the shell visible in the implant and control is returned back on the server. I can take some screenshots later if that would help at all.
This is the first time I've tried an implant on windows so I'm not sure if it works on other versions at all.
Here's the implant log:
2022/09/07 20:57:38 sliver.go:223: [recv] tunHandler 20
2022/09/07 20:57:38 shell_windows.go:71: [shell] [C:\Windows\System32\WindowsPow
erShell\v1.0\powershell.exe -NoExit -Command [Console]::OutputEncoding=[Text.UTF
8Encoding]::UTF8]
2022/09/07 20:57:38 shell_handler.go:82: [shell] Process spawned!
2022/09/07 20:57:38 shell_handler.go:159: [shell] Started shell with tunnel ID 6
12065781856809678
2022/09/07 20:57:38 shell_handler.go:132: [shell] tWriter: {0xc000057c20 0xc0000
54240} outErr: &{0xc0000bc780}
2022/09/07 20:57:38 shell_handler.go:132: [shell] tWriter: {0xc000057c20 0xc0000
54240} outErr: &{0xc0000bc280}
At this point the shell was opened on the implant and I manually typed exit after a bit. and the log continues:
2022/09/07 20:57:56 shell_handler.go:107: [shell] Closing tunnel request 6120657
81856809678 (shell wait error). Err: exec: Wait was already called
2022/09/07 20:57:56 shell_handler.go:107: [shell] Closing tunnel request 6120657
81856809678 (process terminated). Err: <nil>
2022/09/07 20:57:56 sliver.go:223: [recv] tunHandler 22
2022/09/07 20:57:56 sliver.go:223: [recv] tunHandler 22
2022/09/07 20:57:56 data_handler.go:46: [tunnel] Cache tunnel 612065781856809678
(seq: 1)
2022/09/07 20:57:56 data_handler.go:46: [tunnel] Cache tunnel 612065781856809678
(seq: 0)
2022/09/07 20:57:56 data_handler.go:58: [tunnel] Write 54 bytes to tunnel 612065
I wonder if its something to do with the version of powershell?
I wonder if its something to do with the version of powershell?
I have no idea, I'm not a windows user. I only spun up the VM to test that other PR against, figured I'd play around with the windows implant a bit once I had it up and running.
Solved in new release, there was a problem in the client assets code that would not correctly consider paths on Windows.
Describe the bug Cannot install armory seatbelt as well as cannot enter interactive shell session while operating on mTLS implant.
To Reproduce Steps to reproduce the behavior:
armory
armory install seatbelt
shell
Expected behavior Wanted to spawn interactive shell and wanted to install armory.
Desktop (please complete the following information):
Additional context
Spawning shell resulted in CTRL+C and client process killing due to no interaction:
Any ideas how to proceed here?