<![CDATA[Latest posts for the topic "xác định định dạng dữ liệu"]]> /hvaonline/posts/list/8.html JForum - http://www.jforum.net xác định định dạng dữ liệu

file1 wrote:
MIIBUAYJKoZIhvcNAQcDoIIBQTCCAT0CAQAxaaNnAgEAoBsGCSqGSIb3DQEFDDAO BAg3U/tsYTN8hgICB9AwIwYLKoZIhvcNAQkQAwkwFAYIKoZIhvcNAwcECEKoZ/fX JXGoBCBOfMQbAPcm9cXV5ZQm/vnOJaulhwnVy5F5jidCaBevQzCBzAYJKoZIhvcN AQcBMBQGCCqGSIb3DQMHBAj153uAnFY2cYCBqKUxT1mJPZ3ufRuwgrDedAmLzlfG 9SVfWzWL/S2k8qBQudnmkkrGSdY1o4b1V03/yhvUVFvxY3fl+j0iCC5M77nYLjlk XzmcjwyAbNrJ57yFVFheQqeVKayM3eTVU85Bnfr0OFVXKUK3Xx/k+YUuTJL2y2s4 wQbruV6LrEPuQokipzEWVJp4It3xQdqvJuS5A5kJnR6aNgUmbl3iQ3RzjSBFKzpF eNLPwQ==  

file2 wrote:
MIIBUAYJKoZIhvcNAQcDoIIBQTCCAT0CAQAxaaNnAgEAoBsGCSqGSIb3DQEFDDAO BAiB8jQrxkrOsQICB9AwIwYLKoZIhvcNAQkQAwkwFAYIKoZIhvcNAwcECCkxTm2o rCTxBCA8MsiSQgyDN1qVC+pWkhHYGiu0YnSih5wkYobWb0fUdzCBzAYJKoZIhvcN AQcBMBQGCCqGSIb3DQMHBAgJp/Ng3k8kFICBqMjucdvXm1Hd7sDm/iaiQPWYc6rQ KxqR8m67he2IgAorcg1GOlI46hG/+i045PYZVbv4puWnDy3hQMXlp3JXXWRLJPO3 dsGADK01jboFHu1/3ejnH5QPC83XhK6JpqdGLl5ULfOhn4m96Kq/ry3yy6ef92f7 7hkdwFxTco3A9W0BMy2WwbpwMv50s2Zxba6S05q4MQYzEABaTFhK85WaIErciGUJ vTs/Yw==  

file3 wrote:
ww0EAgMCabRWYgouqbhgybirch80WrLmTx4T7RMIBfj6QURbK7b5DbhnCIWHz7Y9 +MzJnYquv9y5+I73ghLXgM2SFvYNqdBAgN+U+PQAqnniRRrZ+/2Cr9Yp2OhQfYp1 NNVXLC0McDQIaThjZ4LBmLiWh1TRkdM2mq2dbjIQ5fWgbiAYuyH4qAB5MDKf5/5M BYapiszP0g01AkW1DpuOMZVh8XLohM3kirfVmPcoPhXa3w0zbNFg4DvMZWIFzGdD wjRsbXtGFoim  
câu trả lời đúng cần phải nêu ra được những ý sau đây: 1. chuẩn của dữ liệu (ví dụ như tuân theo RFC nào) 2. thuật toán mã hóa được sử dụng (mình chỉ dùng block-cipher) và mode 3. cách thức tạo key từ password (tất cả các file đều chỉ được mã hóa bằng một mật khẩu yếu :-D) 4. bonus: decrypt được dữ liệu. các file đều có nội dung giống nhau, chỉ khác nhau ở cách mã hóa thôi. chúc các bạn vui vẻ, -m]]>
/hvaonline/posts/list/29806.html#183760 /hvaonline/posts/list/29806.html#183760 GMT
xác định định dạng dữ liệu thaidn. đương nhiên các thuật toán mã hóa và tạo key không phải là do mình tự chế ra, mà đều là tuân theo chuẩn cả, kể cả định dạng của các file này. giờ có mật khẩu rồi, các bạn thử tìm cách giải mã nó xem. mình tin là khó, tự vì thông tin quan trọng hơn lúc này không phải là mật khẩu, mà là, như đã nói ở trên, cách các file này đã được mã hóa. mình có gợi ý thế này: theo mình biết thì hiện tại có 3 chuẩn dữ liệu mã hóa là PKCS#7 1.5/SMIME 2 (RFC 2315), CMS/SMIME 3 (RFC 3852), và PGP (RFC 4880). Cái CMS thực ra có thể xem là một phiên bản mới của PKCS#7, nên nhìn kỹ thì còn lại 2 chuẩn. mấy cái file của mình cũng xoay quanh hai chuẩn này thôi, nên các bạn tìm hiểu hai cái chuẩn này thì sẽ trả lời được các câu hỏi.]]> /hvaonline/posts/list/29806.html#184023 /hvaonline/posts/list/29806.html#184023 GMT xác định định dạng dữ liệu

