分享
 
 
 

Flash Uncovered.doc

王朝other·作者佚名  2007-01-18
窄屏简体版  字體: |||超大  

Appendix A: Flash Uncovered

A simple .swf file and it’s below the line representation

At some point along your journey to write your own .swf files, you are going to have to be able to read and understand the raw bits and bytes. I created a one frame flash movie that contained only a rectangle and saved it as Rectangle.swf. Let’s take a look at the way the file is represented in its .swf format. Below is the hexadecimal representation of Rectangle.swf. Let’s take a closer look…

000000 46 57 53 03 4F 00 00 00 78 00 05 5F 00 00 0F A0

000010 00 00 0C 01 00 43 02 FF FF FF BF 00 23 00 00 00

000020 01 00 70 FB 49 97 0D 0C 7D 50 00 01 14 00 00 00

000030 00 01 25 C9 92 0D 21 ED 48 87 65 30 3B 6D E1 D8

000040 B4 00 00 86 06 06 01 00 01 00 00 40 00 00 00

Every .swf file has two parts, the header block and a series of tagged data blocks. Let’s begin with the header.

HEADER

The header is always the first 21 bytes of the .swf file (true?). It describes the file version(1,2, or 3), length of the file in bytes, the frame size in TWIPS, frame rate in frames per second, and the frame count.

Here is the “SWF File Reference’ description of the header:

Field

Type

Comment

Signature

UI8

Signature byte always ‘F’

Signature

UI8

Signature byte always ‘W’

Signature

UI8

Signature byte always ‘S’

Version

UI8

Single byte file version

File Length

UI32

Length of entire file in bytes

Frame Size

RECT

Frame size in TWIPS

Frame Rate

UI16

Frame delay in 8.8 fixed number of frames per second

Frame Count

UI16

Total number of frames in movie

The first three bytes are the standard signature for all .swf files. They are the ASCII values of the characters ‘F’, ‘W’, and ‘S’ in that order. The fourth byte indicates the version of the file. Although a file can be of version 1, 2, or 3, we will always be creating version 3 files so this value will also be fixed.

0x46 ‘F’ 0x57 ‘W’ 0x53 ‘S’ 0x03 3

The next 4 bytes represent an unsigned 32-bit integer indicating the file size. Here’s where it starts getting tricky and machine architecture gets involved! The next 4 bytes are 0x4F000000 so that would imply that the file length is 1325400064 bytes, a very large number which doesn’t make sense. What we failed to do is swap all the bytes.

In .swf files, bytes are swapped whenever reading words and dwords such that a 32 bit value B1B2B3B4 is written as B4B3B2B1, and a 16 bit value B1B2 is written as B2B1. Single bytes are written unchanged since there is NO bit-swapping. The reason for this is the differences in storage and retrieval between the Mac and PC processors.

Reversing the bytes we can read the 4 bytes correctly and see that file is 79 bytes long.

0x4F000000 0x0000004F 79

The next 9 bytes represent a data structure used in the .swf format called a Rectangle. Here is the file description of a rectangle:

Field

Type

Comment

Nbits

nBits = UB[5]

Bits in each rect value field

Xmin

SB[nBits]

X minimum position for rect

Xmax

SB[nBits]

X maximum position for rect

Ymin

SB[nBits]

Y minimum position for rect

Ymax

SB[nBits]

Y maximum position for rect

To understand these bytes, we need to look at the individual bits.

78 00 05 5F 00 00 0F A0 00

0111 1000 0000 0000 0000 0101 0101 1111 0000 0000

0000 0000 0000 1111 1010 0000 0000 0000

There are five fields in a rectangle structure: nBits, xmin, xmax, ymin, ymax. The unsigned nBits field occupies the first five bits of the rectangle and indicates how long the next four signed fields are.

Here’s where we hit another subtle point about the .swf file representation. Reading and writing bits is different from reading and writing words and dwords. There is no swapping at all! This is because when Flash is reading an n-bit field, it reads a byte at a time until it has read all n bits. You don’t do any swapping inside of bytes so there is no swapping at all. So the next five bits are read in order and evaluate to 15. Although the nBit field usually varies, it appears fixed in the header so that header has a fixed size (It may just be because the movie dims are usually the same).

