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

Improve / configure logging #12

Open
omern1 opened this issue May 7, 2015 · 5 comments
Open

Improve / configure logging #12

omern1 opened this issue May 7, 2015 · 5 comments

Comments

@omern1
Copy link
Contributor

omern1 commented May 7, 2015

It is difficult to keep track of what happened when, so add logging, I have a logging framework for GO, you can use it.

@flowchartsman
Copy link
Owner

Agreed. This is one of the TODO callouts I hadn't yet added an issue for, mainly because, at the moment, there's not much to log. A device comes in or is removed, it issues a shutdown, and that's that. It will definitely be necessary once the custom command list support is added which I'm currently working on, as it would be useful to the user to know if a command failed to execute or not. For privacy concerns, we might not want to log precisely what the command was, however. Logging will also be useful to show which device has been added/removed, and I'm making a change later today that will allow that to happen. Currently, it only works off of the ID, not the device description, but the full description will be useful for whitelisting.

@omern1
Copy link
Contributor Author

omern1 commented May 8, 2015

See, in USB. Kill, the shutdown of the computer also triggers a full disk encryption. So that way, we can log everything and let only the user have access to it. I know that we don't have the encryption part right now. And another thing, please change the console window's title, it changes to powershell after device enumeration. You may want to call SetConsoleTitle() which is a win32 api function.

@flowchartsman
Copy link
Owner

USBKill does not support encryption, it encourages it, just like this tool does. As for logging WHICH commands failed, the scenario I describe is a situation in which someone is observing the logs as the software is shutting down, or is able to see them after a failed shutdown. Any leakage of information in this way is bad, and as much as possible should be hidden from inspection. Also, the windows version of deadman is not intended to be run as a console app at this time to avoid the problem with the window simply being closed. See issue #5. If and when it becomes feasible to run it in the console again, I will consider using SetConsoleTitle()

@omern1
Copy link
Contributor Author

omern1 commented May 8, 2015

I don't know if you can call win32 API functions in Go, but to get rid of the console window, you can use FreeConsole()

@flowchartsman flowchartsman changed the title Add a little logging. Improve / configure logging May 8, 2015
@flowchartsman
Copy link
Owner

This seems to be solved by building with go build -ldflags -H=windowsgui, though I will look into making the benefits of making this syscall over the method I currently use. At this time, it seems that it would be trading increased code complexity for the small convenience of not having to build the app with flags. It should be noted that, as I mention in issue #5, these flags probably won't be necessary for long. But let's keep the comments here germane to the issue of logging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants