ansaurus

Question

Answer 1

A:

Doh, I solved it by replacing [y,x] with [y][x]

Not sure why it did not give a more clear message what I was doing wrong.

The Guy Of Doom 2010-10-23 09:37:16

I'd say you've found a bug in the compiler, if this was a runtime message. The runtime detected illegal bytecode. The compiler produced that bytecode from non valid actionscript. It should have given you an error and refuse to compile your code.

Juan Pablo Califano 2010-10-23 14:58:47

Possibly. Im using FlashDevelop with the Flex SDK 4.1.0 build:16076 If im to believe the flex-sdk-description.xml file. May be useful if someone wants to reproduce this.

The Guy Of Doom 2010-10-23 15:20:01

I have SKD 3.5.0.12683 available right now, but I was able to reproduce the error just pasting you code, compiling and running. Definitely looks like a compiler bug.

Juan Pablo Califano 2010-10-23 15:59:01

The compiler never bothered to check. This is normal behaviour when using square brackets.

Joony 2010-10-23 16:22:44

@Joony. I disagree. Too bad the compiler didn't check for what I'm almost certain is a syntax error. And even if it's valid syntax (which I doubt), the compiler generated *invalid* bytecode, rejected by the player as such by throwing a VerifyError. That's clearly a bug to me.

Juan Pablo Califano 2010-10-23 16:30:32

Answer 2

+1 A:

This is funky, I love it. What an error!

levelMap[y, x]

Where y is an Object and x is a property of y.

A quick test:

var levelMap:Array = [[0, 100],
                      [20, 21]];
var something:* = levelMap[levelMap[0], 1]; // 100 - The second element of the first array!
trace(something);
something = levelMap[levelMap[0], 'length']; // 2
trace(something);

Some interesting behaviour. Anyone able to explain?

UPDATE:

I think we're just using it wrong.

var a:Object = {num:0, fun:function(num:uint):void{this.num = num;}};
var b:Object = {num:0};
b[a, 'fun'](10);                                                                                                                                                                              
trace(a.num); // 
trace(b.num); // 10

Where b is scope, a is an Object, 'fun' is the property of a, and (10) is the argument. This is equal to (but still with the extra object on the stack):

a.fun.call(b, 10);

The reason b doesn't get popped off the stack is because it's duplicated and the duplicate is being used for the function call.

90:getscopeobject 1
    stack: StackTest
    locals: StackTest StackTest * 
92:getslot 2
    stack: Object? (b)
    locals: StackTest StackTest * 
94:dup
    stack: Object? (b) Object? (Copy of b)
    locals: StackTest StackTest * 
95:setlocal2
    stack: Object? (b)
    locals: StackTest StackTest Object? (Copy of b) 
96:getscopeobject 1
    stack: Object? (b) StackTest
    locals: StackTest StackTest Object? (Copy of b)
98:getslot 1
    stack: Object? (b) Object? (a)
    locals: StackTest StackTest Object? (Copy of b)
100:pushstring "fun"
    stack: Object? (b) Object? (a) String ("fun")
    locals: StackTest StackTest Object? (Copy of b)
102:getproperty {StackTest...Object}::[]
    stack: Object? (b) * (a.fun)
    locals: StackTest StackTest Object? (Copy of b)
104:getlocal2
    stack: Object? (b) * (a.fun) Object? (Copy of b)
    locals: StackTest StackTest Object? (Copy of b)
105:pushbyte 10
    stack: Object? (b) * (a.fun) Object? (Copy of b) int (10)
    locals: StackTest StackTest Object? (Copy of b)
107:call 1 (Call a closure. 1 is the argument count. Stack: function (a.fun), receiver (Copy of b), arg (10).  The result (void) is pushed on the stack.)
    stack: Object? (b) * (void)
    locals: StackTest StackTest Object? (Copy of b)
109:pop
    stack: Object? (b)
    locals: StackTest StackTest Object? (Copy of b)
110:kill 2
    stack: Object? (b)
    locals: StackTest StackTest *

Also, some funky behaviour can be seen using the this syntax:

b[1, true, a, 'fun'](10);

It seems you can just keep adding unused objects to the stack and only the last 2 are evaluated.

