Reverse & More

※ 2013년에 발견된 문서 (PDF, OLE-HWP, OLE-Office, RTF) 관련 취약점에 대해 정리합니다.

[CVE-2013-0603] Adobe Acrobat and Reader Remote Heap Based Buffer Overflow
   - 대상 버전 : Adobe Reader 10.1.3 이하 버전
                     Adobe Acrobat 10.1.3 이하 버전
   - Published : 2013년 1월 8일
   - Updated : 2013년 1월 13일

[CVE-2013-0604] Adobe Acrobat and Reader Remote Heap Based Buffer Overflow
   - 대상 버전 : Adobe Reader 10.1.3 이하 버전
                     Adobe Acrobat 10.1.3 이하 버전
 
   - Published : 2013년 1월 8일
   - Updated : 2013년 1월 8일

[CVE-2013-0609] Adobe Acrobat and Reader Remote Integer Overflow
   - 대상 버전 : Adobe Reader 10.1.3 이하 버전
                     Adobe Acrobat 10.1.3 이하 버전
   - Published : 2013년 1월 8일 
   - Updated : 2013년 1월 11일

[CVE-2013-0613] Adobe Acrobat and Reader Remote Integer Overflow
   - 대상 버전 : Adobe Reader 10.1.3 이하 버전
                     Adobe Acrobat 10.1.3 이하 버전
   - Published : 2013년 1월 8일
   - Updated : 2013년 1월 11일

[0Day] Microsoft 2003/2007/2010 Remote Code Execution
   - 대상 버전 : Microsoft Word 2003/2007/2010
   - Published : 2013년 1월 25일
   - Updated : 

[CVE-2013-0641] Adobe Acrobat and Reader Remote Code Execution
   - 대상 버전 : Adobe Reader 10.1.3 이하 버전
                      Adobe Acrobat 10.1.3 이하 버전
   - Published : 2013년 2월 12일
   - Updated : 2013년 2월 20일

 

OLE 파일은 Object Linking & Embedding 약자로 Microsoft Compound File Binary (CFB) file format 라고 불린다.

OLE 파일의 기본구성은 Header와 Sector 으로 이루어져 있다. Header 에는 OLE 파일의 전반적인 설정(Sector 사이즈, SAT 위치 등)의 값이 저장되어 있고, 각각의 Sector 에는 데이터가 저장되어 있다.

< OLE 파일의 구조 >

구조의 이해를 돕기 위해서 위의 그림과 같이 여러 Sector 로 구성되어 있는 저장공간에 데이터를 저장시킨다고 가정하자. 하나의 Sector 의 사이즈를 4096 bytes 라고 하자. (Sector 크기는 Header 에서 설정되어 진다. 일반적으로 9 로 설정되어 있다.) 저장해야 할 데이터의 크기가 해당 바이트의 크기보다 작을 경우에는 빈 공간이 있을지라도 하나의 Sector 에 데이터가 모두 들어감으로 데이터를 참고할 때, 해당 Sector 번호를 참조하면 된다.하지만 데이터의 크기가 4096 bytes 보다 큰 경우에는 Sector 여러 개에 걸쳐서 저장을 해야 한다. 이렇게 나뉘어진 데이터의 참조를 위해서 OLE 구조에서는 SAT(Sector Allocation Table) 를 사용해서 파일의 전체 Sector 의 상태를 표시하고 있다. 데이터가 이어질 경우, Sector 다음으로 이어지는 Sector Number 를 SAT 에 표기하도록 하고, 데이터의 마지막을 알려주기 위해서는 -2 를 표기하도록 한다. 이러한 방식으로 SAT 를 통해 연결된 Sector 의 연계성을 확인할 수 있다. 또한 SAT 를 통해 특정 Sector 의 상태를 확인할 수 있다. 예를 들어, Sector 가 사용되지 않고 있음을 나타내기 위해서는 -1 이 사용되고, SAT 가 존재하는 Sector 를 표기하기 위해서 -3 이 사용된다.

< 그림 Sector Allocation Table >

여기서 SAT 에 대해 좀 더 생각해보자. SAT Sector 한 개를 사용해서 저장할 수 있는 데이터는 약 4Mb 정도 밖에 되지 않는다. [1024(number of Addr in SAT) * 4096(Sector Size) = 4,194,304] 당연히 여러 개의 SAT 가 필요하게 되고, 여러 개의 SAT Sector 를 관리하기 위해서 MSAT(Master Sector Allocation Table) 를 사용한다.(SAT 를 관리하는 SAT 의 느낌?)

