Assembler Code analysieren

Page 1 of 2

10/11/2015 16:51 Belur#1

Hey, ich habe bei einer Aufgabe Schwierigkeiten zu verstehen, was folgender Assembler-Code macht.
Das zugeh�rige Programm akzeptiert als �bergabeparameter eine Seriennummer und pr�ft ob diese g�ltig oder ung�ltig ist. Nun geht es darum den Algorithmus rauszufinden bzw. das Schema nach welchem die Nummern akzeptiert werden.

Dazu folgender disassemblierter Code:

Code:

Dump of assembler code for function check_key:
   0x00000000004005bd <+0>:	push   %rbp
   0x00000000004005be <+1>:	mov    %rsp,%rbp
   0x00000000004005c1 <+4>:	sub    $0x20,%rsp
   0x00000000004005c5 <+8>:	mov    %rdi,-0x18(%rbp)
   0x00000000004005c9 <+12>:	mov    -0x18(%rbp),%rax
   0x00000000004005cd <+16>:	mov    %rax,%rdi
   0x00000000004005d0 <+19>:	mov    $0x0,%eax
   0x00000000004005d5 <+24>:	callq  0x4004c0 <atoi@plt>
   0x00000000004005da <+29>:	mov    %eax,-0x4(%rbp)
   0x00000000004005dd <+32>:	cmpl   $0x0,-0x4(%rbp)
   0x00000000004005e1 <+36>:	jne    0x4005ea <check_key+45>
   0x00000000004005e3 <+38>:	mov    $0xffffffff,%eax
   0x00000000004005e8 <+43>:	jmp    0x40062e <check_key+113>
   0x00000000004005ea <+45>:	mov    -0x4(%rbp),%edx
   0x00000000004005ed <+48>:	mov    %edx,%eax
   0x00000000004005ef <+50>:	shl    $0x2,%eax
   0x00000000004005f2 <+53>:	add    %edx,%eax
   0x00000000004005f4 <+55>:	add    %eax,%eax
   0x00000000004005f6 <+57>:	add    %edx,%eax
   0x00000000004005f8 <+59>:	mov    %eax,-0x4(%rbp)
   0x00000000004005fb <+62>:	mov    -0x4(%rbp),%eax
   0x00000000004005fe <+65>:	mov    %eax,%edx
   0x0000000000400600 <+67>:	shr    $0x1f,%edx
   0x0000000000400603 <+70>:	add    %edx,%eax
   0x0000000000400605 <+72>:	sar    %eax
   0x0000000000400607 <+74>:	mov    %eax,-0x4(%rbp)
   0x000000000040060a <+77>:	sarl   $0x3,-0x4(%rbp)
   0x000000000040060e <+81>:	addl   $0xf7f9,-0x4(%rbp)
   0x0000000000400615 <+88>:	subl   $0x13c,-0x4(%rbp)
   0x000000000040061c <+95>:	cmpl   $0x17,-0x4(%rbp)
   0x0000000000400620 <+99>:	jne    0x400629 <check_key+108>
   0x0000000000400622 <+101>:	mov    $0x0,%eax
   0x0000000000400627 <+106>:	jmp    0x40062e <check_key+113>
   0x0000000000400629 <+108>:	mov    $0x1,%eax
   0x000000000040062e <+113>:	leaveq 
   0x000000000040062f <+114>:	retq   
End of assembler dump.

#Edit: Hier das gleiche nochmal in Intel-Syntax:

Spoiler

Ich muss dazu sagen, dass ich mich vorher nie wirklich mit Assembler besch�ftigt habe.
Deswegen ein paar Fragen:

Code:

mov    %rdi,-0x18(%rbp)

Hier verschiebe ich also den Inhalt aus %rdi an die Stelle -0x18(%rbp) (also 24Bytes vor dem Register rbp.
Falls das nun ein 4Byte int ist. Steht der dann in positiver oder negativer Richtung praktisch? Also von: -0x18(%rbp) bis -0x14(%rbp) oder von -0x18(%rbp) bis -0x1C(%rbp).

Danach wird vermutlich mein char*-�bergabeparameter mit atoi in ein int umgewandelt. Woher wei� ich da in welches Register bzw an. welche Stelle der Wert geschrieben wird?

Ich w�rde jetzt mal raten, dass der int-Wert nach -0x4(%rbp) geschrieben wurde.
Und danach wird gepr�ft ob der Wert 0 ist?

Code:

cmpl   $0x0,-0x4(%rbp)

Falls ja, dann wird der maximale int-Wert in das %eax Register geschrieben und die Methode verlassen?

Mir gehts prinzipiell erstmal darum den Code bis zum ersten "cmpl" zu verstehen. Habe da so etwas meine Schwierigkeiten. Evtl. kennt auch einer gute Literatur wo man sich einlesen kann.
Der Assembler Code ist f�r eine x86 Maschine (64Bit).

Hoffe mich kann da jemand etwas aufkl�ren.

Gr��e

10/11/2015 17:13 Shadow992#2

Quote:
Originally Posted by Belur
Hey, ich habe bei einer Aufgabe Schwierigkeiten zu verstehen, was folgender Assembler-Code macht.
Das zugeh�rige Programm akzeptiert als �bergabeparameter eine Seriennummer und pr�ft ob diese g�ltig oder ung�ltig ist. Nun geht es darum den Algorithmus rauszufinden bzw. das Schema nach welchem die Nummern akzeptiert werden.

Dazu folgender disassemblierter Code:
Code:
Dump of assembler code for function check_key:
   0x00000000004005bd <+0>:	push   %rbp
   0x00000000004005be <+1>:	mov    %rsp,%rbp
   0x00000000004005c1 <+4>:	sub    $0x20,%rsp
   0x00000000004005c5 <+8>:	mov    %rdi,-0x18(%rbp)
   0x00000000004005c9 <+12>:	mov    -0x18(%rbp),%rax
   0x00000000004005cd <+16>:	mov    %rax,%rdi
   0x00000000004005d0 <+19>:	mov    $0x0,%eax
   0x00000000004005d5 <+24>:	callq  0x4004c0 <atoi@plt>
   0x00000000004005da <+29>:	mov    %eax,-0x4(%rbp)
   0x00000000004005dd <+32>:	cmpl   $0x0,-0x4(%rbp)
   0x00000000004005e1 <+36>:	jne    0x4005ea <check_key+45>
   0x00000000004005e3 <+38>:	mov    $0xffffffff,%eax
   0x00000000004005e8 <+43>:	jmp    0x40062e <check_key+113>
   0x00000000004005ea <+45>:	mov    -0x4(%rbp),%edx
   0x00000000004005ed <+48>:	mov    %edx,%eax
   0x00000000004005ef <+50>:	shl    $0x2,%eax
   0x00000000004005f2 <+53>:	add    %edx,%eax
   0x00000000004005f4 <+55>:	add    %eax,%eax
   0x00000000004005f6 <+57>:	add    %edx,%eax
   0x00000000004005f8 <+59>:	mov    %eax,-0x4(%rbp)
   0x00000000004005fb <+62>:	mov    -0x4(%rbp),%eax
   0x00000000004005fe <+65>:	mov    %eax,%edx
   0x0000000000400600 <+67>:	shr    $0x1f,%edx
   0x0000000000400603 <+70>:	add    %edx,%eax
   0x0000000000400605 <+72>:	sar    %eax
   0x0000000000400607 <+74>:	mov    %eax,-0x4(%rbp)
   0x000000000040060a <+77>:	sarl   $0x3,-0x4(%rbp)
   0x000000000040060e <+81>:	addl   $0xf7f9,-0x4(%rbp)
   0x0000000000400615 <+88>:	subl   $0x13c,-0x4(%rbp)
   0x000000000040061c <+95>:	cmpl   $0x17,-0x4(%rbp)
   0x0000000000400620 <+99>:	jne    0x400629 <check_key+108>
   0x0000000000400622 <+101>:	mov    $0x0,%eax
   0x0000000000400627 <+106>:	jmp    0x40062e <check_key+113>
   0x0000000000400629 <+108>:	mov    $0x1,%eax
   0x000000000040062e <+113>:	leaveq 
   0x000000000040062f <+114>:	retq   
End of assembler dump.
Ich muss dazu sagen, dass ich mich vorher nie wirklich mit Assembler besch�ftigt habe.
Deswegen ein paar Fragen:
Code:
mov    %rdi,-0x18(%rbp)
Hier verschiebe ich also den Inhalt aus %rdi an die Stelle -0x18(%rbp) (also 24Bytes vor dem Register rbp.
Falls das nun ein 4Byte int ist. Steht der dann in positiver oder negativer Richtung praktisch? Also von: -0x18(%rbp) bis -0x14(%rbp) oder von -0x18(%rbp) bis -0x1C(%rbp).

Danach wird vermutlich mein char*-�bergabeparameter mit atoi in ein int umgewandelt. Woher wei� ich da in welches Register bzw an. welche Stelle der Wert geschrieben wird?

Ich w�rde jetzt mal raten, dass der int-Wert nach -0x4(%rbp) geschrieben wurde.
Und danach wird gepr�ft ob der Wert 0 ist?
Code:
cmpl   $0x0,-0x4(%rbp)
Falls ja, dann wird der maximale int-Wert in das %eax Register geschrieben und die Methode verlassen?

Mir gehts prinzipiell erstmal darum den Code bis zum ersten "cmpl" zu verstehen. Habe da so etwas meine Schwierigkeiten. Evtl. kennt auch einer gute Literatur wo man sich einlesen kann.
Der Assembler Code ist f�r eine x86 Maschine (64Bit).

Hoffe mich kann da jemand etwas aufkl�ren.

Gr��e

Ich bin einmal ganz ehrlich:
Da ich die AT&T-Syntax wirklich verabscheue, habe ich mir den Code nur ganz grob angeschaut, aber was ich soweit sagen kann:

1. Bei x86-64 gibt es nur 2 verschiedene Arten eine Funktion zu callen einmal die "Microsoft"-Variante und die "System V AMD64"-Variante.
Ich vermute dein Code lief/l�uft auf einem Linux-System, weil unter Windows meistens die Intel-Syntax benutzt wird.
Daher werden all Funktionen wie folgt gecalled:

Quote:

The calling convention of the System V AMD64 ABI is followed on Solaris, Linux, FreeBSD, Mac OS X, and other UNIX-like or POSIX-compliant operating systems. The first six integer or pointer arguments are passed in registers RDI, RSI, RDX, RCX, R8, and R9, while XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6 and XMM7 are used for floating point arguments. For system calls, R10 is used instead of RCX.

Quelle: https://en.wikipedia.org/wiki/X86_calling_conventions

Das hei�t wenn ich die Syntax richtig lese, m�sste in "rdi" der Pointer zu deinem String stehen.

2.
Das Ergebnis, also der Return-Wert, sollte ,wie immer und wie auch bei vielen 32Bit-Calls (korrigiert mich wenn ich falsch liege), in "eax" bzw. "rax" liegen.

3.
Ein "mov %rdi,-0x18(%rbp)" f�ngt an der Stelle "rbp-0x18" an zu schreiben und schreibt dann an die Stelle "rbp-0x17" das n�chste Byte ...
In Intel-Syntax ist das etwas "intuitiver" dargestellt wie ich finde:
"mov [rbp-0x18], rdi" (man beachte die vertauschte Reihenfolge der Intel-Syntax).

4.
Eigentlich alle Register mit einem "r" vorne und der Zeichenl�nge von 3 sind 8Byte = 64Bit gro�. Register mit einem "e" an erster Stelle + Zeichenl�nge 3 normalerweise 4Byte und Register mit Zeichenl�nge 2, 2Byte.
Ich bin mir gerade unsicher, ob das wirklich immer in allen F�llen zutrifft, aber zumindest in 99% der F�lle passt das.

10/11/2015 17:47 Belur#3

Besten Dank.

Ich f�ge mal den Code in Intel-Syntax hinzu. Vermutlich ist das f�r die meisten besser lesbar. Defaultm��ig war im gdb AT&T eingestellt.

10/11/2015 18:08 Jeoni#4

Da jetzt auch die Intel-Syntax verf�gbar und mir langweilig war, habe ich mir mal die M�he gemacht das nach C zu �bersetzen. Raus kam folgendes:

Code:

int CheckKey(
	const char* arg0 // @ rbp - 0x18
	)
{
	int var0 = atoi(arg0); // @ rbp - 4
	if (var0 == 0)
	{ // @ +38
		return -1;
	}
	var0 = (((var0 << 2) + var0) * 2) + var0; // @ +45 to +62
	var0 = (var0 + (var0 >> 31)) >> 1; // @ +62 to +77
	var0 >>= 3; // @ +77
	var0 += 0xf7f9; // @ +81
	var0 -= 0x13c; // @ +88
	return (var0 == 0x17) ? 0 : 1;
}

Hab an ein paar Stellen rangeschrieben von wo es kommt, aber auch dort, wo nichts steht, sollte sich dann recht leicht wiederfinden lassen. So gro� ist die Funktion ja nicht ;)
Wenn etwas unklar ist, frag einfach. Ich wei� nicht, wie detailliert erkl�rt du es brauchst :)
Ein paar Grundlagen hat Shadow ja schon erl�utert.
Mit freundlichen Gr��en
Jeoni

10/11/2015 18:17 Belur#5

Vielen Dank, das werde ich mir sofort nochmal detailliert anschauen.

Nur mal aus Interesse: Haste das so "frei Hand" reverse-engineered oder mit Hilfe irgendeines Tools? IDA Pro oder Hopper oder wie sie alle hei�en.

Respekt auf jeden Fall, da w�r so schnell nicht hingekommen ;)

10/11/2015 18:27 Jeoni#6

Das war frei Hand. Bzw. mit Visual Studio als Editor, aber da h�tte es auch jeder Andere getan. IDA nutze ich sehr gerne bei gr��eren Projekten. Da ist es denn auch eine Hilfe, wenn man die Funktionen / Variablen (lokal wie global) frei benennen kann und das dann im gesamten restlichen Code automatisch �bernommen wird. Hier waren es ja nur 2 lokale Variablen (von denen nicht eine n�tig gewesen w�re), die kann ich mir noch so merken.
W�re hier jetzt komplizierter gewesen die Funktion in IDA reinzubekommen als das tats�chliche Analysieren :D

Mit freundlichen Gr��en
Jeoni

10/11/2015 19:07 Belur#7

Ich komme einfach mal mit dem zweiten Teil :awesome:

Zu der check_key Funktion gibt es nat�rlich noch die main:

Code:

Dump of assembler code for function main:
   0x0000000000400630 <+0>:	push   rbp
   0x0000000000400631 <+1>:	mov    rbp,rsp
   0x0000000000400634 <+4>:	sub    rsp,0x20
   0x0000000000400638 <+8>:	mov    DWORD PTR [rbp-0x14],edi
   0x000000000040063b <+11>:	mov    QWORD PTR [rbp-0x20],rsi
   0x000000000040063f <+15>:	cmp    DWORD PTR [rbp-0x14],0x2
   0x0000000000400643 <+19>:	je     0x400665 <main+53>
   0x0000000000400645 <+21>:	mov    rax,QWORD PTR [rbp-0x20]
   0x0000000000400649 <+25>:	mov    rax,QWORD PTR [rax]
   0x000000000040064c <+28>:	mov    rsi,rax
   0x000000000040064f <+31>:	mov    edi,0x400734
   0x0000000000400654 <+36>:	mov    eax,0x0
   0x0000000000400659 <+41>:	call   0x400490 <printf@plt>
   0x000000000040065e <+46>:	mov    eax,0x1
   0x0000000000400663 <+51>:	jmp    0x4006a1 <main+113>
   0x0000000000400665 <+53>:	mov    rax,QWORD PTR [rbp-0x20]
   0x0000000000400669 <+57>:	add    rax,0x8
   0x000000000040066d <+61>:	mov    rax,QWORD PTR [rax]
   0x0000000000400670 <+64>:	mov    rdi,rax
   0x0000000000400673 <+67>:	call   0x4005bd <check_key>
   0x0000000000400678 <+72>:	mov    DWORD PTR [rbp-0x4],eax
   0x000000000040067b <+75>:	cmp    DWORD PTR [rbp-0x4],0x0
   0x000000000040067f <+79>:	jne    0x400692 <main+98>
   0x0000000000400681 <+81>:	mov    edi,0x400745
   0x0000000000400686 <+86>:	call   0x400480 <puts@plt>
   0x000000000040068b <+91>:	mov    eax,0x0
   0x0000000000400690 <+96>:	jmp    0x4006a1 <main+113>
   0x0000000000400692 <+98>:	mov    edi,0x40075b
   0x0000000000400697 <+103>:	call   0x400480 <puts@plt>
   0x000000000040069c <+108>:	mov    eax,0x1
   0x00000000004006a1 <+113>:	leave  
   0x00000000004006a2 <+114>:	ret    
End of assembler dump.

Es f�llt mir allgemein sehr schwer, zu verstehen was da gemacht wird:
zB:

Code:

mov    rax,QWORD PTR [rbp-0x20]
add    rax,0x8
mov    rax,QWORD PTR [rax]

Also eine Variable wird in ein Register geladen? Danach wird die Variable um 8 inkrementiert. Und was ist der 3. Schritt? Wird die inkrementierte Variable wieder in "rax" gemovt? Sollte sie da nicht schon drinstehen? Oder passiert da evtl. doch was ganz anderes.
Bevor der Key gepr�ft wird der Schl�ssel + 8 gerechnet?

