0x41C64E6D

What does this number stands for? I've stumbled upon it during reverse engineering a simple encryption scheme.

quick google search gives PRNG source code. How is encryption related to "random" numbers?

"String encoding utilizes LCG fed by the new PRNG algorithm, while the generated keys are then subtracted from each ciphertext byte to generate the plaintext string. The first DWORD in the encoded string is used as the seed, while that same value is XOR’ed against the second DWORD to calculate the size of the encoded string. The encoded string begins at the position after the second DWORD. Most suspicious strings in the unpacked Vawtrak DLL are encoded using this method"

It's standard in RFC 1149 compliant encryption.

>>4
what is the point of using it?

>>2

How is encryption related to "random" numbers

are you seriously asking?
1. encryption keys should be as random as possible, that's why we have CSPRNGs (cryptographically secure pseudorandom number generators)
2. ciphertext should be indistinguishable from random data
3. the very idea of stream cipher (RC4 is the most popular example but it's not very secure) is based around random number generators: key is used as seed, the RNG output is combined (usually by xoring) with plaintext bit by bit.

>>1
it seems to be a constant used in some (mostly proprietary) RNGs. I don't know why this one, in a good crypto application each constant is one of the standard NUMS (nothing up my sleeve) numbers used to show that the generator is not backdoored throug some obscure mathematical magic. common NUMS are square roots of low numbers (e.g. SHA1 used sqrt(2), sqrt(3), sqrt(5) and sqrt(10)) or well-known constants like pi.

how does your crypto work btw? is it a stream cipher or a block cipher? is it similar to any popular algorithms?

>>6

are you seriously asking?

Yes. I have never encountered any encryption algorithm before, so I wonder why "random" numbers are involved. And the constant 0x41C64E6D is not random if anything, because every second random generator use it. Guess it came from Knuth's book or something.

>>6

how does your crypto work btw? is it a stream cipher or a block cipher? is it similar to any popular algorithms?

It works like following (decrypt_init uses random number fill in the table with 1234567890u being the both the seed and the password)

uint32_t GDecryptPRNG_State;
uint32_t GDecryptMap[256];

uint32_t decrypt_sub(uint32_t *table) {
uint32_t a, b, c;
a = table[0];
table[a] = GDecryptMap[a];
b = table[1];
table[1] = GDecryptMap[b];
c = table[b + 2] ^ table[a + 2];
table[a + 2] = c;
return c;
}

void decrypt_init(uint32_t *table, uint32_t seed) {
int i;
uint32_t *p;
int count;
uint64_t t;
unsigned int a;
uint32_t k;
uint32_t *q;
int b;

for (i = 0; i < 256; i++) GDecryptMap[i] = i+1;

GDecryptPRNG_State = seed;
table[0] = 0;
table[1] = 103;
p = table + 251;
count = 250;
do
{
t = 0x41C64E6DULL * GDecryptPRNG_State;
HIDWORD(t) <<= 16;
t += 0xFFFF00003039ULL;
GDecryptPRNG_State = t;
*p = HIDWORD(t) & 0xFFFF0000 | ((uint32_t)t >> 16);
--p;
--count;
} while ( count );
a = 0xFFFFFFFF;
k = 0x80000000;
q = table + 5;
do {
b = *q;
q += 7;
*(q - 7) = k | a & b;
k >>= 1;
a >>= 1;
} while ( k );
}

int decrypt(uint32_t *data, int datasize) {
signed int result;
uint32_t *p;
uint32_t a, b, c, d, e;
uint32_t table[256];
memset(table, 0, 256*sizeof(uint32_t));

decrypt_init(table, 1234567890u);
if (datasize <= 12) return 0;

p = data + 1;
decrypt_init(table, *data);
e = datasize - 4;
if ( (datasize - 4) / 4 > 0 )
{
a = e / 4;
do
{
b = decrypt_sub(table);
c = *p;
++p;
--a;
*(p - 1) = b ^ c;
}
while ( a );
}
d = e % 4;
if ( d > 0 )
{
do
{
--d;
*(uint8_t*)p ^= decrypt_sub(table);
} while ( d );
}

return 1;
}

The checksum is stupid too, because they do usual sum for even words, but a xor for uneven.
do
{
DWord = *PData;
if ( Count & 1 )
chksum += DWord;
else
chksum ^= DWord;
++Count;
++PData;
}
while ( Count < NumDWord );

what does xor solve? That feel when everyone but myself are retarded and use over-engineered solutions.

>>9
from the wikipedia page for "checksum":

Position-dependent checksums[edit]
The simple checksums described above fail to detect some common errors which affect many bits at once, such as changing the order of data words, or inserting or deleting words with all bits set to zero.

i hate how dumbfucks like you always assume they're a repressed genius when the reality is you're too retarded to click the first result in google.

>>10
Kikepedia is selling snake oil as usual. Non-nigger definition: checkSUM is just a sum of bytes. Also, these edge-cases don't pop up in practice, so it makes sense to use simpler and faster algorithm. KISS principle. Learn to apply it, faggets!

>>8

at a first glance looks like an RC4 variant but then it has bitwse ANDs and ORs which don't belong in RC4. so it's probably a custom stream cipher that apparently has a hardcoded key (the seed and password you mentioned) and no IV. what is it used for, if I may ask? because in most uses, such crypto would be disastrously bad.

>>12
it is used to encrypt plain text config files in a video game. Likely to prevent users from being able to look into them, discovering all game mechanics and cheating without buying the official strategy guide. These config files are also compressed, so encrypting them is surely an overkill.

DWord

That was WINDOWS QUALITY!

>>14
The terminology predates Windows by decades. The "word" was originally a formal term for a byte, but then byte was define to be precisely 8 bits, and words now always 16-bit, due to the x86 influence and large quantity of software depending on these plebish conventions of subhuman degenerates. Still Lisp Machines had 36 bit words.

>>15
Word = 64 bit or 32 bit (on 32-bit systems), idiot.

>>16
NO U

BYTE = 8
WORD = 16
DORD = 32
QORD = 64

>>17
Only nerds use words like "dord" or "qord".

>>13
that's one of the few cases where such an algorithm would make sense. BTW what game is that and how are you REing it (I guess you use IDA but who knows, it's expensive)? reverse engineering games sounds interesting and I've got a bit of experience with RE, although from a different (security) perspective.

