16
XOR encryption with a short pad (i.e., shorter than the plaintext) is basically the Vigenère cipher. So standard techniques to break Vigenère should break xor encryption.
The basic idea is that if the encryption key is d symbols long, every d-th symbol is encrypted with the same pad. Thus, take every d-th ciphertext symbol and treat it like simple ...
13
I'd say it's a very useful tool to have in the arsenal, but your use of it will depend upon your ultimate goals. Personally, I use it a fair bit on binary application assessments, but that's not the case for everyone. As I said, it largely depends on what you want to be doing.
At the end of the day, you will see cryptography being used in applications if ...
13
In case of multibyte XOR frequency analysis is the way to go.
As is commonly known, most frequent character in regular English text is E (etaoinshrdlu being the top 12) but in some cases space (0x20 in ascii) can be more frequent, especially in shorter messages.
For executable code on the other hand, tho I can't find a reference, most frequent characters ...
10
There are three main contributions of the research
A proposed indistinguishability obfuscation for NC1 circuits where the security is based on the so called Multilinear Jigsaw Puzzles (a simplified variant of multilinear maps).
Pair the contribution in 1 with Fully Homomorphic Encryption and you get indistinguishability obfuscation for all circuits.
Combine ...
8
00040000 looks like a 32 bit value representing the length of the data.
If we decode it in little-endian we get 1024:
sage: int.from_bytes(bytes.fromhex('00040000'), 'little')
1024
I'm assuming this gives the number of bits that follow; the next 1024 bits (n) are:
...
7
Just to add to the list. SANS posted a blog about a week ago on different tools for XOR encryption. The list is very good and it provides several tools, all which are good in my opinion.
Here is the link : SANS Blog on XOR tools
7
It is more and more important for practical reverse-engineering. It is now present in malware, the example of Stuxnet, Flame and others are quite typical of the usage of cryptography in such context. And, it is also present in most protection schemes because a lot of techniques use cryptography to protect the code and data. Just consider software such as ...
6
This is quite likely either a botched RIPEMD128 or something very similar, as otus also commented.
You wanted to know how to approach such a task so I'll explain what I did.
Typically, when trying to identify crypto-related code you rely on spotting constants. In this case, the constants seem to be obfuscated on purpose, so you need to play around with the ...
6
Like others I would recommend trying to get the assembly code that computes the checksum. If you obtain that the rest is easy.
However sometimes that can be very hard to obtain, so here are some tips on reverse-engineering checksums without any code.
Remember that a checksum algorithm is a design choice made by engineers, so think about the constraints and ...
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
The best way to locate AES in a binary blob would be to locate first the AES S-box. It is specifically designed for AES and recommended by the NIST, so a standard AES must include it. Moreover, they are quite unique and easily found through a simple pattern recognition. Here is the value of such S-box:
unsigned char s[256] =
{
0x63, 0x7C, 0x77, 0x7B, ...
4
This is quite hard question to answer due to variables within reverse engineering.
I would recommend you start off with:
Start game
Get some coins or whatever is saved then save the game.
Restart the game and get more coins and save the game.
Replace the new save with your old file.
Does it load? See Answer 1. Otherwise, Answer 2.
Answer 1
Your modified ...
4
Good news, You're lucky!
What you're facing in front of you is a stream cipher. Why is that good? because the way stream ciphers are built makes them extremely easy to reverse - the decryption and encryption functions of stream ciphers are actually the same function.
A stream cipher is a symmetric key cipher where plaintext digits are combined with a ...
4
Here are some thoughts on the fundamental problem and a possible solution; even if the full system goes way beyond your dev budget, some key ideas might still be useful for fashioning your own solution.
Crypto is of little use if you don't have the leverage that makes the crypto algorithm itself the weakest link in the system, just like a ten-inch steel ...
4
Well, the equation is pretty simple, you say that the hashing is done through the following formula:
v5 = serial[6] + serial[0] - serial[7] - serial[2];
LOBYTE(v5) = serial[1];
v8 = serial[3] + v5 - serial[4];
if ( v8 != serial[5] )
goto FAIL;
We can use an SMT-solver, such as Z3 to find out a possible key for these equations:
$> python
Python 2.7....
3
expanding a bit on the answer by perror and my initial hypothesis
the result for the provided input string "abcdefgh" would result in "b+d-e = f"
providing constraints for input string z3 indeed returns back
the char "a" as the first possible model() here is a slightly modified
python script posted by perror in his answer
:\>cat z3t.py
from z3 ...
3
Try IDAsignsrch, or the original commandline version.
3
An RSA public key consists of two things: the modulus m (a product of two large primes p and q) and the public exponent e (a small and often fixed number, commonly 3 or 65537).
An RSA private key consists of the same modulus m as in the public key and the private exponent d, a number chosen such that xed ≡ x (mod m). Typically, d will be about the ...
3
It's base64. One entry per line. Entries look like they're padded to 0x10. So after base64 decoding the data is probably encrypted by a block cipher with 128-bit block size. Maybe AES. At this stage you probably need to analyze the executable in order to get the plaintext back.
3
The first two lines suggest a string containing all hexadecimal digits, first line lower case, second line upper case. If this assumption holds, then the two lines read
0123456789abcdef
0123456789ABCDEF
The construction principle then would be:
Take four characters, arrange them in reversed order, go to the next four characters etc.
Doing this with the ...
2
Just as an example, consider the source code for AES at https://polarssl.org/aes-source-code. This has various tables, one of which is the Forward S-Box, FSb - which should be the same in all AES implementations. So, a signature checker like signsrch will say "AES" if it finds the fsb table, but it doesn't know which AES implemenation is used.
Now, the FSb ...
2
It doesn't seem to be on the IDA snapshot. You probably identified the right part of the program flow to set the initial key array. and assumed that the left part should have something to do with the iv, but that's not true. iv is 16 bytes, the left part of the IDA disassembly defines 24 bytes, which is the same length as key. Also, the very top of the image ...
2
Do you have any more information, especially, one or two examples for buEncryptKey? Is that a prime number?
The reason i'm asking is: your hash_func is a modulo function, it calculates (serial*running_value) % encrypt_key. This makes key1 = serial^2%encrypt_key and key2 = serial*(serial^2%encrypt_key)%encrypt_key = serial^3 % encrypt_key. And polynomials ...
2
See http://2012.ruxconbreakpoint.com/assets/Uploads/bpx/alex-breakpoint2012.pdf:
So the signing level is embedded in the signed image's (file's) certificate. There are no special flags passed to CreateProcess(), but PspCreateProcess() (a kernel function that's executed as a result of CreateProcess()) extracts and validates the signing level from the ...
2
The crypto definitely isn't a "good" one. Check what happens in your nextDecrypt function.
The nextDecrypt function
There's a variable at ebx+0x200 which gets loaded into edx. This variable gets incremented by one, then written back to ebx+0x200, and this variable is also used to be xored with some byte (low byte of ecx, i.e. cl) before that byte is ...
2
MED17 functional description docs will help with overview of the EEP handler, but not the checksum routine.
Usually it is best to go through the front door with coding tools rather than try to change EEPROM (actually dataflash on most Tricore) directly.
Given time I could probably locate the checksum routines and reverse them, but it is not a small job and ...
2
When it comes to break some encrypted texts, you have to take a few hypothesis and check it with caution (it may make you loose a lot of time... believe me).
The first Base64 decoding seems to be quite promising and lead to some hexadecimal blob that you should analyze first before trying to step further.
I would advise you to make a frequency analysis of ...
2
From my limited cryptographical knowledge and a quick Google search to confirm it, no.
This would be a known-plaintext attack and AES is engineered to be resistant to it.
1
If you have the binary file, for sure you can debug it. I suggest you to use gdb for debug it.
$ gdb your_program
(gdb) b main
(gdb) r
I suggest you to insert some breakpoint in the fuctions that you want to analyze, and then follow them (nexti/stepi)
You could try also to use strace/ltrace to understend better the context
Look at this link http://www....
Only top voted, non community-wiki answers of a minimum length are eligible
