Crypted data

[Ankis59]

Hello, I would like to encrypt data or do something to prevent players to modify their data. I change the sunkist key but there is still that we managed to change their data. Someone would have a solution? Thank you in advance.

[Velmore]

To change the Neuz parameter is useless. with Process Hacker 2 you can see the parameter.

Here you see this.


you can crypt your .res files e.g. with aes or des. Then they can't modify there.

[Wanetrain]

Originally Posted by Velmore

To change the Neuz parameter is useless. with Process Hacker 2 you can see the parameter.

Here you see this.


you can crypt your .res files e.g. with aes or des. Then they can't modify there.

Jo, komm, wir verschlüsseln alle FlyFF Res daten mit AES oder DES, willst net gleich noch bissl mit Twofish und co um dich werfen? bitte, lass es.

Der Effect von AES / DES verschlüsselung: es ist 1 Tag lang unbekannt, dann wird ein Decrypter raus gehauen, zzgl. zieht es enorme zeit beim Laden dass zeug erstmal zu Entschlüsseln damit es die Neuz selbst erstmal lesen kann, also hefe fun noch mit der Idee.

[SandMann016]

DES ist voll der quatsch...
Und nein, eine AES Encryption&Decryption verbraucht keine bemerkbare Zeit zum entschlüsseln auf einem normalem User-PC.
Wenn du dann noch deine Binary(Exe) vor Reversing schützt, ist dein Decryptkey (halbwegs) sicher .

[Wanetrain]

Originally Posted by SandMann016

DES ist voll der quatsch...
Und nein, eine AES Encryption&Decryption verbraucht keine bemerkbare Zeit zum entschlüsseln auf einem normalem User-PC.
Wenn du dann noch deine Binary(Exe) vor Reversing schützt, ist dein Decryptkey (halbwegs) sicher .

Ohje, nächste..

AES ist eine Byte Verschiebung, dass soll verdammt nochmal keine Zeit rauben? Nein, stimmt, hast recht. ._.

[Sedrika]

Originally Posted by Wanetrain

Ohje, nächste..

AES ist eine Byte Verschiebung, dass soll verdammt nochmal keine Zeit rauben? Nein, stimmt, hast recht. ._.

Und ist darauf ausgelegt nicht zeitintensiv zu sein. Mr. IchKannAlles kann sich gehen und sich in der Tonne wälzen.

[Menøx]

Da ich Verschlüsselungen mag, gebe ich mal meinen Senf dazu:

- AES ist bei vielen Prozessoren heutzutage bereits auf hardware ebene möglich, aber auch sonst ist die laufzeit sehr human (ich habe 2 Festplatten mit AES verschlüsselt) bei mir liegt der decrypt speed bei 2,4 gb/s (also wenn man ein Benchmark im ram laufen lässt)

- Ich stimme den Leuten zu, die sagen AES ist eine schlechte wahl Da es sich um einen symmetrischen verschlüsselungsalgorithmus handelt. Besser wäre ein asymetrisches z.B. RSA. Da man zwar einen Decrypter bauen kann aber keinen Encrypter! Nachteil: RSA ist langsamer als AES! Alternative dazu ist, die Files zu signieren um herumpfuschen zu verhindern.

[cletite]

Originally Posted by SandMann016

Ach, du verschiebst natürlich auch Terrabytes an Ressourcen...
Selbst mit einem 2 x 2Ghz Prozessor wirst du kaum eine spürbare Zeit mehr brauchen bei der Entschlüsselung. Und bei einem gutem Prozessor wie meinem braucht man evtl eine MS für den Prozess (8x 4,1GHz)

Doch AES ist unter dieser Masse an Daten sehr langsam. Da bringt es auch nicht viel, __asm{ AES... }zu nutzen. Vorallem weil nichtmal jeder CPU das statement verwenden kann. Auch wenn du das ganze Zeug paralell ballerst bekommste keine ordentliche Performance drauf.