mrro wrote:
mình có gợi ý thế này: theo mình biết thì hiện tại có 3 chuẩn dữ liệu mã hóa là PKCS#7 1.5/SMIME 2 (RFC 2315), CMS/SMIME 3 (RFC 3852), và PGP (RFC 4880). Cái CMS thực ra có thể xem là một phiên bản mới của PKCS#7, nên nhìn kỹ thì còn lại 2 chuẩn. mấy cái file của mình cũng xoay quanh hai chuẩn này thôi, nên các bạn tìm hiểu hai cái chuẩn này thì sẽ trả lời được các câu hỏi. 
Vấn đề cũng hấp dẫn đấy. Nhưng mà "hiện tại có 3 chuẩn dữ liệu mã hóa..." thì phải hiểu thế nào đây? Cái đó thì liên quan gì đến "chuẩn mã hóa dữ liệu"?]]>
/hvaonline/posts/list/29806.html#185078 /hvaonline/posts/list/29806.html#185078 GMT
xác định định dạng dữ liệu /hvaonline/posts/list/29806.html#185086 /hvaonline/posts/list/29806.html#185086 GMT kết quả tìm hiểu Code:
Offset    0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F

00000000  30 82 01 50 06 09 2A 86 48 86 F7 0D 01 07 03 A0  0‚.P..*†H†÷.... 
00000010  82 01 41 30 82 01 3D 02 01 00 31 69 A3 67 02 01  ‚.A0‚.=...1i£g..
00000020  00 A0 1B 06 09 2A 86 48 86 F7 0D 01 05 0C 30 0E  . ...*†H†÷....0.
00000030  04 08                                            ..
OK, 2 file đầu có thể là dạng file có định dạng, tôi thử lấy một chuỗi vài byte trong phần đầu của file 1 và google. Sau vài lần tìm kiếm và tham khảo Wiki, tôi gần như chắc chắn 2 file đầu có chứa dạng dữ liệu liên quan tới PKCS #7. Nhớ tới openSSL có hỗ trợ làm việc với pkcs7, tôi thử kiểm tra file với chương trình này. Code:
~ ./openssl.exe pkcs7 -inform DER -in a.bin
unable to load PKCS7 object
264:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1294:
264:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:380:Type=PKCS7_RECIP_INFO
264:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:710:Field=recipientinfo, Type=PKCS7_ENVELOPE
264:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:749:
264:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1 error:tasn_dec.c:578:Field=d.enveloped, Type=PKCS7
Có gì không đúng rồi. Tìm lại và dò theo các kết quả có chứa chuỗi byte gần giống mẫu, tôi thấy chuỗi "06 09 2A 86 48 86 F7 0D 01 07 03" phù hợp với Identifier Name envelopedData với chuỗi DER Encoding "06 09 2A864886 F70D0107 03". Đọc thêm chút nữa, tôi thấy rằng cần dùng asn1parse để kiểm tra file này trước, kết quả là: Code:
$ ./openssl.exe asn1parse -inform DER -in a.bin -i
    0:d=0  hl=4 l= 336 cons: SEQUENCE
    4:d=1  hl=2 l=   9 prim:  OBJECT            :pkcs7-envelopedData
   15:d=1  hl=4 l= 321 cons:  cont [ 0 ]
   19:d=2  hl=4 l= 317 cons:   SEQUENCE
   23:d=3  hl=2 l=   1 prim:    INTEGER           :00
   26:d=3  hl=2 l= 105 cons:    SET
   28:d=4  hl=2 l= 103 cons:     cont [ 3 ]
   30:d=5  hl=2 l=   1 prim:      INTEGER           :00
   33:d=5  hl=2 l=  27 cons:      cont [ 0 ]
   35:d=6  hl=2 l=   9 prim:       OBJECT            :PBKDF2
   46:d=6  hl=2 l=  14 cons:       SEQUENCE
   48:d=7  hl=2 l=   8 prim:        OCTET STRING      [HEX DUMP]:3753FB6C61337C86
   58:d=7  hl=2 l=   2 prim:        INTEGER           :07D0
   62:d=5  hl=2 l=  35 cons:      SEQUENCE
   64:d=6  hl=2 l=  11 prim:       OBJECT            :1.2.840.113549.1.9.16.3.9
   77:d=6  hl=2 l=  20 cons:       SEQUENCE
   79:d=7  hl=2 l=   8 prim:        OBJECT            :des-ede3-cbc
   89:d=7  hl=2 l=   8 prim:        OCTET STRING      [HEX DUMP]:42A867F7D72571A8
   99:d=5  hl=2 l=  32 prim:      OCTET STRING      [HEX DUMP]:4E7CC41B00F726F5C5D5E59426FEF9CE25ABA58709D5CB91798E27426817AF43
  133:d=3  hl=3 l= 204 cons:    SEQUENCE
  136:d=4  hl=2 l=   9 prim:     OBJECT            :pkcs7-data
  147:d=4  hl=2 l=  20 cons:     SEQUENCE
  149:d=5  hl=2 l=   8 prim:      OBJECT            :des-ede3-cbc
  159:d=5  hl=2 l=   8 prim:      OCTET STRING      [HEX DUMP]:F5E77B809C563671
  169:d=4  hl=3 l= 168 prim:     cont [ 0 ]
