Diskussionen über interessante Themen

ChockoCookie

Sgt. Nukem schrieb:

Da lachen die doch drüber...!

Wenn du es sagst
Hab noch nie versucht ein Programm zu cracken. Aber normalerweise denk ich, gehn cracker davon aus, das es eine Routine in einer Datei gibt. Und wenn das Programm abschmiert, denken sie vielleicht, ihre byteschubserei hätte einen Bug verursacht und verwerfen den ansatz.

Kane

Cracker leben, denken und atmen in Assembler!

Da muß man schon mehr auffahren. Einen binary encrypter z.b.
Dann sollte man durch Timings prüfen ob die Anwendung gedebuggt oder in
ner Sandbox ausgeführt wird.

Eigentlich kann man es Crackern nicht unmöglich machen an den Source zukommen.
Ist die binary zu gut verschlüsselt, starten sie das Programm in Win98 oder ME
und suchen in den Memorydumps vom Prozess nach dem unverschlüsselten Code.

Aber kommen wir jetzt nicht vom Thema ab

ChockoCookie

Selbstverständlich kann man sein Programm nicht auf Dauer schützen, aber man kann den Crack zumindest verzöger und es Skriptkiddies schwer machen. Natürlich ist das mit den DLLs wertlos, wenn man sonst nichts unternimmt, vor allem weil gute Cracker schlauer sind als viele Programmierer. Es geht nur darum, etwas zu machen, womit niemand rechnet.

Aber na gut, genug OT. Noch was interessantes über Skriptsprachen?

otze

Skriptkiddies

du hälst cracker wirklich für scriptkiddies?

ChockoCookie

falsch gelesen. Ich meinte es gibt cracker, die was draufhaben und welche die es nicht draufhaben. Ok, es ist vielleicht auch nicht ganz einfach, aber wenn man zB aus einer DLL eine Funktion IsValidSerial aufruft, macht mans crackern schon einfach. Aber sobald man etwas auf "binärsicherheit" achtet, trennt sich die Spreu vom Weizen.

otze

dann machts wohl heutzutage fast jeder den crackern "zu einfach".
wenn ich dran denke, dass man von vielen spielen und anderer software schon beim release einen funktionierenden cd-key generator, oder no-cd cracks,oder gar emulatoren für den typ von kopierschutz bekommen kann.

ChockoCookie

stimmt, gibt aber auch ausnahmen, zB Cool Edit, dafür gibts zwar auch cracks, aber die funzen (sehr oft) nicht. naja, les mal die Seite, zu der ich den Link oben gepostet hab.

Kane

Idee !

Wie wärs wenn man auf der CD-Rom eine Datei "noise.png" speichert?
Die Bilddaten werden vom Programm als Code interpretiert und führen irgendwelchen crackrelevanten Code aus. (Geht, googlet mal nach TinyC Compiler)
Der Vorteil:
Man muß immer eine CD haben (No-CD Fix unmöglich)
Code ist nicht in einer Datei in der man es vermuten würde.
CD-ROM ist read-only, d.h. der Cracker müßte für jeden "Versuch"
bei der er etwas in dem Code-Bild geändert hat ne neue CD-Rom brennen.
Ich vermute mal das Code eine realistische Noise gibt (Wär mal interessant, wie Word oder so als Bild aussehen :))
Wer vermutet Code in einem Bild?!
Einfach das Bild in den Speicher laden, DataPointer zu einem Funktionspointer
casten und callen.

Schwachpunkt ist hier sicherlich der Funktioncall, aber der Kontext in dem man
ihn tätigt ist auf den ersten Blick für den Cracker völlig uninteressant.
Oder würdet ihr einen Kopierschutz in res::server::LoadBasicTextures() erwarten?

Btw, das Thema gefällt mir, können wir das zwischen schieben?

ChockoCookie

Wieso wär da ein No CD Fix unmöglich? Was hindert den Cracker daran, das einfach in ein Verzeichnis zu werfen?
Darf man unter Windows Daten einfach als Code ausführen? Das wär ja ne Art DLL lite .
Wär sicher interessant, das zu machen. Das erwartet sicher niemand.

TGGC

Wie kann man so naiv sein und denken, indem man Daten in Dateien mit anderen Endungen steckt, wären sie vor Crackern sicher...

Bye, TGGC \-/

ChockoCookie

Hat ja niemand gesagt. Nur schwerer zu finden, weil unerwartet. Ausserdem: wenn jemand die .jpg Dateien bei seinem Spiel in .bar umbenennt, ist das wirklich Unfug, weil das Dateiformat gleichbleibt. Aber wenn man Code in Bildateien versteckt, ist das nicht so offensichtlich. Vor allem, weil der Standard ja vorschreibt, das es dafür DLLs (oder .so) gibt. Und wenn man nicht grade so dumm ist, aus diesem Code heraus ein Message Box oä. zu erzeugen, sondern nur unauffällig eine globale Variable setzt, .... usw., dann dürfte das für ne Weile unentdeckt bleiben. Dann hat man zwar wieder das Problem, das der Cracker einfach die Variable umsetzen kann, aber das Prinzip ist klar. Ich glaube, wenn man einen gewissen Schutz vor Crackern will, ist das Verletzen von Standards unumgänglich.

