15

If you have access to the binary while it is running, it is entirely possible to extract the keys you need to decrypt the SSL/TLS session even with perfect forward secrecy. There is a 48-byte secret, called the master secret, which is shared by both sides and used to generate the session keys for the connection. If the application uses the standard Win32 ...


15

When you download an app from the App Store, Apple injects a special 4196 byte long header into the signed binary encrypted with the public key associated with your iTunes account. This public/private key pair is generated when you create your iTunes Account, and transferred to your iOS device when you log in with your iTunes account or Apple ID. This is ...


13

I wrote a small Python script to deobfuscate the majority of the string obfuscation: import urllib import re php = urllib.urlopen("http://pastebin.com/raw.php?i=wVs8w44v").read() # Slight modification below so that we don't escape $ z26 = "jmiO@sxhFnD>J\r/u+RcHz3}g\nd{^8 ?eVwl_T\\\t|N5q)LobU]40!p%,rC-97k<'y=W:P$1BI&S6\"E(K`Y~.Q;f[v2a#X*ZAGtM" # ...


11

Got it. Here's how to calculate, using your first string as a simple example: 1f456e01 First, we rearrange the packet, omitting the checksum. 1f 01 Then prepend the values A3 02: a3 02 1f 01 Then calculate the checksum by starting with a sum of 0, multiplying the sum by 33 (decimal) each time and adding the value of the next byte. Here it is in C ...


11

One other thing that you could do, which is perhaps overkill but is useful in other scenarios, is to intercept the creation of the 48-byte TLS master secret. For many Windows applications (including IE), this happens in lsass.exe in the following function (taken from Win7 SP1 32-bit): Caller: ncrypt!_Tls1ComputeMasterKey@32+0x57 EIP: ncrypt!_PRF@40+...


11

It's a big-endian CRC16 (polynomial 0x8005) of the data from the byte following the 0x82 up to and including the byte before the CRC. For example, for your last RX frame: 82 00 00 00 ff 00 00 00 01 01 4c 4f 0c 6a 83 The CRC16 of {0x00,0x00,0x00,0xff,0x00,0x00,0x00,0x01,0x01,0x4c,0x4f} is 0x0c6a. To find out this CRC algorithm, I assumed that 0x82 was a '...


11

TL;DR: What we have here is probably not an encryption algorithm, it is more likely a decompression loop, by the look of it. It simply does not do anything that could be considered even remotely similar to encryption. Encryption algorithms are divided into two classes. First is a stream cipher. From wikipedia: A stream cipher is a symmetric key cipher ...


10

If the data is being passed as HTTPS you could try the classic Fiddler man-in-the-middle approach. I'm not sure whether the Windows store respects the proxy settings or whether it has a pinned certificate. If it does respect the proxy settings, which it should, and it doesn't have a pinned certificate you should be able to trivially man-in-the-middle it with ...


10

Currently you can't decrypt iOS apps without a device. The encryption keys are ultimately protected by an unknown key which is burned into the processor and cannot be extracted using software, that's why no "offline" decryption app has been made.


9

To create a full duplicate, able to generate valid transmission packets you'll need the following information: Serial Number Button press mapping 32 bit of KeeLoq encrypted data See attached Figure 1-2, from the datasheet, near "Transmitted information" at the bottom right: Using those three pieces of information you can theoretically create your own ...


8

You can try to use binwalk. It can be used in various ways: Embedded file identification and extraction Executable code identification Entropy analysis and graphing (useful for compression and encryption identification) "Smart" strings analysis You could also try to open your file with 7zip, since it supports a shitload of compression formats.


8

Finding: NGA_FW_CURRENT.BIN is a compressed Videx microchip firmware image file. Preliminary Remarks There is conflicting background information given in the comments about the file alleged to be firmware in the question. A gzip compressed data file called authorizer.tar.gz located at https://70.60.240.178:8443/CyberAuditWeb/services/nga/download/ under ...


7

I'd assume the first byte is a message type ID, the 2nd and 3rd bytes are checksum, and the rest is payload. As the game is probably an i386 game, the payload ought to be little-endian. Now, if we compare your first 4 examples, with bytes 2 and 3 written as a 16-bit-int, we have: 1f 6e45 01 1f 6e46 02 1f 6e49 05 1f 6e4b 07 1f 6e4c 08 in these cases the ...


7

You can give a try to binwalk. This tool is able to do a wild guess about the encryption/compression routine used, with the -BE option.