Joony 2010-10-23 16:07:21

@Joony. I've found a couple of intersting things about this. Check out my answer for the details.

Juan Pablo Califano 2010-10-24 00:27:57

Excellent research! I wish I could +3.

The Guy Of Doom 2010-10-25 21:04:58

Mmm. Interesting. So, somehow, here `b[a, 'fun'](10); `, `b` is being used as the context object? I'll give it a close look when I have a bit of time to spare.

Juan Pablo Califano 2010-10-25 22:17:58

Not sure why (maybe because there are objects and closures involved), but here the behavior is a bit different, as you noted. It adds an extra object (`b`), but still, it pushes it again in the correct order to produce the same effect as `a.fun.call(b,10)`. The sequence that prepares the call looks like this: `obj_b, obj_a, "fun"`, `obj_b, obj_a["fun"]`, `obj_b, obj_a["fun"], obj_b`, `obj_b, obj_a["fun"], obj_b, 10`, `obj_b, obj_a["fun"](obj_b,10)` (the function call result is popped but obj_b is not). This didn't happen in the other case (maybe because the value was null?)

Juan Pablo Califano 2010-10-26 02:34:00

Answer 3

+7 A:

A I said in previous comments, I think this is a compiler bug, based on the simple fact that the compiler produced illegal bytecode and the player was able to catch this malformed bytecode and throw a VerifyError accordingly.

However, upon some investigation, I found a couple of interesting things.

First, Joony's findings put me in the right track. Apparently, as his code shows, you can trick the compiler into translating what's between the square brackets as a property access.

So, this:

foo[foo,'length']

is equivalent to:

foo["length"]

There's a problem here, but I'll explain it in a second.

You can also call methods, like this:

var foo:Array = [];
foo[foo,'push'](1);
trace(foo);

This will effectively push 1 into foo

With some additionaly trickery, you can chain all this to get this nasty beast:

var inner:Array     = [10];
var outter:Array    = [1,2,inner];
(inner[outter, 'pop']).call(null)[inner,'push'].call(null,20);

trace(inner);
trace(outter);

This is equivalent to:

var inner:Array     = [10];
var outter:Array    = [1,2,inner];
outter.pop().push(20);

That is, we pop inner from outter and then push 20 to it.

I started noticing that here

inner[outter, 'pop']

inner is not used.

In fact, you can change it to:

null[outter,'pop']

or even

(void)[outter,'pop']

And the compiler won't complain about it (neither will do the player). I doubt the above is valid Actionscript sintactically (in which case the compiler should refuse to compile it), but I'm not 100% sure. However, this unused object is the root of the problem. (The following requires some basic knowledge of how flash assembly or any other stack based assembly works, but I hope I can explain it so it can be understood without assuming too much.)

I disassembled the bytecode generated by this actionscript code:

var arr:Array = [10];
null[arr,'length'];

Disassembled code:

function private::initLevel():void  /* disp_id 0*/
{
  // local_count=2 max_scope=1 max_stack=3 code_len=17
  0     getlocal0       
  1     pushscope       
  2     pushbyte        10
  4     newarray        [1]
  6     coerce          Array
  8     setlocal1       
  9     pushnull        
  10    getlocal1       
  11    pushstring      "length"
  13    getproperty     null
  15    pop             
  16    returnvoid      
}

Let's go step by step. instr is the offset of the instruction; stack_state shows the current state of the stack after the instruction is executed; comments is self-explanatory ;)

  instr stack_state             comments
  -------------------------------------------------------------------------------------------      
  0     this                    "this" is always passed in local register 0 to instance methods
  1                             "this" is added to the scope chain and popped
  2     10                      now, we have 10 on the stack    
  4     [10]                    an array is created and initialized taking 1 element from the stack
  6     [10]                    this is sort of like doing [10] as Array
  8                             the array is assigned to local variable 1
  9     null                    null is pushed. That is the null in this line:
                                null[arr,'length']
                                HERE BEGINS THE PROBLEM!
  10    null,local1             local 1 is pushed
  11    null,local1,"length"    the string constant "length" is pushed
  13    null,local1["length"]   getproperty null is used for dynamic lookup (object["prop"]). Both operands are popped from the stack
  15    null                    in the previous step, the result of local1["lengtht"] was pushed. But we dind't use it, so it's discarded
  16    null                    here the method returns. The stack should be empty, but it's not. 
                                The generated code should have popped the null pushed at #9, 
                                or it shouldn't have pushed it in the first place