>>17
You're a dord.

It's usually DWORD or QWORD

>>21
Check 'em

>>19
The game is Magic & Mayhem. I'm interested in how it stores map files (maps are also encrypted, probably to avoid game magazines publishing nice maps/guides without paying the devs) and draws isometry, without doing expensive 3d sorting. There is no community around it, so made a thread at openxcop forum:
http://openxcom.org/forum/index.php/topic,3932.0.html

I'm using a cracked version of IDA. I have disabled "no-return" analysis, because it led to malloc being determined as never returning and all calls to it turning int procedure ends (you can never be sure that there is enough memory), breaking analysis. IDA also doesn't init tables or vtables, so you have to look for them in data segment and manually convert to function lists, so it will analyze and cross reference them.

>>23

I'm currently working on my own game for Steam: http://steamcommunity.com/sharedfiles/filedetails/?id=514233906

Oh cool, I didn't know that. I'll buy a copy.

>>24
Whom are you quoting?

Can't you read the config files as they are processed by the program while run in a debugger?

>>26
I'm running Wine on top of OSX, so debugger doesn't function properly

>>27
applefags? in my /prog/?

>>28
XNU > Linux

>>28
This is not /g/.

>>30
(you)

Very Secure Curve™
a = 1
n = 5846006549323611672814741753598448348329118574063
Polynomial Basis:
G x = 2 fe13c053 7bbc11ac aa07d793 de4e6d5e 5c94eee8
G y = 2 89070fb0 5d38ff58 321f2e80 0536d538 ccdaa3d9
Normal Basis:
G x = 0 5679b353 caa46825 fea2d371 3ba450da 0c2a4541
G y = 2 35b7c671 00506899 06bac3d9 dec76a83 5591edb2

Randomly generate these dubs