Kane

@TGGC: Ich benne keine Dateiendungen um.
noise.png ist ein normales Bild wie jedes andere auch, nur die Pixeldaten
lassen sich als ausführbaren Coden "interpretieren".
Deshalb hab ich sie auch "noise" genannt, ich glaube nicht dass der Source ein
assozierbares Muster ergibt.

Edit: ich -> nicht

Kane

Ich hab das mal schnell zusammen gehackt:

#include <iostream>
#include <string>
#include <fstream>
#include <IL/il.h>// -lIL
using namespace std;

typedef const string cstring;
typedef unsigned char uchar;
typedef unsigned int uint;

uint GetFunctionLength(const void* ptr)
{
	const uchar* p = (const uchar*)ptr;

	if((*p) != 0x55)
		return 0;//kein pointer auf eine funktion!

	uint size = 1;

	for(; (*p) != 0xC3; ++p)
		size++;

	return size;
}

void WriteFunction(cstring& filename, void* ptr)
{
	if(uint length = GetFunctionLength(ptr))
	{
		ofstream out(filename.c_str(),ios::binary);
		out.write((char*)ptr,length);
	}
}

float VectorPunktProdukt(float v1[3], float v2[3])
{
	return v1[0]*v2[0] + v1[1]*v2[1] + v1[2]*v2[2];
}

int main(void)
{
	if(ilGetInteger(IL_VERSION_NUM) < IL_VERSION)
		return 0;

	ilInit();
	ilEnable(IL_FILE_OVERWRITE);
	ilEnable(IL_ORIGIN_SET);
	ilOriginFunc(IL_ORIGIN_LOWER_LEFT);

	uint id = 0;
	ilGenImages(1,&id);
	ilBindImage(id);

	ilTexImage(GetFunctionLength((void*)VectorPunktProdukt),
						1,//height
						1,//depth
						1,//bpp
						IL_LUMINANCE,
						IL_UNSIGNED_BYTE,
						(void*)&VectorPunktProdukt);

	ilSave(IL_PNG, "noise.png");

	ilDeleteImages(1,&id);
	ilShutDown();
	return 0;
}

Compiled auf dem gcc ohne Warnings. Wenn ihr es selber compilen wollt
brauche ihr noch DevIl aka OpenIL (openil.sourceforge.net)
Hier ist die noise.png (www.codecreator.net/noise.png),
so wie's aussieht kann man ne Menge Source als Bild speichern.
Macht nur nicht den Fehler und versucht auch Dinge zu verweisen
die im Hauptprogramm deklariert wurden (Strings z.B)

TGGC

Schon klar...

Bye, TGGC \-/

Kane

Hatte auch nicht bezweifelt dass du damit Probleme hast.

*sry* aber der mußte sein :p

SirLant

Ich bin mir sicher, dass ein Cracker das genauso schnell wie nen anderer Schutz
ausgehebelt hat, weil er ziemlich schnell beim debuggen sehen wird, dass du
diese Datei öffnest und die Daten darin als Code weiterverwendest und nicht als
Bilddaten.

Er braucht doch gar keine CD, wofür gibts virtuelle Laufwerke?

TGGC

@Kane:
Du bist ja so schlau!

Aber du hast den Schutz vergessen. Warum sollte das mit einer kopierten noise.png nicht klappen?

Bye, TGGC \-/

Kane

Aber du hast den Schutz vergessen. Warum sollte das mit einer kopierten noise.png nicht klappen?

Der Schutz ist das Ungewöhnliche. Wie oft hast du schon Source in einem Bild
gesehen? (Von dem Bsp. hier mal abgesehen...)
Außerdem kann man den Source ja auf mehrere Bilder verteilen (jedes Bild hat nur
ein paar relevante Bits die so beim Betrachten nicht auffallen)

Außerdem der Cracker wird nach Funktionen wie "CheckCopyProtection" und Strings
wie "Please insert the correct CD-Rom" suchen. Ich kenne keinen No-CDFix
der außer der Dll oder der Exe etwas anderes verändert.

Letztlich kannst du natürlich nichts komplett schützen, aber von Standardlösungen (if Abfragen in der Exe z.B.) sollte man absehen.
Für die meisten kommerziellen Protections haben Gruppen wie DEViANCE eh
schon automatische(!) Crackingprogramme.

TGGC

Kane schrieb:

Aber du hast den Schutz vergessen. Warum sollte das mit einer kopierten noise.png nicht klappen?

Der Schutz ist das Ungewöhnliche.

Wo bitte ist der Schutz? Eine stinknormalen Kopie aller Datei und es läuft.

Bye, TGGC \-/

Kane

Ich wollte damit eingentlich den Source schützen der nacher die CD auf Echtheit prüft.
Er soll einfach nicht in einer Dll oder Exe wie auf dem Präsentierteller rumliegen. Was man nicht findet kann man auch net cracken.

Btw, echter Source und Daten (Variablen etc, also auch das Bild)
liegen in anderen Speicherbereichen was die Sache imho noch etwas schwieriger macht.

@TGGC: Was würdest du den favourisieren?