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

Add support for regular expressions in collection list file #33

Closed
jj1985 opened this issue Dec 31, 2016 · 15 comments
Closed

Add support for regular expressions in collection list file #33

jj1985 opened this issue Dec 31, 2016 · 15 comments

Comments

@jj1985
Copy link

jj1985 commented Dec 31, 2016

This would also ideally allow for recursively selecting/finding files based on the specified regular expression.

@jj1985
Copy link
Author

jj1985 commented Dec 31, 2016

Just a thought on a possible way to tackle this:

Use PowerForensics.Ntfs.FileRecord from github.com/Invoke-IR/PowerForensics (or something similar for rapidly parsing the MFT) to get a list of file entries, and then process the list against the file collection list.

@Lansatac
Copy link
Collaborator

Do you mean running PowerForensics as separate tool and then piping the output of that into CyLR? That sounds like a good approach.
I am not against the idea of adding something like a regex search to the tool, but I feel like that opens the door to a ton of complexity and is probably best solved by a specialist tool that focuses on complex searching, and then piping that into CyLR for extraction.
Perhaps the best approach here is to ensure that CyLR is highly compatible with other tools. Supporting powershell and *nix "pipe" operations seems like a good thing to have that we don't currently do.

@jj1985
Copy link
Author

jj1985 commented Dec 31, 2016

The more I think about it, the more I agree with you. Implementing robust regular expression support may be outside of the scope of the project, and one of the things I appreciate about the tool is its simplicity and the fact that it is extremely quick. The more functionality you add, the more time it takes to process.

What I currently do is dynamically build a collections list in PowerShell, write it to a file, and pass it to CyLR. This approach works well.

@Lansatac
Copy link
Collaborator

Does #36 get closer to what you'd like to have?

@jj1985
Copy link
Author

jj1985 commented Jan 1, 2017

That should work for the use case of collecting a single file.

@Lansatac
Copy link
Collaborator

Lansatac commented Jan 1, 2017

#31 actually addresses that. Once both of those PRs go through, CyLR will support
CyLR.exe C:\SomeFile.txt
and #36 will let you do
Get-ChildItem | Select-Object -ExpandProperty Name | CyLR.exe
which would let you collect all files in the current directory.

@Lansatac
Copy link
Collaborator

Lansatac commented Jan 1, 2017

So, to do a full regex search:
Get-ChildItem -recurse | Select-Object -ExpandProperty Name | sls ".log" | CyLR.exe

This would grab any ".log" files underneath the current directory.

@Lansatac
Copy link
Collaborator

Lansatac commented Jan 1, 2017

The Unix equivalent being (when I finally manage to get mkbundle to work properly):
ls -R | grep \.log | CyLR

@jj1985
Copy link
Author

jj1985 commented Jan 1, 2017

Ahh yes, I actually just downloaded your fork and tried it. That works very well. The only concern I see with it though is that it appears "Console.IsInputRedirected" only exists in .NET 4.5 and up. Any way to make it compatible with .NET 4.0 as well?

@jj1985
Copy link
Author

jj1985 commented Jan 1, 2017

Possibly solved with this code snippet from SO? Includes a cross-platform snippet for using with Mono as well.

http://stackoverflow.com/questions/3453220/how-to-detect-if-console-in-stdin-has-been-redirected

@Lansatac
Copy link
Collaborator

Lansatac commented Jan 1, 2017

Oh, good catch. We're trying to target mono, which makes that a touch more difficult. I'll see what I can do.

@Lansatac
Copy link
Collaborator

Lansatac commented Jan 1, 2017

That's the most sad code I've had to write in a long while, but it works now.

@jj1985
Copy link
Author

jj1985 commented Jan 1, 2017

Not at all related to this issue but Happy New Year, and really appreciate this project and your efforts.

@Lansatac
Copy link
Collaborator

Lansatac commented Jan 3, 2017

Thanks! It's been a fun project to work on.

@Lansatac
Copy link
Collaborator

I'm going to close this issue for now. I'm still open to discussion on this point, but at the moment I think searching for artefacts is best handled by other, better tools, and if it isn't, lets write those tools!.

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

No branches or pull requests

2 participants