01111 15

What if nBit has a value of sixteen? This is exactly the size of a word so do we read the following fields as words and swap bytes? No. Fields described by bit size are always read a byte at a time. No swapping, just read the next n bits in that order.

000000000000000 0 = xmin

010101011111000 11000 = xmax

000000000000000 0 = ymin

001111101000000 8000 = ymax

For the header, the rectangle is used to store the movie dimensions with xmax corresponding to the movie width and ymax corresponding to the movie height, both in TWIPS. “What’s this TWIPS thing?” you ask. According to whatis.com :

A twip (twentieth of a point) is a measure used in laying out space or defining objects on a page or other area that is to be printed or displayed on a computer screen. A twip is 1/1440th of an inch or 1/567th of a centimeter. That is, there are 1440 twips to an inch or 567 twips to a centimeter. The twip is 1/20th of a point, a traditional measure in printing. A point is approximately 1/72nd of an inch.

For Flash a point corresponds to a pixel, so if we convert from TWIPS to pixels, we see that our movie is 550 x 400.

Now we have looked at all of the fields of the rectangle and evaluated them, but what about those last seven bits which are all 0’s. Well, they were just “filled.”

0000000 = filled bits

After the end of any structure, if the structure does not completely fill up its last byte, then that last byte is filled with 0’s to keep the next item byte aligned. So if the next item is a word or dword, you can read it as such and not worry about being in the middle of a byte. In this case, only 1 bit in the last byte is used so the last 7 bits are filled with 0’s.

Next in the header is the frame rate, which is kind of weird. It is supposed to be stored as a 16bit integer, but the first byte (or last depending on how you look at it) is completely ignored. So the frame rate is 12 fps.

0x000C 0x0C00 0x0C 12 = frame rate

Next is the frame count, which is also a 16-bit integer. So the frame count is 1.

0x0100 0x0001(byte swapping) 1 = frame count

Now we are done with the header. After the header is a series of tagged data blocks. Here is the file description of a tag:

Short Tag

Field

Type

Comment

Tag

UB[10]

Tag id

Length

UB[6]

Length of tag

Long Tag

Field

Type

Comment

Tag

UB[10]

Tag id

Long Header Flag

UB[6]

Always 0x3F

Length

UI32

Length of tag

There are 2 types of tags. They are the short and long data header. Regardless of which case you have, you begin by looking at the first word.

0x4302 0x0243 0000 0010 0100 0011

The first 10 bits of the tag are the unsigned tag ID. The tag ID indicates what type of data is to follow in the body of the data block to follow. In this case the value of the tag ID is 9 which corresponds to a setBackgroundColor block. (APPENDIX SHOULD HAVE ALL ID MEANINGS). The last 6 unsigned bits of the tag indicate the length of the data block to follow if it is 62 bytes or less. If the length of the data block is more than 62 bytes, then this field has all 1’s and the length is indicated in the following dword. In this situation though the field does not have all 1’s so the field does indicate the actual length which is 3 bytes.

0000001001 = 9 = setBackgroundColor 000011 = 3 = body length

Since we know that the length of the body is 3 bytes, let’s take a look at it. A setBackgroundColor block only contains the 3 byte rgb color description so we evaluate it as such. A color is its own 3 byte data type so there is no byte swapping.

0XFFFFFF = white

The next tag is a long tag and is a defineShape tag.

0xBF00 0x00BF 0000 0000 1011 1111

0000000010 = 3 = defineShape 111111 = body length (so we have to look at the

next dword)

0x23000000 0x00000023 35 = body length

Here is the file description of defineShape:

Field

Type

Comment

Header

RECORDHEADER

Tag ID = 2

ShapeId

UI16

ID for this character

ShapeBounds

RECT

Bounds of the shape

Shapes

SHAPEWITHSTYLE

Shape information

The body of a defineShape is composed of an unsigned 16-bit character ID, a rectangle defining the bounds for the shape, and a ShapeWithStyle structure which contains shape information.

0x0100 0x0001 1 = shape ID

Now the Rect which defines the boundaries:

70 FB 49 97 0D 0C 7D 50

0111 0000 1111 1011 0100 1001 1001 0111 0000 1101 0000 1100 0111 1101 0101 0000