The problem is that after leaving the method, all of the objects pushed onto the stack by the method sould have been popped. This is not the case, as the null constant remains on the stack after the method returns. In other words, we have an unbalanced stack. Now, the player apparently doesn't mind or doesn't check. I think it should, and should not run this code, since this could (at least potentially) lead to a stack overflow if this grows bigger enough.

Now, if we change the problematic code section to be included within a jump block (such as the block reached after a conditional jump like an if), the player rejects the code with the message:

VerifyError: Error #1030: Stack depth is unbalanced. 1 != 0.

The same as the OP. So, it seems that the presence of a branch triggers some kind of check for stack integrity in the player. At this point, it should be noted that an Actionscript loop (any kind of loop) is implemented at the bytecode level as a conditional jump, just like an ìf. So, even though we don't have a loop in the following code (an if produces code that is shorter and simpler to analyze), since it triggers this check in the player, for our purposes, it's the same as having a loop, as the OP did.

In AS code:

var dummy:int = 1;
var arr:Array = [10];
if(dummy != 0) {
    null[arr,'length'];
}

Disassembled:

function private::initLevel():void  /* disp_id 0*/
{
  // local_count=3 max_scope=1 max_stack=3 code_len=27
  0     getlocal0       
  1     pushscope       
  2     pushbyte        1
  4     setlocal1       
  5     pushbyte        10
  7     newarray        [1]
  9     coerce          Array
  11    setlocal2       
  12    getlocal1       
  13    pushbyte        0
  15    ifeq            L1

  19    pushnull        
  20    getlocal2       
  21    pushstring      "length"
  23    getproperty     null
  25    pop             

  L1: 
  26    returnvoid      
}

Step by step:

  instr stack_state             comments
  -------------------------------------------------------------------------------------------      
  0     this                    "this" is always passed in local register 0 to instance methods    
  1                             "this" is added to the scope chain and popped
  2     1                       now, we have 1 on the stack    
  4                             1 is popped and assigned to the local variable 1 (the dummy var in the code)
  5     10                      10 is pushed
  7     [10]                    an array is created and initialized taking 1 element from the stack
  9     [10]                    this is sort of like doing [10] as Array
  11                            the array is assigned to local variable 2 (the arr var in the code)
  12    local1                  local1 (dummy) is pushed
  13    local1,0                0 is pushed
  15                            this instruction consumes (pops) both local1 and 0 to compare them
                                If this condition is satisfied, it jumps to the label L1
                                If it is not, it falls-through to the next instruction 
                                (the same as a case label in a switch statement that does not have a break, in Actionscript code)
  19    null                    null is pushed. That is the null in this line:
                                null[arr,'length']  
                                Again, HERE BEGINS THE PROBLEM!
  20    null,local2             local2 is pushed
  21    null,local2,"length"    the string constant "length" is pushed
  23    null,local2["length"]   getproperty null is used for dynamic lookup (object["prop"]). Both operands are popped from the stack
  25    null                    the value returned by local2["length"] is discarded

  26    null                    the method returns, but null is not properly popped from the stack!

So, again, null is still on the stack after the method returns; the stack is unbalanced. But this time, the player checks this, finds the problem, throws a VerifyError and aborts the code.

At any rate, to wrap it up, my conclusions are: the compiler generates illegal bytecode in both cases. I think this is a bug. The player rejects this code if it's able to detect it. But it seems it's only able to detect it if the problematic code is within a jump block (looks like a bug, too).

Addendum:

Joony mentions in a comment that "If you return immediately before the jump then no error". Which is true. The reason is that the code within the if but after the return is "dead code", so the compiler strips it off the bytecode.

So, it's not the jump itself what causes the player to check for stack integrity. I googled a bit and found this on the haxe site.

This is a stack unbalanced error. It means that two branches of a Jump result in different stack sizes when they join back. All jumps or code leading to a given position should result in the same stack size.

