In einer der unseren Geraeten ist so was drin - uralt, leider der PIC in einem Geraet defekt ist (Schweissanlage, keine Transil am Eingang !!!). Das EEPROM laesst sich problemlos auslesen, lediglich wie koennen wir die Daten interpretieren ? Es ist kaum drin .....
Im zweiten Geraet ist die ganze Briefmarke noch in Ordnung. Wir moechten dieses altes Mosul mit etwas neueres ersetzten, bloss die Inhgalt des PICs ist natuerlich auslesegeschuetzt. Beshalb eine Idee den BASIC-Programm auszulesen und selbst implementieren. Laesst sich ueberhaupt das Programm auslesen ?
Kann vielleicht jemand helfen ? Im voraus besten Dank !
MfG
--
Grzegorz Zalot
complex ltd.
office tel/fax : +48 32 2505840
mobil : +48 501 301515
http://www.complex.org.pl/
mailto:complex@alpha.pl
Am billigsten ist es, wieder neue Stamps einzusetzen, EEPROM sicherheitshalber auslesen und kopieren. Einen 'offiziellen' Weg vom TokenCode zurück ins Basic gibt es wohl nicht. Im EEPROM selbst ist kein Basic. Die Parallax Leute könnten das sicherlich, aber ich vermute, die werden das als reverse engineering Versuch auffassen und verweigern. Fragen kostet freilich nix.
Der Programmierer/Quellcode ist nicht mehr aufzutreiben?
Da die Programme in einer Stamp nicht sonderlich komplex sein können, sollte sich das Programm doch schon aus dem Steuerungsverhalten extrahieren lassen.
Den will ich sehen, der aus Assembler wieder einen Hochsprachencode zurechtzimmert. Okay, BASIC ist jetzt nicht gerade eine _Hoch_sprache, ist aber IMHO trotzdem nicht möglich. Genausowenig wie ich aus meinen Win32-Applikationen wieder Sourcecode machen kann.
Grundsätzlich kann man natürlich aus jeder Applikation im Binärformat immer auch wieder einen übersetzbaren Sourcecode machen. Das ist nur eine Frage des Aufwands, den man dafür betreiben möchte/kann.
Richtig. Nur wenn der Aufwand des Neuprogrammierens unter dem des "zurückübersetzens" liegt, dann macht es halt einfach keinen Sinn. Da hab ich mich unklar ausgedrückt. Deswegen bezweifele ich ja auch dass es die Parallax Leute (hier jetzt nicht "können") machen würden.
Ich frage mich wie du zu dieser naiv-arroganten und anmaßenden Unterstellung kommst. Bevor du solche Äußerungen machen kannst würde ich vorschlagen du liest erstmal was über das Thema.
formatting link
Und dann könenn wir weiterreden über die Komplexität von Compilern, Compileroptimierungen und sonstiger Stolpersteine. Oder du beweist mir einfach das Gegenteil und schickst mir mal eben den Quellcode deines "Microsoft Internet News" Readers zu, ich bin wirklich sehr gespannt.
Erfahrung Johannes, Erfahrung. Erfahrung die du offenbar nicht hast.
a) Jemand der programmieren kann, richtig programmieren kann, weiss was sein Compiler aus dem Hochsprachenquellcode macht, weil er es schon x mal beobachtet, kontrolliert und edukativ betrachtet hat. Ja, auch Real Programmers benutzen mal den Debugger, und finden damit gar Fehler ihres Compilers (wir haben bisher 3 echte Compierfehler in Borland C++
4.5 und 3 in Microsoft C++ 6.0 gefunden).
b) "Been there done that" sagt Oliver. Ich habe einige Dutzend Programme in ihren Quellcode, ob Assembler, Pascal oder C zurueckverwandelt, aber jemand wie du "Den will ich sehen, der aus Assembler wieder einen Hochsprachencode zurechtzimmert." kann sich so was offenbar noch nicht mal theoretisch vorstellen.
c) Du kannst dir auch mal ueberlegen, wie gross der Abstand zwischen
formatting link
und einem C-Decompiler ist. Der ist naemlich gar nicht so gross. Also ueberleg dir, wem du so einen Antwort schreibst. Das dein urspruengliches ÖPosting unueberlegter Unsinn war, hast du immerhin inzwischen selbst eingesehen (Siehe "Richtig" als Antwort auf Heiko).
Es spricht nichts dagegen, das der Decompiler die Optimierung mitnimmt bei 'rueckuebersetzen'. Er muss ja nicht dasselben unoptimalen Quelltext erzeugen, wie ihn der urspruengliche Programmierer geschrieben hat. Er muss halt bloss syntaxfehlerfreien Hochspreche erzeugen, bei manchen Optimierungen die in der Hochspreche nicht abbildbar sind also die 'Ausgangskonstrukte' erzeugen.
Hier gilt:
! Nur wenn der Aufwand des Neuprogrammierens unter dem des ! "zurückübersetzens" liegt, dann macht es halt einfach keinen Sinn.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Hast Du doch selber zugestanden mit Deinen Aussagen.
Das ist ja auch absolut mit der "Komplexität" einer Basic Briefmarke zu vergleichen... Danke für den erneuten Beweis, daß Du keine Ahnung hast.
--
everything done. Thank you for downloading a media file containing
proprietary and patentend technology.
--- Meldung von 'mmsclient' nach Download eines mms://-Streams
Ob dus glaubst oder nicht, ich weiß nicht nur wie man Debugger schreibt, ich setze den gdb sogar selber ein.
Einen Code in Assembler "zurückzuverwandeln" ist denkbar einfach. Einen Code allerdings in eine Hochsprache zu verwandeln kann ich mir wohl vorstellen - und da gebe ich dir Recht, dass ich mich ungenau ausgedrückt habe - es ist allerdings ein nahezu unzumutbarer Aufwand verglichen mit der Arbeit, ein Programm neu zu schreiben.
Ich habe nicht die geringste Ahnung wie eine Windows HLP-Datei zusammenegsetzt ist und habe ehrlichgesagt auch nicht die Motivation mich in die Definition einzulesen. Allerdings habe ich mir den Quellcode heruntergeladen, durchgeblättert und es sieht nach einem Haufen Arbeit aus.
Richtig. Ich halte es einfach für spitzfindig zu sagen "Ich kann schon, nur ist es so aufwändig, dass ich es lieber ganz neu mache."
Genau darin liegt das Problem, diese Ausgangskonstrukte "wiederzufinden". Und die verschiedenen Methoden, wie gleiche Konstukte in einer Lowlevelsprache von verschiedenen Compilern in unterschiedlichen Code umgesetzt werden. Plus eventuelle direkt "Einstreuungen" von Assembler, die der Programmierer möglicherweise verwendet hat. Es ist _wirklich_ viel Arbeit. Soviel Arbeit, dass nichteinmal für das primitive Basic Stamp Dingens ein "Decompiler" erhältlich ist.
Bist du in der Lage, "Basic Stamp" Code in ein Hochsprachen (verglichen mit ASM zumindest eine Hochsprache) Basic zurückzuverwandeln? Ich bezweifele es.
Im Übrigen wäre es für viele Leute von viel größerem Interesse, x86-Assembler in einen Hochsprachencode zu verwandeln, als einen Basicstamp-Decompiler zu schreiben. Ergo gibt es auch wohl viel mehr Leute, die sich daran versucht haben. Trotzdem ist noch nichts brauchbares dabei herausgekommen.
Das x86-Assembler noch deutlich schwieriger zurückzuübersetzen ist, da besteht kein Zweifel. Aber noch nichteinmal für Basicstamp-ASM ist ein Decompiler zu finden.
Wiegesagt, der Aufwand ist einfach zu hoch. Theoretisch ist es natürlich möglich, praktisch aber wohl meistens Unsinn.
Das überschätzt du offensichtlich, zumindest ist es in dieser Allgemeinheit formuliert wiederum nicht richtig.
Das hängt nämlich stark von den Eigenheiten des verwendeten Compilers ab, inbesondere von der Vielfalt seiner Optionen und Optimierungsmöglichkeiten.
Z.B. ist es relativ einfach, einen Recompiler für in Delphi geschriebene Programme zu schreiben, da sich beim Borland-Compiler die Zahl der Optionen und Optimierungsmöglichkeiten stark in Grenzen halten und obendrin nennenswerte Anteile der Typinformationen im Binärprogramm enthalten sind. Ein Recompiler dafür kann deshalb so gut sein, daß er in vielen Fällen auch bei nichttrivialen Programmen _vollautomatisch_ sofort wieder übersetzbaren Delphi-Sourcecode generiert.
Der hat natürlich trotzdem relativ wenig mit dem Originalquelltext zu tun (Variablen- Feld- und Methodennamen z.B. sind zwangsläufig nur vom Recompiler generierte Bezeichner) und zur zielgerichteten Änderung des Decompilats ist deshalb immer noch die logische Nachbearbeitung durch einen erfahrenen Programmierer erforderlich. Da sich aber erwünschte Änderungen meist nur auf kleine Details beziehen und man den Delphi-Debugger auf das Recompilat ansetzen kann, hält sich der Aufwand dafür in durchaus überschaubaren Grenzen.
Generell gilt: Je einfacher ein Compiler gestrickt ist, desto einfacher ist auch ein brauchbarer Recompiler dafür zu schreiben.
Ich hatte etwas gefunden - einen "disassembler", der lediglich einen kleinen Fehler hat (OR statt AND ;-) ! ). Nach neukompilation durch STAMP ist dasselbe rausgekommen.
Ein Einsatzt der Briefmarke ich nicht mehr moeglich, weil die Umgebung sehr viel Stoerungen hat. Und sehr oft die Prozessoren kaputt sind - kein Wunder, die Briefmarke hat gar keine Entstoerungselemente.
Naja ich sehe im Internet viele Personen, die einen Decompiler zu illegalen Zwecken benutzen würden. Im Übrigen auch wirklich fähige und hochintelligente Leute. Und einige von denen bieten sehr wohl auf ihren Homepages genügend Tools an (selbstverständlich auch illegal), um Programme zu entpacken und zu disassemblieren/decompilieren. Allerdings sind die "decompilierten" Programme (ich selber habe das schonmal mit dem von dir genannten Delphi getestet) eher nicht zu gebrauchen. Um etwas aus dem Code "herauszulesen" wohl schon, da ists natürlich einfacher (statt ASM-Listing zu lesen), aber neu Compilieren kann man den Mist, der da rauskommt nicht. Und das lauffähig-machen birgt wirklich astronomischen Aufwand.
Naja das Umsetzen von OPCode in MNemonics (Assemblercode), also das disassemblieren, ist trivial. Was aber wohl mit höherem Aufwand (ich drücke mich da jetzt sehr vorsichtig aus) verbunden ist, ist das decompilieren, also das zurückübersetzen in die "Basic"-Sprache.
Spitzfindig ist das nicht, bloss realistisch betrachtet. Viele Dinge 'gehen' sind aber 'zu teuer' so das man's lieber anders macht.
Noe. Compiler sind doof. Du erkennst die Muster von IF, WHILE, CASE, etc. sofort wieder. Sicherlich gibt es denselben Konstrukt in einem ordentlichen Programm tausende Male, weswegen man die Arbeit lieber automatisiert.
Ja, ein Decompiler pro Compiler, sogar pro Compilereinstellung (na ja, zumindest die Muster sind andere)
Nun ja. Sagen wir etwa so viel Arbeit es wie den Compiler zu erstellen.
Das hat meist andere Gruende.
Stell dir vor, morgen sagt jemand: "Ich habe dank Decompiler mal alle Quelltexte von allen Microsoft-Programmen mal auf einen WebServer gestellt"
Dann gibt es Microsoft-Aktien fuer 1 EUR.
So ein Ding ist also eine Wirtschaftsmacht.
So was macht man nicht, um es dann gratis ins Netz zu stellen. Und so was entwickelt man nicht, um dann fuer andere netterweise zu sagen, was der Virus so treibt, wie die Displomarbeit so naiv sagt, die du genannt hast.
Dafuer war die Entwicklung eh zu aufwaendig.
Die finanziert entweder nur das NSA, und sagt dann noch nicht mal das sie so ein Programm haben, oder der Investor will das als Dienstleitung "rette ihre verlorenen Quelltexte" teuer verkaufen, oder gar unter der Hand "sehen sie wie ohre Konkurrenz programmiert" vermarkten.
So ein Kinderkram wie der DCC kratzt nur an der Oberflaeche, das gibt's natuerlich gratis.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
ACK. Ist ja auch nur ein Beispiel in der Arbeit. Wobei selbstverständlich - um die Liste deiner Beispiele zu erweitern - auch Virenprogrammhersteller ein grosses Interesse daran haben, zu sehen, wie die ganzen Würmer und weiß der Kuckuck funktionieren. Das ginge zwar mit einem Debugger auch, bräuchte aber viel fähigere Leute, die eben mehr Geld kosten. Da steckt man das Geld lieber in einen Personenkreis, der dann entsprechende Decompiler entwickelt.
Genau darum gings mir ja.
ACK.
Ist aber ein gutes Beispiel um zu zeigen wie aufwändig das wirklich ist.
Aber da bin ich jetzt schon erleichtert dass hier kein Flamewar loseght, ich dachte schon ich werde morgen mit nem Messer im Rücken tot aufgefunden. Auf jeden Fall sind wir uns einig, dass der Universaldecompiler, der x86 ASM, Java, 8051 und BasicStamp in Basic, Pascal, C++ und Fortran verwandelt ein Multimilliarden Euro Projekt wäre.
Nun, du musst akzeptieren, das in der NG falsche Aussagen (oder Einschaetzungen, dein Posting war ja eine Einschaetzung), nicht unkommentiert durchgehen.
Aeh, nein.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Jein. Je fortgeschrittener der Compiler und je abgehobener die Zielarchitektur, desto fragwürdiger wird das Ganze. Insbesondere, wenn das Ziel nicht nur *irgendein* Quellcode ist, der das gleiche macht, sondern dem Originalcode möglichst ähneln soll.
Fortgeschrittene Optimierungen wie
- loop unrolling
- inlining
- common subexpression elimination
und die weitgehend freie Abbildung von Variablen auf Register (natürlich nicht bei x86, aber z.B. bei RISC-Architekturen) lassen die eigentliche Struktur eines Algorithmus untergehen. Die Abbildung Hochsprache -> Maschinencode ist eben nicht ein- deutig umkehrbar.
Solange wir von Borland-Pascal (da habe ich vor laaanger Zeit mal den generierten Maschinencode inspiziert) & Co reden, hast du recht. Aber ein z.B. g++ Compilat für ULTRASPARC ist doch etwas anders...
LOL
Allein das wäre Grund genug, daß das wirklich mal jemand macht. Aber das ist unergiebig und im Endeffekt auch langweilig.
Als ich noch jung war ;-) habe ich diverse C-64 Software mit dem Maschinensprach-Monitor seziert und dabei eine Menge über Program- mierung gelernt (von Nebeneffekten wie Cracks ganz zu schweigen).
Allerdings war diese Software auch ursprünglich mal in Assembler geschrieben. Wenn ich heutzutage noch etwas über Programmierung lernen will, lese ich ein Buch und (selten) fremden Code. Ganz sicher werde ich dazu aber keine fremden Binärprogramme durch einen Decompiler jagen.
Die einzigen Gründe, warum man so etwas machen wöllte, sind
- Re-Engineering fremder Software (selten mit legalem Motiv)
- verzweifelte Rettungsversuche verloren gegangenen eigenen Codes
XL
--
Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
die anderen sind einfach von sich aus unlogisch. -- Anselm Lingnau
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.