WoWInterface - Trojo - Doing it right from the start

WoWInterface (https://www.wowinterface.com/forums/index.php)

- Cataclysm Beta (https://www.wowinterface.com/forums/forumdisplay.php?f=82)

- - Trojo - Doing it right from the start (https://www.wowinterface.com/forums/showthread.php?t=34002)

Trojo - Doing it right from the start

With alot of addons going to have to be updated and worked out again. I am just waiting for the new API to be released with all sorts of neat new calls and everything. I have a suggestion.

Awhile back, there was an amazing idea. Elements. Earth Lib, Water lib, Air Lib. Awesome. Libraries to do different things. Then came more classes and libraries to help aid in development. I want to take it a step further.

Trojo.

Trojo is going to be a module based framework. With the ability to load on demand, and update on demand. Trojo is an addon, much like a suite, which developers create plugins for. Trojo is a raid addon, or its a bar addon, or its a buff addon...or its a... you get the point.

I have tested with my work group many of different ways to do asynchronous loading as well as updating live. I know that WoW becomes a sandbox... but there are ways around this.

Trojo will be the only core addon that gets updated. Trojo will have a list of addons that are allowed, as well as a developers key which is a compiled LUA code to protect from malicious attacks.

Here is an example of how the update works:

Trojo -> Mojo(Unit Frame library built in) -> User A is using v1.0 -> Join TrojoUpdate.channel

Channel Broadcast: User B has Trojo v1.1A and Developer Key xxxxxxxxxx was fired off.

User A Trojo <-- Fire popup: Would you like to update Trojo?
User A Hits YES!
User A gets a channel ping: USERA,ChannelID
USERA, Trojo A joins Channel ID, Trojo B joins.
Trojo B sends Line by line update chat 2 lines per 3 seconds.

Trojo A Update complete.
Trojo A has code stored in cache text. Trojo now has a new addon.

-----------

My goal is to create a way for users to say.. hey man we really need you to have XXX addon. Ok, send it to me. Bam. You get it.

Trojo testing will start as soon as the UI is allowed in Cataclysm. Currently the working copy of Trojo is limited to what it can do, as alot of the code is staying opened until we know for sure whats in Cataclsym.

I will be making a development set, as well as a plugin system as soon as we are ready for developers to port addons to the Trojo system.

I hope this explains everything that I am working on. If you have questions about this please ensure to contact me on PvP realm Beta US Horde. My name is Trojo

You can't load compiled binary code into WoW, you would need some sort of public/private key setup. OpenRDX has done this sort of update system, but if I remember right it's small scale updates.

Letting an entire addon live in the SV would kill your load times, and you'd likely hit the limit on SavedVariables for a large addon. You would also need to distribute the entire addon to do this, which is slow over the addon comms channel. Better off telling someone to use an addon updater.

It's interesting from an implementation standpoint, but what you want to do is impractical.

Agreed on the impracticality, but the SavedVars limit is pretty large. It will hold, for example, the text of every item pre-ICC (yes, I test my limits :D).

However, there is no "you can't put more here" error. If an addon's SavedVars file gets too large, it will be deleted the next time the addon loads.

The load times wouldn't be a whole lot worse than a normal addon. Either way, you're still loading and executing. Stored in SavedVars, you're loading a string, then executing the string, which lua handles fairly efficiently if you do it all as one string (not line by line and concatenating it together). As long as you store each lua file as its own string it shouldn't be too bad.

I still think the current model is better for most uses; while I would love the ability to send someone an addon, the reality is that they'd almost always need to go get Trojo first anyway. May as well just have them get the addon. Also, you'd have all the settings for all the Trojo addons stored together, so if one of them corrupted itself, all of them would be at risk.

Finally, security would be a nightmare. I prefer having the code somewhere I (or WOWI :)) can read it first.

That said, if you can come up with a macro that will allow receiving of an addon for quick-and-dirty testing/whatever, you may have a use-case. I wouldn't make them persistent though. Instead, make Trojo send a URL with each addon and save the URLs so they can see where to get the full version.

Quote:

Originally Posted by Shadowed (Post 198326)

You can distribute compiled code and execute it in WoW. Carbonite when it was closed source has proven this. Using the LUA -c parser will allow you pass an 'encoded' version so that it cannot be reversed.

The Saved Variables will be kind of...adjusted.

If you get a chance look at Tweet Craft, and how it works. Allowing updated information in realtime to go from WoW to Twitter, and Back. Though an ExE will not be needed because were not uploading to a source destination.

Modules is something that is a little tough, which is why Trojo will have all the required libraries which are load on demand.

Dynamics are stored in Variables. The AutoUpdater is for players that are on and raiding.. or playing and want to update or pull addons they never heard of written for Trojo.

It may be something you need to see. I will be glad to show you in the coming weeks. :-)

Quote:

Originally Posted by Kookie (Post 198342)

Wrong. Carbonite was never compiled. It was heavily obfuscated, decrypting itself over and over using loadstring(), until the low level obfuscation layer was attained. But the code itself was never compiled, just heavily obfuscated.

Note: I'm saying "compiled" as in "compiled in byte code", not "compiled into an horribly obfuscated version", which would be against the new EULA from Blizzard anyway.

If you don't believe me, load the Wow.exe into a disassembler such as IDA pro free: http://www.hex-rays.com/idapro/idadownfreeware.htm, and go to 00856190 (valid as of the latest 3.3.5 binary). If you know the Lua Virtual Machine, you'll recognize the f_parser function here, which sourcecode is:

Code:

static void f_parser (lua_State *L, void *ud) {

  int i;

  Proto *tf;

  Closure *cl;

  struct SParser *p = cast(struct SParser *, ud);

  int c = luaZ_lookahead(p->z);

  luaC_checkGC(L);

  tf = ((c == LUA_SIGNATURE[0]) ? luaU_undump : luaY_parser)(L, p->z,

                                                            &p->buff, p->name);

  cl = luaF_newLclosure(L, tf->nups, hvalue(gt(L)));

  cl->l.p = tf;

  for (i = 0; i < tf->nups; i++)  /* initialize eventual upvalues */

    cl->l.upvals[i] = luaF_newupval(L);

  setclvalue(L, L->top, cl);

  incr_top(L);

}

Look at 008561BC: the call here is luaY_parser, and you'll notice that the luaU_undump call from the conditional call is missing. The whole signature reading, condition on signature comparison, and call to the lua vm are being removed here, thus leaving only the ability to load non-precompiled, plain text binaries.

In all cases, I don't see how pre-compiling the addon would protect against anything. Only a key/signature check could. Nothing would prevent me from distributing a pre-compiled malicious piece of code. So that's redundant and irrelevant protection here.

Also, I hope you don't even think of "adjusting" the maximum size of the saved variable by modifying the Wow.exe binary. That, again, would be against the EULA, and probably detected by Warden as a cheat attempt, if you can even pass the authentication with a modified binary that is.

All in all, I too believe this is a bad idea overall. Several reasons:

-) This will drastically explode the size of the saved variables.
-) Circumventing that max size will probably cause troubles.
-) The CPU load to do a signature check will be insane in plain Lua.
-) The overall loading time for players will be insane.
-) The scalability of this kind of distribution method is probably going to make the Blizzard servers crying for their lost bandwidth.

Oh and, several other things "against" pre-compiled Lua code:

-) The bytecode is ridiculously easy to understand and reverse. Thus your "it can not be reversed" argument is void. See http://luadec.luaforge.net/
-) The bytecode is machine dependant. World of Warcraft still runs on powerpc machines. Loading pre-compiled lua wouldn't work, because you'd most likely load a little-endian bytecode whereas PPC is big endian.

also if you are running everything from an SV file how are you going to deal with errors since there wont be any decent trace of the error (no meaning full line numbers).

Without even actually talking about the fact this would potentially work only for Lua code, and not for any other kind of file addons may have.

Quote:

Originally Posted by Shadowed (Post 198326)

OpenRDX has done this sort of update system, but if I remember right it's small scale updates.

OpenRDX is an emule system for objects and packages only, which is basically the content... raidframes, unitframes, scripts, threat meters, damage meters, and so on and so forth.

OpenRDX does NOT update the framework or actual coding of the addon through this emule system, however.

There is no limit on the size of the object we can share with OpenRDX.

But we do not share code LUA directly. We share some definitions, it is like you are sharing a profile ace for example.

OpenRDX will generate code on the fly base on this definition.

Definition, could be a player frame, a damage meter frame etc ...

Cheers
Sigg