#169750 - LOst? - Sat Aug 01, 2009 10:27 pm
My dream is to take a C function and put it on the stack (or any custom memory, like memory allocated with malloc), then execute it from that location.
Is that possible in C?
In assembler, relocating code to another memory area and execute it is possible.
What do I want to do? I want to have code that I can change in real time, like a bitmap blitter where the clipping tests are immediate and when blitting, the code is adjusted instead of having to read from a memory variable to get the clipping values. Like a real time C++ template... Is that possible to do?
C/C++ should be able to allow such things, I think :P
_________________
Exceptions are fun
#169753 - vuurrobin - Sun Aug 02, 2009 12:20 am
if you're talking about Self Modifying Code, then I don't think its possible in c/c++. you can use function pointers, but I dont think you can modify a function this way.
#169758 - Karatorian - Sun Aug 02, 2009 7:40 am
It is possible in C, very few things aren't. However C doesn't provide much in the way of support for this sort of thing. It's all complier and compile time option dependant.
It's actually pretty simple to do what you describe. If you have a compiled C function and you know the size that it compiles to (there are a number of ways to figure this out), you can copy the original into memory (on the stack, heap, or anywhere else you can write to) and then you can execute it.
To modfiy the code, you'll have to know where in the compiled function the bits you which to change are. (Again, there are various ways to calculate this.) Then you can write the desired values and run your modified function.
Of course, this all depends on being able to execute memory that is writeable or was writeable at one point. On modern systems with MMU and such, it's often part of the security measures to disallow such things. But on embedded systems, that is not a concern.
The bigger question is why bother. For starters, while C can do it, it's easier in assembler and wouldn't be at all portable anyway. Plus there's little to no advantage.
If you're imagining that you'll be able to squeeze fantasic new levels of performance out of a given device, you're dead wrong unless your skills are utterly amazing. In which case, you'd already know the answer to your question, so they're not.
For staters, most of the time a decent optimizing compiler will produce asm code as good or better than hand hacked. Secondly most people aren't any good at asm these days, so the results are even more stacked againtst hand hacking.
I mention this because it's bascially the same idea. It's pitting your hand hacked optimization tricks against the compiler. Chances are, the compiler's better.
In short, what exactly are you trying to accomplish and why is it your dream?
#169761 - LOst? - Sun Aug 02, 2009 11:40 am
| Karatorian wrote: |
| In short, what exactly are you trying to accomplish and why is it your dream? |
It is basically harder to hack code that is relocated. I would like to have code at a random offset that needs to be used to decrypt data. And where the data and code is mixed together to make it harder to realize they are all part of the decrypt process.
_________________
Exceptions are fun
#169762 - keldon - Sun Aug 02, 2009 12:03 pm
| LOst? wrote: |
| Karatorian wrote: | | In short, what exactly are you trying to accomplish and why is it your dream? |
It is basically harder to hack code that is relocated. I would like to have code at a random offset that needs to be used to decrypt data. And where the data and code is mixed together to make it harder to realize they are all part of the decrypt process. |
The debuggers display code wherever it is in memory so that isn't much of a layer at all. All you can do is make the process more tedious is adding layers of complexity/deception/difficulty/processing/whatever-you-would-call-it in order to slow down the task.
There was this one item of abandon ware that made debuggy puke, that's about the best way to make it more difficult to hack - render debugging impossible!
Layers of interpretation would make it quite time consuming to reverse engineer as well, such as having an interpreted language run an interpreted language running an interpreted language. It will be cracked eventually, but each layer has to be debugged making it totally annoying :D And on the plus side, it's not that hard to create (in terms of knowledge required to understand it).
You could even transform your interpreted code to an obscure language like P", now try making sense of that ^_^
Hope it helps!
#169769 - Karatorian - Mon Aug 03, 2009 5:38 am
Ah, so you're thinking security through obscurity. It's pointless really, many have tried and failed, for the fundamental reason that what it's attempting to do is, by definition, impossible.
Those who resort to obscurity for thier security are doing one of two things. They're either attempting to make a securable system secure using a method that has been shown to be failed and unworkable, or they're attempting to secure a system that by it's very nature cannot be.
The latter case is usually some copy protection scheme or so called "digital rights management." As history has demonstrated and mathematics can show, it isn't possible. One can delay the inevitable, but you cannot stop it.
To me, I'd prefer to write code that isn't pointless, but to each his own. If you can hold off the crackers for the effective market life of your product and you're in it solely to make a buck, it may be worth it to try, is but usually unsuccessful. If you're cracked "ahead of schedual" as it were, you'll actually be wasting resources.
If you don't mind me asking, what have you got that you think is so valuable to put the effort into developing a copy protection system from scratch, but not so valuable as to attract the attention of those who can (and will) crack it?
#169770 - keldon - Mon Aug 03, 2009 9:48 am
Bear in mind that games get shipped to stores long before the release date, amongst the hundreds and thousands of workers worldwide there will always be at least one who will leak it to a cracker. So the [commercial] ideal is to make it take at least a week or two to crack (minimum), and then you would want another month long window to get you past the initial sales phase.
Given the time it takes to crack one layer, adding additional layers [inevitably] increases the time to do so linearly. As you know, most protected games feature more than one layer, for which each has tutorials available for cracking.
I wouldn't tell anyone to give up on making cracking more difficult, that's just a mystic belief that it's impossible; though I would encourage anyone doing so to study cracking first.
Too much arrogance amongst crackers and diffidence amongst vendors is not good for development of the field.