데이터가 Sector 사이즈보다 큰 경우에 OLE 가 저장하는 방법을 확인했으니, 사이즈가 작을 경우를 생각해보자. 기본적으로 설정된 Sector 의 크기는 4096 Bytes 이다. 만약 저장하고자 하는 데이터의 사이즈가 1 Bytes 라면? 1 Bytes 의 데이터를 위해서 한 개의 Sector 를 모두 써야할까? 극단적인 예시이긴 하지만 분명히 공간 사용이 비효율적이게 된다. 보다 효율적인 데이터의 저장을 위해서 OLE 는 Short-Sector 를 사용한다. Short-Sector 란, Sector 크기보다 작은 데이터를 저장하기 위해서 보다 작은 단위로 Sector 나눈 것으로 특정 크기(이 정보 또한 Header 에 설정이 되어있다.) 단위의 여러 Short-Sector 로 구성되어 있다. 이 Short-Sector 를 관리하기 위해 Sector 관리에 SAT 를 사용하는 것과 마찬가지로 SSAT(Short-Sector Allocation Table) 를 만들어 여러 Short-Sector 에 나뉘어진 데이터를 관리하고, Short-Sector 의 상태를 확인할 수 있다.

< Short-Sector Allocation Table >

지금까지 OLE 파일이 데이터를 저장하기 위해서 어떤 방법을 사용하고, 어떤 방식으로 관리하는지 확인했다. 그럼 이러한 구조에 들어가는 데이터는 어떻게 사용되어 질까?

OLE 파일에 들어가는 데이터는 아래의 그림과 같은 구조로 되어있다.

< Storage & Steam >

Storage 와 Stream 으로 이루어진 이 그림은 OLE 파일 구조를 단순화 시킨 것으로, 여러 Storage 와 Stream 를 구분하기 위해서 고유한 이름이 설정되어 있는 것을 볼 수 있다.(이름은 같은 Storage 내에서 중복되지 않으면 된다.) 위와 같은 구조를 나타내기 위해서 Directory 구조를 사용하여 각각의 Storage 와 Stream 의 정보를 저장하게 된다.

Storage 와 Stream 은 파일 관리에서 사용하는 폴더와 파일 개념과 비슷하다고 생각하면 이해가 쉬울 듯 하다.

< 그림 한글 문서 구조 中 >

위에서 언급한 것처럼 Storage 와 Stream 은 Directory Entry Structure 구조를 가지고 있고, 여기에서 직접적인 데이터와의 연결이 이루어진다. 앞서 확인하였던 SAT 나 SSAT 에는 Sector 또는 Short-Sector에 저장되어 있는 Stream 의 시작과 끝 만을 알 수 있었고, Directory Entry 에서 어떤 Stream 이 몇 번 Sector 부터 시작하는지 알려줌으로써 데이터의 mapping 이 이루어진다. 시작 Sector ID 정보 외에도 directory Entry 에서 Type 이나, Stream 크기 정보를 통해 해당 Directory 가 Root Storage 인지, User Storage 인지, Steam 인지 확인이 가능하고, Steam 크기를 확인함으로써 시작 Sector ID 를 SAT 에서 참조해야 하는지, SSAT 에서 참조해야 하는지 확인이 가능하다.

< Directory Entry Structure >

< Directory Entries with properties >

참고 페이지 :

• http://www.decalage.info/file_formats_security/office
• http://msdn.microsoft.com/en-us/library/cc313118.aspx
• http://www.openoffice.org/sc/compdocfileformat.pdf

※ CVE-2012-1535 취약점에 대한 정보를 게시합니다.

[ 분석 보고서 및 분석 참고 자료 ]

[ 참고 사이트 ]
CVE : CVE-2012-1535
Adobe Security Bulletin : Security Update Available for Adobe Flash Player
AlienVault : CVE-2012-1535 : Adobe Flash being exploited in the wild
nProtect 대응팀 : [긴급] CVE-2012-1535 취약점 악성파일 증가, Adobe Flash Player 업데이트 권고
MS OTF Format : The OpenType Font File