01110 = 14 = nBits

00011111011010 = 2010 = xmin /20 to covert to pixels from TWIPS 100.5

01001100101110 = 4910 = xmax 245.5

00011010000110 = 1670 = ymin 83.5

00111110101010 = 4010 = ymax 200.5

000 = fill bits

The ShapeWithStyle structure has five parts. A fill style array, a line style array, a nFillBits field, a nLineBits field, and an array of shape records. Here is the file description:

Field

Type

Comment

FillStyles

FILLSTYLEARRAY

Array of fill styles

LineStyles

LINESTYLEARRAY

Array of line styles

NumFillBits

nFillBits = UB[4]

Number of fill index bits

NumLineBits

nLineBits = UB[4]

Number of line index bits

ShapeRecords

SHAPEREC[one or more]

Shape records - see below

A fill style array itself has three fields. The first field is an 8 bit integer count which indicates how many fill styles are in the array. This count works similar to the tag’s length field in that if it is all 1’s, you have to look at the next 16-bits to get the actual length. Here is the file description:

Field

Type

Comment

FillStyleCount

count = UI8

Count of fill styles

FillStyleCountExtended

If count = 0xFF count = UI16

Extended count of fill styles. Supported only for Shape2 and Shape3.

FillStyles

FILLSTYLE[count]

Array of fill styles

In this case, the 8 bit count is equal to 0 so there is nothing to follow it.

0x00 = 0 = count This is the end of the fill style array because it has no elements

A line style array is exactly the same as a fill style array except it stores line styles. Here is the file description:

Field

Type

Comment

LineStyleCount

count = UI8

Count of line styles

LineStyleCountExtended

If count = 0xFF count = UI16

Extended count of line styles

LineStyles

LINESTYLE[count]

Array of line styles

0x01 = 1 = count So there is one line style in the array.

A line style has two parts, an unsigned 16-bit integer indicating the width of a line in TWIPS, and a color. Here is the file description:

Field

Type

Comment

Width

UI16

Width of line in twips

Color

RGB (Shape1 or Shape2)

RGBA (Shape3)

Color value including alpha channel information for Shape3s

The color in this case is a 24-bit RGB, but if we were doing a defineShape3, it would be a 32-bit RGBA where alpha is the transparency of the color.

0x1400 0x0014 = 20 = width = 1 pixel

0x000000 = RGB = black

Back to the ShapeWithStyle, the nFillBits field is 4 bits, as is the nLineBits.

0x0 = 0 = nFillBits 0x1 = 1 = nLineBits

Now for the array of shape records. There are three types of shape records. Here are the file descriptions:

Shape Record Type 0

Field

Type

Comment

TypeFlag

UB[1] = 0

Non-edge record flag

EndOfShape

UB[5] = 0

End of shape flag

Shape Record Type 1

Field

Type

Comment

TypeFlag

UB[1] = 0

Non-edge record flag

StateNewStyles

newStyles = UB[1]

New styles flag. Used by DefineShape2 and DefineShape3 only.

StateLineStyle

lineStyle = UB[1]

Line style change flag

StateFillStyle0

fillStyle0 = UB[1]

Fill style 0 change flag

StateFillStyle1

fillStyle1 = UB[1]

Fill style 1 change flag

StateMoveTo

moveTo = UB[1]

Move to flag

MoveBits

If moveTo nMoveBits = UB[5]

Move bit count

MoveDeltaX

If moveTo UB[nMoveBits]

Delta X value

MoveDeltaY

If moveTo UB[nMoveBits]

Delta Y value

Fill0Style

If fillStyle0 UB[nFillBits]

Fill 0 Style

Fill1Style

If fillStyle1 UB[nFillBits]

Fill 1 Style

LineStyle

If lineStyle UB[nLineBits]

Line Style

FillStyles

If newStyles FILLSTYLEARRAY

Array of fill styles

LineStyles

If newStyles LINESTYLEARRAY

Array of line styles

Shape Record Type 2

Field

Type

Comment

TypeFlag

UB[1] = 1

This is an edge record

EdgeRecord

EDGERECORD

Line or curve edge record

