Why does this work? - Self modifying code.

[Skids]

I had a late night thought which went along these lines. Would it be possible to build a livecode application for MacOS that parses a text file that specifies the controls and the scripts of the application. So the fist step was to see if the handler in a button can set the script of a second button. I built a simple stack with two buttons. It seemed to work so I extended it to the following button script.

Code: Select all

on mouseUp pMouseButton
   answer "My name is " & the name of me
   create button "Btn01" in card id 1002
   set the loc of btn "Btn01" to 200,80
   create button "Btn02" in card 1 of this stack
   set the loc of btn "Btn02" to 200,115
   
   
   put "on mouseUP " & cr into tscript
   put tscript & "put " & quote & "Hello World from " & quote & " & the name of me" & " into tmsg" & cr  into tscript
   put tscript & "answer " & tmsg & cr into tscript
   put tscript & "end mouseUp" & cr into tscript
   
   set the script of button "Btn01"  to tscript
   set the script of button "Btn02"  to tscript
   
   set the disabled of me to true
end mouseUp

The IDE complains about external modification but otherwise the code runs. What surprises me is that it works when saved as a standalone application. In my example I have been lazy and don't load the text from a file but I can see no reason why an open stack handler could not load and parse a UI description file, building the application on the fly.

I'm not sure why Livecode allows this. The second surprise is that MacOS does not throw a fit when a running application is modified in this way.

Now the down side is that getting all the quotes in the right places is extremely error prone but it seems that a simple script runner interface could be built this way. It would mean that the built app could in effect be modified at anytime in the future just by editing the UI description file.

Is anyone else surprised ?

S

[tperry2x]

Is anyone else surprised ?

Not really. When you are modifying the script of objects and creating things on the fly through other scripting, you aren't actually modifying the app in any way. You are just changing the stack loaded by the standalone in RAM. As soon as you close it, your changes are lost and are temporary.

This is essentially how a livecodescript file (the revmenubar) puts the stack together. All changes being temporary and modified in memory.

Of course, you'd still need working exec code in the standalone, but there's nothing stopping you loading other scripts like this. You can't modify the script of a button while it's executing, but you could do:

Code: Select all

on mouseup
   -- this is my script in a button called "one"
   send tChangeScript to button "two" in 1 second
end mouseup

Code: Select all

-- this is my script in a button called "two"
on mouseup
   answer "script from button two"
end mouseup
on tChangeScript
   set the script of button "one" to the script of me
end tChangeScript

Or another way of putting it, let's say you are creating a stack but haven't yet saved at all. All those changes are purely in ram at that point.
Nothing is saved to file, and that's essentially the state of things when you are making changes within a standalone with scripting.

The standalones would of course allow this kind of modification of objects in ram - they'd have to, otherwise you'd not be able to change the appearance or position of an object such as a button through scripting.
What I mean is, you could have this in a button in a standalone:

Code: Select all

on mouseup
   set the left of me to the left of me -10
end mouseup

This moves the button 10px to the left, but only in RAM. All these changes are temporary and lost the moment you close it.

The save feature is just turned off in standalones because there's no stack file to actually save to: at that point, the stack code is intermixed with the application binary executable by the engine when the standalone is built, so there'd be no way of saving it anyway.

[FourthWorld]

Is anyone else surprised ?

The IDE builds itself at runtime from scripts. It's been doing that since the introduction of script-only stacks, useful for Github-dependent teams.

And as Tom pointed out, the ability to have scripts affect object properties is as old as HyperCard; a script is just another object property. The only difference in the modern era is that OSes no longer allow executables to save changes to themselves, but you can do anything you want in memory.

This is useful in all the ways the IDE exemplifies, but also implies a risk: if your scripts can modify your other objects, so can scripts from others. Be mindful of what you're running in your session. In a community as small as ours we almost never see malware, but the freedom xTalks offer, like all freedoms, also carries a burden of responsibility to manage the environment.

This raises a question for future consideration: the proprietary edition of this engine includes script encryption, which not only prevents scripts from being copied but also prevents them from being dynamically modified. The former isn't useful in open source, but the latter may be useful for runtime security. How might we provide similar optional protection from external script modification in OXT?

[tperry2x]

This raises a question for future consideration: the proprietary edition of this engine includes script encryption, which not only prevents scripts from being copied but also prevents them from being dynamically modified. The former isn't useful in open source, but the latter may be useful for runtime security. How might we provide similar optional protection from external script modification in OXT?

A larger question is how do you prevent this throughout the entire OS?
Have a look at WinHex for example. With that, you can actively tweak whatever is currently loaded into RAM and provided you know the expected insertion string, you can make any program do whatever you want on the entire OS. This is the way most Windows game cheat engines work. There's even one written in Java for Windows here.

So to tweak an open stack in RAM within LCC/OXT, you'd just need to know the memory offset, the string and what you want to change it to.