[ 분석 샘플 ]

[ 기본 정보 ]
대상 프로그램 : Flash Player 
대상 파일 : Flash32_11_3_300_270.ocx 이전 버전
취약 함수 : unknown ( createTextLine( ) 추정 )
취약점 설명 : unknown
         ( SWF 파일내의 취약한 Action Script 함수 호출로 인해 HeapSpray 발생 후 임의의 코드 실행가능 취약점 )
패치 여부 : 업데이트 가능 ( Flash32_11_3_300_271.ocx )

[ 분석 환경 ] 
OS :  Windows XP SP3 ( vmware )
Program : Office 2007 Word 
Flash Player : 11.1.102.55 ( Flash11e.ocx )

[ 취약점 공격 방법 ]
Crash 원인에 대해서는 아직 미확인 상태임.
추정 - Flex내부 함수를 통해 Font를 출력하는 과정에서 Font의 속성을 설정할 때 속성정보에 담긴 데이터의 크기에
         상관없이 Heap에 복사/접근/실행이 발생함에 따라 임의의 코드가 실행되는 형태

[ ShellCode 분석 ]

1) Main_FontClass를 생성해 FontClass로 명명한다. 이때 생성한 Main_FontClass는 FontAsset의 확장된 Class로
    Flex에서 Font 출력을 위해 사용되는 Class로 추정된다. 
   (  http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/core/FontAsset.html )

2) Super( ) 함수를 수행한다.

3) 내부 함수 HeapSpray( ) 를 수행한다. 

   :: ShellCode의 가장 큰 특이점은 생성한 ShellCode Block의 동작이다. 해당 취약점이 동작하면 DOC 파일내의
      추가 샘플이 Drop되어 동작하도록 설계되어 있는데 WINWORD.EXE에서 현재 실행중인 DOC 파일에 접근해야
      추가 Drop이 가능하다. 이를 위해 ShellCode 제작자는 악성 DOC 파일의 핸들을 얻는 방법으로 일반적으로 PID
      를 얻는 방법인 4씩 증가시키며 특정 함수 ( GetFileSize( ) ) 의 인자값으로 전달하는 방법을 취했다. 
      이 때문에 실제 ShellCode가 동작하는 과정에서 시간이 Random하게 소요되게 된다. 
      좀더 구체적으로 살펴보자. 
Inside 1 ) ShellCode를 별도의 EXE 파일로 작성해 동작을 확인한다. ( ShellCode2Exe )
      :: GetFileSize( )를 통해 전달하는 hFile은 마치 PID 처럼 4씩 증가시키며 전달한다. 정상적으로 GetFileSize( )
         Return을 받는다면 파일의 Size를 얻게되고 이때 얻은 파일의 크기가 0x48E000 ( DOC 파일 크기 ) 와 일치하
         는지 비교 후 추가 동작을 하게 된다. 
         전제 1) hFile은 4씩 증가하는 특성을 갖는다. 
         전제 2) GetFileSize( )로 전달되는 hFile은 Kernel Handle이다. 

      :: GetFileSize( ) 의 정의를 MSDN을 통해 확인하면 다음과 같다. 
Inside 2 ) GetFileSize( )의 정확한 동작을 확인한다. 
      :: GetFileSize( )는 아래의 그림에서 "call dword ptr [ebp + 8]" 부분이다. 

      :: 이때 전달되는 hFile은 [ebp + 113h] 부분이다. 이를 메모리에서  확인하면 다음과 같다. 

      :: 위에서 hFile은 Kernel Handle이라고 정의했다. 이를 확인해 보면 실행되는 DOC 파일은 WINWORD.EXE가 
         Open하고 있으므로 그 Handle 또한 WINWORD.EXE에 있을 것이다. 따라서 WINWORD.EXE로 Context
         Switching 이후 Handle을 조사해 봤을 때 위에서 나왔던 Handle인 0x430이 나올 것이다. 

      :: 실제 확인 결과 WINWORD.EXE가 갖는 Handle중 0x430은 "iPhone 5 Battery.doc" 악성 파일임을 알 수 있다. 

[ ShellCode 동작의 결론 ]
Handle은 4의 배수로 이뤄져 있다는 전제하에 4씩 증가시키면서 DOC 파일의 Handle이 맞을 때까지 Loop를 반복하며 DOC Size를 얻었을 때 hFile을 이용해 악성 파일 Drop을 시도하게 된다. 