7

The blob file is compressed with zlib, so you have to decompress it first. The first 4 bytes of the blob is the decompressed size and the compressed content start at 6th byte. After the decompression you got binary file starting with 0xDEADBEAF (in big-endian, marked as yellow in the figure). After it you can find some header parameters, one of the 0x22 (...


6

Properly implemented SSL traffic has a property of forward secrecy. Which means that you can't decrypt it even if you have the whole packet dump and required private keys. As Brendan Dolan-Gavitt points out in his answer, you need access to the binary while it's running to do that. What you can try to do is set up SSL mitm using something like ettercap. ...


6

The checksum is very simple, as can be seen from the minimal difference in checksum between 11111111111111111111111111111 and 11111111111111111111111111112, the difference is 0x21 (33 in decimal). Then, difference between 11111111111111111111111111121 and 11111111111111111111111111111 is 0x441, that is 0x21^2. The checksum (I'll call it y) is clearly a ...


6

This seems to be a checksum, just as you state in your question, not a CRC as mentioned in the header. Group the values into blocks of 4 bits, add them, ignore overflow (in these examples, ignore overflow means subtract 32): 1000 1000 0000 1000 0100 0101 0001 8+8+0+8+4+5=33 1 1000 1000 0000 1000 0101 0101 0010 8+8+0+8+5+5=34 2 1000 1000 0000 1000 0110 ...


6

There are two noteworthy communities dedicated to reversing file formats with video games: XeNTaX and ZenHAX Both of them have their own respective applications used for creating scripts that unpack files (and sometimes, repack). Those programs are MultiEx (from XeNTaX) and QuickBMS (from ZenHAX). There are tutorial sections on each site where you can learn ...


6

The file does not appear to be obfuscated or encrypted in any way. The header appears to be trivial. I have included a description of the header for the .zdata you posted. The .unity3d files contained within are the typical Unit3d webpack files. You can google around for a depacker for those, there are several.


6

I have been wondering, if every program is based on machine code, can we not decompile a program until it hits machine code and make it up to real programming languages? This question is based on a false premise; namely that every program is based on machine code. Programs are typically written in high-level languages, which are by design architecture ...


5

You can always feed the original binary to IDA and use the plugin Findcrypt2 to identify the algorithms used. Other than this the Kanal plugin for PeiD can also detect cryptography used. Another tool for the same task is Hash & Crypto Detector


5

SHA256 is a hash. It doesn't have a key. It's a one way transformation function from input a to output b which is irreversible. The best you can do is to try various inputs until you get your output.


5

There are a number of approaches you could take with extracting the local key being used by Windows Store and feeding that into Wireshark, however, I think your best bet is to inject a DLL that hooks the Network IO functions send() and recv() out of your process. You could try to do this on a "low level" yourself, but in the interest of pragmatism you'd ...


5

I would start with checking the first bytes of a file after base64 decoding. Those would indicate what file format is. MZ(5A4D) - meaning this is an executable file and you can start with executing it in save (virtual) environment with SysInternals utilities open - ProcMon and Process explorer. In addition, calculate its MD5 value and look it in the Net, ...


5

Wow to identify firmware format In old days the Intel HEX and bin Flash memory dump was used the firmware was usually copied to device by HW programer for specific IC or by ISP. HEX is very specific Intel_HEX (*.hex) text file easy to identify. Ont he other hand BIN dumps are hard to identify. If you can see any tokens inside or can disassemble it and the ...


5

it seems to be compressed in some way because you can read some plain text there This statement is contradictory. If the binary were compressed or encrypted in its entirety there would not be any readable ASCII strings in a hexdump. Readable ASCII data indicates at the very least that there are regions within the binary that are not compressed or encrypted. ...


4

You could give a shot at dynamic binary visualization. There's an excellent presentation given by Christopher Domas at REcon as well at BlackHat 2013. The deck for REcon is available here. I believe the tool is out now in beta so you could give a try at it.


4

It's a Pseudorandom number generator: it's a simple piece of code that produces values that are hard to predict while not taking too long to compute. Check the Wikipedia article for more informations. edit: the equivalent C code is something like: int random(unsigned int *seed) { int temp1; int temp2; temp1 = (*seed >> 16) + 36969 * (...


4

Just debug the file in IDA itself and take a memory snapshot once the data is decrypted.


Only top voted, non community-wiki answers of a minimum length are eligible