Open XVilka opened 5 years ago
Awesome! We have a propietary version of some code similar to myoriginal ECFS being worked on at ArcanaCS.com that is still within the format specifications of ECFS but has been re-designed and has some additional specifications. I think it would be very complimentary for radare2 to be able to process these snapshots. Thank you for the consideration, I am honored.
-elfmaster
EDIT: Grammars
@XVilka I would say this to myself about this matter, so please don't be so serious okay? :)
While Linux is in supporting bigger and bigger CPU/GPU cores & architectures, and yet it is also growing its support for the tinier and tinier embedded environments also, as I am in DFIR/RE so I am not against ECFS at all, but executables will have to ride on those both OS directions (above). That's really a big matter to decide and to deal with, since that may overhaul linkable execution logic, compile-decompilation steps we know, I think the decision is beyond our scope, to be very frank.
And if, I may consider myself as an executable file's analyst, I will have to work under committed upper level's decision for executions, so shortly, in Linux, if Linus say we go to ECFS I'll go, If FreeBSD project say we drop the ELF and go with ECFS,, so it's okay. But the transition will be long and painful steps.
@XVilka you know it better than anyone, the fact is, supporting ECFS means affecting many codes of radare2 project has, from parsers, opcodes reading, rebuild database (headers, link flow for ECFS) again to adjustment, and btw we depend on capstone now, right? ECFS reading and ELF reading, shared libs-linking adjustment anda lot of minors too. Much work to be done. We're talking about adding stuff that doesn't exist in the code at this moment, we have to support legacy ELF still too yes? So what I am saying is, that extension could be almost as same as the amount codes of handling ELF itself, no?
Further, as I use radare2 for both natively installed and non-native (i.e. in analytic mode on other machines), if the OS gods said supporting ECFS, let's think from there. We still need to have r2 to run natively under SH4 board for example.
Thinking about the overhaul possibility I am like, maybe I will still be happier with calculating inodes for XFS/ZFS for knowing more artifacts for forensics rather than imagining these :)
So, please, it is just me talking to myself, don't be so serious :)
This issue has been moved from radareorg/radare2 to radareorg/ideas as we are trying to clean our backlog and this issue has probably been created a long while ago. This is an effort to help contributors understand what are the actionable items they can work on, prioritize issues better and help users find active/duplicated issues more easily. If this is not an enhancement/improvement/general idea but a bug, feel free to ask for re-transfer to main repo. Thanks for your understanding and contribution with this issue.
his issue has probably been created a long while ago
Not trolling, but, I don't get it. @XVilka was creating this 551 days ago.. it's not even 2 years, what do you mean by "a long while ago"? Am I wrong?
ECFS - Extended Core File Snapshot format
See https://github.com/elfmaster/ecfs and http://bitlackeys.org/papers/libelfmaster_talk_hushcon.pdf for more information.
ECFS is an extension to the existing ELF core file format in Linux. Its job is to intercept the Linux core-dump handler, catch the core-dump before it is written to disk, and carefully reconstruct it into an ecfs-core file. An ecfs-core file is backwards compatible with regular core files but has been extended in such a way that they boast prolific amounts of data useful for process forensics analysis. An ecfs-file is not limited to just ELF program headers, but also contains many section headers as well as fully reconstructed relocation and symbol tables that reflect the state of code and data in runtime.
Use cases:
FYI @unixfreaxjp @radare