4) 내부 함수 TextBlock_createTextLineExample( )를 수행한다. 

5) 내부 함수 createLine( )을 호출한다. 

Action Script는 Flex 문자열 출력과 관련된 createTextLine( ) 함수가 실행될 때 ShellCode가 실행되는 취약점을 갖고 있으며 해당 취약점은 악성 DOC 파일의 hFile을 얻기 위해 4씩 증가시켜 자신의 DOC파일의 Size가 나올때 가지 반복하는 형태를 띄고 있다. 이때 ShellCode는 HeapSpray 방법을 이용한다. 

Action Script 및 실행되는 ShellCode에 대한 분석이 완료되었으므로 정적분석을 통해 추가 분석을 진행해 보자. 
( 저 - DOC 파일 실행시 악성 DLL이 실행되는 일반적인 형태이므로 동적 분석은 제외하겠다. ) 

  ###############################################################################################
  이전에 올렸던 글에서 문제점이 발견되었다. 
  애초에 올렸던 글에 오류가 있었던 것이다. 따라서 해당 사항에 대해서는 삭제하고 관련 사항에 대한 정리는
  최상위에 추가한 분석보고서로 대체한다.
  ############################################################################################### 

[ 분석 Point ]
Crash가 발생하는 지점 :: Flash11e + 0x003d7c08 ( Flash11e!DllUnregisterServer+0x23ccda ) 
HeapSpray가 발생하는 지점 :: Flash11e + 0x 0x5D0F50 ( Flash11e!__VEC_Memcpy->_fastcopy_I( ) )

[ TIP :: SWF 파일 추출하기 ]
이번 취약점과 같이 DOC 파일내에 취약점을 갖는 SWF 파일이 존재할 경우 SWF를 분석하기 위해 DOC로 부터 해당 파일을 추출할 수 있어야 한다. 따라서 DOC에서 SWF 파일의 위치를 확인할 수 SWF File Format에 따라 파일을 추출한 후 Decompiling을 통해 분석하면 된다. 

실제 분석 샘플이었던 "iPhone 5 Battery.doc"의 경우 위와 같이 SWF파일이 DOC 내에 존재한다. 

SWF File Format을 바탕으로 확인해 보면 첫 3Bytes는 SWF Signature, 다음 1Byte는 File Version, 다음 4Bytes가 File의 크기가 된다. 따라서 분석 대상 샘플의 SWF 파일의 크기는 0x0000D6AD ( 54,957 Bytes ) 가 된다. 물론 압축되어 있는 형태 ( CWF ) 의 경우 위의 파일 크기를 바로 반영해서는 안된다. 그 이유는 CWF는 압축된 파일이고 이때 보여지는 Size는 압축이 해제된 이후 SWF 파일일 때의 Size이기 때문이다. 이는 다음에 추가로 설명하겠다. 



 

※ CVE-2011-0611 Adobe Flash Player Zero-Day 취약점에 대한 정보를 등록합니다.
   본 취약점은 MS Office MSWord와는 무관한 Adobe Flash Player내의 취약점입니다. 


[ 파일 정보 ]
파일명 :: Disentangling Industrial Policy and Competition Policy.doc
            ( 내부 파일명 :: [Malware] Disentangling Industrial Policy and Competition Policy.doc )
파일 크기 :: 176,144 ( Bytes )
MD5 :: 96cf54e6d7e228a2c6418aba93d6bd49

파일명 :: Japan Nuclear Weapons Program.doc
            ( 내부 파일명 :: [Malware] 2011.doc )
파일 크기 :: 167,440 ( Bytes )
MD5 :: df45a5bc07153b20af1e375626b5addc
 
< 샘플 파일 >

CVE-2011-0611.zip

Exploit DB :: http://www.exploit-db.com/exploits/17175/

[Exploit DB] CVE-2011-0611.zip

 [ 동적 분석 ]

0. 동작 시나리오

< Figure. 동작 시나리오 >

1. 최초 유입

< Figure. Mail을 통한 Malicious DOC 파일 전파 >

2. Malicious DOC 파일 실행 

< Figure. Malicious DOC 파일 실행 화면 >

   :: Malicious DOC 파일을 실행하면 악성 동작을 완료한 후 사용자가 악성 동작 의심을 갖지 않도록 정상DOC 파일
      을 보여준다. 

