Zend certified PHP/Magento developer

What would be the best Way to implement some Kind of IDS(Intrusion Detection System) for Firmware which lives on Hardware??? #Linux [closed]

May i begin with informing you seemingly downvote/delete obsessed Moderators, that i’m new here and this here is not about the usual Problems with ‘/sys’,’/proc’,’/dev’ at a small Scale, even if it starts with everything you have already an asked Question for, so it is absolutely no Duplicate of Anything here –at least of what i’ve found over the Years here–! And sadly your own Rules demand, that One has to list what he already tried, so don’t wonder if you have to read through much Stuff that has already a separate Question here! ;P

It has a legit and well defined Purpose compared to all the other ‘/sys’ “Backup” Questions which falsely got laughed at with the counter Question “Why do you want to do this anyway?!”…

It also points out, that there seems to be an extreme Problem in our Linux World, since either ‘/sys’ should no longer be designed as pseudo FS, or the Admin Tools must be able to handle it correctly, but as it is, it seems unacceptable to me, so if no High-End Guru here could point me to a Tool or relatively acceptable Method, which can reliably and uniformly(No shitty Hacks for each Subcategory!) operate in the Security critical ‘/sys'(And optionally also in ‘/proc’ and ‘/dev’), i then want to use the Pro Answers/Comments to this Question/Problem here for a BUG Report either on the Kernel, or the Toolset!

What i have in Mind and tested so far:

After falling deep down into the Rabbit Hole of Firmware Malware “Paranoia”(If i provide no Links, i’m just stamped as only “Opinion” based, if i would do provide a Ton of them, i’ll probably again get deleted for “spamming”, so it’s really perplexing stupid here i must say!), i tried to devise me a Way, which probably at least could monitor if any potential Malware would luckily be too stupid to hide its Traces, and AFAIK the ‘/sys’ Path lets us read out Portions(Or even Everything?) of some EEPROMs(Maybe other Chips too, i don’t know, therefore i ask, but that seems strangely almost illegal and reprehensible here…And yes, i’m sadly well aware, that the only serious way to do such Things is by desoldering the Chips and reading them out in a Chip Flasher, but surely no one does this as often as he probably should) like for Example if the Motherboard has ever been “infected” with an Windoze License Key, which can be read out with

`sudo strings -- '/sys/firmware/acpi/tables/MSDM' | tail -n1`

(Probably good for Installs of it in a VM, if one has to, but “strangely” didn’t found the License Keys anywhere anymore), so my Idea was to initially backup the whole ‘/sys'(Maybe the interesting Parts of ‘/proc’ and ‘/dev’ too) Path and its Contents from my newly bought Machine with

`sudo rsync -HAXhaxSW -- '/sys' '/mnt/Backup/'`

which i always use to successfully copy whole Systems with all their Sockets, Pipes, Sparse Files and what not, but since ‘/sys’ is just a pseudo FS, rsync seems to fail miserably on these Files…(I know why, don’t waste your Time on this One, it’s discussed here already)

So i resorted to use

`sudo cp -av -- '/sys' '/mnt/Backup/'`

which surprisingly worked for a While as expected, but then it of course chocked on a ‘/sys/kernel/debug/tracing/trace_pipe’ Pipe… cp -a also seems to not have any exclude Functionality for such Cases…

Then i thought i’ll couple it with find '/sys/' -not -type p,s, but that of course would not preserve me the Folder Hierarchy in the Target Directory –which it should of course if one wants to compare it afterwards with meld or some other Diff GUI–, and the recursively operating cp -a which had this Functionality, would not be a very good Idea to be fired by find‘s ‘-exec’ namely because of its recursive working Nature…

Last but not least i hacked me

`sudo find '/sys/' -not -type d,p,s -not -iname '*pipe' -exec cp --parents --preserve=all -d -v -- '{}' '/mnt/Backup/' ;`

together just to realize, that it is truly so, that find simply can not detect and therefore exclude Pipes on a pseudo FS like the ‘/sys’ Path, and the ‘-exec’ Execution of cp again chocked somewhere on a damn Pipe, so in Despair i resorted to the “-iname ‘*pipe'” Approach you already saw in my Oneliner, but guess what, not every Pipe is of course named “Pipe” in the ‘/sys’ FS, and there comes One after the Other, and we would had to catch and exclude them all manually or with some ultra psychotic arcane Terminal Witchcraft Hack i no longer wanted to invent, since i very hardly believe it just should not be so problematic and the Kernel Folks should just change that stupid Behavior if no *nix Tool can handle that pseudo FS properly!!!

With tar i guess it would have been the same Problem, that One has to exclude all the Pipes and other blocking Stuff manually…

One can also not just make an complete Image of ‘/sys’ with dd since it is not a Mountpoint from a Blockdevice, because it is so pseudo…

So finally my ultimate Questions are:

  1. Has anyone a reliable Shell Way to achieve what i wanted? (If it was somehow not clear till now, i want to Backup the whole –or as much as i can get of it at least– ‘/sys’ to real Files so that i later always can compare it against the actual System State, in the probably just naive Hope of maybe one Day finding not legit Changes in the Parts of the BIOS –or other Firmware– which seem to be “stored” in ‘/sys’ and maybe other EEPROM Dumps one can seemingly find there –i’m no Pro yet in such Things, but if i can diff it, i can one fine Day understand it all–, or just any Device that after a Corruption with Malware maybe changes Something obvious One could monitor if he had collected all System Data right from the Start after he bought his new Machine. In other Words, i just want total Control over any Data all my Devices could spit out about them self in order to detect potentially dubious Changes, so if there is a better Way than dumping the whole ‘/sys’ pseudo “FS”, then i like to hear about that too of course! And with i want it all, i mean all, even the EDID of the Display via I2C, SPI, whatever, just f*cking EVERYTHING One can get about his Machine!)
  2. Is there maybe already any finished Free Software Tool which does all that –or even more, something like a sophisticated IDS for Firmware on Chips which would do this initial Logging of any Hardware Info for later Comparisons?– and preferably comes from the regular Distro Repository, which is Debian in my Case? Chipsec? If Chipsec would be the right Tool for the Job, then i’ll had a little Bonus Question –if allowed–, namely, is it secure to use this on a Production Server, since i for Example don’t like to fire Pen Testing Suits on them, because to my Understanding they mostly just demonstrate that a Hack is possible, but maybe not in the safest Way i guess… Therefore i’d mostly like to do it all by my self with basic Sys Tools, since i somewhat hate studying other –potentially dubious non Distro Repository– Peoples Code just to be sure, especially if their Projects are way too big or in Languages i don’t understand very well!
  3. Am i right in the Assumption, that there is no regular *nix Tool which could handle ‘/sys’ properly or that it at least should not be so hard to be able to achieve such a legit and Security important Task like backing up any Hardware related Information?! If so, where must we conspire in order to make them change this bad Behavior in the Kernel and make ‘/sys’ less pseudo or the Linux *utils Toolset more capable?

Thanks in Advance for your Time and thoroughly Answers(You can write a Bible about the Topic if you are a Monster Mutant Guru in this Sector and wish to do so, it doesn’t have to be short, i like Details, especially in this horrible “How do we fight the closet(No Typo!:D) Source Firmware Dangers which undermines all our free Software Security Measures and Efforts…” Topic)!

No cowardly Downvotes without clear Explanation of the Reasons why please, be a Man!