Linked by Thom Holwerda on Tue 22nd May 2012 23:26 UTC
Permalink for comment 519144
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
More Features »
Sponsored Links



Member since:
2005-07-24
**ALL** languages talk to the hardware the same way!
Memory pointers are a hardware feature. They just happen to be 'exposed' in c/++. I can use assembly to fool any programming written in any language that I am friendly and of the same breed and interject myself using hardware features.
Security like you are speaking would require a massive hardware change where memory is addressed in locked relative-memory segments. That is every process can create restricted areas of memory which can only be accessed by a compile-time validated code-path - something a few steps beyond nX-bits.
Even then, you would only need to find a way to inject yourself into that code-path by altering the binary... but that would be easier to catch and prevent. You would then need to rely on OS/hardware bugs... but you would still be able to get 'in' in some manner...nothing is safe beyond not permitting execution at all...
Which language was used simply doesn't mean squat. A program written in Delphi still debases itself to the same approximate code which was written in c. I'm still using movl %eax, %ecx, call, jmp, etc...
--The loon
Edited 2012-05-23 17:02 UTC