3. Binary 확인
1) SWF 파일 확인

< Figure. DOC 파일내의 SWF 파일 >

   :: SWF File Format 에 따라 DOC내에 확인된 SWF 파일은 Signature + Version까지 모두 포함한 파일 크기가
     <Figure. DOC 파일내의 SWF 파일> 에서 언급한 파일 크기 0x2775 이다. 따라서 위의 SWF 파일 크기는
     10,101 Bytes가 된다.
     ( 실제 다른 분석 정보를 참고하면 파일의 크기가 10,421 Bytes로 되어 있으나 아직 그 이유는 모르겠다. )

2) SWF DeCompile

파일명 :: 513.swf ( 추정 )
파일 크기 :: 10,101 Bytes
MD5 :: 79b1c0ed2df4977d70c7d21817213fa6

< Figure. SWF 파일 생성 >

   :: SWF를 DeCompile 할 수 있는 Tool은 여러가지가 있겠지만 우선 내가 알고 있는 swfdump.exe를 이용할 것
      이다. 우선 DOC에서 확인한 SWF 파일을 확인한 크기 ( 10,101 Bytes )를 HxD 등의 Hex Editor 툴을 이용해
      별도의 파일로 저장한다. ( Offset 0x2E08 ~ 0x557D ) 이때 1)에서 언급한 파일 크기 10,421 Bytes로도 파일
      을 생성해 보겠다. ( Offset 0x2E08 ~ 0x56BD )
     - Dump_10101.swf ( Size :: 10,101 Bytes )
     - Dump_10421.swf ( Size :: 10,421 Bytes )
   :: 내부 문자열을 통해 추정해 보면 내장된 SWF 파일명은 "d:\513.swf" 이다. 

< Figure. swfdump.exe를 이용한 DeCompile 시도 >

< Figure. 생성된 DeCompile 파일 >

   :: swfdump 를 사용해 DeCompile을 수행한다. 이때 두 파일의 DeCompile 내용을 비교해 차이가 무엇인지 확인
      해 보겠다. 실제 두 파일을 DeCompile 하면 다음과 같이 10,421 Bytes를 갖는 파일의 경우 Error가 발생하며
      DeCompile 파일을 생성하지 못하지만 10,101 Bytes 파일의 경우 정상적으로 DeCompile이 되는 것을 확인할 수
      있다. 따라서 다른 분석 정보에서 10,421 Bytes로 입력한 이유는 아마 샘플의 차이가 아닐까 생각한다.
   :: 이제 생성된 DeCompile 파일을 분석해 보겠다.
< DeCompile 파일 >

3-1) DeCompile 파일 분석 ( swfdump.exe 이용 )
    :: DeCompile이라고 표현했으나 실제는 SWF 파일형식에 맞춰 Assembly를 했다고 보는게 맞다. 
    :: 10101 Bytes 파일이 우리가 원하는 악성 SWF 로 추정되므로 이를 Action Script DeCompiler를 통해 소스
       레벨의 내용을 확인할 수도 있다. ( Decoded Action Script Code )
    :: Assembly 된 파일에서 ShellCode를 확인할 수 있고 해당 ShellCode는 push를 통해 Stack/Heap에 저장되는
       것을 알 수 있다. x86 Assembly에서 PUSH 명령어는 Stack에 저장하는 명령어이므로 Stack에 저장하는 것으로
       추정할 수 있다. 그럼 위의 ShellCode를 확인해 보자.

3-2) DeCompile 파일 분석 ( Action Script Decompiler 이용 )

   :: Assembly 형태로 표현된 것과 크게 차이가 나지 않음을 알 수 있다. 
< DeCompile 파일 >

4) ShellCode 분석

파일명 :: Unknown
파일 크기 :: 1,484 Bytes
MD5 :: a7435d599a0b7e9ffd5f94338412a93d

   :: ShellCode로 추정했던 부분이 SWF 파일이었다. 즉, SWF 파일내에 실제 Crash를 발생시키는 SWF 파일이
     내장되어 있다는 것이다. 이 파일을 Assembly 로 확인해 보자.

<Figure. swfdump.exe  Error 발생 >

[ 정밀 분석 ]










