deadman
deadman copied to clipboard
flowchartsman
Improve / configure logging
It is difficult to keep track of what happened when, so add logging, I have a logging framework for GO, you can use it.
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.
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.
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()
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()
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.