On Linux, you can do a similar thing with ptrace (although you'd need to be root to do that).

On MacOS, it's increasingly hard - although there are a few ways to do that.

ram-write.png (61.66 KiB) Viewed 9993 times

[foxtrot47]

Have a look at WinHex for example. With that, you can actively tweak whatever is currently loaded into RAM

So this connected to that, and an hour or so later I'm gobsmacked: unencrypted source from a distant and long forgotten part of my life, pulled straight from the executable running in RAM!!!

I was convinced I'd never see those LiveCode scripts again! Whether it's a perfect conversion process or not, a WinHex personal license is a small price for the opportunity to explore a "now free for everyone" release on the product responsible for supporting a small percentage of my 20's.

tperry2x, thank you Seriously, I owe you a meal, drinks, and some friendly conversation sometime in the future!

[OpenXTalkPaul]

If the application directory has the correct privileges set once installed then the system probably should not allow writes to that directory unless the user has the correct privileges ( root/ admin ), of course you could have your script copy and then modify anything you want in a writeable directory (probably user ~/Documents/ or 'temporary' specialFolder path).

Is anyone else surprised ?

The IDE builds itself at runtime from scripts. It's been doing that since the introduction of script-only stacks, useful for Github-dependent teams.

Just for accuracy SOME of the IDE builds itself ... specifically: MenuBar and Tools, most of the rest of the IDE pieces are binary UI stack and/or a stack-template with script-only behavior scripts attached.

There is a script called scriptify in one of the GitHub repos, that seems to be meant to automate the conversion from binary stacks to separated binary UI + script-only behaviors. Monte Goulding also released a similar script that looks like it was meant do that for scriptifying UI elements too (so having no binary stack format involved at all, the UI is built at runtime).

A while back I started writing a stack that tries to convert a binary stack to Dan's HTML based 'stack' format. I think there are a few other community released stacks around that try to do similar stack-UI to html conversion. the difference is that with Dan's HC Sim 'Engine' script.js embedded you include have functioning HyperTalk+ scripts in the generated webpage too.

[tperry2x]

So this connected to that, and an hour or so later I'm gobsmacked: unencrypted source from a distant and long forgotten part of my life, pulled straight from the executable running in RAM!!!

Haha, yes - RAM inspection is a fun game. More often than not, it makes a mockery of any 'encryption'.

tperry2x, thank you Seriously, I owe you a meal, drinks, and some friendly conversation sometime in the future!

No problem at all, happy to help.

Edit: something related that occurred to me regarding Supercard, in this respect.

[foxtrot47]

Edit: something related that occurred to me regarding Supercard, in this respect.

That Supercard discussion was living rent free in my head all week, so today finally I did something about it.

While I couldn't get code injection working with WinHex (yet), I did see success with the GNU Debugger. After injecting my payload, I successfully extracted the mainstack (including substacks) from RAM and saved everything to storage. The stack file runs perfectly in RunRev 4, LCCE 7-9, and OXT.

I did it!! However, now I'm wondering if I should share the process and tools I used on my web site, or if I should keep it to myself. After all, I am talking about hacking encrypted standalones here. What do you think?

[tperry2x]

...should share the process and tools I used on my web site, or if I should keep it to myself. After all, I am talking about hacking encrypted standalones here. What do you think?

Well, I'm glad you found the technique useful. It's probably not a good idea to share it - it would ruffle a few feathers. I'm glad it means you managed to get back your stack that way.

It can also be used to peek at the inner workings of pretty much anything running on your system too. If nothing else, it's interesting. A lot (and I mean a lot) of programs out there have active bug bounties - you can (and I have in the past) get paid for finding bugs like this. Best to check with them before making anything public. Other companies may offer a cash incentive for you not to go public with exploits.

Disclosing anything publicly without first letting the company know though is most definitely, definitely frowned upon and is a real no-no. In fact, it can really land you in hot water - so if in doubt, I'd always give the company the heads-up (not the full procedure - just a brief proof-of-concept) and see how they respond. Just to be clear, I'm not talking about threatening any company into action either. A good developer will be interested and receptive to what you've found, and if it's commercial software, it's probably in their interests to want to know about it.

If the developer doesn't seem interested after being contacted, then I'd always err on the side of caution and keep it to yourself. (I used to do white-hat pentesting for a time, and I was always amazed by the number of companies that played loose with customer data - even exposing that data online normally) - but that was a long time ago now and a lot has changed.

[foxtrot47]

Disclosing anything publicly without first letting the company know though is most definitely, definitely frowned upon and is a real no-no. In fact, it can really land you in hot water - so if in doubt, I'd always give the company the heads-up (not the full procedure - just a brief proof-of-concept) and see how they respond.

Thank you, I appreciate your perspective on this. I'll take your advice and keep the process private while also giving LC a courtesy heads up. While I highly doubt I've discovered anything even remotely close to a "new" exploit, I'm all smiles when I think about the shiny new feather in my cap!

[richmond62]

SShot 2025-03-17 at 14.36.58.png (256.87 KiB) Viewed 7133 times

-
Methinks the whole shebang is wide open for attack.

[richmond62]

One of the 'interesting' things will be to see if one can modify the script in a standalone like that.

I suspect one can, but it won't be saved: not that that would stop it from being executed.

YES! that does work in a standalone.

NO! it is not retained between launches.