* 참고 사이트
  - MS Technet :: http://blogs.technet.com/b/mmpc/archive/2011/04/12/analysis-of-the-cve-2011-0611-adobe-flash-player-vulnerability-exploitation.aspx
  - BugiX :: http://bugix-security.blogspot.com/2011/04/cve-2011-0611-adobe-flash-zero-day.html
  - AhnLab :: http://blog.ahnlab.com/asec/518
  - Sempersecurus :: http://sempersecurus.blogspot.com/2011/04/using-volatility-to-study-cve-2011-6011.html

[ 참고 사이트 ]
CVE :: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0611
National Vulnerability :: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0611
Security Focus ::  http://www.securityfocus.com/bid/47314
Secunia :: http://secunia.com/advisories/cve_reference/CVE-2011-0611/ 
Adobe Security Bulletin :: http://www.adobe.com/support/security/advisories/apsa11-02.html 

Update 2011.04.15

Adobe의 Zero-Day가 Patch 되었다. 
* 관련 기사 
  - Threatpost :: http://threatpost.com/en_us/blogs/adobe-patch-flash-zero-day-windows-mac-friday-041411
  - Virus Bulletin :: http://www.virusbtn.com/news/2011/04_14.xml?rss
 

※ Adobe에서 공개한 SWF File Format Spec v10.pdf 파일을 기준으로 한 내용이며 다음의 Post는
   해당 문서중 Appendix A : SWF Uncovered - A Simple SWF File Dissected 의 내용 일부를 번역한
   것이다.

[ Appendix A ]
SWF Uncovered : A Simple SWF File Dissected 

SWF  파일을 만들기 위해선, RAW Bit와 Bytes를 읽고 이해할 수 있어야 한다. 이 Appendix에서는 하나의 Rectangle과 하나의 Frame으로 되어 있는 SWF 파일을 통해 간단히 알아 보겠다.

다음은 SWF 파일의 Hex dump 이다. Figure 1

SWF파일은 항상 Header로 시작된다. Header는 파일 버전, Byte 단위의 파일 길이, Twip 단위의 Frame 크기, 초당 Frame의 Frame Rate, Frame Count 등이 포함된다.
그 타입은 11 페이지의 Chapter 1. "Basic Data Type" 에 정의되어 있다.
Figure 2

첫 세 Bytes는 모든 SWF 파일의 표준 Signature이다. 표준 Signature는 ASCII 값 "F" ( 또는 "C" ) , "W" , "S" 이다.
네번째 Byte는 파일의 버전을 의미한다.

0x46 ▶ "F"   0x57 ▶ "W"   0x53 ▶ "S"   0x03 ▶ 3

다음 네 Bytes는 Unsigned 32-Bit Integer로 파일 크기를 가리킨다. 시스템의 Architecture에 따른 약간의 Trick이 있다. Figure 1을 통해 다음 4Bytes를 확인하면 0x4F000000 으로 파일 길이가 1325400064 Bytes가 된다. 이 값은 너무 큰 값이다. SWF 파일에서, Bytes는 0xB1B2B3B4의 32Bit 값은 0xB4B3B2B1로 쓰여진고 16Bits 0xB1B2는 0xB2B1으로 쓰여진다. 이러한 이유는 MAC과 PC 의 프로세서간의 저장장치와 반환간의 차이 때문이다.

역으로 4Bytes를 읽어보면 파일은 79 Bytes 길이가 된다.

0x4F000000 ▶        0x0000004F ▶         79

다음 9Byte는 Rectangle이라는 SWF 파일 포멧에서 사용하는 데이터 구조체이다. 다음은 Rectangle의 각 Parameter를 설명한 부분이다.
Figure 3

이러한 Bytes을 이해하기 위해, 각각의 개별 Bits를 확인해야 한다.
Figure 4

Rectangle 구조체는 5개의 Field로 구성되어 있다. : Nbits , Xmin , Xmax , Ymin , Ymax. Unsigned Nbits Field는 Rectangle의 첫 5Bits로 다음 네개의 Field의 길이를 기리킨다. SWF 파일에서 또 다른 미묘한 부분은 Bit를 읽고 쓸때 Word와 dwords에 차이가 있다. Bits를 읽고 쓸때, Byte-Swapping은 발생하지 않는다. 이는 Flash Player는 n-bit Field를 읽을 때, n Bits를 모두 읽을 때 까지, Bytes 단위로 읽기 때문이다. 그러므로, 다음 5Bits는 다음과 같이 읽어야 한다.

