BlackBoard | Druckvorschau: java script hackit

BlackBoard (http://www.black-board.net/index.php)
- Computerecke (http://www.black-board.net/board.php?boardid=30)
-- Netzwerke/Telekommunikation (http://www.black-board.net/board.php?boardid=2)
--- HackIt java script hackit (http://www.black-board.net/thread.php?threadid=8579)

Geschrieben von AC!D am 19.11.2002 um 16:44:

endlich hört ihr auf zu nörgeln und versucht es zu lösen, ich kann nur sagen das es zu lösen ist, ich habs doch selbst schon gelöst

oha, wartet mal, ich hab die falsche datei hochgeladen, ups tut mir jetzt wirklich leid, das war noch die total schwere, wollt euch ja ne ganz leichte machen, so jetzt ist sie up

ach und zarias, im grunde hasst du ja shcon allen erklärt wie man auf die lösung kommt.
und da es ja jetzt vereinfachter ist, dürfte es jeztt für keinen mehr schwer sein, auf die lösung zu kommen. Schade wenigstens hab ich bewiesen das auch java script anspruchsvoll sein kann

Geschrieben von LX am 19.11.2002 um 19:17:

Zitat:

Original von AC!D
Schade wenigstens hab ich bewiesen das auch java script anspruchsvoll sein kann

*räusper*
Da finde ich aber das da: schamlose Eigenwerbung anspruchsvoller. Denn das Aufmultiplizieren von Zahlen bis zu einer Höhe, bei der die Programmiersprache weit über ihre Genauigkeitsgrenzen geht (ich kenne keine Programmiersprache die Integerzahlen > 64bit kann *g) um dann andere das ganze per Primfaktorzerlegung zurückverfolgen zu lassen (was wegen der eingebüßten Genauigkeit ohne "Brute Force" nicht möglich ist), ist für mich kein Anspruch, sondern Zeitverschwendung.

Sorry, das ist nix gegen dich persönlich, AC!D, aber als Hackit fand ich das hier nicht zu gebrauchen. So, wie es jetzt dasteht, mag es zu lösen sein, so wie es vorher war (mit 3.174...e+34) definitiv nicht.

Geschrieben von AC!D am 19.11.2002 um 19:29:

so ist es nur leichter, aber is mir jetzt auch irgendwo egal, ich finds lächerlich, ich stell hier ein hackit hin, und dann wird es als unlösbar abgestämpelt, ich mein, lx, vielleicht kannst du es nur nicht lösen. aber es ist mir echt egal. Ich glaub ich lösch auch gleich mal den ganzen threat. Ein hackit ist nunmal zum knobeln und kopfzerbrechen da, es muss ja nicht immer sofort gelöst werden. Und ich mein, ich hab es schließlich bei the-security unter level 6 gehabt, und zwar so wie ihr es am anfang hattet, und ich habe lösungen per e-mail bekommen. Darum könnt ihr mir erzählen was ihr wollt, es ist lösbar und damit basta

Geschrieben von Zirias am 19.11.2002 um 19:58:

Acid, rechne es doch bitte mal vor wenn du sich für so viel schlauer hältst.

Ich hab eben für 1000 Zahlen die durch Rundung auf die angegebene geführt haben könnten die Primfaktorzerlegungen bestimmt und bei keiner einzigen geht es mit Faktoren kleiner 256.

Dein letzter Post war hochgradig kindisch, echt peinlich. Wenn du keine Kritik vertragen kannst, rede nicht mit Leuten.

Übrigens für die, die es auch mal durchprobieren wollen oder sich vergewissern wollen, dass ich nichts falsch gemacht habe:

code:

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:

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

long long x,y;
long i,j;
int k;

int main(int argc, char **argv) {
        if (argc<2) {
                fprintf(stderr,"USAGE: %s n\n",argv[0]);
                return 1;
        } else {
                x=1000*atoll(argv[1]);
                for (k=-500;k<500;k++) {
                        y=x+k;
                        printf("Faktorisierung von %llu :\n\n",y);
                        i=2;
                        while ((y>1)&&(i<256)) {
                                for (j=0;y%i==0;j++) y/=i;
                                if (j>0) printf("%lu ^ %lu\n",i,j);
                                i++;
                        }
                        if (i<256) {
                                printf("fertig.\n");
                                break;
                        } else {
                                printf("...\n\n");
                        }
                }
                return 0;
        }
}

Geschrieben von Antion am 20.11.2002 um 07:28:

also das war schon einbishen einfacher, I got it.

Antion

Geschrieben von Compuholic am 20.11.2002 um 11:30:

Zitat:

zwar so wie ihr es am anfang hattet, und ich habe lösungen per e-mail bekommen.

Es mögen sich Doch bitte mal die zu Wort melden, die es geschafft haben. Rein mathematisch ist es meiner Ansicht nach definitiv nicht zu lösen. Aber ich revidiere meine Meinung gerne, wenn sich hier jemand findet, der einen rein mathematischen Weg gefunden hat um das Problem zu lösen.

Übrigens: Derjenige sollte sich vielleicht mal bei der NSA melden. Ich glaube die würden sich brennend für das Verfahren interessieren, was er angewendet hat.

Geschrieben von Zirias am 20.11.2002 um 13:28:

Compuholic, lösbar ist es schon. (Schublade wenn ich mal Zeit habe *g*)

Man nehme eine objektorientierte Sprache und erstelle sich eine 128bit-Integer-Klasse. Mit der kann man dann also alle benötigten Verknüpfungen (/,%) durchführen, die man natürlich vorher überladen muss. Man kann dann also theoretisch sämtliche Zahlen durchprobieren, die durch Rundung auf die Zahl im JavaScript-Code führen (sehr viele) und stoppen sobald man eine findet, deren Faktorisierung keine Zahl größer als 255 enthält. Das ist natürlich nicht rein mathematisch, aber auch kein reines Bruteforce. Ist jedenfalls der einzige rechnerische Lösungsweg, der mir einfällt, und mit viel Programmieraufwand verbunden.

Deshalb tippe ich mal stark, dass die Leute, die das bisher angeblich rausgekriegt haben, einfach eine Wordlist zur Hand genommen haben

Greets, Ziri

PS: Mit dem oben beschriebenen Verfahren kann man theoretisch ALLE Lösungen bestimmen, also wenns mal jemand programmieren will?

Geschrieben von Antion am 20.11.2002 um 13:41:

Zitat:

Deshalb tippe ich mal stark, dass die Leute, die das bisher angeblich rausgekriegt haben, einfach eine Wordlist zur Hand genommen haben

Hab es von hand ausgerechnet, geht ganz leicht.

15 min Arbeit, bei der neuen url.

du musst ja nur die buchstaben ausrechnen, mann müsste vielleicht sagen dass der username und passwort nur aus den KLEINBUCHSTABEN besteht.

dann dürfen die produkte nicht die untere und die obere Grenze 97 - 122 überschreiten.

Ich glaub dass ich schon zu viel verraten habe.

Antion

Geschrieben von AC!D am 20.11.2002 um 13:52:

gut, ich sag jetzt nochmal was dazu, egal ob groß oder klein buchstaben, es wäre trotzdem das selbe ergbnis, habt ihr euch überhaupt mit dem editor auseinander gesetzt? es sind einfach die ascii codes, also a =97 b = 98 usw. und egal ob du jetzt a groß oder klein schreibst, es ist immer die 97

so, und jetzt poste ich mal aus nem anderen forum, einen post von nem user, der sich auch gedanken macht, vielleicht hilft es ja jemanden:

gut, bin jetzt soweit, also, z.b. 10 mal das a würde ergeben:

73742412689492830000

das wäre auch genau das ergebnis als wie wenn ich in meinen taschenrechner 97 hoch 10 eingeb

wenn ich jetzt aber 11 mal das a eingeb kommt dieses zeug raus

7.153014030880804e+21

wenn ich meinen taschen rechner das eingebe, kommt auch diese zahl raus, aber anstat e+21 ist da eine kleine hoch 21, keine ahnung was die bedeutet.

so jetzt hab ich mal einen größeren taschenrechner hergenommen, und zwar den von microsoft, der unter zubehör.

und hab da mal 97 hoch 11 eingegeben und da kam das raus

7153014030880804126753

so, vielleicht sind ja dieses e und das + und der . bloß mathematische zeichen. kennt die jemand?

e = Exponent Exponent = deine kleine komische Hochzahl

...

aha, und wie kann ich dann aus der zahl mit dem exponent also 7.153014030880804e+21 diese zahl 7153014030880804126753

berechnen? dann hätte ich s ja shcon geschafft, dann müsste ich nur noch, in priemzalhen zerlegen

Geschrieben von Antion am 20.11.2002 um 14:14:

Zitat:

es sind einfach die ascii codes, also a =97 b = 98 usw. und egal ob du jetzt a groß oder klein schreibst, es ist immer die 97

Da muss ich dich korrigieren AC!D nach der ASCII Zeichentabelle ist gross A = 65 und klein a = 97

Gross und Kleinbuchstaben haben nicht den Gleichen wert.

Antion

Geschrieben von AC!D am 20.11.2002 um 14:21:

ja, dort aber schon.

das mein ich.

Geschrieben von Zirias am 20.11.2002 um 17:12:

Zitat:

Original von Antion
Hab es von hand ausgerechnet, geht ganz leicht.

15 min Arbeit, bei der neuen url.

Du musst schon richtig lesen, es ging um die "alte" Version. Und da für die Zahl dort ganz offensichtlich keine Primfaktorzerlegung mit Zahlen < 255 existiert, muss diese Zahl durch Rundung entstanden sein. Wenn man zurückrechnen will, muss man also viele Zahlen ausprobieren und braucht mehr als 64bit (was z.Zt. das längste ist, was Programmiersprachen i.A. verarbeiten). Daher das Problem.

Die neue Version ist ein exakter Wert und passt auch in 64bit, also leicht berechenbar.

Geschrieben von LX am 20.11.2002 um 17:17:

Durch das *.toLowerCase() in seinem Code wird der eingegebene String erstmal in Kleinbuchstaben umgewandelt, insofern hat AC!D schon recht. Das vereinfacht aber die Aufgabe auch net.

Zu dem zitierten Forenpost: Sag dem Kerl dass "e+x" auf Taschenrechnern und auch bei höheren Zahlen auf dem Computer dasselbe bedeutet wie "*10^x". Und wie er sehr schön erkannt hat (zumindest sind die Zahlen so, ob er's auch so gedeutet hat weiß ich net) tauchen ab einer bestimmten Höhe Rundungsungenauigkeiten auf, weil die Fließkommaberechnung auch in JavaScript nur bis zu einer bestimmten Zahl an Nachkommastellen reicht. Deswegen kommt er bei 7.153014030880804e+21 ausgeschrieben auch net auf 7153014030880804000000, sondern eben auf besagte 7153014030880804126753. Und diese Ungenauigkeit von schlappen 126753 ist schon recht erheblich bei ^21, dann kannst du dir ja ausrechnen, wie groß sie ungefähr bei ^34 ist. Soviel nochmal zum Thema "Eindeutigkeit" *g