Vielleicht solltest du dir die Arbeitsweise von AES mal ansehen ( http://de.wikipedia.org/wiki/Advanced_Encryption_Standard )

Originally Posted by SandMann016

Nachteil wäre also das man gar keine Files Crypten kann? Auch irgend wie logisch...

Wat?

Originally Posted by SandMann016

Also jegliche asymmetrische Verschlüsselung ist hier vollkommener quatsch.
Asymmetrische Verschlüsselungen sind so gedacht, du hast einen Content, zB Kreditkarteninformationen und möchtest diese in einer Datenbank abspeichern, wobei höchste Sicherheit gefordert ist.

Wat? Willst du uns hiermit sagen dass AES + RSA schwachsinn ist?
Weil Asymmetrisch heist ja, das es keinen zusammenhang zwischen einzelnen bytes gibt ;O?

Originally Posted by SandMann016

Man hat einen Public Key der auch in dem Script steht wo die Verschlüsselung stattfindet, dies kann auch im Client zB in JavaScript sein. Der Key ist kein Geheimnis...
Wenn du diese Informationen wieder Entschlüsseln möchtest, brauchst du den Privat Key, der Key wird nur zur Entschlüsselung benutzt und kein anderer Key passt hier.
Den Key zu knacken ist mit bisherigen Mitteln unmöglich.
(Das ganze wende ich täglich an, bei der Speicherung von PSC Codes, und der Backup Speicherung von Serialkeys, falls ein Unbefugter Zugriff zur Datenbank hat (was durchaus oft vorkommt) Sind die Sensiblen Daten geschützt.)

Jetzt ist es fraglich wie du das ganze umdrehen möchtest, da der Client doch die Ressourcen lesen soll, dabei ist es ganz egal ob Symmetrisch oder Asymmetrisch verschlüsselt, an einer Stelle wird der Key/Privatkey durchgegeben und an der Stelle kann man sich einklinken und die Daten auslesen oder direkt den Key auslesen...

Bin mal auf eine Antwort gespannt.

Warum ist den ein RSA key Austausch hier schwachsinnig?


Und das mit dem Auslesen würde ich hier nicht anprangern. Ich schätze mal dass ich hier der einzige bin, der an Themida vorbei kommt. Geschweigedenn die Anwendung zu analysieren.

Originally Posted by Sedrika

Und ist darauf ausgelegt nicht zeitintensiv zu sein. Mr. IchKannAlles kann sich gehen und sich in der Tonne wälzen.

Ok danke dir. Ich erkläre mal den Entschlüsslungsprozess für dich. (Ohne Initialize. Findest du bei http://de.wikipedia.org/wiki/Advanced_Encryption_Standard unter Arbeitsweise )

#define QUARTER_ROUND(L, T, t, a, b, c, d)	\
	a ^= L(T, 3, byte(t)); t >>= 8;\
	b ^= L(T, 2, byte(t)); t >>= 8;\
	c ^= L(T, 1, byte(t)); t >>= 8;\
	d ^= L(T, 0, t);
#define QUARTER_ROUND_D(t, a, b, c, d)		QUARTER_ROUND(TL_M, Td, t, a, b, c, d)

void Rijndael::Dec::ProcessAndXorBlock(const byte *inBlock, const byte *xorBlock, byte *outBlock) const
{
	typedef BlockGetAndPut<word32, NativeByteOrder> Block;

	word32 s0, s1, s2, s3, t0, t1, t2, t3;
	Block::Get(inBlock)(s0)(s1)(s2)(s3);

	const word32 *rk = m_key;
	s0 ^= rk[0];
	s1 ^= rk[1];
	s2 ^= rk[2];
	s3 ^= rk[3];
	t0 = rk[4];
	t1 = rk[5];
	t2 = rk[6];
	t3 = rk[7];
	rk += 8;

	const int cacheLineSize = GetCacheLineSize();
	unsigned int i;
	word32 u = 0;

	for (i=0; i<1024; i+=cacheLineSize)
		u &= *(const word32 *)(((const byte *)Td)+i);

	u &= Td[255];
	s0 |= u; s1 |= u; s2 |= u; s3 |= u;

	QUARTER_ROUND_FD(s3, t2, t1, t0, t3)
	QUARTER_ROUND_FD(s2, t1, t0, t3, t2)
	QUARTER_ROUND_FD(s1, t0, t3, t2, t1)
	QUARTER_ROUND_FD(s0, t3, t2, t1, t0)

	// Nr - 2 full rounds:
    unsigned int r = m_rounds/2 - 1;
    do
	{
		s0 = rk[0]; s1 = rk[1]; s2 = rk[2]; s3 = rk[3];

		QUARTER_ROUND_D(t3, s2, s1, s0, s3)
		QUARTER_ROUND_D(t2, s1, s0, s3, s2)
		QUARTER_ROUND_D(t1, s0, s3, s2, s1)
		QUARTER_ROUND_D(t0, s3, s2, s1, s0)

		t0 = rk[4]; t1 = rk[5]; t2 = rk[6]; t3 = rk[7];

		QUARTER_ROUND_D(s3, t2, t1, t0, t3)
		QUARTER_ROUND_D(s2, t1, t0, t3, t2)
		QUARTER_ROUND_D(s1, t0, t3, t2, t1)
		QUARTER_ROUND_D(s0, t3, t2, t1, t0)

        rk += 8;
    } while (--r);

	word32 tbw[4];
	byte *const tempBlock = (byte *)tbw;

	QUARTER_ROUND_LD(t2, 7, 2, 13, 8)
	QUARTER_ROUND_LD(t1, 3, 14, 9, 4)
	QUARTER_ROUND_LD(t0, 15, 10, 5, 0)
	QUARTER_ROUND_LD(t3, 11, 6, 1, 12)

	Block::Put(xorBlock, outBlock)(tbw[0]^rk[0])(tbw[1]^rk[1])(tbw[2]^rk[2])(tbw[3]^rk[3]);
}

Evtl siehst du nun das hinter AES eine etwas "größere" Schleife steckt.
Aber machen wir ein kleines Gedanken experiment.

Der Ancient Flyff-Client hatte eine Startzeit von ~10 sek.

Dieser hatte lediglich die standart ROL 2 verschlüsslung.

Nun denkst du ernsthaft das AES, welches alleine PRO byte 8 * 4 shifts hat, die ladezeit nicht beeinträchtigt?


Und Sedrika, sei nicht traurig. Es gibt einfach Menschen die sachen besser können als du

Lg Clemi