Hallo Leute, Ich will in meinem vb.net Programm eine Funktion einbauen, welche das Programm, z.bsp. beim Erkennen eines Debuggers, gezielt abstürzen lässt. Das Programm wird aber noch zusätzlich mit einem Obfuscator/Protector geschüzt. Wichtig auch: Keine Adminrechte vorhanden. Also fallen Api Dinge wie WriteProcessMemory weg. Folgende Ideen sind mir eingefallen: In einer Schleiffe alle Controls auf Nothing setzen. Danach die Thread Priorität auf Low setzen Danach eine Endlosschleife starten. Dann würde das Programm hängen und ein Dumper könnte kein Memoryimage mehr ziehen, oder? Alle Ideen sind willkommen!
30 Jahre alte Konzepte fuer einen banalen Kopierschutz ... und wie willst du einen Debugger erkennen ?
omg schrieb: > warum beendest du dein Programm nicht einfach? Ganz einfach. Würde ich das Programm mit z.bsp end oder failfast beenden, kann man das Beenden abfangen und danach einen memorydump erstellen. Mit einem kontrollierten zerstören ost der dump unbrauchbar.
Purzel H. schrieb: > 30 Jahre alte Konzepte fuer einen banalen Kopierschutz ... und wie > willst du einen Debugger erkennen Drinn schrieb: > omg schrieb: > >> warum beendest du dein Programm nicht einfach? > > Ganz einfach. Würde ich das Programm mit z.bsp end oder failfast > beenden, kann man das Beenden abfangen und danach einen memorydump > erstellen. > Mit einem kontrollierten zerstören ost der dump unbrauchbar. Check for managed debugger Check for unmanaged debugger Check for remote debugger Check debug port Detach from debugger process Check for kernel debugger Hides current process OS thread ( managed threads soon ) Scan and Kill debuggers (ollydbg, x32dbg, x64dbg, Immunity, MegaDumper, etc) Die Tools und deren Funktion sind ja bekannt. Aaber: Um das geht es nicht! Es geht darum, aktiv gegen den Debugger/Dumper vorzugehen und sowenig bzw. so unnütze Informationen wie möglich preiszugeben.
Das klingt sehr interessant! Hast du die Möglichkeit zu erkennen ob ein Debugger oder Dumper aktiv ist? Es gab einmal vor Jahren (glaube ich Medion) dass eine Software erkennt ob sie in einer VM läuft und dann jeden Blödsinn unterbunden hatte um normal zu laufen. Diese Erkennung könnte auch für Debugger genutzt werden?
Ob eine Software die in VB geschrieben ist wohl so interessant ist dass sie jemand auseinandernehmen wollte?! Man kann im Debugger alles instrumentieren, mit Breakpoints an den richtigen Stellen kann man alle Debugger-Prüfungen "false" zurück liefern lassen. Man kann sich eine History des Speicherabbilds aufbauen lassen, sodass egal was du überschreibst, jeder Zustand rekonstruierbar ist. Die einfachste und effektivste Möglichkeit eine Anwendung zu schützen ist es, sie serverseitig laufen zu lassen, z.B. als Web-Anwendung. Wird dann halt mit VB schwierig.
Habe ich einen Beitrag vorderbei schon geschrieben. Check for managed debugger Check for unmanaged debugger Check for remote debugger Check debug port Detach from debugger process Check for kernel debugger Hides current process OS thread ( managed threads soon ) Scan and Kill debuggers (ollydbg, x32dbg, x64dbg, Immunity, MegaDumper, etc) GetSysTickcount Die ANTI Antidebugger Tricks sind mir bekannt. Das ist nicht das Problem. Aber nochmals: Um das geht es nicht.
Programmierer schrieb: > Ob eine Software die in VB geschrieben ist wohl so interessant ist dass > sie jemand auseinandernehmen wollte?! Gilt ebenso für C#. Sobald du den Debugger startest, schlägt die Erkennung zu! Das ist nicht das Thema!
Drinn schrieb: > Aber nochmals: Um das geht es nicht. Das ist alles nur Trickserei, die im Endeffekt nichts bringt. Im Gegenteil fordern solche Spielereien doch nur dazu heraus, sie zu knacken. Aber wenn du unbedingt eine Antwort willst: Überschreibe halt das Datensegment und den Stack mit Nullen. Ob danach eine Endlosschleife oder ein abort() kommt ist egal. Bringt natürlich nichts, man macht den Memory Dump halt vor dem Überschreiben. Drinn schrieb: > Sobald du den Debugger startest, schlägt die Erkennung zu! Den Debugger startet man natürlich vorher, stoppt das Programm direkt zu Beginn (noch vor dem Startup-Code und der main), und lässt die Erkennung immer false zurückgeben, egal was sie findet. Oder einfach im Programmmabbild praktisch ein "return false;" direkt an den Anfang der Erkennungsfunktion einbauen. Ist eine Fingerübung. Dann das Programm laufen lassen und es sieht den Debugger nicht mehr...
Drinn schrieb: > Habe ich einen Beitrag vorderbei schon geschrieben. > > Check for managed debugger > Check for unmanaged debugger Und ich habe gefragt wie man das umsetzt in code! Eventuell missverständlich gewesen, aber als Programmierer sollte man verstehen was damit gemeint war Drinn schrieb: > Programmierer schrieb: >> Ob eine Software die in VB geschrieben ist wohl so interessant ist dass >> sie jemand auseinandernehmen wollte?! > > Gilt ebenso für C#. > Sobald du den Debugger startest, schlägt die Erkennung zu! > > Das ist nicht das Thema! Das Problem war wohl die Zeichenfolge "VB". Da bekommen einige hier Bluthochdruck...
:
Bearbeitet durch User
Du kannst das Programm nicht einfach durch einen Debugger (oda,Olly,...) jagen, da es noch durch SmartAssembly geschützt ist. Die nochmalige Erkennung soll ja genau das Gemeine sein. Aber: Darum geht es nicht. Ab jetzt ist die Voraussetzung C#. Stack kann nicht überschrieben werden, weil es Assembler in C# nur mit Tricks und Adminrechten spielt.
Drinn schrieb: > Du kannst das Programm nicht einfach durch einen Debugger > (oda,Olly,...) > jagen, da es noch durch SmartAssembly geschützt ist. > Die nochmalige Erkennung soll ja genau das Gemeine sein. > > Aber: Darum geht es nicht. > > Ab jetzt ist die Voraussetzung C#. > > Stack kann nicht überschrieben werden, weil es Assembler in C# nur mit > Tricks und Adminrechten spielt. Wie schaut bei dir der C# Code aus um einen Debugger zu erkennen?
Content B. schrieb: > Das Problem war wohl die Zeichenfolge "VB". Da bekommen einige hier > Bluthochdruck... Das hat alles so ein Bisschen was vom jugendlichen Hobbyprogrammierer der auf 587 Zeilen eine "geniale" Anwendung geschrieben hat, in VB halt weil er das in der Schule gelernt hat, und die jetzt gegen alle bösen Hackertricks schützen muss wegen all der Neider, die die nie zuvor dagewesenen Algorithmen klauen wollen. Wer es mit Anti-Debugger-Maßnahmen ernst meint, muss sich sowieso mit Assembler & Co auskennen und sollte auch kein Problem damit haben sein Programm abstürzen zu lassen... Drinn schrieb: > Du kannst das Programm nicht einfach durch einen Debugger > (oda,Olly,...) > jagen, da es noch durch SmartAssembly geschützt ist. Doch klar. Es braucht halt nur etwas mehr Arbeit sich durchzuwühlen. Es sind ja lediglich die Bezeichner zerwürfelt. Damit wird es gerade mal so schwierig wie eine native Anwendung zu reverse engineeren... Drinn schrieb: > Stack kann nicht überschrieben werden, weil es Assembler in C# nur mit > Tricks und Adminrechten spielt. Quatsch, du kannst von managed Code aus immer direkt auch nativen Code ausführen, und der kann Assembler sein. Wobei es auch C tun sollte.
Nochmals NICHT auf die bezogene Frage zurückkommend: VB kam vom Kunden. Nicht von mir. Normalerweise C++ oder eben immer mehr C#. Es geht hier sowieso ums Framework. Da ists egal welcher "Slang". Hobbyprogrammierer. OK. Dann kann der Hobbyprogrammierer schon seit 25 Jahre davon Leben. Durch den Code durchwühlen wird intressant, bei einem signierten Packer. (Darum kann ich auch nicht die Sektion überschreiben) Der CRL (wir erinnern uns auf .net) kann von sich aus keinen unmanaged Code ausführen. Der muss über Marshalling importiert werden. Eine externe Dll zum abschiessen der Anwendung importieren? DLL Injection???? Dein Ernst??? Nochmals: Das ist nicht die Frage gewesen. Vergesst endlich das Debugging! Akzeptiert es als "Unknackbare Blackbox"! Ausgangslage wird generell nun als .net festgelegt. Egal ob J# oder C#. Die anderen zwei Buchstaben erwähn ich gar nicht mehr.
Drinn schrieb: > Vergesst endlich das Debugging! > Akzeptiert es als "Unknackbare Blackbox"! Ja gut, damit sind also auch deine super-duper Hacker Konzepte hinfällig..? > .net Du kannst hier nicht beliebig alle 5 Minuten die Sprache wechseln. Dir ist selber schon aufgefallen, dass manche Konzepte in X funktionieren und in Y garnicht existieren.
In der .net Welt ist die Version fast essentiell. Es geht jetzt generell um .net
Mach dir doch nicht so einen Aufwand. Jedes VB(.net) und C# Geraffel stürzt früher oder später ab. Das liegt in der Natur der Dinge.
Drinn schrieb: > VB kam vom Kunden. Nicht von mir. Normalerweise C++ oder eben immer mehr > Hobbyprogrammierer. OK. Dann kann der Hobbyprogrammierer schon seit 25 > Jahre davon Leben. Und nun hat der Hobbyprogrammierer ein Problem, das er nicht lösen kann und darum eben nicht mehr davon leben kann also soll ihm gefälligst eine community dabei helfen das Problem zu lösen, damit er wieder davon leben kann? Schuss und Knall und hören und so, ne?! Mach deine Hausaufgaben und gut is. Alternativ Stackoverflow.
Normalerweise habe ich mit den .net Apps noch keine Schwierigkeiten. Unter Mono sieht Das aber anders aus. Ja. Genau. Ich frage, ob jemand eine originelle Lösung kennt und darum kann man nicht programmieren X-) Schade, dass man Dir ständig nur den Neid raushört, obwohl du so gut bist und deswegen keinen Lösungsvorschlag gemacht hast. Frage scheinbar nicht verstanden aber zehnmal seinen Senf dazugegeben. Sehr professionell !
Falls ich Zeit und den willen haette, wuerde ich das Programm stoppen. zB mit Processexplorer in den Sleep legen, dann bekommt es einfach keine CPU Zeit mehr. Dann kann ich's einfach anschauen. Kann mir welche dumps auch immer machen, denn das Programm schlaeft.
Genau da ist schon der erste ungemütliche Teil zum Debuggen: Processexplorer gestartet -> Absturz -> Dump fehlerhaft So. Grade gezählt. Nun zum 6. Mal: Um das geht es nicht. Es geht darum, die Anwendung so schnell und Variablen/Thread/Control verändernt/vernichtent wie möglich abzustürzen zu lassen. Ohne Adminrechte. In .net .
Dann zum 7. Mal: egal, was du da auch bastelst, wenn es jemandem wert ist, die Software zu re-engineeren, dann wird das jemand tun. Wenn nicht, ist’s eh egal. Oliver
Es geht auch nicht um einen Norkorianischen Berufs bzw. Zwangshacker. Wenn es einem Wert ist, wird er das Ding neu schreiben. Aber wiedermal eine Themaverfehlung. Respekt.
Im MSDN bin ich endlich fündig geworden! Zuerst alle Objekte auf Nothing setzen und dann mit dem .net Garbage Collector ein collect ausführen. Wenn ich dazukomme, werde ich einen Artikel zum Thema Antidebuging in .net schreiben. Es ist schon klar, dass der Eine oder Andere das Programmieren erfunden hat. Aber den Ein oder Abderen, hilft es weiter, spart seine Entwicklungszeit oder ist einfach nur ein Denkabstoss für was raffinierteres. Also Danke nochmals, dass ich eure Zeit verschwenden durfte und noch schöne Weinachten, Euer Drinn
Hallo, ich finde den ganzen Ansatz insbesondere mit .net sehr unnötig. Wer in der Lage ist, so einen Dump zu machen, der wird auch in der Lage sein das übersetzte Programm in der CIL zu editieren, und deine aufwendig erstellten Hindernisse einfach zu löschen.
gamp schrieb: > Wer in der Lage ist, so einen Dump zu machen, Jeder mit z.bsp. IDA gamp schrieb: > der wird auch in der Lage sein das übersetzte Programm in der CIL zu > editieren, und deine aufwendig erstellten Hindernisse einfach zu > löschen. Gehört ein bischen mehr dazu. Nochmals. Das Programm wird mit smartassembly geschützt. Es ist bis jetzt noch nicht bekannt, das die neue Version geknackt wurde. Meine Mechanismen swtzen schon im Vorfeld an. Startest du eines dieser speziellen Tools, ist das Programm schon nicht mehr da. Startest du das Programm über den Debugger, greift SmartAssembly UND 10 ms später mein System. Ja ich weiss. Jeder ist in der Lage die AES512 so nebenbei zu knacken. Also. Vergesst es. @Moderator: Bitte nach /dev/null verschieben.
Drinn schrieb: > Startest du das Programm über den Debugger, greift > SmartAssembly UND 10 ms später mein System. Du verstehst es nicht. Wenn man das Programm in den Debugger lädt, LÄUFT ES NICHT. Es ist direkt vom Anfang an GESTOPPT. Es kann also NICHT auf irgendwas reagieren oder irgendwas löschen. Der Debugger kann dann nach Belieben Breakpoints setzen, den Code umsortieren, deine "CheckDebugger"-Funktion oder die von SmartAssembly einfach auf "return false;" umbauen, whatever. Erst DANN wird dein Programm gestartet, und dann gibt CheckDebugger leider immer false zurück. Drinn schrieb: > Ja ich weiss. Jeder ist in der Lage die AES512 so nebenbei zu knacken. Das Programm entschlüsselt sich doch freundlicherweise selbst. Jeder Code, der auf die CPU geht, muss entschlüsselt sein. Man muss bloß ans Ende der Entschlüsselungsroutine einen Breakpoint setzen, dann kann man den entschlüsselten Code beliebig manipulieren.
Und warum wurde das noch nicht geschaft, das bischen return false? Warum sind bei Woodman noch alle damit überfordert? (In deinen Augen sicher alles VB Hobbyprogrammierer) Warum wurde die Grafis SRM noch nicht aufgemacht? Warum macht Arma den meisten schon Probleme? Warum kennst nur du den OEP des Smartassembly und fixed Handrücks die IAT? Zeigs Ihnen doch, wies geht! BTW: Bist an der Frage wieder vorbei. Gegenfrage bezüglich deiner Auffassungsgabe, der letzten Aufgabenstellung: Programmierst du eigentlich, was der Kunde haben will, oder verbesserst du die FDS insofern, das der Kunde es so bekommt, wie du es für richtig empfindest? Drinn schrieb: > Es geht darum, die Anwendung so schnell und Variablen/Thread/Control > verändernt/vernichtent wie möglich abzustürzen zu lassen. > Ohne Adminrechte. > In .net .
Drinn schrieb: > Und warum wurde das noch nicht geschaft, das bischen return false? Entweder weil diese Softwares so primitiv sind dass es sich nicht lohnt, oder weil man keine Lust auf die rechtlichen Konsequenzen hat. Ein Nachbau hat auch den Vorteil dass man ihn verbessern und legal vermarkten kann. Im Gaming-Bereich wird auch jeder Kopierschutz ruckzuck geknackt, und da ist das nochmal schwieriger (native Anwendungen). Eine rein offline arbeitende App kann man einfach nicht schützen. Drinn schrieb: > Zeigs Ihnen doch, wies geht! Bezahlst du mir das?
Programmierer schrieb: > Drinn schrieb: >> Zeigs Ihnen doch, wies geht! > > Bezahlst du mir das? PS: Und den Anwalt und die Schadensersatzforderungen natürlich auch!
Wieso lieferst du das Prg. denn als Debug-Version aus.??? Ich habe in VB die Möglichkeit eine RELASE-Version auszuliefern. Da sind 0 Debug-Infos drin. Entweder ich fange den Fehler ab, oder es kackt ab. Davon mal abgesehen. Es gab damals ein Re-Compiler der die ganze Show wieder zurück schreibt. K.a. ob der mit den aktuellen Versionen zurecht kommt. Ist zwar ne saumäßige Arbeit die neuen Variablen-Namen logisch zuzuordnen aber ES GING. Ich hatte es nicht nötig meine Software zu schützen. Meine Kunden damals wollten ja, das die Software verteilt wird.
Was machst du eigentlich wenn ich den Dumper nach HansGuckInDieLuft.exe umbenenne? Findest du den immer noch? Was wenn ich deinen Prozess einfach an einem beliebigen Zeitpunkt im Task Manager suspendiere, sodass er nichts mehr tun kann und ich in aller Ruhe den Debugger, Dumper o.ä. anwerfen kann? Oder darf man nichtmal den Task Manager starten wenn dein Programm läuft weil es den auch als "böse" erkennt? Deine Kunden werden es lieben! ... Oder was wenn ich eine eigene suspendierer.exe schreibe die genau das tut? Was wenn ich ein rootkit schreibe, welches sich versteckt, damit in der Prozessliste nicht sichtbar ist (ist ja kein Problem mit Adminrechten) und dann dein Prozessimage dumpt bzw. den Prozess anhält?
Schlaumaier schrieb: > Es gab damals ein Re-Compiler der die ganze Show wieder zurück schreibt. Dieser Satz zeigt, das du Smartassembly nicht kennst. Sobald du den Task durch deinen Debugger freigibst, stürzt er ab. Sobald du den Dump startest, stürzt er ab. Warum? SmartAssembly. Man sieht, du kennst das Programm gar nicht. Ich frage mich, warum ich überhaupt mit dir über ein Thema diskutiere, der überhaupt nichts mit der letzten Frage (wie immer) zu tun hat. "Was ist 1 x 5" "Ich weiss es! 5 x 7 = 56, weil mich ihre Aufgabenstellung gar nicht intressiert, ich aber glaube auf eine anderes Problem die richtige Antwort zu kennen."
Drinn schrieb: > Warum? SmartAssembly. Ist das hier ne Werbung für Smartassembly, den Stein der Weisen, den einzig sicheren Kopierschutz der Welt? Drinn schrieb: > Sobald du den Dump startest, stürzt er ab. Es kann nicht abstürzen, wenn der Prozess VORHER suspendiert wurde und keine Rechenzeit bekommt...
Soll keine Werbung sein. Die section ist signiert. Du bist Deiner bewusst, was das heißt? Und was für Konzequenzen es nun nach sich zieht, wenn der Tickcount anders ist, geschweige den, nur ein OPCode geändert wird. Ich mach hier Schluss. Deine kleinen Crackversuche waren früher mal was wert. Probiers einfach aus. Vom Protector gibts auch eine Demo. Dann kannst du deine Threads abhalten was du willst. Aber schreib es ja nicht im bösen, bösen, VB !
Drinn schrieb: > Die section ist signiert. > Du bist Deiner bewusst, was das heißt? Wer prüft die Signatur? Etwa das Programm selbst? Also da wo man einfach die Funktion CheckSignature durch "return true;" ersetzen kann? Oder den Public Key, gegen den geprüft wird, einfach gegen einen anderen ersetzen, nachdem man manipuliert und neu signiert hat? Drinn schrieb: > wenn der Tickcount anders ist Der Tick Count vom Windows API? Ersetze ich einfach durch irgendwas anderes. Immer 0 vielleicht? Win32 APIs sind so einfach umzubiegen, weil sie indirekt geschehen. Drinn schrieb: > Deine kleinen Crackversuche waren früher mal was wert. Du verstehst es offenbar nicht. Ich habe Vollzugriff auf die Maschine. Ich kann dem Programm alles vorgaukeln, es beliebig manipulieren. Alle Instruktionen die am Prozessor ankommen kann ich auch sehen, und auch alles was im Speicher landet. Ich kann auch einfach den Prozessor komplett emulieren. Dann sieht der Emulator ALLES was dein Programm tut. Aber alles viel zu kompliziert. Einfach im Task Manager den Prozess einfrieren und dann den Prozess dumpen... Bis zum Einfrieren muss der Dumper/Debugger nicht mal installiert sein. Das OS kann jungfräulich sein. Und wenn der Prozess eingefroren ist, kann er eh nicht reagieren und ich kann alles damit machen. Drinn schrieb: > Dann kannst du deine Threads abhalten was du willst. Es ist viel witziger zu sehen wie du dieser Snakeoil-Software huldigst ohne die Angriffsszenarien überhaupt zu verstehen...
Programmierer schrieb: > Angriffsszenarien überhaupt zu verstehen... Ich weiß, sie haben das Programmieren erfunden. Ihre Vorfahren haben ja bereits in Babylonien die Keilschrift erfunden. Jeder rechnet mal eben so schnell eine AES Verschlüsselung zurück. Nein,stopp. Nicht jeder. Nur Sie können das. Ja, Sie sind der Mann des Tages, weil sie jeden Public Key mir nichts, dir nichts erzeugen können! Fähiger Mann. Und vermögent, weil seine Wenigkeit alle Preise aller Challenges erhalten hat. Aso. Muss er ja nicht. Er ist ja der Herr, der Verschlüsselungen. Ich würde es Profilierungsneurose nennen.
Drinn schrieb: > Jeder rechnet mal eben so schnell eine AES Verschlüsselung zurück. > Nein,stopp. Nicht jeder. > Nur Sie können das. > Ja, Sie sind der Mann des Tages, weil sie jeden Public Key mir nichts, > dir nichts erzeugen können! Immerhin weiß ich dass AES keine public/private Keys hat, weil es eine symmetrische Verschlüsselung ist. Public Keys muss man auch nicht erraten, sie sind ja Public, öffentlichen! Außerdem muss ich da gar nichts berechnen. Das Programm entschlüsselt sich ja selbst beim Start. Das lasse ich einfach durchlaufen... und der Key ist ja auch da, oder fällt der vom Himmel? Also im Zweifelsfall einfach nur den Key aus der .exe fummeln und mit einer der Tausend AES-Implementationen entschlüsseln. Etwas interessanter wird es bei der Signatur, und die hat einen Public Key, aber das ist ja kein AES sondern wahrscheinlich RSA. Jedenfalls kann ich einfach mein eigenes public/private Schlüsselpaar generieren, die Anwendung neu signieren und den Public Key ersetzen. Oder halt einfach die Prüfung ersetzen/lahmlegen. Oder nach der Prüfung die Manipulation beginnen oder das Programm anhalten.
Ja. Grosser. Ja. Probiers aus, dann reden wir weiter. Muss nicht das Tool sein. Nimm den .net Reactor. Aber eine Version grösser 6.5.
Drinn schrieb: > Probiers aus, dann reden wir weiter. Wozu? Ich weiß dass es funktioniert. Probier du es doch aus. Starte dein ach so tolles Programm. KlickeStart->Ausführen, gib resmon ein, Enter. Suche deinen Prozess in der Liste, Rechtsklick, "Suspend Process". Dann kannst du den Debugger deiner Wahl starten und dich an den Prozess anhängen und was auch immer damit machen. Viel Spaß! Auch schön: https://www.codeproject.com/Articles/230005/Launch-a-process-suspended
> Genau da ist schon der erste ungemütliche Teil zum Debuggen:
Processexplorer gestartet -> Absturz -> Dump fehlerhaft
Das geht aber so nicht. Denn bei mir ist der Prozess Explorer immer am
Laufen. Bedeutert dein Programm laeuft nie. Maengelruege - Geld zurueck.
Ein normaler Bueroanwender hat keine Debug Tools am laufen. Würdest die Software e nicht kaufen, weil mit HASP SRM verdongelt.
Programmierer schrieb: > Du verstehst es offenbar nicht. Ich habe Vollzugriff auf die Maschine. > Ich kann dem Programm alles vorgaukeln, es beliebig manipulieren. Alle > Instruktionen die am Prozessor ankommen kann ich auch sehen, und auch > alles was im Speicher landet. Ich kann auch einfach den Prozessor > komplett emulieren. Dann sieht der Emulator ALLES was dein Programm tut. > > Aber alles viel zu kompliziert. Einfach im Task Manager den Prozess > einfrieren und dann den Prozess dumpen... Bis zum Einfrieren muss der > Dumper/Debugger nicht mal installiert sein. Das OS kann jungfräulich > sein. Und wenn der Prozess eingefroren ist, kann er eh nicht reagieren > und ich kann alles damit machen. Du hast natürlich im Prinzip recht :-) In der Praxis schaut es aber anders aus. So einfach lässt sich ein guter Kopierschutz nicht umgehen. Da werden z.B. nur die gerade benötigten Programmteile entschlüsselt, und der Schlüssel ist auf viele Teile aufgeteilt. Die Leute die viel Geld für einen Kopierschutz ausgeben sind ja auch nicht blöd...
Stefan P. schrieb: > Einfach irgendwas durch 0 teilen. Schmeisst nur eine Exception. Die Zeiten waren mal. udok schrieb: > So einfach lässt sich ein guter Kopierschutz nicht umgehen. > Da werden z.B. nur die gerade benötigten Programmteile entschlüsselt, > und der Schlüssel ist auf viele Teile aufgeteilt. > Die Leute die viel Geld für einen Kopierschutz ausgeben sind ja > auch nicht blöd... Nein,das stimmt doch nicht. Wir alle sind blöd. Nur einer ist hier der Obermaker. Der knackt alles. Selbst die Packer, die in bekannten Kreisen als (bisweilen) unantastbar gelten. Das ist das Problem mit den Theoretikern. Keine Ahnung, aber uralte Theorien zu Tage fördern.
Drinn schrieb: > Wir alle sind blöd. Du kennst ja nichtmal den Unterschied zwischen AES und Public-Key. Und das nach 25 Jahren Erfahrung? Ha! udok schrieb: > So einfach lässt sich ein guter Kopierschutz nicht umgehen. Nein, einfach ist es nicht. Aber es ist prinzipbedingt nie unmöglich. Ein Prozessabbild ziehen ist hier aber das geringste Problem... Die normalen Variablen sind ja prinzipbedingt unverschlüsselt, und um die geht es ja die ganze Zeit. Drinn schrieb: > Selbst die Packer, die in bekannten Kreisen als (bisweilen) unantastbar > gelten. VB ist in Excel-Kreisen auch der heilige Gral! Es ist einfach eine Kosten-Nutzen-Anwendung. Es wäre sicherlich spannend das ganze zu knacken, aber was hab ich davon? Eine gratis Unterlassungsklage? Da kann ich mir ne schönere Freizeitbeschäftigung vorstellen.
>bzw. so unnütze Informationen wie möglich preiszugeben.
Was machst Du gegen decomplieren, was sehr einfach bei C#/Vb.net
Applikationen ist?
Keine Ahnung, was SmartAssembly neben Obfuscating noch so alles macht. Sofern das geschützte Programm am Ende aber mit einer Runtime basierend auf der CoreCLR läuft, würde ich als Angreifer schauen, ob ich diese nicht gegen eine modifizierte Variante ersetzen kann. Irgendwann muss die Assembly geladen werden, Strings entschlüsselt werden, der CIL-Code durch den JIT-Compiler, etc. An all diesen Stellen könnte man innerhalb der Runtime einhaken.
Dirk schrieb: > Was machst Du gegen decomplieren, was sehr einfach bei C#/Vb.net > Applikationen ist? So. Der Typ ist die Krönung. Aber man sieht, wie genau die Aufgabestellung durchgelesen wurde. Drinn schrieb: > Es geht darum, die Anwendung so schnell und Variablen/Thread/Control > verändernt/vernichtent wie möglich abzustürzen zu lassen. Kinderspielplatz hier .....
Drinn schrieb: > Kinderspielplatz hier ..... Was solls schrieb: > Was willstn machn, alter Sack? > Du dumm. Du kapieren? Antworten auf seine Fragen wurden nicht geliefert. Seine Frage hat er sich aber selbst schon beantwortet. Und nun? Der Eine ist der beste Hacker. Der Eine ist der beste Anwendungsschützer. Und dann gibt es die Leute wie mich, die sicher nicht alles von euch zwei Idioten durchlesen! Ich glaube der Beitrag sollte nun "Anti Debugging Schutz möglich - Pro und Contra" heissen. Für mich liest sich das wie eine Werbung für das Schutzprogramm.
Programmierer schrieb: > VB ist in Excel-Kreisen auch der heilige Gral! Sicher nicht. Das ist VBA und hat mit VB.net ungefähr so viel zu tun wie Sackratten mit Zwergantilopen. Sprich: es gibt sicher einen kleinen Teil gemeinsames Erbgut im Genom, aber das war's auch schon.
Kann es sein, dass Eure Hotline unter chronischem Arbeitsmangel leidet? Was ist z.B. wenn jemand "sein" Programm entwanzen will/muss, während Du Dir die Ressourcen geschnappt hast? Oder willst Du ins Manual den biblischen Passus: Du sollst nicht... aufnehmen.
Es gibt Packer, die Ihre eigene VM mitbringen. Das Programm wird also quasi in dieser VM ausgeführt. Das ist richtig sicher. Da siehst du in der CPU nicht viel, weil alle Security Features der CPU ausgereizt werden. Auf den Speicher kannst du zugreifen, aber das ist alle verschlüsselt. Wie Die das machen weiß ich aber nicht. Aber die Preise für die Lizenzen.... Hatten wir mal bei einer grösseren Bank vorgeschrieben bekommen. Angeblich beim Militär auch recht gross. Aus Israel. Hat der TO eigentlich jemals erwähnt, was sein Programm macht? VB ist doch nur was für Hobbyprogrammierer. So wie ein Arduino für Hobbyelektroniker.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.