Tuyệt! Có vẻ như đã có khá nhiều thông tin. des-ede3-cbd rõ ràng là một thuật toán mã hóa và mode rồi. Tôi tìm kiếm với "1.2.840.113549.1.9.16.3.9" và "PBKDF2" và được dẫn tới http://tools.ietf.org/html/rfc3852 http://tools.ietf.org/html/rfc3211. RFC 3852 mô tả Cryptographic Message Syntax (CMS), được "phát triển" từ PKCS #7 version 1.5, nó cũng tương thích ngược với CMS1 RFC 2360, CMS 2 RFC 3369). Tài liệu này cùng với các tài liệu tham khảo trong mục http://tools.ietf.org/html/rfc3852#section-13 cung cấp cho ta đầy đủ thông tin để ta tiến hành dẫn xuất khóa từ password, salt, count (PBKDF2), giải mã khóa và giải mã dữ liệu với các thuật toán dẫn xuất, giải mã khóa với điều kiện... có mật khẩu. Không có mật khẩu, việc tìm bản rõ sẽ cần nhiều thời gian (tôi nghĩ rằng sẽ cần đọc kỹ hơn các tài liệu trên + các tài liệu thám mã TripleDES, chú trọng những phần liên quan quá trình giải mã để có một phương án hiệu quả). Dĩ nhiên, vì ta có thông tin "các file được tạo với mật khẩu yếu" nên có thể thử tiến hành brute force trước. Đến đây tôi tạm dừng, và tiếp tục với file thứ 3. Tuy nhiên do gặp khó khăn với file 3, tôi quyết định đọc tiếp các gợi ý của mrro, thấy mật khẩu được dùng cho cả 3 tệp là "thaidn". Tôi thử với file 1 và 2: Code:
~ openssl cms -decrypt -inform DER -in file1.bin -pwri_password thaidn
~ openssl cms -decrypt -inform DER -in file2.bin -pwri_password thaidn
Kết quả thu được bản rõ giống nhau: Code:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
cccccccccccccccccccccccccccccccccccccccc
dddddddddddddddddddddddddddddddddddddddd
Với file thứ 3, đầu tiên tôi nhận thấy file này hình như chẳng có họ hàng gì với 2 file trước. Nội dung nó đây: Code:
Offset    0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F

