|
Wie "offen" ist ein Password (String) im Arbeitssp
Ich habe eine DLL programmiert welche ein Textdokument - mit einem Password verschlüsselt - speichern und wieder öffnen kann. Juhee, das funktioniert auch prima - sie macht sogar noch einiges mehr!
Doch heute Nacht kam mir mit schrecken plötzlich folgender Gedanke: wie "offen" für Hacker ist meine Variable mit dem Passwort in einer DLL überhaupt? Beispiel - Funktionen der DLL: - Open(AFilename, APassword: WideString) öffnet die Textdatei und schreibt das Password in eine private Variable (weil ich diese in der DLL sonst noch mehrmals benötige) - Close speichert die Textdatei durch das Passwort verschlüsselt wieder ab Schön und gut - doch nun ist während dem Open und dem Close das Password in der Variablen doch für "jeden" ersichtlich? da wird meine Verschlüsselung ja überflüssig? Was denkt ihr dazu? Vielen Dank für eure Hilfe |
Re: Wie "offen" ist ein Password (String) im Arbei
Wieso werden wohl auch aktuelle Sicherheitssysteme unter Windows geknackt: Weil man mit einem Debugger oft ran kommt.
Willst Du es sicherer muss sich deine Anwendung beenden wenn ein Debugger aktiv ist. Auch mußt du jeden Hook erkennen da ja aufgrund des DLL-Funktionsnamens diese Funktion wie auf dem Präsentierteller liegt. Hier wirst Du u.U. mittels Obfuscation/Verschleierung etwas verbesserung bekommen. |
Re: Wie "offen" ist ein Password (String) im Arbei
Zufällig beschäftige ich mich grad mit DLL-Injection und Function-Intercepting (meist tagsüber, selten nachts ;) ). Dabei bin ich zu folgendem Schluss gekommen: Wenn es einem "schlechten" Programm gelingt, die Rechte zu erlangen, eines anderen Prozesses Memory zu lesen (ReadProcessMemory, ...), ist Schluss mit lustig. Diese Rechte hat ein Administrator auf NT-Systemen automatisch.
Mit diesen Rechten kann man alle Variablen lesen, die eine Prozess benutzt. Idealerweise kann man auch allen anderen Speicher inklusive der Instructions (also den eigentlichen Code) lesen (und wenn man will auch schreiben). Das führt dazu, das man nachverfolgen kann, wie du zu deinem Passwort kommst. Was sollte man daraus folgern? Eine gewisse Sicherheit gegen Attacken von Boon's geben folgende 2 Hinweise: 1. Man sollte die Rechtestruktur von Windows(NT) nutzen. (Wenn es um Prozesse geht, die nicht unter der eigenen UID laufen). Sie hat ihren Sinn. 2. Man sollte in regelmäßigen Absänden die Liste dergeladenen Module durchsehen und prüfen ob alle diese Module ihre Daseinsberechtigung haben (wenngleich man diese Informationen auch fälschen kann; aber das ist was für richtige Insider). Man sollte aber darüber nachdenken, wie hoch die Wahrscheinlichkeit eines Angriffes ist. Ein Programm, das 100 Menschen nutzen verdient imho keinen Extra-Aufwand für Sicherheitsmechanismen von 100 Stunden. |
Re: Wie "offen" ist ein Password (String) im Arbei
Ich führe am besten einen Vergleich an:
Du sicherst dein Haus mit einem Vorhängeschloß und hängst den Schlüssel für das Schloß direkt daneben an einem Nagel. So wie dieser Schlüssel "an den Mann" gehört (mein Uffz der BW lässt grüßen), gehört dein Passwort in den Kopf des Anwenders, alles andere muß im Falle deines kryptographischen Verfahrens unsicher sein. Am besten ist der Gedanke das deine Anwendung/DLL/EXE nur eine andere Form deines Sources darstellt. Dh. alles was du in deinem Source lesen kannst kann man auch direkt aus deiner Anwednung/EXE/DLL herauslesen. Wenn du in deinem Source dein hardcoded Passwort lesen kannst so kann man dies auch ohne Probleme aus der fertigen Anwendung herauslesen Du musst also grundsätzlich dein Konzept des Datenschutzes überdenken. Aus meiner Sicht möchtest du Anwenderdaten per Verschlüsselung schützen. Also lass einfach den Anwender das Passwort selber auswählen und per Dialog fragst du es ab. Damit lösst du nicht nur dein eigentliches Problem sondern du erhöhst sogar die Sicherheit enorm. Denn jeder Anwender deiner Software schützt seine Daten mit eigenen Passwörtern. Dh. es gibt deinem "General-Schlüssel" nicht mehr. Die Frage die sich jetzt stellt ist ob dies deinem Konzept/Ziel entspricht. Gruß Hagen |
Re: Wie "offen" ist ein Password (String) im Arbei
du kannst auch per PHP-Script etc. die Verschlüsselung vornehmen, dann kommt keiner ran. Du müsstest dann die Rohdaten an das Scriptschicken und das Script schickt dann das verschlüsselte Ergebnis zurück. So sollte niemand an den verschlüsselungscode ran kommen.
|
Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
2.) Das funktioniert ebenfalls nicht. Treiber wie LogiTech Mäuse, Keyboard Treiber, Grafik Treiber, DCOM, Protected Storage etc. pp. injezieren ihre DLLs permanent in die eigene Anwendung. Davon abgesehen kann ein Angreifer auf seinem System sehr wohl diese Treiber DLLs durch eigene DLLs oder durch die "Side by Side" Technik, austauschen. Dh. aus Sicht deiner Anwendung hast du keine Möglichkeit zu erkennen welche DLLs sich mit welchem Ziel in deine Anwendung injeziert hat. Ergo: Punkt 2.) ist ebenfalls untauglich. 3.) Man kann über die Wahrscheinlichkeit eines Angriffs viele Jahre lang sinnieren, analysieren und rumgrübeln. Man wird immer zu dem Schluß kommen das selbst die billigste Software mit den schlechtesten Features denoch ein Angriffziel eines Angreifers sein kann. Die Gründe warum ein Angreifer einen Angriff startet haben sehr oft rein garnichts mit Geld, Know How oä. zu tuen. Fazit: auch Punkt 3.) ist Zeitverschwendung. Gruß Hagen |
Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
- man muß eine sicherer Datenübertragung im INet sicherstellen - man benötigt zu jeder Zeit eine INet Verbindung, ohne das Proxies, Rooter, Firewalls etc.pp. dazwischen funken - man benötigt einen INet Server samt Software So und wenn man dies alles hat muß man noch das Problem lösen das man ja mit einem General-Schlüssel der für alle Benutzer identisch ist, arbeiten möchte. Dh. selbst mit dem sicheren PHP, mit sicherer Kommunikation übers INet, mit einem sicheren Server, wird der Angreifer EINMALIG diesen General-Schlüssel legal abfragen, und kann dann JEDE Anwendungskopie ohne weitere Abfragen entschlüsseln. Dh. alleine die Benutzung eines General-Schlüssels für alle Benutzer ist unischer und tödlich. Das identische Problem tritt zb. bei den Serialnummern/Registrationsschlüsseln von Software-CDs auf. Auch hier ist der technische Aufwand JEDE dieser CD-ROMs individuell zu serialisieren enorm, und deshalb benutzt man bei solche CDs eben auch "General-Schlüssel" in Form von Schlüssel-Ableitungs-Funktionen == Registrations-Funktionen. Hat man diese Funktionen einmalig reverse-engieneered kann man sich seine eigenen Schlüssel erzeugen. Gruß Hagen |
Re: Wie "offen" ist ein Password (String) im Arbei
nja ist sehr leich ein hardcore(einprogrammierten) password zu finden
ich habe mich schon etwas mit cracken beschäftigt, und ich weis es ;) debugger starten und die PWs gehören dir ;) |
Re: Wie "offen" ist ein Password (String) im Arbei
gibt es nicht die pgp en/decoder als commandline ?
|
Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
Der Anwender der Software oder die Software des Anwenders muß für diesen Anwender als erstes beim Setup einen eigenen a-symmetrischen Schlüssel erzeugen, zb. eben RSA Schlüssel. Der Anwender muß nun 1.) den rivaten Teil dieses Schlüssel per Passwort schützen und auf Platte/USB Stick öä. speichern 2.) dann muß der Anwender den öffentlichen Teil dieses Schlüssel zum Server übertragen/senden 3.) der Server benötigt nun die Möglichkeit die Authentizität, sprich die Zuordnung -> öffentl. Schlüssel zum berechtigten Benutzer, sicherzustellen. Gerade Punkt 3.) ist aber das Problem. Man benötigt eine Dritte Partei, einen sogenannten Trust der die Authentizität sicherstellen kann. Ist dies NICHT möglich so kann ein Angreifer ohne Probleme sich als regulärer Benutzer ausgeben und der Server wird somit wiederum an das "Gerneral-Passwort" zu Verschlüsselung der Daten rankommen. Effektiv hat man also nur die Komplexität des gesammten Prozessings erhöht aber rein garnichts an Sicherheit gewonnen. Denn ein einfaches Benutzergewähltes Passwort (wie oben schon beschrieben) wäre identisch sicher. Denn bei all den Verkomplizierungen muß der Anwender ja nun seinen privaten Schlüssel schützen und da er viel größer ist als ein im Kopf gespeichertes Passwort muß er diesen sogar noch extern irgendwo speichern. Satt diesem Umweg kann man ja dann gleich das identische Passwort benutzen. Gruß Hagen |
Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
Zitat:
Zitat:
Und btw: Selbst wenn man fachlich kompetent ist, muss man nicht reden als ob man der Schöpfer der Welt ist. Manchmal hilft es auch, einen Moment länger über die Meinung eines Anderen nach zu denken. |
Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
|
Re: Wie "offen" ist ein Password (String) im Arbei
Zum einen denke, ich das das sehr selten ist. Hast du schon mal sowas gesehen?
Zum anderen kann ich dafür einen Schalter einbauen, mit dem der Nutzer wählen kann: - Secure Mode: alle ungewollten Module rausschmeißen (also auch Logitech und Konsorten) - Unsecure Mode: nicht empfohlen, aber wenn der Nutzer es so will |
Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
Und was für Module von der VCL und anderen Teilen, die du verwendets geladen werden, darauf hast du ja auch keinen Einfluß. |
Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
Aber ehe wir uns hier total in OT verrennen: Ich wollte mit meinem ersten Post genau eine Sache sagen(auch wenn sie scheinbar nicht so rübergekommen ist): Es gibt imho keine(0, nil, null :) ) Sicherheit für ein Passwort im RAM. Und das ist wohl die Frage, um die es hier geht. |
Re: Wie "offen" ist ein Password (String) im Arbei
@chaosben:
es ist eben nicht selten sondern eher der normale Vorgang. Und seit dem es die "side by side" Technik gibt gibt es auf OS Ebene ein API das es ermöglicht zb. die WinSock DLL so zu laden das sie unbemerkbar durch eine Angreifer-WinSock-DLL geladen wird. Dh. selbst wenn deine Anwendung WinSock lädt, und das auch gewünscht ist durch deine Anwendung, so kann ein Angreifer eine "Side by Side" DLL für WinSock installieren die dann mit Hilfe des APis vollkommen transparent die originalen Funktionen der originalen WinSock DLL ersetzt. Die Anwendung selber hat dabei keine Möglichkeit zu erkennen das es eine "Side by Side" DLL ist. Somit stellt das OS von Hause aus einen Weg zur Verfügung ganz regulär eigenen Code in andere Anwendungen zu injezieren. Also selbst wenn die eigene Anwendung WinSock absichtlich und STATISCH lädt. Und dann gibts noch die "Delayed Load" DLLs die erst zu einem Zeitpunkt nachgeladen werden. Bei sowas ist es denn wichtig das deine Anwendung auch korrekt zeitlich synchron die Überprüfung der geladenen DLLs durchführt, da sie ansonsten solche DLLs garnicht detektieren kann. Ich erwähne dies (auch wenn es teil-OT) ist nur aus einem Grunde: nämlich um fehlendes Wissen nachzuliefern das deutlich zeigt das deine 3 postulierten Taktiken wirkungslos sind. Der Trend der "Treiber" Programmierer Funktionalitäten über injezierte DLLs zur Verfügung zu stellen wird dabei immer stärker. Dh. gabs sowas vor Jahren noch nicht so häufig so stelle ich heutzutage immer öfter fest das von den vielen DLLs in meinen Prozessen die meisten injezierte DLLs oder "side by side" geladene DLLs sind. Ein sehr hilfreiches Tool dafür ist der Dependency Walker. Alleine die fucking Treiber für die HP Drucker werden injeziert. Zwar nicht über Hooks dafür durch das OS selber wenn man Drucker-APIs in der Anwendung aufruft. Deine Aussage zeigt also das du selber noch niemals sowas beobachtet hast. Besteht noch die zweite große Frage: WIE und WANN will die eigene Anwendung erkennen welche DLLs im eigenen Prozess geladen wurden ? Hört sich trivial an ist es aber weiß Gott nicht. Denn der Weg über ToolHelp ist durch einen Angreifer so enorm leicht auszuhebeln (globale Hooks) das deine Anwendung garnicht die Chance hat eine Angreifer DLL zu entdecken. Desweiteren besteht das Problem nicht nur zu verifizieren das eine spezielle DLL tatsächlich geladen wurde sondern zu verifizieren ob diese DLL noch das Original darstellt. Da helfen auch keine digitalen Signaturen da diese NUR und ausschließlich NUR auf dem Image der Festplatte arbeiten und NICHT auf dem Code der geladenen DLL im Speicher ! Ergo: so bald es um DLLs geht kann sich eine Anwendung in nichts sicher sein. Und mal erhlich, wer hat von euch nicht schon mit SetWindowsHookEx() rumgespielt und seine eigene KeyBoard-Hook-DLL gebastelt. Das ist wohl eines der offensten Geheimnisse und selbst für Visual Basic for Applications gibts Beispielcode im WEB. Wir können aber gleich auf eine höhere Ebene wechseln, ins Kernel, dann Treiber und dann, oh Gott finden wir raus das das komplette OS nur rein virtuell in einer Sandbox, VM, in SoftICE oder auf einem Hardware Debugger läuft. Ergo: das Passwort in der Anwendung zu speichern ist schlecht. Ergo: ein Passwort als General-Schlüssel der für alle Anwendungskopien identisch ist ist eine unsichere Idee. Ich empfehle das Passwort durch den Anwender eingeben zu lassen und damit auch Anwenderbezogen seine Daten zu verschlüsseln. Klar ein kompromittiertes, unsicheres System wird mit keiner Lösung einen Schutz bieten. Ausnahme ist einbruchsichere Hardware. Alledings greift man so nur EIN Anwenderpasswort auf EINEM System an und nicht ALLE Anwender der gleichen Software in einem Rutsch und das auch noch OFFLINE. Gruß Hagen |
Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
Und da ich selber über genügend Kenntnisse verfüge, kann ich mir dessen sogar sicher sein. Man braucht übrigens nicht einmal eine DLL verwenden, openProcess und createRemoteThread tuen es auch. Und zu dem Vorschlag, eines Securemodus, der sich nur mit bestimmten DLLs aktivieren lässt... Erstens: siehe Hagens Thread und zweitens: Wie findest du denn heraus was geladen ist? Ein komplettes Speicherabbild vergleichen? Und sagen wir rein theoretisch, du würdest es schaffen, so vertausche man ein true und false in deinem Programm und es denkt der Securemodus ist aktiv... Rest siehe Hagens thread. Zitat:
|
Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
|
Re: Wie "offen" ist ein Password (String) im Arbei
Siehst du und ich will klarstellen das man nicht nur "scharz & weiß" sieht.
Zitat:
Dh. überall gibt es Entwicklung die Kryptographie direkt in die HW integrieren. - DVI, HD-TV, SPDIF Datenübertragungen mit Entschlüsselung im Endgerät - Sachen wie TCP im Betriebssystemen wie Palladium, Linux - Hardware wie Secure Digital Speichermedien, Compact Flash Karten, xD Pixture Cards, Sony Memory Stick - Datenübertragungsstandards wie Bluetooth, ZigBee, WLAN - IDE ATA/ATAPI-7 Standard mit Hardwareverschlüsselungen direkt in der Festplatte (ein großes Ärgernis bei originalen xBox HDs) - serieller SRAM Speicher für Grafikkarten und PCs die ihre Daten ebenfalls live verschlüsseln - selbst Druckerpatronen nutzen kryptographische Protokolle heutzutage Es gibt also fast in jedem Sektor Bestrebungen Kryptographie direkt in HW zu integrieren nachdem die komplette Datenübertragung/haltung digitalisert ist. Die nötigen Schlüssel liegen dabei NICHT in den Händen des Besitzers der gespeicherten Daten sondern bei den Herstellern von HW und SW und TrustCentern. Es gibt also auch schon Speicherchips die zwar ausgelesen werden können, aber das was man da ausließt ist live verschlüsselt worden und kann nur innerhalb einer entsprechenden CPU mit Krypto-Co-Prozessor real verwertet werden. Die Aussage das ein Passwort im RAM absolut unsicher und ungeschützt wäre ist also ebenfalls nicht mehr "ganz" richtig. Vielleicht noch heute aber nicht mehr in 4-5 Jahren. Technologisch und auch vom Know How her gesehen wissen die heutigen Experten sehr genau was sie wie entwickeln müssen damit unsere Hardware in Zukunft vor UNS als Benutzer ABSOLUT sicher wird. Das kann vorteilhaft für uns als Anwender sein weil ein entsprechendes OS dann wirklich sicher vor Viren/Trojanern etc.pp. sein könnte. ABER! eher nehme ich an das solche "Features" nur zum Zwecke der Profitmaximierung benutzt werden, sprich zur Kontrolle unserer Daten oder unseres Verhaltens. Aus dieser Sicht könnte man ja eigentlich froh sein das unsere heutige Technik so "unsicher" ist, da wir damit auch noch die absolute Kontrolle über unsere private HW haben. Denn eines steht fest: die Entwicklung und Vermarktung solcher krypto-gebundener-Hardware wird von Experten die wissen was sie tuen forciert. Dh. die Hoffnung das es intelligente Hacker in Zukunft gibt die dann immernoch überall einbrechen können (was ich schon heute für ein Gerücht halte) ist absolut falsch. Sollte in Zukunft jeder Schritt der Herstellung von Informationen/Daten, zur Vermarktung, über deren Speicherung und Datenübertragung bis hin zum Abspielen auf dem digitalem HD-TV Fernseher digitalisiert, kryptographisch geschützt und authentifiziert worden sein, so wird es mit den schon heute bekannten mathematischen Verfahren KEINERLEI effiziente Möglichkeit mehr geben ein solches System zu knacken. Bestes Beispiel sind die bedauernswerten Benutzer der xBox die ihre persönlichen Daten auf Platte speicherten und später beim Einbau dieser HD in andere Rechner keinen Zugriff mehr auf diese, IHRE Daten haben. Also gibt es Möglichkeiten ein Passwort sicher auf einem Rechner zu speichern, das Problem dabei ist es dieses Passwort sicher in der eigenen Anwendung zu speichern und zum Anwender zu transportieren. Das geht bisher noch nicht sicher. Wenn man also heute feststellen muß das ein Passwort in einer EXE absolut unsicher ist so liegt das nur daran das es noch keine durchgängige "Kryptographisierung" der Daten vom Hersteller einer Software bis hin zum Endkunden-Gerät existiert. Aber das wird kommen. Man kann also heute über die Protected Storage und dem Cryptographic Service Provider im Windows sehr wohl Daten sicher im Speicher ablegen. Das Problem ist nur wie man diese Daten über die eigene Anwendung dahin tranportiert. Falls diese Daten durch die Anwendung dynamisch erzeugt wurden so ist dies kein Problem. Ein Passwort hardcoded in der EXE gespeichert ist damit aber immer noch nicht sicher. Gruß Hagen |
Re: Wie "offen" ist ein Password (String) im Arbei
Ach Hagen ... das wir 2 uns immer in die Wolle bekommen ist komisch. :? (Vielleicht sind unsere Charaktäre zu unterschiedlich: du mit deinem gegen mich mit keinem ;) )
Natürlich hast du Recht. Theoretisch besteht die Möglichkeit auf einem PC ein Passwort im RAM sicher abzulegen. Aber versteh bitte auch mich. Wenn hier jemand fragt, ob sein Passwort im RAM sicher ist, dann gehe ich davon aus, das wir hier von Windows(darüber könnte man sich nocht streiten, aber muss man ja nicht) und aktuell gängiger Hardware reden. Und wie wir schon festgestellt haben, gibt es auf einem solchen System keine Sicherheit dafür, das ein Passwort nicht erschnüffelt werden kann. Warum sollte ich also eine andere Antwort als diese geben? Nur weil es theoretisch möglich wäre, wenn man spezielle HW nutzen würde? Ich denke, der Thread-Ersteller wollte eine präzise Antwort, die er beim nächsten Programmieren nutzen kann. Und eine solche wollte ich ihm geben. |
Re: Wie "offen" ist ein Password (String) im Arbei
Benjamin, ich glaube du nimmst das alles zu persönlich. Klar greife ich eine spezifische Meinung/Aussage an, bzw. versuche einfach nur Irrtümer aufzuklären oder noch zusätzlich interessantes Wissen mit zu geben. Das hat aber rein garnichts damit zu tun WER diese Meinung/Aussage getroffen hat. Es ist mir also Schnuppe ob du oder ein Anderer oder sogar ich selbst diese Aussage getroffen hat.
Es ist zwar richtig wenn man versucht ausschließlich nur auf die Frage zu antworten und dabei nicht Offtopic zu werden. Aber das ist mir einfach zu trocken und verdirbt mir jeglichen Spaß an einem Forum. Also gerade weil man hier in den Threads Persönlichkeiten/Menschen antrifft die natürlich auch ihre persönlichen Meinungen offenbaren macht mir das so viel Spaß. Wenn also meine Ausführungen über die, meiner Meinung nach, in naher Zukunft existenten Möglichkeiten zwar Off Topic sind so finde ich es denoch interessant. Und ich meine eben das das nicht nur für mich interessant sein dürfte. Ergo: poste ichs hier. Die eigentliche Eingangsfrage ist ja auch schon mit den ersten 3-4 Postings beantwortet worden und die nachfolgenden Postings betrachte ich nur noch als interessante Randinformationen. Zitat:
Aus meiner Sicht sind wir eben NICHT aneinander geraden sondern nur unsere unterschiedlichen Ansichten. Tja, und es ist auch gut so das es unterschiedliche Ansichten gibt, das ist doch das Normalste der Welt. Gruß Hagen |
Re: Wie "offen" ist ein Password (String) im Arbei
Committed;
:) |
Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
Ab dem Zeitpunkt der Eingabe befindet sich das Passwort im Speicher der Applikation, wobei gefragt wurde wie sicher eben genau dies ist (unabhängig davon, ob die Verschlüsselung nun in einer DLL oder wo auch immer stattfindet). Zitat:
|
Re: Wie "offen" ist ein Password (String) im Arbei
@Phoenix:
ja dies stimmt auch ;) Ich gehe also davon aus das der Computer des Clients NICHT kompromittiert wurde. Denoch betrachte ich auch den Worstcase und der ist erreicht wenn ich davon ausgehen muß das der Client und sein Rechner ein Angreifer sind. Und wenn wir nun beide Annahmen vergleichen so ergibt sich folgendes Bild: 1.) Generalschlüssel in der EXE hardcoded gespeichert: - Angreifer kann erfolgreich ALLE Benutzer der Software kompromittieren, offline - Angreifer kann somit an ALLE Benutzerdaten rankommen 2.) kein Generalschlüssel und Benutzer verschlüsseln ihre Daten mit einem eigenen Passwort - Angreifer muß alle Clienten/Rechner kompromittieren, ein ungleich höherer Aufwand, meistens online - Angreifer kommt bei einem kompromitierten System/Client nur an dessen Daten ran Also selbst unter der Annahme das die Clients und deren Rechner Angreifer darstellen ergeben sich auf Grund des unterschiedlichen kryptographischen Konzeptes ganz andere Sicherheitsschrabken. Gruß Hagen |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 05:37 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz