[Help]Find/Decrypt Encryption

[PenGuin :O]

Ich will mich eig. gar nicht gegen Smith stellen, aber ich weiß auch, dass mov und xor beide nur 1 Takt benötigen jedoch xor nur ein 4 bit Opcode und mov ein 8bit opcode hat.
Außerdem kommt es bei der Geschwindigkeit sowieso nur auf den gesamte Befehlskette ankommt, da moderne Prozessoren Befehls-Pipelines selbstständig verwalten und versuchen Konflikte aufzulösen und Sprünge schätzen.
Hinzu kommt auch noch, dass in einer Schleife öfters Stalls vorkommen, sodass die Zeit sowieso egal ist. Und der Prozessor muss sowieso Wartetakte einbauen...

Aber ich will Smith mal sehen, wie du Takte zählst.
Wenn du ne Schleife machst und am Zählen bist, wird fleißig interuptet :P

Also ist Zeit eher nebensächlich. Hauptargument sind 4 bit opcode, wo bei der compiler sowieso aus einem xor wieder ein mov macht :P

Letztendlich können uns diese Frage nur Compilerbauer beantworten

€: Hat unser Informatikuntericht doch was gebracht^^

[Lazeboy]

Originally Posted by MrSm!th

und warum soll das nun nicht per CE gehen?

btw. es ist keine XOR verschlüsselung.
wenn du eine verschlüsselung reversen willst, solltest du erstmal asm können.

könntest du asm, wüsstest du, dass xor eax, eax eax auf 0 setzt.
wenn dort mal xor vorkommt, dann immer nur in der form xor register, gleiches_register, ergo register = 0 (es ist schneller und braucht weniger platz als mov eax, 0)


wenn ich mir den code und deine kommentare so ansehe, deutet da gar nichts auf eine verschlüsselung hin, sondern auf irgendwelche operationen mit dem namen der datei o.o

ich habe das mit der xor gesagt, weil mir das jmd gesagt hat. Ich finde aber anscheinend nichtmal die richtige stelle lol

[Akorn]

Originally Posted by PenGuin :O

Ich will mich eig. gar nicht gegen Smith stellen, aber ich weiß auch, dass mov und xor beide nur 1 Takt benötigen jedoch xor nur ein 4 bit Opcode und mov ein 8bit opcode hat.
Außerdem kommt es bei der Geschwindigkeit sowieso nur auf den gesamte Befehlskette ankommt, da moderne Prozessoren Befehls-Pipelines selbstständig verwalten und versuchen Konflikte aufzulösen und Sprünge schätzen.
Hinzu kommt auch noch, dass in einer Schleife öfters Stalls vorkommen, sodass die Zeit sowieso egal ist. Und der Prozessor muss sowieso Wartetakte einbauen...

Aber ich will Smith mal sehen, wie du Takte zählst.
Wenn du ne Schleife machst und am Zählen bist, wird fleißig interuptet :P

Es gibt listen wo man nachschauen kann welcher befehl mit welchen operanden wieviel takte benötigt.
Beim 8086:
xor braucht 3 takte wenn beide operanden register sind.
mov braucht 4 takte wen der eine operand ein register ist und der 2te ein Immediate wert ist.

[PenGuin :O]

Ja gut stimmt...
Aber Takte von bestimmten Routinen zu zählen ist ohne viel Investitionen nicht möglich.
Außerdem lohnt sich Taktezählen nur bei Projekten wo es wirklich um Geld geht.
Kannst ja mal testweise bei CERN anrufen und frag nach was das Zählen auf einem 200-Prozessor "PC" mit 5 Terabyte RAM kostet :P

Aber ich glaub wir driften ab :P

[MrSm!th]

Zeit und Größe spielen bei der Größe heutiger Programme sehr wohl eine Rolle.
Natürlich ist der Unterschied bei einem Befehl gering, aber multiplizier das mal mit ein paar hunderttausend Mal.
Fakt ist, die xor Schaltung ist/war simpler, ob es nun ab und zu interrupts gibt oder nicht.

aber er hat recht, zurück zum thema leute

[lolkop]

sry das ich hier jetzt nochmal was dazu sagen muss...
aber wenn ich sowas lese:

Originally Posted by Akorn

Es gibt listen wo man nachschauen kann welcher befehl mit welchen operanden wieviel takte benötigt.
Beim 8086:
xor braucht 3 takte wenn beide operanden register sind.
mov braucht 4 takte wen der eine operand ein register ist und der 2te ein Immediate wert ist.

es tut mir leid wenn ich davon ausgegangen bin, das heute niemand mehr cpus von 1979 nutzt. wenn du noch ein solches urgestein zuhause hast macht es natürlich einen unterschied, ob du xor oder mov nutzt...

heute benötigen allerdings beide befehle nurnoch einen takt... und auf MrSm!ths frage, was genau ich mit der parallelen ausführung meinte, nein ich meinte keineswegs multithreading... die cpus von heute sind so aufgebaut, das bei mehreren befehlen, die keinerlei speicherzugrif benötigen, und bei denen das ergebnis vorheriger aktionen irrelevant sind, parallel ausgeführt werden. somit werden natürlich nicht aus 2 5takt aktionen eine 5takt aktion, aber es können takte eingespart werden.

bin mir nicht sicher, ob man hierzu wirklich aktuelle daten gelistet im netz finden kann, aber wenn man sich denn mit den herstellern der cpus in verbindung setzt, wird einem hier sicher genaueres erklärt.

