Generic offline collector do not work with Velociraptor versions 0.75.6 and 0.75.5

[Dafa11235]

As in the title it seems that using --embedded_config switch to run generic collector does not work on those versions. Interestingly, using older version of velociraptor (0.75.4 and even 0.74.2) is fine.

Screenshot from execution:

Used command is the same as in the documentation for running generic collector.
Collector_velociraptor-collector was generated using CreateCollector artifact.
Command was tried on Windows 10.

[scudette]

This is very weird because it works fine for me

Can you try again in a plain cmd.exe shell?

[scudette]

From the error message it looks like the commandline parser does not consider the --embedded_config to start with a dash (so it is not a flag). I wonder if this is some kind of emdash/unicode issue with your terminal.

[Dafa11235]

Ok, I've tested it on another two machines (Win10 and Win 11) and on both I got exactly the same behavior (in cmd as administrator). Working fine with 0.75.4 velociraptor binary and throwing errors with expected commands on other versions. I've also tried running it in powershell but with similar effect. I'll check if this could be the case due to weird generic collector data, but still why this one would even work with 0.75.4 if something is wrong with it.

[scudette]

Couple of things to check:

1. Does it still have the same issues parsing other command line flags? can you run any other commands?

For example

velociraptor-v0.75.6-windows-amd64.exe --embedded_config Collector_velociraptor-collector config show

2. It looks like you might be using desktop+ - can you try in a vanilla cmd.exe shell?

[Dafa11235]

Other commands behaved similarly (error with 0.75.6 and correct behavior with 0.75.4):

But in the above example error was different than before - unable to load config.

I've also tried generating collector from gui (previous one was generated from cli, but still via CreateCollector) and this time it worked:

So I guess the problem is with generic collector file itself. It is really weird that it still working with version 0.75.4... Additionally, the size difference between two collector files is huge - 123KB (gui) vs 11.1MB (builder). I'll need to debug it more - maybe in newer versions parsing of mine collector config fails in this unintuitive way ( "error: expected command...") and in older versions it was less restrictive?
In any way, I'll continue to investigate this and let you know if I'll be able to solve it.

Also, thanks for quick replays!

[scudette]

The generic collector should be very small as it just contains the artifacts and config.

When you say "collector from builder" what do you mean exactly? Did you actually produce a binary with embedded config instead of a generic collector?

[Dafa11235]

I've checked both collectors and they seem very similar in structure:

I have a lot of custom made VQLs so it is natural that the one from builder will be bigger. For gui based collector I've used only Windows.Triage.Targets. Also I believe that generic collector also attaches tools to this config which would also explain the size.

By "builder" I mean code automating creation of offline collectors. Previously I've used binaries with embedded config, but with changes to Kape/Triage artifact I had problems with "config file is too large to embed", so I'm trying to move to Generic collectors (intended solution for too large config problem).

[scudette]

When you say build with a builder I assume this is using the velociraptor collector command. Are you using the latest version to build the generic collector too?

[scudette]

It looks like the limit for the embedded config size was reduced to 10mb recently

velociraptor/config/embedded.go

Line 28 in 91fa1b7

buf, err := utils.ReadAllWithLimit(fd, 10*1024*1024)

Maybe we need to increase it. This 10mb applies to only the config (i.e. artifact yaml) but not the binaries included into the config

[Dafa11235]

I've been able to reduce file size of this generic collector to about 7MB and it worked. So it seems that the limitation of 10 MB could be the reason for previous failures. Not sure if only artifacts would amount to as much, but the size itself seems to be the answer and I can work around this 10MB limitation.

I've used artifacts collect Server.Utils.CreateCollector but maybe it's a good time to change this approach ;).

Thank you for your help!

[scudette]

Thanks for reporting this issue - it should be fixed in #4690 where the size limit is set to 100mb now. It also highlighted some issues with the error reporting because the reported error message is not very indicative.