-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DEFINESHAPE (etc) blocks in modified .swfs are wrong size #7
Comments
If possible, could you attach a sample FLA and/or SWF? The current fork of the format lib is most likely parsing or writing some aspect of the shape data incorrectly compared to my own shape parsing code in the 2013 release. |
I'll have to get corporate approval for that, since it's corporate IP - let me get back to you once I've had a chance to ask. (I may not get an answer until later next week... or after Christmas...) I'll try to do some digging myself in the meantime, since I'd like to continue wrapping my head around more of this. |
Correction: The PLACEOBJECT2 blocks which are different are 1 byte larger than the original. I'm not sure at this point whether the difference is in the actual size of the blocks or only in the reported size. |
Thanks! If you can repro the problem in a minimal example SWF, that helps too! |
I've attached a minimal example which shows a couple of the changes that the current version makes to the SWF with all mutators turned off. It doesn't make Flash Player go boom like the production SWF does, but hopefully it illustrates some of the mangling that's happening. movecircle.: Original files. I've pushed compiled Swivel versions to my write-intermediate branch if you want to play with them: https://github.com/andrew-klaassen/Swivel/tree/origin/write-intermediate/bin They go into an endless loop when they get to the movie-outputting stage, but just before that they put a "modified-201[37].swf" file into the application storage directory (...\com.newgrounds.swivel.Swivel\Local Store). For now, I've been able to hack your missing-first-frame fix onto the 2013 release, and it seems to be working fine. |
I took a quick look, and I think the attached SWF is working fine; there's some flexibility in the way you can write data in the SWF file, so you can have SWFs with different data, but that are semantically the same. In particular, the difference in the dumps you posted is the matrix of the last PlaceObject2 tag, which has an extra byte. The transform has zero translation, which is being written with a length of 1 bit in the current format version, but my old code didn't bother to write the translation in this case and wrote it with a length of 0. Both should be equivalent and valid, so I don't think this is the issue you're hitting in the problem SWF! |
Ah, that makes sense. I was just stepping through the matrix code, trying to make sense of it; thanks for the explanation. I'll keep working on trying to get a broken version to send you. |
No worries, thanks for helping out!!! |
This might be less than helpful in the absence of the full file, but I think that I've narrowed the problem down to the DEFINEMORPHSHAPE changes. I've created two SWFs where this is the only difference: Working (original, differences with non-working highlighted with **):
Not working (produced by Git version of Swivel):
The PLACEOBJECT2 which immediately follows is fine, but the second time that id 0213 is accessed - for another PLACEOBJECT2 17 frames later - Flash Player (and Swivel) crash. |
Yikes, it looks like the morph shape writing code in the current format lib is a mess. I see quite a few problems in there, chiefly I think the # of colors in the gradient is not being written. Also looks like it's writing the radial gradient as linear gradient there. There's also #5, so I think I should just check over all of the shape tween code in format. Relevant code: I can fix this later tonight, or if you want to give it a shot, let me know! |
(I actually think the old Swivel didn't even bother to parse the DefineMorphShape tags and just read the bytes as is. But since it's in format now, might as well fix it.) |
I just now pieced my way through the bits to get to the part where swf_gradient structure is missing its count. I'm happy that you came to the same conclusion, because it means that all the manual bit-aligning I've been doing for the past couple of hours wasn't a waste. :-) I am about to switch into child care mode, but I wouldn't mind giving it an attempt tomorrow. If you know of any magical tools which break down SWF bit fields so that I don't have to do it bit-by-bit myself, I would love to know about them! (I did learn a lot by going bit-by-bit, but it was a bit painful.) |
I think the best way is to use the HaxeDevelop debugger and put a breakpoint in format/swf/Reader.hx or Writer.hx. You can step thru and see where things get weird. Also, this is the best SWF decompiler and inspector around: https://www.free-decompiler.com/flash/ |
I've been stepping through with the HaxeDevelop debugger, but for this problem it wasn't as helpful since Swivel would just go boom when it called _frame.drawWithQuality(), and the debugger would just sit there silently. I ended up using a manual binary search, stitching together part of the original SWF with part of the mangled SWF until I found the specific location of the problem. Very hacky, but it got me there eventually. Stepping through with the debugger definitely did give me a better understanding of the program flow, though. I will check out that decompiler - thanks! |
Oh, wait, I have been using that decompiler! With the broken SWF, the morph shapes were simply missing, which probably should've given me a clue as to where to look. |
I've submitted a couple of pull requests for format.swf: andrew-klaassen/format@00c26ea fixes the crash that led to this bug report. andrew-klaassen/format@2b58581 matches the matrix writing behaviour of Flash so that real bugs are easier to spot. The other two commits in my pull requests deal with other things; should I open new issues for them? (I haven't done much on Github so far, as you can see, so I'm uncertain about the niceties. :-) ) Thanks. |
A couple of my swfs are fine in the 2013 release of Swivel, but always crash the current version. By turning off all mutations in both 2013 and current versions, and then writing out the intermediate swf that gets fed to _loader.loadBytes(), I think I'm getting closer to finding the culprit: The byte length of some blocks is changed by a few bytes in the intermediate swf, but only using the current version. The intermediate swf created by the 2013 version doesn't have these differences.
Using swfdump and diff, here are a couple of typical lines showing the difference between the original swf and the (theoretically unmutated) intermediate swf created by the current version of Swivel:
In the swf I'm testing:
DEFINESHAPE2, DEFINESHAPE3: ~25% of blocks are 1-65 bytes larger than the original
DEFINESHAPE: ~5% of blocks are 1 byte larger than the original
DEFINEMORPHSHAPE: 100% of blocks are 1 byte smaller than the original
PLACEOBJECT2: ~.005% of blocks are 6 bytes smaller than the original
Everything else in a detailed dump (swfdump -D) comes out the same.
I'll hopefully get a chance to look into this further sometime in the next few days. I wanted to get it written down before I forget what I've figured out.
The text was updated successfully, but these errors were encountered: