I am currently investigating a disk image with a FAT12 file system for data recovery purposes/researching for file carving. For this investigation, I have the actual files that need to be carved/recovered from the disk image so that I can validate my results obtained from the carving process/recovery.
During the comparison and analysis from the recovered files, I noticed that after exactly 2 clusters (each of size 16384 bytes/32 sectors) of file data there are 4 extra/embedded bytes. These repetitive and distinct 4 bytes that are being noticed after 2 clusters are not found in the corresponding actual files. I think that these bytes are used somehow by the file system, is this right? What is their purposes and how can be identified during the recovery process?
Hex dump:
Actual File that needs to be recovered from disk (hex between 2 clusters):
Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
00016336 BC 55 B4 F8 A5 E1 69 82 2A DD 4A 5D DC 46 B9 80 ¼U´ø¥ái‚*ÝJ]ÜF¹€
00016352 E1 33 D3 F9 76 AE 8A 79 2E 22 0F 58 EE 67 FD AD á3Óùv®Šy." Xîgý
00016368 49 E9 7B 76 45 99 3E 25 69 36 F2 00 8B 71 70 C0 Ié{vE™>%i6ò ‹qpÀ
00016384 FC BB 6D 65 E9 DC F2 30 7E BD 6A B4 BF 17 52 0B ü»meéÜò0~½j´¿ R
00016400 64 9A 2D 13 58 B8 0E FB 13 65 9B 1E 87 93 F9 00 dš- X¸ û e› ‡“ù
00016416 7F 11 55 4F 21 AD A7 3A 51 D7 B9 CF 3C DE 35 25 UO!§:Q×¹Ï<Þ5%
Disk Image:
Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
00132880 BC 55 B4 F8 A5 E1 69 82 2A DD 4A 5D DC 46 B9 80 ¼U´ø¥ái‚*ÝJ]ÜF¹€
00132896 E1 33 D3 F9 76 AE 8A 79 2E 22 0F 58 EE 67 FD AD á3Óùv®Šy." Xîgý
00132912 49 E9 7B 76 45 99 3E 25 69 36 F2 00 8B 71 70 C0 Ié{vE™>%i6ò ‹qpÀ
00132928 **08 B5 A9 88** FC BB 6D 65 E9 DC F2 30 7E BD 6A B4 µ©ˆü»meéÜò0~½j´
00132944 BF 17 52 0B 64 9A 2D 13 58 B8 0E FB 13 65 9B 1E ¿ R dš- X¸ û e›
00132960 87 93 F9 00 7F 11 55 4F 21 AD A7 3A 51 D7 B9 CF ‡“ù UO!§:Q×¹Ï
00132976 3C DE 35 25 <Þ5%
From the above hex dump it can be visualized that 08 B5 A9 88 is exactly between the two clusters, however in the actual file those 4 bytes were eliminated.
The extra 4 bytes that were being encountered between the two clusters were CRCs that were embedded by the Encase disk image file format for security purposes. You can refer to the following link for more detail.
Related
After getting data from old software, I can save it to a file with a specific format.
I wanted to extract the data from this file.
Unfortunately, this format is unreadable.
It seems to have specific characters (? or #).
I don't really understand how it is encoded but I have the data in the software to check the answer.
Here is a small sample of the bytes that the file contains:
0000-06f0: 10 db 2f 34-dc 80 c4 3f-8c e7 f7 ae-e6 61 02 40 ../4...? .....a.#
0000-0700: 41 69 af a4-f1 9e c2 3f-d9 e4 52 91-d4 1e 02 40 Ai.....? ..R....#
0000-0710: 50 0f be bc-f0 b5 c3 3f-df 4e 84 c9-0e e0 02 40 P......? .N.....#
0000-0720: 51 fe 42 71-a4 15 c3 3f-52 58 bc ab-ff f5 02 40 Q.Bq...? RX.....#
0000-0730: f6 26 e6 87-3c 27 c3 3f-ef 02 25 a5-db 9b 02 40 .&..<'.? ..%....#
0000-0740: 1e d4 37 19-a1 56 c3 3f-b5 76 c8 6a-34 3c 02 40 ..7..V.? .v.j4<.#
0000-0750: 81 34 51 8c-b0 f8 c4 3f-2e 74 d6 cd-4a 84 01 40 .4Q....? .t..J..#
0000-0760: 14 c7 40 00-7a 93 c5 3f-02 43 07 2b-76 a4 01 40 ..#.z..? .C.+v..#
0000-0770: c9 2d 42 c2-03 51 c6 3f-0c c5 30 d2-b5 38 01 40 .-B..Q.? ..0..8.#
0000-0780: 70 3e bb b0-cb 0a c8 3f-4b b7 12 c7-28 18 00 40 p>.....? K...(..#
0000-0790: 6a ad b4 7a-62 ae c7 3f-90 11 50 41-f1 f2 fd 3f j..zb..? ..PA...?
0000-07a0: 3a e9 01 1a-a7 f4 c7 3f-96 7b d0 a5-33 40 fd 3f :......? .{..3#.?
0000-07b0: 87 a1 ac 47-6c c0 c6 3f-90 78 3d 69-07 43 fe 3f ...Gl..? .x=i.C.?
0000-07c0: 36 d7 1c 39-43 27 c8 3f-d4 a3 47 47-80 df fd 3f 6..9C'.? ..GG...?
If someone knows how to decode it to get, it could be super useful.
Thanks.
I am trying to get the NAL units from an mp4 file using C. I got inside the "mdat" atom and tried extracting the NAL units. The first 3 were as "size, data" where size is the size of data in bytes. After that, I continued looking for the next unit. The size was 0xde02004c, which is too big. When I checked it with the hex editor, I saw that that is indeed true. But then I noticed the "Lavc" written right next to it.
00004930 92 43 19 61 93 4e de 02 00 4c 61 76 63 35 38 2e |.C.a.N...Lavc58.|
00004940 35 34 2e 31 30 30 00 42 20 08 c1 18 38 00 00 00 |54.100.B ...8...|
00004950 c9 01 9e 41 79 09 7f 7a 03 ed 3f 54 39 fb c2 01 |...Ay..z..?T9...|
00004960 c4 53 76 51 2d bf 57 5f 04 25 00 b9 fb df 43 67 |.SvQ-.W_.%....Cg|
00004970 f3 27 b9 f5 d7 e7 95 e9 b4 06 14 6b 4a c7 4e ff |.'.........kJ.N.|
00004980 23 ed 8f 17 d0 4d d4 21 a7 b3 84 0e 65 60 41 67 |#....M.!....e`Ag|
00004990 ec db 10 c9 b3 4c 3f 71 df 6b 73 c2 df cd fe 85 |.....L?q.ks.....|
The previous NAL unit ends right before the bytes "de 02 00 4c", so that should be the size of the next one. But it isn't. It looks like codec information. Why?
Edit: The first bytes of the first nalu:
00 00 02 af 06 05 ff ff ┊ ab dc 45 e9 bd e6 d9 48 │00•×••××┊××E××××H│
b7 96 2c d8 20 d9 23 ee ┊ ef 78 32 36 34 20 2d 20 │××,× ×#×┊×x264 - │
the second:
00 00 41 80 65 ┊ 88 84 01 ff 5e e7 6f ea
36 23 b7 5d 16 f8 5f 54 ┊ a3 5d 7c 9e ac d1 9b f6
and the third:
00 04 cb 41 9a 22 6c 5f
6e 75 69 b0 e3 e1 d9 c9 ┊ d4 71 cb 05 a3 60 09 71 ```
I am working on developing an application for a smart card reader, using the Visa test kit in the C language. On reading card number 2, am getting the following Issuer Public Key Certificate after reading the card:
uint8_t ISSUER_PK_CERTIFICATE[] = {41 03 b1 61 f7 dd 14 34 85 79 1b f6 01 04 ea 10 08 06 9d 16 b6 c3 b3 5b 4e 37 ed 20 25 66 d8 77 6f 48 02 28 32 0a 90 31 ae 28 28 75 fa 1b 3a bf c7 6d 15 6f f4 b5 08 4a fd 9c b0 ef b0 8a 8e 5b 41 fa be 99 3b 04 fe 1b 76 8d ef b6 eb ae d1 77 4d d0 5e 7f f7 0c 45 86 42 85 e6 d0 06 2d 86 65 4e 7a 88 5f 49 f9 f3 11 9f 24 35 18 4c 28 1c 14 93 d2 ac 69 ec c7 88 da c0 75 9a 73 ec d5 f0 28 b3 27 a1 e5 1d c5 cb 43 53 7b 1d 2a a7 04 62 cd a3 c8 74 a5 7c 45 8e 52 15 09 ff 98 73 71 d6 da 8d 7a 4f f5 6f 10 87 89 68 86 33 17 1e f1 d6 9d},
...(ignoring the specifics of formatting in C arrays) where the modulus is 176 and from Visa, I have the following CA Public Key Modulus. The cards are test cards, thus I have no problem sharing the output publicly:
uint8_t VISA_PK_MODULUS[] = {99 6A F5 6F 56 91 87 D0 92 93 C1 48 10 45 0E D8 EE 33 57 39 7B 18 A2 45 8E FA A9 2D A3 B6 DF 65 14 EC 06 01 95 31 8F D4 3B E9 B8 F0 CC 66 9E 3F 84 40 57 CB DD F8 BD A1 91 BB 64 47 3B C8 DC 9A 73 0D B8 F6 B4 ED E3 92 41 86 FF D9 B8 C7 73 57 89 C2 3A 36 BA 0B 8A F6 53 72 EB 57 EA 5D 89 E7 D1 4E 9C 7B 6B 55 74 60 F1 08 85 DA 16 AC 92 3F 15 AF 37 58 F0 F0 3E BD 3C 5C 2C 94 9C BA 30 6D B4 4E 6A 2C 07 6C 5F 67 E2 81 D7 EF 56 78 5D C4 D7 59 45 E4 91 F0 19 18 80 0A 9E 2D C6 6F 60 08 05 66 CE 0D AF 8D 17 EA D4 6A D8 E3 0A 24 7C 9F},
also ignoring the formatting (I have written it like that here for simplicity),
where the modulus is also 176. The CA Public Key index is 5 and the exponent is 3, that's how I retrieved the above key. Now, I have written the following function to implement the RSA decryption algorithm to be able to verify the signature of the certificate:
uint32_t buffer[ISSUER_PK_CERTIFICATE_LENGTH]; //this holds the "decrypted" data
void decryptCertificate(uint8_t exponent)
{
uint32_t buffer[ISSUER_PK_CERTIFICATE_LENGTH]; //the length is in hex
for(int i = 0; i < hexToDecimal(ISSUER_PK_CERTIFICATE_LENGTH); i++) //conversion to integer for my convenience
{
uint32_t powered = pow(ISSUER_PK_CERTIFICATE[i], exponent);
uint32_t remainder = powered / VISA_PK_MODULUS[i];
uint32_t multiplied = remainder * VISA_PK_MODULUS[i];
uint32_t original = powered - multiplied;
buffer[i] = original;
}
}
but the final "decrypted" array does not fit the requirements of the Validation test specified by VISA. Anyone see where I could have gone wrong in the implementation of the above algorithm or can someone point me in the right direction if I have gone wrong? the output of the decryption is as shown:
8f 1b 94 1f 2d 3d 23 00 8b 40 be 00 01 40 06 d0 24 0c 2e 2e 5c 03 35 16 82 7d 5c 08 7b 94 67 4b 0b 84 02 00 8a 14 01 c9 20 9e 98 5d 1c 63 8c 08 43 35 27 14 0c 3d 86 94 61 81 4c 27 3a 48 d0 31 05 01 20 3f b3 40 a1 77 1b 4b ef 5b ab 60 36 38 31 1c 18 01 3d 01 45 e0 43 13 6e 43 d8 4e 6e 29 7a 08 70 41 48 27 37 11 28 00 32 5a 0a 10 34 3e 00 00 0d 49 b0 c7 36 08 30 4d 00 1b 08 99 00 11 b3 27 3d 19 01 35 0c 03 07 2a 5e ed 2f 40 20 8d 02 39 2f 45 13 bd 0d 10 2d 09 41 08 25 08 58 00 01 2c 51 05 06 07 13 a1 cc 0a 1b 88 00 01 04 97
NB: The Visa Specification states the Recovery function as: X = Recover(PK)[S] = Se mod n, given a digital Signature S and public key PK
It appears that you're trying to perform RSA decryption on each byte individually. This is incorrect — the certificate and modulus arrays each represent a single big integer. You will need to use a big-integer math library (or a special-purpose crypto library) to perform this decryption.
As a general comment OpenSSL may be a good fit for you. If its overhead or library size is too large for the card reader, there are other libraries specifically designed for embedded device environments. Check out the crypto library modules on the wiki (Crypto Libraries) and among them CyaSSL, MatrixSSL, PolarSSL, and SharkSSL are known to be for embedded devices.
I'm trying to ID (and maybe recover) the filesystem/partition table. Friend brought a "broken" USB drive, Windows can't recognise the partition layout.
Under Linux, fdisk says the partition table is empty. Tried mounting it as NTFS, vfat, no luck. With fdisk/mkfs, created an empty: DOS partition table, ntfs and fat filesystems, tried to compare magic numbers in the first block of the respective three and the broken drive - none seem alike. dd'd the first 1MB of the drive to a file on disk (so that file doesn't say it's a block device), file said "data".
This is the first 8 lines of hd:
00000000 0e 21 e9 6e 2c 64 39 b5 63 bf a5 08 8b 07 85 a6 |.!.n,d9.c.......|
00000010 63 aa ec 58 c3 ff fb 92 64 ec 80 02 f4 3c 4c d1 |c..X....d....<L.|
00000020 8f 2a e4 58 24 39 ba 3d 86 4a 8e e0 d3 27 ac 60 |.*.X$9.=.J...'.`|
00000030 eb 81 73 9f 26 68 f6 15 72 60 02 6b 32 32 4c 75 |..s.&h..r`.k22Lu|
00000040 b1 0a cd ff ff ff f4 ea 23 c8 2a ba 25 01 20 9d |........#.*.%. .|
00000050 26 52 b1 31 2c 4d 72 b1 2f bc 9f 1f 59 5b 98 98 |&R.1,Mr./...Y[..|
00000060 41 9d 3c 10 17 d0 58 9a ab 24 d9 31 ff 3a 79 55 |A.<...X..$.1.:yU|
00000070 f3 88 08 6b 57 ec 7a 5f ff e0 21 c7 87 4c 62 83 |...kW.z_..!..Lb.|
Any idea how to proceed with the recovery?
If you study fdisk code on Linux, you will see code to create/parse a Master Boot Table. This is the table that contains diff codes for diff boot partitions, starting block/offset, bootable/non-bootable flag, etc. If this table is corrupted, then it is difficult to recover.
One option is to find out where the MBT is stored on USB...usually, it is a standard location based on the file system. If the data there is not readable, then go beyond it and see where the first file system block is resident (most probably also a fix starting location. If the hex dump is recognizable at this location, create a MBT with this block number and see if the boot works..
The other option is to find out if there is a duplicate copy of MBT stored by the FS on the USB. Study the File system that formatted the USB and you may get closer.
This is the data it displays:
http://krill.larvit.se/resihop_dev/style.css
HTTP/1.1 200 OK
Date: Tue, 17 Jul 2012 20:36:17 GMT
Server: Apache/2.2.16 (Debian)
Last-Modified: Mon, 16 Jul 2012 23:33:42 GMT
ETag: "3003d8-92f-4c4fadc326180"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 871
Content-Type: text/css
00000000: 4a 01 00 00 03 08 00 00 68 fc 1b c8 a2 23 2e 00 J.......h....#..
00000010: c4 c4 1c c8 a2 23 2e 00 0f 01 00 00 48 54 54 50 .....#......HTTP
00000020: 2f 31 2e 31 20 32 30 30 20 4f 4b 00 44 61 74 65 /1.1 200 OK.Date
00000030: 3a 20 54 75 65 2c 20 31 37 20 4a 75 6c 20 32 30 : Tue, 17 Jul 20
00000040: 31 32 20 32 30 3a 33 36 3a 31 37 20 47 4d 54 00 12 20:36:17 GMT.
00000050: 53 65 72 76 65 72 3a 20 41 70 61 63 68 65 2f 32 Server: Apache/2
00000060: 2e 32 2e 31 36 20 28 44 65 62 69 61 6e 29 00 4c .2.16 (Debian).L
00000070: 61 73 74 2d 4d 6f 64 69 66 69 65 64 3a 20 4d 6f ast-Modified: Mo
00000080: 6e 2c 20 31 36 20 4a 75 6c 20 32 30 31 32 20 32 n, 16 Jul 2012 2
00000090: 33 3a 33 33 3a 34 32 20 47 4d 54 00 45 54 61 67 3:33:42 GMT.ETag
000000a0: 3a 20 22 33 30 30 33 64 38 2d 39 32 66 2d 34 63 : "3003d8-92f-4c
000000b0: 34 66 61 64 63 33 32 36 31 38 30 22 00 41 63 63 4fadc326180".Acc
000000c0: 65 70 74 2d 52 61 6e 67 65 73 3a 20 62 79 74 65 ept-Ranges: byte
000000d0: 73 00 56 61 72 79 3a 20 41 63 63 65 70 74 2d 45 s.Vary: Accept-E
000000e0: 6e 63 6f 64 69 6e 67 00 43 6f 6e 74 65 6e 74 2d ncoding.Content-
000000f0: 45 6e 63 6f 64 69 6e 67 3a 20 67 7a 69 70 00 43 Encoding: gzip.C
00000100: 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 38 ontent-Length: 8
00000110: 37 31 00 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 71.Content-Type:
00000120: 20 74 65 78 74 2f 63 73 73 00 00 00 1c 75 7f de text/css....u..
00000130: 67 1f 5e 3e ea 80 b1 88 00 f0 37 0c 0b 00 00 00 g.^>......7.....
00000140: 33 31 2e 32 34 2e 36 37 2e 36 37 00 50 00 31.24.67.67.P.
00000000: 1f 8b 08 00 00 00 00 00 00 03 8d 55 db 4e e3 30 ...........U.N.0
00000010: 10 7d 6e be c2 6a b5 62 41 04 28 2d 2c 4d df 10 .}n..j.bA.(-,M..
00000020: ec 6f ac a6 89 93 78 71 ec c8 76 81 6e c5 77 ed .o....xq..v.n.w.
00000030: fb 7e d9 8e 6f 49 1a 0a 42 55 a5 d8 99 cb 99 33 .~..oI..BU.....3
00000040: 67 26 97 67 1b d0 2c 27 1c 76 72 6b ce 2e 93 59 g&.g..,'.vrk...Y
00000050: 2e 85 01 26 a8 da 27 93 17 56 98 3a 23 f3 ab ab ...&..'..V.:#...
00000060: 6f eb 64 d2 4a cd 0c 93 22 23 b0 d1 92 6f 0d c5 o.d.J..."#...o..
00000070: cb 9a b2 aa 36 9d 8d 7c a6 aa e4 f2 25 23 35 2b ....6..|....%#5+
00000080: 0a 2a d6 c9 5b 92 cc 38 2d 0d f9 5a 3c 6b 9a 91 .*..[..8-..Z<k..
00000090: 2b 7c ba 3c c3 10 4c 54 c4 d4 94 6c 2b be 23 da +|.<..LT...l+.#.
000000a0: 6c cb 92 80 71 37 1b 69 8c 6c 88 2c dd a9 81 16 l...q7.i.l.,....
000000b0: c1 f7 68 ae 5d 06 6f 93 91 d4 1d 3b 24 2d 42 69 ..h.].o....;$-Bi
000000c0: 40 55 4c b8 4c f6 1e fd 7f e5 20 9e 41 5b 9c 2d #UL.L..... .A[.-
000000d0: 14 36 b3 c7 31 aa f0 a0 06 e7 ab ec fb de 2b 55 .6..1.........+U
000000e0: d1 be 7d 45 fb 82 e9 16 d9 cd c8 86 cb fc c9 82 ..}E............
000000f0: 82 fc a9 52 72 2b 8a 34 97 5c aa 8c bc d4 ec 73 ...Rr+.4.\.....s
00000100: 2e 75 ae 24 e7 7d f2 e5 62 e1 62 1f 65 30 a4 f7 .u.$.}..b.b.e0..
00000110: d9 8d 6c 63 8d 97 67 0f 54 b3 4a 20 4f 0d 15 db ..lc..g.T.J O...
00000120: fd 07 ee 91 33 ef ef 83 4d 42 2d 1d 2f f6 ec c8 ....3...MB-./...
00000130: 19 d0 38 28 ac 2f e9 10 30 a2 b0 a9 09 67 98 9d ..8(./..0....g..
00000140: 33 6d 52 6d 76 9c a6 66 d7 d2 8c 08 29 e8 80 30 3mRmv..f....)..0
00000150: 26 38 b3 17 6f d1 27 db d0 52 2a 6a 1b 64 45 4a &8..o.'..R*j.dEJ
00000160: 05 56 39 fd f7 97 4c 87 81 b3 92 29 8c 9b d7 8c .V9...L....)....
00000170: 17 47 1d bc f5 46 16 3b 7b 5f e2 7d 5a 42 c3 38 .G...F.;{_.}ZB.8
00000180: 76 68 ca b7 39 2b 80 54 0a 44 41 a7 e7 06 6a d9 vh..9+.T.DA...j.
00000190: c0 39 b6 a1 00 01 e7 a0 18 f0 73 0d 42 a7 9a 2a .9........s.B..*
000001a0: 56 ae 83 bb 66 7f 10 fd dc b7 c4 62 4e bb 46 fe V...f......bN.F.
000001b0: 70 77 87 5a 03 07 c7 36 7e 32 5b dc df ac 56 77 pw.Z...6~2[...Vw
000001c0: b6 4f f4 d5 a4 05 cd a5 02 df 11 4f 06 9a 27 90 .O.........O..'.
000001d0: d5 56 09 fb 23 46 48 35 55 91 a5 f7 42 f4 b3 34 .V..#FH5U...B..4
000001e0: bf 09 d4 fb f7 a4 9e ef 0f 80 33 51 63 35 66 1d ..........3Qc5f.
000001f0: 51 d9 f2 77 4e 08 0a a3 a7 51 0f 73 ec 38 8a 84 Q..wN....Q.s.8..
00000200: 15 64 f6 b8 b2 bf 58 fe 4b 28 56 48 d5 00 1f aa .d....X.K(VH....
00000210: e4 ce 8a 84 74 04 a4 03 31 a2 1a b9 04 8c 8f 6a ....t...1......j
00000220: bc f0 4f 07 92 c0 da 14 ff 7e 02 bf e1 35 f5 af ..O......~...5..
00000230: 2f 2a 56 9e 9c 3a e7 e0 e0 65 14 8b 8d 38 63 b5 /*V..:...e...8c.
00000240: bd 11 81 03 ad 2b ca 91 be 67 1a a7 23 5d 06 0f .....+...g..#]..
00000250: c4 84 56 26 b5 28 2c 2c 7b d0 e3 6d 70 d8 cb 24 ..V&.(,,{..mp..$
00000260: 58 8d 15 dd 89 f9 0b 24 1e 45 d6 4f 1a 6d 42 ae X......$.E.O.mB.
00000270: 90 89 35 55 b7 be 46 ab 06 97 05 e0 c9 b6 dd 7b ..5U..F........{
00000280: 58 c1 0c f7 79 f0 f2 ba b8 f5 4e 61 42 17 37 73 X...y.....NaB.7s
00000290: 7b 7c ef e6 d9 1b 91 ec b5 9e 73 0a a8 17 07 e2 {|........s.....
000002a0: 48 c2 c1 9e 0d ad 8f ad 11 d0 d0 fd 48 3e 1b c9 H...........H>..
000002b0: 0b ff b6 a1 5a 43 45 7b e7 77 ad 35 ac a1 a4 9f ....ZCE{.w.5....
000002c0: 23 32 bb 7d b8 5b de 2f 3f 9d a3 e0 f4 d5 61 72 #2.}.[./?.....ar
000002d0: e6 83 0c ab 55 27 f8 30 ef f3 c1 6c 77 10 e3 aa ....U'.0...lw...
000002e0: cd 65 83 0b c9 68 ab a3 f8 fc 91 94 6e dc 98 5c .e...h......n..\
000002f0: 8d 76 68 fc 38 cc 1e 1f 1e 7f fe 5c 1e 4b 6e 61 .vh.8......\.Kna
00000300: c6 e0 5e 81 0d 42 89 cb 67 e1 74 fd b1 02 e3 8a ..^..B..g.t.....
00000310: ee 30 a1 bd c3 12 fe eb c9 58 ed 7d b2 d1 17 b4 .0.......X.}....
00000320: ff c8 f5 4b bb 37 b6 8d 7a 67 f0 51 f3 07 f5 5c ...K.7..zg.Q...\
00000330: d0 d7 16 17 f1 a8 ac f1 97 c6 a2 cd d1 03 f5 66 ...............f
00000340: 57 46 f0 bf 68 45 75 8a cd 4f 15 6d 29 98 f5 78 WF..hEu..O.m)..x
00000350: 29 5e 5f 7b 02 8f e4 73 78 8f 6e b6 b7 e4 3f 49 )^_{...sx.n...?I
00000360: 7b 1f b2 2f 09 00 00 {../...