01111 ▶ 15

Nbits의 값 16은 무엇일까? 이는 Word의 크기를 나타내는 것으로 Word와 Swap Bytes로 다음의 Field와 같이 읽어야는 것인가? 그렇지 않다. Field는 Bit 크기를 가리키므로 항상 Byte 단위로 읽어들인다. Swapping 없이 단순하게 순서대로 읽으면 된다.

Figure 5

Header에서 Rectangle은 파일의 Height를 위해 Xmax와 Ymax 치수를 파일에 저장하기 위해 사용한다. SWF 포멧에서, Twip은 20/픽셀 을 의미한다. 그래서 만약 픽셀을 변환하면, 파일은 550 * 400이 된다.

이제 Rectangle Field를 모두 확인해 계산해 보았다. 그러나 마지막 7Bits는 왜 0일까? Byte 경계를 맞추기 위해 0으로 채워놓은 것이다.

0000000 = pagging bits

어떤 구조체 다음, 마지막 Bytes까지 정확하게 채워져 있지 않다면, Byte 단위 정렬을 위해 0으로 채운다. 그래서 만약 다음 Item이 Word나 dword이면, Bytes의 중간부터 읽어야 한다는 걱정없이 읽을 수 있다. 이 경우, 마지막 Byte내의 1Bit를 사용해 나머지는 0으로 채워진다.

Header의 다음은 Frame Rate이다. Frame Rate는 16Bit Integer로 저장되어 있지만, 처음 Byte는 무시한다. 그래서 Frame Rate는 12fps이다. 

0x000C ▶      0x0C00 ▶     0x0C ▶     12 Frame Rate

다음은 Frame Count로 이 또한 16 Bit Integer로 되어 있다. 그래서 Frame Count는 1이 된다.

0x0100 ▶       0x0001 ( Byte Swapping ) ▶     1 = Frame Count

( 역 - 지금까지 위에서 설명한 내용을 바탕으로 악성 SWF 파일을 분석한 구조도이다. )

Header는 이제 모두 살펴 보았다. Header 다음은 Tagged Data Blocks이 잇다. 다음은 tag에 대해 설명해 놓았다.

Figure 6

Tag의 타입은 두 종류가 있다. : Short Tag Header 와 Long Tag Header. 첫번째 Word를 찾음으로써 Tag가 시작된다.

0x4302 ▶      0x0243 ▶     000 0010 0100 0011

Tag의 첫 10Bits는 Unsigned tag 이다. Tag 타입은 다음에 따라오는 Body내의 Data Block의 Data 타입을 결정한다.이 경우 Tag 타입은 9이고, SetBackgroundColor Block을 가리킨다. 다음 Unsigned 6Bits는 62Bytes 보다 작거나 같으면 Data Block의 길이를 의미하고 62Bytes보다 크면, 이 Field는 모두 1로 그 길이는 dword가 가리키게 된다. 우리가 살펴본 Tag에서, Field는 모두 1이 아니므로, 3Bytes 길이값을 의미한다.

0000 0010 01 = 9 = SetBackgroundColor
00 0011 = 3 = Body Length

Body의 길이가 3Bytes이므로, Body를 살펴보자. SetBackgroundColor tag는 3Bytes의 RGB color를 갖고 있으므로 다음과 같이 계산할 수 있다. Color은 3Bytes Data Type이므로 Byte Swapping은 일어나지 않는다.

0xFFFFFF = White

다음 Tag는 Long Tag이고 DefineShape Tag 이다.

0xBF00     0x00BF     0000 0000 1011 1111

0000 0000 10 = 2 = DefineShape

11 1111 = 63 = Body Length
( 다음 두 Bytes가 Body Length를 가리킨다. ( 역-Body Length가 62Bytes를 넘었기 때문에 다음 2Bytes가 Body Length가 된다. ))

0x23000000     0x00000023     35 = Body Length

다음은 DefineShape 을 정의한 것이다.

Figure 7

( 역 - 이 이후의 추가적인 번역은 수행하지 않겠다. 하지만 지속적으로 Tag를 찾아가 Parsing해 원하는 정보를
         얻는 과정은 모두 동일하다. )