Type 0 defines the end of the shape record array. Type 1 defines changes in line style, fill style, position, or a new set of styles. Type 2 defines a straight or curved edge. The first bit in a shape record is a type flag. A 0 corresponds to a non-edge record, and a 1 corresponds to an edge record. Looking at the first bit of our first shape record, we see that it is not an edge record. Now we must look at the next 5 bits which are all flags which tell us what is to follow. If all of the 5 bits are 0, then that is a type0 shape record and defines the end of the array of shape records.

25 C9 92 0D 21

0010 0101 1100 1001 1001 0010 0000 1101 0010 0001

0 = 0 = non edge record

01001 = 5 flags line style flag is true, and move to flag is true

Since the move to flag is true, the next 5 bits are the nMoveToBits field. This value is 14 so the next two fields which are the moveDeltaX, and the moveDeltaY are of size 14. These are unsigned numbers.

01110 = nMoveToBits

01001100100100 = 4900 (TWIPS) = 245 pixels = moveDeltaX

00011010010000 = 1680 = 84 pixels = moveDeltaY

Since the line style flag is true, the next field is a nLineBits = 1 bit field representing the line style. This field is equal to 1. What exactly does this mean? It means that the line style for the line to follow is the first one in the line style array.

1 = 1 = line style

Now for the rest of the shape records:

ED 48 87 65 30 3B 6D E1 D8 B4 00 00

1110 1101 0100 1000 1000 0111 0110 0101 0011 0000 0011 1011 0110 1101 1110 0001 1101 1000 1011 0100 0000 0000 0000 0000

The next shape record begins with a 1 so it is an edge record. There are two types of edge records. Here are the file descriptions:

Edge Record Type 0 (Curved)

Field

Type

Comment

EdgeFlag

UB[1] = 0

Curved edge - always 0

NumBits

nBits = UB[4] + 2

Number of bits per value

ControlDeltaX

SB[nBits]

X control point change

ControlDeltaY

SB[nBits]

Y control point change

AnchorDeltaX

SB[nBits]

X anchor point change

AnchorDeltaY

SB[nBits]

Y control point change

Edge Record Type 1 (Straight)

Field

Type

Comment

EdgeFlag

UB[1] = 1

Straight edge - always 1

NumBits

nBits = UB[4] + 2

Number of bits per value

GeneralLineFlag

lineFlag = UB[1]

General Line equals 1

DeltaX

If lineFlag = 1 SB[nBits]

X delta

DeltaY

If lineFlag = 1 SB[nBits]

Y delta

VertLineFlag

If lineFlag = 0 vertFlag = SB[1]

Vertical Line equals 1

DeltaX

If vertFlag = 0 SB[nBits]

X delta

DeltaY

If vertFlag = 1 SB[nBits]

Y delta

The next bit indicates if it is a straight or curved edge. It is a 1 which stands for a straight edge. The next 4 bits indicate the size of any delta fields which follow. The formula for the nbits value is 2 + whatever the value of that 4 bit field. In this case, the value of nbits is 13. Following the nbit field is a 1-bit line flag. This indicates whether the line being described is a general line or horizontal/vertical line. The value of 0 corresponds to a hor/vert line, so the next bit is a vertFlag field and indicates whether the line is horizontal or vertical. The value of the bit is 1 which corresponds to a vertical line. The next field for a vertical line is the signed DeltaY field which is nbits = 13 bits long. The value corresponds to 116 pixels. That is the end of the shape record.

1 = 1 = edge record

1 = 1 = straight edge

1011 = 11 + 2 = 13 = nbits

0 = 0 = hor/vert line

1 = 1 = vertical line

0100100010000 = 2320 TWIPS = 116 pixels = DeltaY

The next three records are very similar to the last one:

1 = 1 = edge record

1 = 1 = straight edge

1011 = 11 + 2 = 13 = nbits

0 = 0 = hor/vert line

0 = 0 = horizontal line

1010011000000 = -2880 TWIPS (2’s complement number) = -144 pixels = DeltaX

1 = 1 = edge record

1 = 1 = straight edge

1011 = 11 + 2 = 13 = nbits

0 = 0 = hor/vert line

1 = 1 = vertical line

1011011110000 = -2320 TWIPS = -116 pixels = DeltaY

1 = 1 = edge record

1 = 1 = straight edge

1011 = 11 + 2 = 13 = nbits

