Decompiling the GPL violated Linux kernel using Evolutionary Algorithms
far.chickenkiller.com
Decompiling the GPL violated Linux kernel using Evolutionary Algorithms
1–10 of 16 posts
Re: Decompiling the GPL violated Linux kernel using Evolutionary Algorithms
#2Not exactly the same goal but in the ballpark, reminded me of the linux-libre patches (removes binary blobs and non-gpl code from the kernel)-
Re: Decompiling the GPL violated Linux kernel using Evolutionary Algorithms
#3I'm having a really hard time parsing this title.
Re: Decompiling the GPL violated Linux kernel using Evolutionary Algorithms
#4I thought this would be an actual process, not a blog post with idle musings.
Re: Decompiling the GPL violated Linux kernel using Evolutionary Algorithms
#5This is a difficult project. The blog post seems to hint at reasonable feasibility, this stuff is hard! We build a less ambitious tool in the university lab: "ASTANA: Practical String Deobfuscation for Android Applications Using Program Slicing" [0].
Would advise to first read the reverse engineering related work. Genetic programming is just a technique best used when everything else has failed :-)
Re: Decompiling the GPL violated Linux kernel using Evolutionary Algorithms
#6I'm having a really hard time parsing this title.
A dash between GPL and violated would probably help.
Re: Decompiling the GPL violated Linux kernel using Evolutionary Algorithms
#7> Theoretically, we could also go for finding the semantically equivalent C code. However, last time I researched, checking semantic equivalency is a very complex problem. I think it was NP hard.
Already deciding whether two finite automata decide the same (regular) language is PSPACE-complete; it's undecidable for anything that can decide arbitrary context-free languages (which C programs can clearly do).
Re: Decompiling the GPL violated Linux kernel using Evolutionary Algorithms
#8> Theoretically, we could also go for finding the semantically equivalent C code. However, last time I researched, checking semantic equivalency is a very complex problem. I think it was NP hard. Already deciding whether two finite automata decide the same (regular) language is PSPACE-complete; it's undecidable for anything that can decide arbitrary context-free languages (which C programs can clearly do).
Well I knew that checking if two binary circuits are equivalent is NP hard. Checking semantic equivalency of C code, of course, should be harder.
Re: Decompiling the GPL violated Linux kernel using Evolutionary Algorithms
#9Re: Decompiling the GPL violated Linux kernel using Evolutionary Algorithms
#10I thought this would be an actual process, not a blog post with idle musings.
I wanted to append [idea] but it became too long. I think there should be balance "musings" and actual work. I learned very valuable lessons in my wakegp research. Even though I haven't completed it. If the one doing this research would be me, I would go for no actual work as long as I can. And when I start to do the work, I should do as little as I can and move very slowly. Like the saying "When you move slowly, you can see the path ahead clear". After all, we should know if the next step we go forward, the ground under us is solid.