00000000  C3 0D 04 02 03 02 69 B4 56 62 0A 2E A9 B8 60 C9  Ã.....i´Vb..©¸`É
00000010  B8 AB 72 1F 34 5A B2 E6 4F 1E 13 ED 13 08 05 F8  ¸«r.4Z²æO..í...ø
00000020  FA 41 44 5B 2B B6 F9 0D B8 67 08 85 87 CF B6 3D  úAD[+¶ù.¸g.…‡Ï¶=
00000030  F8 CC C9 9D 8A AE BF DC B9 F8 8E F7 82 12 D7 80  øÌÉ.Š®¿Ü¹øŽ÷‚.×€
00000040  CD 92 16 F6 0D A9 D0 40 80 DF 94 F8 F4 00 AA 79  Í’.ö.©Ð@€ß”øô.ªy
00000050  E2 45 1A D9 FB FD 82 AF D6 29 D8 E8 50 7D 8A 75  âE.Ùûý‚¯Ö)ØèP}Šu
00000060  34 D5 57 2C 2D 0C 70 34 08 69 38 63 67 82 C1 98  4ÕW,-.p4.i8cg‚Á˜
00000070  B8 96 87 54 D1 91 D3 36 9A AD 9D 6E 32 10 E5 F5  ¸–‡TÑ‘Ó6š­.n2.åõ
00000080  A0 6E 20 18 BB 21 F8 A8 00 79 30 32 9F E7 FE 4C   n .»!ø¨.y02ŸçþL
00000090  05 86 A9 8A CC CF D2 0D 35 02 45 B5 0E 9B 8E 31  .†©ŠÌÏÒ.5.Eµ.›Ž1
000000A0  95 61 F1 72 E8 84 CD E4 8A B7 D5 98 F7 28 3E 15  •añrè„Í䊷՘÷(>.
000000B0  DA DF 0D 33 6C D1 60 E0 3B CC 65 62 05 CC 67 43  Úß.3lÑ`à;Ìeb.ÌgC
000000C0  C2 34 6C 6D 7B 46 16 88 A6                       Â4lm{F.ˆ¦
mrro đã cho biết các file có nội dung giống nhau và đều được mã, tức là kích thước dữ liệu rõ khoảng 168 byte, để ý kích thước của file 3 nhỏ so với hai file 1 và 2, chỉ có 201 byte, lớn hơn kích thước dữ liệu rõ 33 byte, có thể đó là phần dữ liệu định dạng. Lẻ nhỉ? Nhìn phần đầu, thấy phần đầu file lạ hoắc, không có vẻ là một dạng file có định dạng. Thử tìm một vài byte có thể là giá trị [file-size] cũng không thấy thông tin gì có ích. Dù sao cũng chỉ là cảm giác. Tôi thử kiểm tra lại bằng cách dùng Google để tìm kiếm vài byte trong phần đầu, cũng thấy không có kết quả nào có vẻ thích hợp. Loay hoay một hồi, tôi kiểm tra lại file3 theo các dạng encode khác của ASN1 cũng không thấy phù hợp. Lúc này, bắt đầu cảm thấy bế tắc, tôi đọc tiếp các gợi ý phía dưới của mrro. Nhưng rồi tôi cũng không tiến thêm được chút nào. Tôi đã tính gửi trước trả lời cho file 1 và 2, nhân tiện xin gợi ý thêm và hỏi dữ liệu của file 3 có "đúng" không (không làm được, nên nghĩ đề ra sai). Nhưng lại nghĩ, nếu đây là một tình huống computer forensic, thì sao làm vậy được? Nhìn lại thì thấy, tôi chưa xem xét kỹ chuẩn PGP, do trước đây tôi luôn có ấn tượng là PGP (chỉ) sử dụng hệ mã khóa công khai. Tôi quay ra đọc lại RFC 4880. Lúc trước tôi có tìm kiếm định dạng file PGP (google "PGP file format"), cũng là đọc sơ sơ - đây là ảnh hưởng của lối làm việc theo cảm tính. Giống như khi đi tìm thứ gì đó, ta thường ít để ý tìm tòi ở một vài nơi mà ta cho rằng nó đó "chắc chẳng đời nào ở đó". Đầu tiên tôi duyệt lại mục lục để có cái nhìn bao quát, rồi xem mục Packet Headers trước. Tôi ngạc nhiên nhận ra rằng lúc trước mình không hề nghĩ đến file 3 chỉ là một loạt các packet, mà luôn cho nó là một file có định dạng tương tự file1 và file2 (lúc trước tôi đã đọc, và bỏ qua phần này ở một trang khác). Đọc lại cẩn thận bắt đầu từ phần http://tools.ietf.org/html/rfc4880#section-4, tôi thấy nội dung RFC này ngắn gọn nhưng rất cụ thể và rõ ràng. Một điểm quan trọng mà lúc trước tôi không để ý là có đến 2 định dạng packet, "cũ" và "mới", lúc trước tôi chỉ đọc lướt và thử với định dạng "cũ" nên bị confused khi thấy 4 bit từ 5-2 của byte đầu tiên (0xC3 - 11000011) là 0000. Đọc đến đây, tôi xem lại file 3, đối chiếu với RFC và nhận ra rằng, hóa ra 15 byte đầu của file 3 hoàn toàn phù hợp với một packet PGP. Code:
C3 | 0D | 04 | 02 | 03 | 02 | 69 B4 56 62 0A 2E A9 B8 | 60
- Packet là dạng new packet (xem phần http://tools.ietf.org/html/rfc4880#section-4.2). - Tag là Symmetric-Key Encrypted Session Key Packet (phần http://tools.ietf.org/html/rfc4880#section-4.3). - Body Length là 0xD. - Theo mục http://tools.ietf.org/html/rfc4880#section-5.3, ta có: phiên bản 04, symmetric algorithm là 02 - TripleDES (DES-EDE, 168 bit key derived from 192), thông tin về string-2-key (S2K) là (xem http://tools.ietf.org/html/rfc4880#section-3.7.1.3): + Type: 03 - Iterated and Salted S2K (xem http://tools.ietf.org/html/rfc4880#section-3.7.1). + Hash algorithm: 02 - SHA1 ( http://tools.ietf.org/html/rfc4880#section-9.4) + 8-octet salt : 69 B4 56 62 0A 2E A9 B8 + Coded value of count: 0x60 = 96, tính ra count = 2000. Dữ liệu tiếp theo packet đầu tiên cũng có vẻ phù hợp với một packet PGP với tag là Symmetrically Encrypted Data Packet, Body Length là 0xB8 = phần còn lại của file. Như vậy kết hợp với các thông tin đã có, gần như có thể khẳng định rằng file 3 chứa các packet PGP (2 packet), trong đó gói đầu tiên chứa thông tin về chuẩn mã hóa dữ liệu, gói thứ hai chứa dữ liệu đã mã hóa. Nếu không có mật khẩu, ta chỉ có thể sử dụng các thông tin đã có để thám mã: chuẩn mã TripleDES (DES-EDE), Salt, Count và Hash algorithm, bản mã. Vì mật khẩu đã dùng là yếu, có thể tiến hành brute-force. Tuy nhiên, với khóa đã biết "thaidn" ta có thể sử dụng luôn GnuPG http://www.gnupg.org để giải mã: Code:
> gpg --list-packets file3.bin
:symkey enc packet: version 4, cipher 2, s2k 3, hash 2
        salt 69b456620a2ea9b8, count 96

gpg: 3DES encrypted data
:encrypted data packet:
        length: 184
:literal data packet:
        mode b, created 0, name="",
        raw data: 166 bytes
gpg: WARNING: message was not integrity protected

> gpg --decrypt file3.bin
gpg: 3DES encrypted data
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
cccccccccccccccccccccccccccccccccccccccc
dddddddddddddddddddddddddddddddddddddddd
gpg: WARNING: message was not integrity protected
Để ý rằng gói thứ 3 (literal data packet) "nằm trong" gói thứ 2. Thông tin về loại packet này có trong mục 5.9. Literal Data Packet. http://tools.ietf.org/html/rfc4880#section-5.9 Như vậy, file 3 chứa các gói PGP, theo RFC 4880, thuật toán mã hóa là TripleDES - EDE, khóa được sinh theo mô tả ở mục http://tools.ietf.org/html/rfc4880#section-3.7 với hàm hash là SHA1, mật khẩu, salt và count đã biết. Nhìn lại cả quá trình trên đây, tôi thấy rằng, mặc dù kinh nghiệm và trực giác đôi khi có thể giúp tiến đến kết quả nhanh hơn, nhưng với những bài toán dạng này, trước hết cần phân tích toàn bộ thông tin có được với cách nhìn khái quát, tìm hiểu một số kiến thức nền tảng rồi mới tiến hành thử nghiệm từng bước (có kế hoạch). Cách tiếp cận đó có thể giúp ta hạn chế phạm vi tìm kiếm và tránh được những sai sót cơ bản. Chẳng hạn, trước hết tôi nên tập trung nghiên cứu các chuẩn dữ liệu mã hóa (để ý rằng câu hỏi 1 đã tiết lộ những dữ liệu này đều tuân theo những chuẩn nhất định. Cảm ơn mrro đã cho một câu đố thú vị!]]>
/hvaonline/posts/list/29806.html#208745 /hvaonline/posts/list/29806.html#208745 GMT
xác định định dạng dữ liệu ftp://ftp.openssl.org/snapshot/ của openssl, vì tính năng hỗ trợ CMS password based chưa được đưa vào các bản realse. Thêm nữa, để openssl làm việc được với CMS, cần thêm tuỳ chọn enable-cms khi tiến hành cấu hình biên dịch. Các gói binary sẵn có thường không hỗ trợ tính năng này. ]]> /hvaonline/posts/list/29806.html#208875 /hvaonline/posts/list/29806.html#208875 GMT xác định định dạng dữ liệu g09w4ZCW6v27ONXx3ggGZvghgJWxsHeIuEglRGmyw2hd9nO13wfphL2D2DpXmv1DTGWE5gZti8puQ+SIoTmGlMJ3wFthSLt/jpc1mdHY/2a/4FNHHKL+T+54dKHYG4Zk+DYMV+Yh1dNtayaRO10Mb+AdJShFQa1aI6C57Fn0VAA=   ]]> /hvaonline/posts/list/29806.html#208888 /hvaonline/posts/list/29806.html#208888 GMT