einfaches beispiel zu dem was ich meinte wäre einfach nur das 10 malige setzen von eax mit 0.
in mov schreibweise:

mov eax,0
mov eax,0
mov eax,0
mov eax,0
mov eax,0
mov eax,0
mov eax,0
mov eax,0
mov eax,0
mov eax,0

in xor schreibweise:

xor eax,eax
xor eax,eax
xor eax,eax
xor eax,eax
xor eax,eax
xor eax,eax
xor eax,eax
xor eax,eax
xor eax,eax
xor eax,eax

für den mov befehl ist es in diesem falle absolut irrelevant, welchen wert eax denn nun gerade beinhaltet, so können befehle hier ohne probleme parallel abgearbeitet werden. je nach cpu können hier bis zu 5 takte eingespart werden. was bei 10 takten arbeitsaufwand immerhin 50% sind.

beim xor befehl jedoch muss immer erst der aktuelle eax wert eingelesen werden. selbst wenn es eig irrelevant ist, was in eax steht, kann xor natürlich nur ausgeführt werden, wenn bekannt ist, was denn nun im register steht.
das hat zurfolge, das hier parallele abarbeitung nicht möglich ist, was den aufwand bei 10 takten hält.

auch wenn das beispiel hier relativ sinnlos war, sollte es doch zeigen was ich denn nun meinte.
und wenn MrSm!th nun der meinung ist, das dieser 2 byte unterschied beim speicheraufwand mehr relevanz hat, als der eventuelle effizienzverlust, der hierbei nebenbei gesagt auch absolut lächerlich ist, dann sei es so...

in diesem falle würde ich dir nur raten, die hände von hochsprachen zu lassen, da diese (gerade im falle von c++ compilern) leider alles andere als optimal auf aktuelle hardware ausgelegt sind. wenn du dich wegen 2 byte größenunterschied hier aufregst, solltest du einmal rein in asm geschriebene programme von der größe her mit gleichwertigen in c++ geschriebenen programmen vergleichen.
selbst wenn du ein wirklich großes programm schreiben solltest, welches sich mit 500mb oder noch mehr im speicher ablegt, machen diese wenns hoch kommt 500kb die du durch das nutzen von xor statt mov um register 0 zu setzen, auch nichts mehr aus...

heute wird doch aufgrund der sich rasant entwickelnden hardware, durch abstraktion eig. immer mehr wert darauf gelegt, die sprachen möglichst userkomfortabel zu machen, und nicht so hardware nahe wie möglich zu halten, um so wenige takte bzw bytes im speicher freihalten zu können...

[PenGuin :O]

Originally Posted by MrSm!th

Zeit [...] spielen bei der Größe heutiger Programme sehr wohl eine Rolle.

Eine Sache dazu noch:

Wenn du Zeitsparend programmierst, haut der Prozessor dir sowieso noch Wartetakte dazwischen... Und wenn du noch mehr Gründe gegen die Zeit willst, lies meinen Post absolut irrelevant.
Der einzige Grund ist prinzipiell nur die Größe, wo aus einem 8B00000000 ein 31C0 Opcode wird.
Einwandfrei

[MoepMeep]

Originally Posted by PenGuin :O

Eine Sache dazu noch:

Wenn du Zeitsparend programmierst, haut der Prozessor dir sowieso noch Wartetakte dazwischen... Und wenn du noch mehr Gründe gegen die Zeit willst, lies meinen Post absolut irrelevant.
Der einzige Grund ist prinzipiell nur die Größe, wo aus einem 8B00000000 ein 31C0 Opcode wird.
Einwandfrei

Geh in deinen AutoIt sandkasten.

Zeit > alles.

[5769854332]

Vielleicht klappt das:
Evtl. läd das Programm die encryptete Datei mit CreateFile und ReadFile.
-In Olly "Set Breakpoint on every reference" auf ReadFile
-Solange "F9" drücken, bis du die Addresse erreichst, an der ReadFile die gesuchte Datei "liest".
- ReadFile läd die Datei in einen Buffer. Hardware Breakpoint on acces auf den Beginn des Buffers.
- "F9" drücken.
- Du landest am Beginn der decryption routine.


Versuche erst anhand einer kleineren ImportDatei, die Verschlüsselung zu verstehen. Eine Datei mit 20 Bytes ist schneller analysiert als eine mit 2.000.000 Bytes. Hast du die Verschlüsselung der kleinen Datei geknackt, kannst du zur ursprünglichen Datei zurückkehren.

[Lazeboy]

Originally Posted by Kiakar

Vielleicht klappt das:
Evtl. läd das Programm die encryptete Datei mit CreateFile und ReadFile.
-In Olly "Set Breakpoint on every reference" auf ReadFile
-Solange "F9" drücken, bis du die Addresse erreichst, an der ReadFile die gesuchte Datei "liest".
- ReadFile läd die Datei in einen Buffer. Hardware Breakpoint on acces auf den Beginn des Buffers.
- "F9" drücken.
- Du landest am Beginn der decryption routine.


Versuche erst anhand einer kleineren ImportDatei, die Verschlüsselung zu verstehen. Eine Datei mit 20 Bytes ist schneller analysiert als eine mit 2.000.000 Bytes. Hast du die Verschlüsselung der kleinen Datei geknackt, kannst du zur ursprünglichen Datei zurückkehren.

jo ^^ cool ich werds probieren so macht mans ja auch bei den meistenb packet routinen kommt man ja eigentlich immer auf den richtigen weg.