Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recording on Ashirt Server a bit broken #64

Open
AnubisSec opened this issue Jul 18, 2022 · 4 comments
Open

Recording on Ashirt Server a bit broken #64

AnubisSec opened this issue Jul 18, 2022 · 4 comments
Labels
bug Something isn't working triage Issue needs triage

Comments

@AnubisSec
Copy link

Golang version (go version): go version go1.18.3 darwin/arm64

OS version (uname -a if on a Unix-like system): Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:37 PDT 2022; root:xnu-8020.121.3~4/RELEASE_ARM64_T6000 arm64

Description of the problem including expected versus actual behavior: When viewing an uploaded recording from aterm, the beginning of every output includes the originating command as seen here:
image

Steps to reproduce:

Please include a minimal but complete recreation of the problem,
including (e.g.) index creation, mappings, settings, query etc. The easier
you make for us to reproduce it, the more likely that somebody will take the
time to look at it.

  1. start aterm by running aterm
  2. Run commands
  3. Finish recording by typing exit
  4. Upload recording
  5. View on Ashirt server

Provide logs (if relevant):

@AnubisSec AnubisSec added bug Something isn't working triage Issue needs triage labels Jul 18, 2022
@JoelAtDeluxe
Copy link
Contributor

@AnubisSec were you using zsh when you captured this? Also, have you tried any other shells, like bash or fish (or zsh if you weren't using that)? I'll see if I can investigate this week.

@AnubisSec
Copy link
Author

Yeah, i was using zsh, and i haven't tested any other shells but I'll test that today and will report back if anything changes. Thanks for looking into this!

@AnubisSec
Copy link
Author

Sorry for the small screenshots, but yeah seems to be an issue with zsh, /bin/bash worked just fine:

image

@JoelAtDeluxe
Copy link
Contributor

Unfortunately, we were not able to reproduce this issue. It might be some weird with your environment in particular, and maybe some eccentricities of zsh as a contributing factor. I'll keep looking, but it might be a bit before we know more. But, here's what I'm seeing:

Zshell (with my extension) is writing a bunch more than seems necessary. In particular, after putting in whoami, then a new line, it writes:

\u001b[?1l\u001b\u003e
\u001b[?2004l\r\r\n
\u001b]2;whoami\u0007\u001b]1;whoami\u0007

(note that this string was coerced into json, per the asciinema format)

the \r\n on line 2 should be the new line I entered, but I don't know why there's an extra \r there. The \u001b]2;whoami\u0007 is confusing as well. That's probably an important zshell-ism, but I'm not well enough versed in zshell to know why it's there, or what purpose it's serving.

Here are a couple of things to try (not in any particular order):

  1. Try a different terminal emulator. I know of 3 for macos: native terminal, iterm2, and hyper. I don't expect this to make a difference, but you never know.
  2. If you're using ohmyzsh, you might try a different theme.

As an aside, you can also try to play back your capture locally with asciinema. Aterm will tell you where the recording is being captured to, and once you are complete with that capture, you can find the file, and play it back with asciinema play $filename. That might not tell you much, but it's an option that's available if you want to do your own investigation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working triage Issue needs triage
Projects
None yet
Development

No branches or pull requests

2 participants