Eine andere Sache w�re: Beim ersten cmp wird [rbp-0x14] mit 2 verglichen. Ich kann mir jetzt nur vorstellen dass damit die L�nge des args-Arrays gemeint ist. Weil wenn die nicht passt wird auch eine Fehlermeldung ausgegeben. Vor dem print passieren aber dann noch etliche andere Sachen.

Gibt es irgendein gutes Buch a la "Assembler from scratch" oder eine gute Seite wo man Schritt f�r Schritt die Befehle nachvollziehen kann?

10/11/2015 20:03 wurstbrot123#8

Bei schritt 3 ist RAX eine Addresse, der Wert der an der Addresse steht wird in RAX gepackt.

10/11/2015 20:14 Jeoni#9

Code:

mov    rax, QWORD PTR [rax]

Dies dereferenziert rax und l�dt das Ergebnis wieder nach rax. Man k�nnte es sich in C folgenderma�en vorstellen:

Code:

rax = *rax;

(Register sind nat�rlich untypisiert)

Das erste cmp vergleicht die lokale Variable an rbp-0x14 mit 2. Die lokale Variable wird zwei Zeilen dar�ber mit RDI, welches dort das erste Argument von main enth�lt, gef�llt. Du gehst also recht in der Annahme, dass es sich dort um argc handelt.

Das Argument f�r die check_key funktioniert kommt letztlich ja aus der lokalen Variable an rbp-0x20. Oben in main sieht man wie diese Variable mit RSI, laut der Aufrufkonvention also dem zweiten Argument von main (argv) gef�llt wird.
Wenn man sich nun ansieht, was damit gemacht wird, um zum argument f�r die check_key Funktion zu gelangen kommt man f�r den Aufruf erstmal auf sowas:

Code:

check_key(*(argv + 8))

(mal unter der Annahme, dass es keine Typen g�be und Pointerarithmetik uns hier nicht aufh�lt)
argv ist allgemein bekannt als Array aus Pointern auf (konstante) Zeichenketten (const char*[]). 8 ist, da es x64 ist, genau einmal die Pointergr��e. Was hier also passiert ist, dass auf den Eintrag von argv an Index 1 zugegriffen wird.

Code:

check_key(argv[1])

Damit macht der vorherige Check von argc nat�rlich auch Sinn.

Kann leider keine Empfehlungen f�r B�cher oder Tutorials machen, ich habe mir das eigentlich alles selbst beigebracht (und ein paar Mal bei Bekannten nachgefragt). Wenn ich eine Instruktion nicht kannte, habe ich sie bei Google gesucht. Als Referenz nutze ich h�ufig [Only registered and activated users can see links. Click Here To Register...], aber gab auch schon Instruktionen, die dort nicht erl�utert wurden. Nebenbei muss man dann nat�rlich sich auch Wissen zu den Registern und Aufrufkonventionen aneignen. Ist dann auch recht lehrreich, wenn man sich den asm Code ansieht, den der Compiler aus eigenem Source Code ausspuckt. Dann fallen einen noch eher die Zusammenh�nge auf, was beim R�ck�bersetzen von asm dann nat�rlich auch n�tzlich ist.

Mit freundlichen Gr��en
Jeoni

10/11/2015 20:39 Belur#10

Danke, die Seite speicher ich mir auch mal ab ;)

Werde vor allem die Berechnungen in der check_key Methode morgen nochmal Schritt f�r Schritt durchgehen. Irgendein System muss da ja hintersteken, sodass man das vereinfachen kann.

Rein theoretisch m�sste ich ja so alle g�ltigen Schl�ssel ausgeben lassen k�nnen:

Code:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
	int var0;
	int i;
	for (i = 0; i <= 9223372036854775807; i++) {
		var0=i;
		var0 = (((var0 << 2) + var0) * 2) + var0; // @ +45 to +62
		var0 = (var0 + (var0 >> 31)) >> 1; // @ +62 to +77
		var0 >>= 3; // @ +77
		var0 += 0xf7f9; // @ +81
		var0 -= 0x13c; // @ +88
		if (var0 == 0x17){
			printf("%d", i);
		}
	}

}

Und er findet tats�chlich passende Schl�ssel.
Respekt ich war echt skeptsich ob das mit den ganzen Klammern und Shifts passt O.o