Which makes it all more clear.

In the second code example above, that is what's actually happening.

If the code follows the jump at instruction 15, it lands directly on the last instruction (26) to return to the caller. null has not been pushed and nothing else is on the stack, so we arrive at this point with a stack size of 0.

If the code doesn't jump and falls-through, null will be pushed (19) and not popped off. So, this path will reach the last instruction (26) with null on the stack, which means the stack size is 1. This last instruction is the point where both branches join back, but following one branch, the stack size is 0, while following the other, it's 1. And this is what causes the player to complain about an unbalanced stack.

Juan Pablo Califano 2010-10-24 00:27:04

very interesting!

grapefrukt 2010-10-24 00:32:57

Excellent post. I too was hot on the trail of the 'jump.' If you return immediately before the jump then no error. I love the <code>(inner[outter, 'pop']).call(null)[inner,'push'].call(null,20);</code> I wonder where this strange syntax came from. Maybe someone from Adobe can explain it.

Joony 2010-10-24 08:33:39

@Joony. Thanks. Good point about the immediate return. It makes sense. Googling a bit I found what this error message really means on the haxe site. Which explains the problem more clearly. I've added this to my answer.

Juan Pablo Califano 2010-10-24 16:42:44

I've just updated my answer with more findings...

Joony 2010-10-25 11:48:53

This is all very interesting! I know some basic assembly and stack (very basic), but this seems like it bay be exploitable if you manage to keep the stacks the same length when they rejoin. Has someone contacted Adobe yet? I wish I could +3.

The Guy Of Doom 2010-10-25 21:04:40

@The Guy Of Doom. That was my first reaction too (as I wrote in the answer). But I'm not so sure now. I tried to get access to this "orphan" stack item after the method return and got an stack underflow error, so for the player, the thing is not there anymore. It's likely that after return the player resets the stack to the state it had at call time, instead of relying in the caller not to left junk floating around. That would explain why if there's no branching, the player doesn't bother to check whether the stack is balanced or not.

Juan Pablo Califano 2010-10-25 22:21:28

@The Guy Of Doom. On the other hand, I did manage to pass this extra value as a function argument to another function called from the problematic method. I couldn't do it directly, though. I had to manually move the pushnull instruction a couple of instructions ahead (also I had to manually patch the swf); I didn't need to change other stuff, just swap instructions ;that's why I could patch the (uncompressed) swf by hand with an hex editor; otherwise it's almost impossible not to break relative addressing. But even this doesn't seem exploitable.

Juan Pablo Califano 2010-10-25 22:26:58

Answer 4

A:

omg you most likely just solved the misterious problem that almost killed me ^_^ i was trying to re-create an swf file from a dump:

`[SWF]
  Header:
    Version: 10
    FileLength: 623
    FileLengthCompressed: 454
    FrameSize: (180,160)
    FrameRate: 8
    FrameCount: 10
  Tags:
    [69:FileAttributes] AS3: true, HasMetadata: false, UseDirectBlit: false, UseGPU: false, UseNetwork: false
    [09:SetBackgroundColor] Color: #666666
    [86:DefineSceneAndFrameLabelData]       Scenes:        [0] Frame: 0, Name: Scene 1
    [83:DefineShape4] ID: 1, ShapeBounds: (-100,1100,-100,1100), EdgeBounds: (0,1000,0,1000)
      FillStyles:
        [1] [SWFFillStyle] Type: 0 (solid), Color: FFFF0000
      LineStyles:`(and so on)

using as3swf (a library which uses almost only bytecode inside itself) but today (with a fresh-downloaded flex sdk 4.1) all i got was a strange trace (recieved many times):

    [SWF]
    Version: 10
    FileLength: 21
    FileLengthCompressed: 21
    FrameSize: (14,14)
    FrameRate: 50
    FrameCount: 1
  Tags:

and the strangest thing for me was that it was a trace of global storage ByteArray variable that most likely was only read during the runtime, but the information it was storing didn't have just some part missing - almost every value changed

so thank you for your answer, it explained a lot for me)

www0z0k 2010-10-24 07:14:02

ansaurus

tags:

views:

answers:

Error #1030: Stack depth is unbalanced

related questions