Timeline for JIT based on precompiled code templates
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 14, 2016 at 17:44 | comment | added | jdm | @MartinMaat: Ahh, no shell code is only indirectly related to shells like powershell or bash :-) It comes from hacking/cracking jargon. If you find a buffer overflow etc. in a program on another PC, you can write a piece of evil machine code, the "shellcode", and inject it. The program crashes, executes the evil code, and gives you a shell, meaning you now have a command line on the hacked system! There are specific techniques used to build this kind of code - you have to circumvent protection mechanisms and use bytes already in memory. I proposed to use these tricks to build a new compiler. | |
| Jan 14, 2016 at 7:05 | comment | added | Martin Maat | Perhaps I still do not understand the question. Putting executable code in memory upfront only strengthens my association with DLLs. Be it that a DLL does not contain "guesses" or "may be useful", it is just compiled source code. Part of the miscommunication may be that you seem to be from a UNIX environment and I am familiar with Windows. Is shell code your reference? I may have to move my frame of reference from C(#) to PowerShell. Which does pre-load objects in memory to be used by the script. We call them cmdlets rather than gadgets. Anyway, I am sorry if I am missing the point. | |
| Jan 13, 2016 at 23:14 | comment | added | jdm | I should have said it explicitly (and I did but edited it out), but the idea was to go far beyond optimizing individual functions by putting them in DLLs. In the terminology of exploits and shellcode, the idea was to intentionally put a lot of "gadgets" into memory and connect them via something like return-oriented-programming and clever use of conditional jumps, moves, etc.. | |
| Jan 13, 2016 at 23:12 | comment | added | user7043 | I don't see what any of this has to do with the question. | |
| Jan 13, 2016 at 22:38 | history | edited | Martin Maat | CC BY-SA 3.0 | elaboration |
| Jan 13, 2016 at 22:17 | review | Low quality posts | |||
| Jan 13, 2016 at 22:38 | |||||
| Jan 13, 2016 at 22:11 | comment | added | user40980 | I realize this is a somewhat descriptive answer. It would be a much better one if you could describe how a DLL lines up with the concepts presented in the question post and if there are any parts of the question that don't align properly with DLL. This would be especially useful for the programmers who haven't gone deeply into writing DLLs (as a unix side coder I know about shared libraries - but the idea of a DLL for perl or python or lua or dc doesn't ring any bells). | |
| Jan 13, 2016 at 21:57 | history | answered | Martin Maat | CC BY-SA 3.0 |