10/11/2015 20:52 Jeoni#11

Jetzt wo ich mir die neue Aufgabenstellung ansehe, f�llt mir ein Fehler in meinem r�ck�bersetztem Code auf. Korrigiert sollte es so lauten:

Code:

int CheckKey(
	const char* arg0 // @ rbp - 0x18
	)
{
	int var0 = atoi(arg0); // @ rbp - 4
	if (var0 == 0)
	{ // @ +38
		return -1;
	}
	var0 = (((var0 << 2) + var0) * 2) + var0; // @ +45 to +62
	var0 = (var0 + (var0 >> 31)) / 2; // @ +62 to +77
	var0 /= 8; // @ +77
	var0 += 0xf7f9; // @ +81
	var0 -= 0x13c; // @ +88
	return (var0 == 0x17) ? 0 : 1;
}

Falls es dich interessiert: Ich hatte "sar" f�r einen einfachen Shift gehalten, der es aber nicht ist. Andernfalls w�re 0x17 wohl nicht erreichbar, wenn ich mich jetzt auf die schnelle nicht vertan habe.
Mit freundlichen Gr��en
Jeoni

10/11/2015 20:58 Belur#12

Also deine erste Version scheint richtig zu sein.

Wenn ich alle ints durchgehe und jedes Mal die Berechnung ausf�hre bekomme ich g�ltige Schl�ssel.
zB:
390359730
780811302
780811303

Bei deiner zweiten L�sung kommen keine g�ltigen Schl�ssel raus. Von daher war die erste Berechnung wohl doch richtig.

10/11/2015 21:05 Jeoni#13

Nein, die L�sung des "korrigierten" Codes liegt lediglich im negativem Bereich, wie ich gerade durch R�ckentwickeln festgestellt habe. Mit einer Eingabe von -91843 ist das Endergebnis nach den paar Operationen ebenso 23 (0x17). Ich bin mir recht sicher (aber das will nichts hei�en), dass meine korrigierte Fassung die korrektere ist, da die benutzte sar-Instruktion eben kein normaler Shift ist, sondern sich wie ein n-faches vorzeichenbehaftetes Teilen durch 2 verh�lt, was meine erste Version au�er Acht l�sst. Dies w�re korrekt, wenn statt "sar" die "shr" Instruktion benutzt werden w�rde.
Referenz: [Only registered and activated users can see links. Click Here To Register...].
Obige Zahl ist meines Wissens nach auch die einzige L�sung, so dass sich die check_key Methode auf ein simples

Code:

atoi(argv[1]) == -91843)

reduzieren lie�e.
Mit freundlichen Gr��en
Jeoni

10/11/2015 21:30 Belur#14

Interessant, du hast da mehr Ahnung als ich, deswegen vertraue ich dir mal.

Da deine erste L�sung aber nur passende Schl�ssel generiert, muss es auch irgendwie passen. Eine Aufgabe ist auch einen Keygenerator zu schreiben, der nur passende Schl�ssel generiert. Das spricht ja auch daf�r, dass es mehr als einen passenden Schl�ssel gibt.

Falls du dich selbst �berzeugen m�chtest, hab ich das Programm einfach mal angeh�ngt.
-91843 ist allerdings auch eine korrekte Eingabe f�r das Programm. Ich kanns mir nicht wirklich erkl�ren, aber deine "nicht-ganz-korrekte" Version produziert ausschlie�lich korrekte Schl�ssel.

10/11/2015 21:39 Jeoni#15

Ah, jetzt hab ich's. Bei positiver Eingabe ist ja egal, ob shr ("richtiger" Shift) oder sar (n-faches vorzeichenbehaftetes Dividieren durch 2). Das hei�t, dass die zweite, korrigierte Version den positiven L�sungsraum der ersten Version, von der du ja schon Schl�ssel gefunden hast, inkludiert, sich der negative L�sungsraum jedoch unterscheidet.
Die zweite Version ist in der Tat korrekter, aber meine Annahme, dass es nur eine einzige L�sung g�be, war falsch, was wohl darauf zur�ckzuf�hren ist, dass ich die Divisionen nicht mehr als Shifts gesehen habe, was sie ja immernoch sind.
Vielleicht gehst du auch nochmal den negativen Zahlenraum durch, vielleicht befindet sich dort ja auch noch eine L�sung, wobei ich das irgendwie nicht glaube.
Mit freundlichen Gr��en
Jeoni

Page 1 of 2