0 = 0 = hor/vert line

0 = 0 = horizontal line

0101101000000 = 2880 TWIPS = 144 pixels = DeltaX

Finally, the last shape record begins with a 0 which means it is not an edge record. Furthermore all of it’s flag bits are equal to 0 which means that it is the last shape record and we are through with our shape record array.

0 = 0 = non-edge record

000000 = flags (since they are all 0, this is the end of the shape record array

Since we are done with our structure, we must now fill our last byte with 0’s to keep byte aligned.

000000 = filled 0’s

We are also done with our shape with style since the shape record array is the last element of the shape with style. Since we are already byte aligned, we can go on to our next tagged data block.

The tag ID of the block is equal to 26 which corresponds to a placeObject2. The length field has a value of 6 so the length of the data block is 6 bytes.

0x8606 0x0686 0000 0110 1000 0110

0000011010 = 26 = tag ID = placeObject2

000110 = 6 = length

06 01 00 01 00 00

0000 0110 0000 0001 0000 0000 0000 0001 0000 0000 0000 0000

Here is the file description of the placeObject2:

Field

Type

Comment

Header

RECORDHEADER

Tag ID = 26

PlaceFlagsReserved

UB[2]

Reserved Flags

PlaceFlagHasName

UB[1]

Has name

PlaceFlagHasRatio

UB[1]

Has ratio

PlaceFlagHasColorTransform

UB[1]

Has color transform

PlaceFlagHasMatrix

UB[1]

Has matrix

PlaceFlagHasCharacter

UB[1]

Places a character

PlaceFlagMove

UB[1]

Depth

UI16

Depth of character

CharacterId

If PlaceFlagHasCharacter = 1 UI16

ID of character to place

Matrix

If PlaceFlagHasMatrix = 1 MATRIX

Transform matrix data

ColorTransform

If PlaceFlagHasColorTransform = 1 CXFORM

Color transform data

Ratio

If PlaceFlagHasRatio = 1 UI16

Name

If PlaceFlagHasName = 1 STRING

Name of character

The first 8 bits of the body are all flags indicating what is to follow. A 1 in the 6th bit indicates that the body has a transform matrix, and the 1 in the 7th bit indicates that the object to be placed has a character ID.

00000110 body has a transform matrix and object has a character ID

Following the flags is a 16-bit unsigned integer which indicates the depth of the character. In this case the depth is 1 which makes sense since the rectangle is the only object in the movie.

0x0100 0x0001 depth = 1

Since the object has a character ID, the next field in the body is the unsigned 16-bit ID. Being the only object in the movie, the ID of the rectangle is 1.

0x0100 0x0001 character ID = 1

The final field for this placeObject2 is the transform matrix. Here is the file description:

Field

Type

Comment

HasScale

hasScale = UB[1]

Has scale values if equal to 1

NscaleBits

If hasScale nScaleBits =UB[5]

Bits in each scale value field

ScaleX

If hasScale FB[nScaleBits]

X scale value

ScaleY

If hasScale FB[nScaleBits]

Y scale value

HasRotate

hasRotate = UB[1]

Has rotate and skew values if equal to 1

NrotateBits

If hasRotate nRotateBits = UB[5]

Bits in each rotate value field

RotateSkew0

If hasRotate FB[nRotateBits]

First rotate and skew value

RotateSkew1

If hasRotate FB[nRotateBits]

Second rotate and skew value

NtranslateBits

nTranslateBits = UB[5]

Bits in each translate value field

TranslateX

SB[nTranslateBits]

X translate value

TranslateY

SB[nTranslateBits]

Y translate value

Since this shape has no transform information, the matrix is empty. All of its flag bits have values of zero. This is not super efficient but it is valid.

0x00 completely empty matrix with leftover bits filled

Since we are done with our placeObject2, let’s take a look at our next tag.

0x4000 0x0040 0000 0000 0100 0000

tag ID = 1 = showFrame

length = 0

We see that the tag is an instruction to show the frame. A showFrame has no body. Its length is 0, so we move on to the next tag.

0x0000 0x0000 0000 0000 0000 0000

tag ID = 0 = end

length = 0

We have reached the end tag which signals the end of our .swf file!!!!!!!!!!

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有