I have been using wireshark for a project I am working on, and I noticed that a lot of, seemingly malformed, messages are being send over my wlan0 interface. I am not sure where they come from, so I was hoping that someone could shed some light on this.
I run Ubuntu 12.04 on a Dell XPS 13.
The only thing I can think of is posting one of these messages here:
0000 5c f8 a1 96 0f 5f 00 1e 0b 70 b0 98 00 4c 50 03 \...._...p...LP.
0010 00 20 00 00 00 00 1e e0 1f e8 a3 93 99 f4 41 9d . ............A.
0020 93 76 82 9d 4e 99 da 43 cb bc 29 86 83 9c 8e f4 .v..N..C..).....
0030 20 df a9 4f e9 3e df a1 32 2c 59 e3 e6 a6 8a 97 ..O.>..2,Y.....
0040 40 ce fc a2 74 f2 a7 5d ce 12 e5 69 74 ec 4c e1 #...t..]...it.L.
0050 8e cd d3 19 92 b0 84 12 29 6f ........)o
A lot of these messages seem to use the LLC (Logical link control) protocol, though not all. Any suggestions are welcome.
Related
im trying to reverse one app, and wanted to ask, maybe some one can help with fresh idea, or already know what is used here.
So the case, i have client and server, now i have written mitm app, and i can see the packets.
Tha packets order is
s2c: sending rsa key
c2s: sending some always static data, encrypted with rsa
s2c: sending some response, seems like an packet without body (im here)
c2s: sending data, and here is problem, that this packet is not encrypted as packet 2
c2s: sending response
this is packet header
50 50 00 00 40 00 50 00 00 00 00 00 ... rest is body
lets divide it
50 50 - this is always same
00 00 - this is some packet flag, cause always after packet 3, it becomes x04 00
40 00 - this is length 100%
50 00 - packet code i think
00 00 00 00 - i dont know what i this
body - is not readable, but also is not encrypted with rsa
here is example of stream
**s2c packet 1**
2023/01/24 21:32:56 Received: 176
00000000 *50 50 00 00 a4 00 01 00 00 00 00 00* a2 00 2d 2d |PP............--|
00000010 2d 2d 2d 42 45 47 49 4e 20 52 53 41 20 50 55 42 |---BEGIN RSA PUB|
00000020 4c 49 43 20 4b 45 59 2d 2d 2d 2d 2d 0a 4d 45 63 |LIC KEY-----.MEc|
00000030 43 51 51 43 71 49 4e 36 37 76 45 52 47 37 34 49 |CQQCqIN67vERG74I|
00000040 64 77 38 6d 76 6c 66 6d 45 31 38 31 31 56 74 2b |dw8mvlfmE1811Vt+|
00000050 53 76 66 67 73 36 43 68 59 51 78 4e 5a 52 57 74 |Svfgs6ChYQxNZRWt|
00000060 7a 31 6f 62 50 53 69 34 62 75 78 72 41 0a 5a 6d |z1obPSi4buxrA.Zm|
00000070 6d 77 32 4e 69 38 44 59 74 67 6d 77 54 74 48 51 |mw2Ni8DYtgmwTtHQ|
00000080 66 6b 6d 35 65 59 2f 76 63 54 41 67 49 44 43 51 |fkm5eY/vcTAgIDCQ|
00000090 3d 3d 0a 2d 2d 2d 2d 2d 45 4e 44 20 52 53 41 20 |==.-----END RSA |
000000a0 50 55 42 4c 49 43 20 4b 45 59 2d 2d 2d 2d 2d 0a |PUBLIC KEY-----.|
2023/01/24 21:32:56 RSA Key chaged - here i changed key to my
**c2s packet 2**
2023/01/24 21:32:56 Received: 76
00000000 *50 50 00 00 40 00 50 00 00 00 00 00* 97 4a 85 34 |PP..#.P......J.4|
00000010 e6 e0 f8 56 d6 5b 12 a4 4b 3f e2 f3 c7 b4 a1 fc |...V.[..K?......|
00000020 c7 fe b8 88 bc b7 8b 93 89 c2 7f 02 09 7b 52 4a |.............{RJ|
00000030 23 be a4 47 eb b8 02 f5 0a 62 9a 88 15 13 12 de |#..G.....b......|
00000040 a4 94 2c 3a 0a 34 47 bb 13 6f d4 ae |..,:.4G..o..|
2023/01/24 21:32:56 Header: 76
00000000 *50 50 00 00 40 00 50 00 00 00 00 00* |PP..#.P.....|
2023/01/24 21:32:56 Encoded with my key
00000000 *97 4a 85 34 e6 e0 f8 56 d6 5b 12 a4* 4b 3f e2 f3 |.J.4...V.[..K?..|
00000010 c7 b4 a1 fc c7 fe b8 88 bc b7 8b 93 89 c2 7f 02 |................|
00000020 09 7b 52 4a 23 be a4 47 eb b8 02 f5 0a 62 9a 88 |.{RJ#..G.....b..|
00000030 15 13 12 de a4 94 2c 3a 0a 34 47 bb 13 6f d4 ae |......,:.4G..o..|
2023/01/24 21:32:56 Decoded body
00000000 29 00 00 00 23 48 00 00 be 18 00 00 84 67 00 00 |)...#H.......g..|
2023/01/24 21:32:56 Encoded with original key
00000000 0a cb d2 7f f6 a3 8b 57 2c 6b e8 6d ed f0 c1 36 |.......W,k.m...6|
00000010 e4 c8 00 9d ca 55 41 62 ef 4b 72 91 7c fc 7b 1d |.....UAb.Kr.|.{.|
00000020 e4 5c f0 2b ce 86 01 79 ae b8 13 dd 51 a0 30 c5 |.\.+...y....Q.0.|
00000030 6f 77 fa 11 ed 03 7b 2c 77 7c 5b 7e 61 6f 86 9d |ow....{,w|[~ao..|
**s2c packet 3**
2023/01/24 21:32:56 Received: 12
00000000 *50 50 00 00 00 00 02 00 00 00 00 00* |PP..........|
**c2s packet 4**
2023/01/24 21:32:56 Not decoding next packet
2023/01/24 21:32:56 Received: 174
00000000 *50 50 04 00 a2 00 01 30 00 00 00 00* 00 9f 53 ab |PP.....0......S.|
00000010 c8 58 49 ea 4d fa 18 f4 f1 fc 9a 3c 04 ca 11 94 |.XI.M......<....|
00000020 ab ec ba 1d c6 f0 5d e0 1f d6 87 2d de 0c 97 eb |......]....-....|
00000030 29 b7 d1 dc 48 38 f4 63 74 29 e2 ea 9f 81 a8 59 |)...H8.ct).....Y|
00000040 47 75 32 0d 53 0e 55 3e cd 7b 89 d9 c3 22 d5 39 |Gu2.S.U>.{...".9|
00000050 c4 18 a5 c7 e2 eb 3a 9e 72 13 36 c3 52 f5 e6 7d |......:.r.6.R..}|
00000060 9b bf 37 06 e5 e9 4c 74 ac 85 37 85 94 81 37 67 |..7...Lt..7...7g|
00000070 f9 28 60 c7 0a ca 4c 5a 57 20 d6 ce 7c 91 58 6b |.(`...LZW ..|.Xk|
00000080 56 af 96 a8 e4 b5 8c 19 2e 9a 8c fa a6 c2 08 24 |V..............$|
00000090 ab 97 5d be 74 c2 19 d2 bd f1 93 5f a5 65 c5 7c |..].t......_.e.||
000000a0 fa bb 46 07 80 fd b6 79 5c 19 6f 65 54 35 |..F....y\.oeT5|
**s2c packet 5**
2023/01/24 21:32:56 Received: 174
00000000 *50 50 04 00 a2 00 01 40 00 00 00 00* 00 9e e7 03 |PP.....#........|
00000010 1b aa 67 36 1e 6f 34 20 c3 7c a9 85 93 74 b7 53 |..g6.o4 .|...t.S|
00000020 cc 10 68 90 ec 41 54 68 bb 9e 3d 41 c9 3f db 41 |..h..ATh..=A.?.A|
00000030 09 b9 ae 6a 9b f9 5c 0f 47 c6 4b bd 94 08 20 b0 |...j..\.G.K... .|
00000040 2e f2 6e 40 11 b6 14 8b e0 51 89 db 0c e0 c8 5b |..n#.....Q.....[|
00000050 92 1f a3 08 90 05 5c b5 bb bb 50 c0 3e f6 ee e8 |......\...P.>...|
00000060 63 bd 23 74 53 24 8f a3 0b 4e 72 12 a0 0e ac 96 |c.#tS$...Nr.....|
00000070 03 2c e8 31 6a 34 10 84 63 7a e1 32 42 d3 69 17 |.,.1j4..cz.2B.i.|
00000080 73 df a4 89 35 90 0f 92 06 d7 3b 2e 3c 3d 6e 7e |s...5.....;.<=n~|
00000090 db 73 cb f0 96 95 df 84 af 20 b7 7b 7c 64 61 a9 |.s....... .{|da.|
000000a0 b2 0e 9d 1e bc 57 73 5f f0 bc a5 aa b8 36 |.....Ws_.....6|
Maybe some one can identify protocol by packet header, cause i havent seen something similar before.
Thank you
i know that only packet 2 is encrypted, cause i changed rsa key to my key, and decoded data, its not work with other packets.
I'm trying to understang which TLS version is used based on this logs (http trace)
System.Net Information: 0 : [2544] SecureChannel#49129953::.AcquireClientCredentials, new SecureCredential() (flags=(ValidateManual, NoDefaultCred, SendAuxRecord), m_ProtocolFlags=(Ssl3Client, Tls10Client), m_EncryptionPolicy=RequireEncryption)
Algorithm: RSA
Length: 2048
Key Blob: 30 82 01 0a 02 82 01 01 00 b8 de 6a 2c a0 05 1d c1 2e 54 2d de 74 40 a6 83 2b 81 25 29 8d c1 2b e1 4d 4b 63 bd 7f c0 75 fe 15 eb 6b a6 2f 3c 65 d6 7a 55 dc 68 07 1c 6c 2e 8c cd d5 01 74 9f ca ca bb 5e b0 6d 9a 44 d1 1c 74 11 ca 4f 44 fa 59 59 22 f5 f9 c2 00 21 d6 1d a3 09 5a 0e fe da b7 ea d2 c8 55 51 c7 53 90 d1 b9 bf 2c 98 49 75 82 30 ....
System.Net Information: 0 : [2544] SecureChannel#49129953 - Remote certificate was verified as valid by the user.
System.Net Information: 0 : [2544] ProcessAuthentication(Protocol=Tls, Cipher=Aes128 128 bit strength, Hash=Sha1 160 bit strength, Key Exchange=RsaKeyX 2048 bit strength).
Any idea? If you need more log let me know.
Thank you
... m_ProtocolFlags=(Ssl3Client, Tls10Client)
... ProcessAuthentication(Protocol=Tls
Based on this it should be TLS 1.0. For other versions like TLS 1.2 there is probably something like Protocol=Tls12 instead
I am trying to gain access to in game chat information from dota2 packets. I knew this used to possible since there were multiple projects that intercepted dota2 network traffic and translated chat text to print out on an overlay over dota2. Right now I am using wireshark with protobuf addon installed. I can see a few packets here and there to valve servers outside the USA and can see the protobuf addon for wireshark working on these packets but I get an unknown wiretype error for 95% of the packets I believe to be related to dota. In almost all of these packets the UDP data payload starts off with 56 53 30 31
here is an example hex dump from wireshark. Are these 4 bytes some sort of header and then the proto messages start?
0000 c8 a7 0a a4 63 ed 6c fd b9 4b 6e 16 08 00 45 00
0010 00 70 58 db 40 00 40 11 85 1a c0 a8 01 f5 d0 40
0020 c9 a9 9e 96 69 89 00 5c 72 7c **56 53 30 31** 30 00
0030 06 00 00 02 00 00 00 1d fe 11 11 10 00 00 d7 0a
0040 00 00 01 00 00 00 11 10 00 00 30 00 00 00 24 fd
0050 37 3c b4 30 a5 48 fa 3d ea 30 1a 1f d8 a9 41 e0
0060 e0 6c 44 ba bb 4e ba fc e7 ac ed f9 40 19 86 20
0070 84 71 52 5d b3 1f da 36 40 d9 b6 2e e1 e5
That is ascii code for "VS01", so yes, it might be some kind of version identifier.
In wireshark, I am able to see the encrypted data to and fro from my PC. It does not use diffie hellman algorihm for key exchange because I see only the Client Key Exchange packet but there is no Server Key Exchange packet. That means the browser is sending the encrypted key to the server(encrypted using the server's public key).
But I do not see any encrypted data in that packet("Client Key Exchange"). How to view the encrypted key?
You won't see the encrypted shared-key, it's not exchanged. You can see the encrypted pre-master secret when using RSA authenticated key exchange. (Note that using Ephemeral Diffie-Hellman isn't the only reason for not seeing a server key exchange message: it could also use a DH_DSS or DH_RSA cipher suite, but this is unusual as far as I know).
If you follow the instructions about decrypting SSL with Wireshark, use the "SSL debug file" option to store the logs into a file. (Note that the user interface has changed slightly in newer versions of Wireshark, in the way you configure the private key.)
The log files will contain the pre-master secret and the shared keys.
(By the way, you need the server's private key to do this, of course.)
Using the sample data provided on the Wireshark page, you get:
pre master encrypted[128]:
65 51 2d a6 d4 a7 38 df ac 79 1f 0b d9 b2 61 7d
73 88 32 d9 f2 62 3a 8b 11 04 75 ca 42 ff 4e d9
cc b9 fa 86 f3 16 2f 09 73 51 66 aa 29 cd 80 61
0f e8 13 ce 5b 8e 0a 23 f8 91 5e 5f 54 70 80 8e
7b 28 ef b6 69 b2 59 85 74 98 e2 7e d8 cc 76 80
e1 b6 45 4d c7 cd 84 ce b4 52 79 74 cd e6 d7 d1
9c ad ef 63 6c 0f f7 05 e4 4d 1a d3 cb 9c d2 51
b5 61 cb ff 7c ee c7 bc 5e 15 a3 f2 52 0f bb 32
pre master secret[48]:
03 00 ff 84 56 6d a0 fb cc fd c6 c8 20 d5 f0 65
18 87 b0 44 45 9c e3 92 f0 4d 32 cd 41 85 10 24
cb 7a b3 01 36 3d 93 27 12 a4 7e 00 29 96 59 d8
master secret[48]:
1e db 35 95 b8 18 b3 52 58 f3 07 3f e6 af 8a a6
ab c3 a4 ed 66 3a 46 86 b6 e5 49 2a 7c f7 8c c2
ac 22 bb 13 15 0f d8 62 a2 39 23 7b c2 ff 28 fb
key expansion[136]:
11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7
b3 f7 33 aa b2 42 d0 1c a6 4e fb e9 9b 13 dd 29
63 aa 17 1f 47 71 95 71 08 e0 4b 8e e1 da 7b 4a
5a f3 c2 32 bd e0 a5 82 6d 14 44 3a d6 cb 2d c0
7d 57 be a8 37 de 5d d9 a1 07 fd 1b 22 71 b9 4b
7a 1e 0f 70 37 14 97 0a f0 db 98 3b 7b 74 e3 2d
51 66 2e 31 68 90 ac 6f e6 53 3c c9 5e 48 0c 05
bc 9f 92 e7 f9 91 98 f5 95 1c c4 bf d9 cb 26 ef
35 70 5e ad 21 22 3e f6
Client MAC key[20]:
11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7
b3 f7 33 aa
Server MAC key[20]:
b2 42 d0 1c a6 4e fb e9 9b 13 dd 29 63 aa 17 1f
47 71 95 71
Client Write key[32]:
08 e0 4b 8e e1 da 7b 4a 5a f3 c2 32 bd e0 a5 82
6d 14 44 3a d6 cb 2d c0 7d 57 be a8 37 de 5d d9
Server Write key[32]:
a1 07 fd 1b 22 71 b9 4b 7a 1e 0f 70 37 14 97 0a
f0 db 98 3b 7b 74 e3 2d 51 66 2e 31 68 90 ac 6f
Client Write IV[16]:
e6 53 3c c9 5e 48 0c 05 bc 9f 92 e7 f9 91 98 f5
Server Write IV[16]:
95 1c c4 bf d9 cb 26 ef 35 70 5e ad 21 22 3e f6
Until recently the dissection of the ClientKeyExchange was like this(version 1.6 and below):
TLSv1 Record Layer: Handshake Protocol: Client Key Exchange
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 134
Handshake Protocol: Client Key Exchange
Handshake Type: Client Key Exchange (16)
Length: 130
But if you use this verison(1.7.2 upwards) the key dissection will be like this:
TLSv1 Record Layer: Handshake Protocol: Client Key Exchange
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 134
Handshake Protocol: Client Key Exchange
Handshake Type: Client Key Exchange (16)
Length: 130
RSA Encrypted PreMaster Secret
Encrypted PreMaster length: 128
Encrypted PreMaster: 761b1beac35e59de9a3bb9f74ebf9109b738e8ad346
You can see the encrypted pre-master:)
Awesome write up here explaining how SSL works, notice at no time during this handshake is the private key ever sent over the wire.
http://4orensics.wordpress.com/2011/10/21/ssl-in-a-nutshell/
Long story short there is no way to decrypt SSL streams without the server's private key (unless you work for the NSA or something), however you may want to look into getting in between the server and client during the handshake and if the user does not check the validity of the certificate that is presented you are in business.
Here is a tool that can do that for you among many others
http://mitmproxy.org/
Of note I highly recommend the sans reading room article on SSL Mitm(Man in the Middle) attacks.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I have a file givin to me as a project, it has an unknown encryption type and is compressed. The compression type used is Zlib but the ratio is unknown. I have attempted to decompress the file and have produced 30 1kb files. I am unsure if the file is compressed then encrypted or vice versa.
I was given this output as a clue which I assume is produced in Bash shell Linux. I have cygwin installed in my Win machine and I'm using Bash, however I was unable to reproduce this ouput.
The file in question is a .FF which I assume stands for fastfile. I have included a hex snippet at the bottom of this thread.
$ ls -l bin.bin
-rw-r--r-- 1 sc sc 17150 2010-11-23 18:51 bin.bin
$ zip bin.zip bin.bin
adding: bin.bin (deflated 20%)
$ ./a.out < bin.bin | sort -k2rn | head -20
C3: 2756
C2: 1534
E2: 756
80: 709
C5: 294
A2: 185
A1: 158
A6: 154
BD: 149
AC: 140
B9: 133
93: 128
92: 127
9C: 127
B0: 127
A0: 121
BE: 121
B8: 120
9D: 116
BA: 116
49 57 66 66 30 31 30 30 00 00 01 D9 00 00 00 02 50 48 45 45 42 73 37 31 00 00 00 00 70 61 74 63 68 5F 6D 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A0 FA C7 BF 09 FC 57 8D 0E 0B 9B 3F 24 D2 FC 12 CC 78 71 2C BC 06 78 A0 3B 41 CA 92 19 C5 E8 3B 32 9D 39 ED 68 32 98 38 EB 8D DC D8 02 62 91 83 77 BA C4 3D 81 CD C0 0A F0 00 55 A3 6A 8A 9D 4D C8 C7 3D 8F 02 4A E4 FB EF F8 6A AA 33 95 AA DB DC 82 90 16 DC BD 9F 65 A1 70 07 8F 4A BE A4 83 DA AA 4F 84 8A 9D A0 5E 5E B1 54 9C C7 99 F8 83 74 71 B3 F9 46 D2 C5 22 7B 66 97 BA 47 89 1C FB DB D9 21 D3 B3 E6 93 5F 26 98 A1 42 E3 A5 D8 99 08 56 55 4F 5D F7 19 BA 79 9A BD 53 CE 6B 5A DA 84 F8 E2 F9 86 A0 7F 49 FD B9 95 33 02 E4 4B 2C 94 5F 95 25 7D E6 31 EB 43 4C 46 AE C4 4D 5C 5A B2 B2 EC 74 8D 07 D4 C7 6C E1 F4 B2 CF A4 B4 EA 4B BB 46 58 81 C4 5A CE 56 CE 8E 0B E0 10 2A 18 20 EB 09 F4 B2 A5 43 3E F8 0B 20 10 05 D8 03 EF CD F2 55 1C 4C 54 B1 A2 67 E4 F6 84 B7 8E 08 2A 00 00 00 17 66 40 A2 AF 03 82 81 08 C4 A9 C8 DF 48 56 56 ED FD 4D BA 8E F9 9A BE 00 00 2F 5E 79 A8 9C 56 BC 76 53 3F F8 F5 95 BE 97 57 95 93 E6 F0 AC D8 F1 11 45 C3 94 57 69 0B F3 68 30 EF 13 23 3C B9 50 7A AA 8A 16 74 59 E3 8E F1 F2 70 DA ED 3A F7 00 87 AA 81 93 4C 3F 1E 4F 2D B8 F1 EF A4 0E 6A E5 1A 0F 81 41 EF 79 C0 C6 B4 14 CB 81 5D B2 90 10 54 9E ED 05 00 06 AF 16 AD 74 49 3B A8 D0 3E B3 C0 68 3F 18 A7 77 15 68 F3 79 EC D5 8E 10 AD 8E 80 E8 1A 7D 0C B2 97 A3 52 5F DF AD 28 81 68 34 50 6C 16 18 01 08 1A 95 FF 15 06 93 3E 91 92 AE 2E 7B CA C9 C7 78 6F 69 9F D1 E1 58 32 9C 66 A1 BA F7 25 E3 8E 8F 70 80 8A 25 70 CC 1F 8D 1E D4 E2 91 6F 36 22 07 A7 E8 D5 16 D2 30 A3 82 6A 34 6B 86 FB A5 FE 6E 9B 96 FF EC 9A 5C B6 4B 18 57 4B 7C 36 BC 40 A6 17 F4 EE 39 F6 D1 86 FE C2 4F 51 DC 79 5B E3 1A C4 3E D1 7C 42 73 9A D2 D9 A6 BE 58 E1 BF FF 30 1B AE B2 BD B0 07 AA C2 E5 7D AF 6C FF A7 78 80 C6 5B 68 CD E3 A8 EF 03 7C 01 A7 A1 1A B1 D2 5C 98 20 E1 8D D5 E8 4E CD C2 DB AF 33 BF BF 79 C2 00 E3 E4 E2 0A D5 43 EF 35 8F 1D 07 6F D4 16 3E C9 5E 63 FE 74 7D 94 84 B0 58 79 08 E4 7D C2 80 0F AC 91 F8 58 27 6D A4 BD 83 4D 2B B4 7C B6 FF DA 74 D2 34 0B E4 8E DC 65 73 CE 7C 0E 25 58 2B 95 5B 08 40 27 D1 C2 22 67 32 59 27 98 0D 43 5A 15 0F FE 9C EC 8C E4 4E 9E B1 39 0F 67 54 3B B4 DF 3F 27 75 52 07 43 6A 27 3C 2C 4B 07 EC FE E5 ED 52 26 0D CF 29 06 75 16 91 96 63 09 B5 24 DC 8D 83 5E 08 42 82 48 1B 64 6B 55 46 35 0F 18 D6 85 87 4B CE 66 9E 8A 46 70 EF F3 18 E0 58 8C AD CE CF C6 BD F3 6F BE C5 F9 FB 63 B9 A4 34 6E 79 35 17 56 28 72 15 5D 93 57 C6 18 BA AE 31 CA 4B 43 C3 3C 73 F5 B1 A5 8B 25 B6 48 91 75 34 DA A0 86 74 BB 8B 9A 0C 00 32 D8 8E F9 EB 24 08 3D A4 1A 0A 54 B4 8A CF 57 82 BE 0D F9 43 0C A7 D0 97 47 50 23 4A FE 00 D9 10 55 EB 2C 79 60 E2 9A 47 47 57 EC EC 3D BB DA 33 73 92 2D DC C7 D6 73 04 42 6B 8D CB EA 15 EF 4D F3 B9 1A 89 3E 55 6E 73 1F 4D 8F 16 D9 FE 6E 88 D2 27 05 C1 B1 DE 6E DC 1A 95 B3 76 66 20 F4 DF A4 08 78 E0 4C D7 44 42 5A DE E9 63 AE 43 E5 E9 C2 CB 79 FA 5B 28 72 66 A9 29 88 3B 74 27 02 78 EC 53 69 AE 3D E6 66 F6 7F B4 43 A8 B8 BE 32 AE 6D E6 C2 FA 9C 9D 43 E2 A4 7F 22 6E 5C 6A 55 77 A4 C5 DB 5C D5 21 AD 54 F2 9B C6 C7 46 97 03 11 07 D3 3B 59 62 E8 7E 5C 92 DB A5 ED F2 CA 15 76 37 D2 E5 04 69 D5 18 27 39 3A 2C 61 55 22 F6 86 AD 28 70 48 DA ED 15 A6 9B 24 0D BA 35 31 54 55 7B 95 6A CB 60 E3 13 09 DA 8A 68 9D 96 52 AD A1 50 7B 43 06 A9 DE 62 85 88 C7 69 5F 42 3E CC D1 E6 CA 06 D1 AC 62 4D 96 41 97 29 B1 90 F8 D1 2A 70 74 DC E4 37 E8 14 CA 4F 12 3F 75 83 7D 23 48 30
I think this'll be somewhat out of SO's league. We're programmers, not cryptographers. With an unknown encryption, and unknown compression, you might as well give up. Even if it's something standard like AES or 3-DES, the odds of being able to recover a key that would decrypt into something legible are basically 0.
Even if it's something simplistic like XOR, the odds of finding the key string are low without any hint as to what the plaintext is. Was it encrypted with a single-byte? two bytes? 50 kilobyte? Perhaps it was a one-time-pad, in which case it's essentially impossible to decrypt without the original pad.
Any good crypto program isn't going to leave any plaintext or almost-plaintext signatures in the file to be spotted - that just gives a crack for a cryptographer to wedge their tools into and start prying.
According to the internets this is a (console) patch file.
Check this link for details (found via Google)
There also seems to be viewer available:
FFViewer