BASIC Briefmarke v1.4 - wie auslesen ?

G

Grzegorz Zalot

Guest
Hallo !

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
 
Grzegorz Zalot schrieb:

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 !
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.



- Carsten

--
Audio Visual Systems fon: +49 (0)2238 967926
Carsten Kurz fax: +49 (0)2238 967925
Fasanenweg 38a email: audiovisual@t-online.de
50259 Pulheim / Germany WGS84:N50°58'44.7" E06°47'03.5"
 
On Tue, 23 Sep 2003 02:22:10 +0200, Carsten Kurz
<audiovisual@t-online.de> wrote:

Die Parallax Leute könnten das sicherlich, aber ich vermute, die werden
das als reverse engineering Versuch auffassen und verweigern. Fragen
kostet freilich nix.
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.

MfG
Johannes
 
Johannes Bauer wrote:

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.
 
Johannes Bauer <dfnsonfsduifb@gmx.de> schrieb im Beitrag <bkovkd$kmi$04$1@news.t-online.com>...
Den will ich sehen, der aus Assembler wieder einen Hochsprachencode
zurechtzimmert.
[ ] du kannst programmieren
--
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.
 
On Tue, 23 Sep 2003 11:19:00 +0200, Heiko Nocon <Heiko.Nocon@gmx.net>
wrote:

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.

MfG
Johannes
 
On 23 Sep 2003 09:28:02 GMT, "MaWin" <me@privacy.net> wrote:

Johannes Bauer <dfnsonfsduifb@gmx.de> schrieb im Beitrag <bkovkd$kmi$04$1@news.t-online.com>...

Den will ich sehen, der aus Assembler wieder einen Hochsprachencode
zurechtzimmert.

[ ] du kannst programmieren
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.

http://agn-www.informatik.uni-hamburg.de/papers/doc/diparb_andre_janz.ps.gz

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.

MfG
Johannes
 
Johannes Bauer <dfnsonfsduifb@gmx.de> schrieb im Beitrag <bkp5ei$9q0$05$1@news.t-online.com>...
Ich frage mich wie du zu dieser naiv-arroganten und anmaßenden
Unterstellung kommst.
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
http://www.geocities.com/mwinterhoff/helpdeco.htm 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).

Und dann könenn wir weiterreden über die Komplexität von Compilern,
Compileroptimierungen und sonstiger Stolpersteine.
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.

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.
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.
 
On 23 Sep 2003 10:37:30 GMT, "MaWin" <me@privacy.net> wrote:

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).
Ob dus glaubst oder nicht, ich weiß nicht nur wie man Debugger
schreibt, ich setze den gdb sogar selber ein.

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.
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.

c) Du kannst dir auch mal ueberlegen, wie gross der Abstand zwischen
http://www.geocities.com/mwinterhoff/helpdeco.htm und einem C-Decompiler
ist. Der ist naemlich gar nicht so gross.
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.

Das dein urspruengliches ÖPosting unueberlegter
Unsinn war, hast du immerhin inzwischen selbst eingesehen (Siehe "Richtig"
als Antwort auf Heiko).
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."

Er
muss halt bloss syntaxfehlerfreien Hochspreche erzeugen, bei manchen
Optimierungen die in der Hochspreche nicht abbildbar sind also die
'Ausgangskonstrukte' erzeugen.
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.

MfG
Johannes
 
On Tue, 23 Sep 2003 10:59:43 +0000 (UTC), Michael Holzt
<spam@fqdn.org> wrote:

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.

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.
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.

MfG
Johannes
 
Johannes Bauer wrote:

[Recompiling]
es ist allerdings ein nahezu unzumutbarer Aufwand
verglichen mit der Arbeit, ein Programm neu zu schreiben.
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.
 
Johannes Bauer wrote:

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 würde ich so nicht sehen. Nicht alles, was existiert, kann man auch
irgendwo im Internet runterladen. ;o)
 
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.

Fuer alle Antworten vielen Dank !

Grzegorz Zalot
 
On Tue, 23 Sep 2003 14:29:30 +0200, Heiko Nocon <Heiko.Nocon@gmx.net>
wrote:

Johannes Bauer wrote:

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 würde ich so nicht sehen. Nicht alles, was existiert, kann man auch
irgendwo im Internet runterladen. ;o)
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.

MfG
Johannes
 
On Tue, 23 Sep 2003 14:34:31 +0200, Grzegorz Zalot
<complex@nospam.alpha.pl> wrote:

Ich hatte etwas gefunden - einen "disassembler", der lediglich einen kleinen
Fehler hat (OR statt AND ;-) ! ). Nach neukompilation durch STAMP ist dasselbe
rausgekommen.
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.

MfG
Johannes
 
Johannes Bauer wrote:
Ich frage mich wie du zu dieser naiv-arroganten und anmaßenden
Unterstellung kommst.
Hast Du doch selber zugestanden mit Deinen Aussagen.

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.
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
 
Johannes Bauer <dfnsonfsduifb@gmx.de> schrieb im Beitrag <bkpan9$uk3$01$1@news.t-online.com>...
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."

Spitzfindig ist das nicht, bloss realistisch betrachtet. Viele Dinge
'gehen' sind aber 'zu teuer' so das man's lieber anders macht.

Genau darin liegt das Problem, diese Ausgangskonstrukte
"wiederzufinden".
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.

Und die verschiedenen Methoden, wie gleiche
Konstukte in einer Lowlevelsprache von verschiedenen Compilern in
unterschiedlichen Code umgesetzt werden.
Ja, ein Decompiler pro Compiler, sogar pro Compilereinstellung
(na ja, zumindest die Muster sind andere)

Es ist _wirklich_ viel Arbeit.
Nun ja. Sagen wir etwa so viel Arbeit es wie den Compiler zu erstellen.

Soviel Arbeit, dass nichteinmal für
das primitive Basic Stamp Dingens ein "Decompiler" erhältlich ist.
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.
 
On 23 Sep 2003 17:37:48 GMT, "MaWin" <me@privacy.net> wrote:

Soviel Arbeit, dass nichteinmal für
das primitive Basic Stamp Dingens ein "Decompiler" erhältlich ist.

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.
ACK.

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.
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.

Dafuer war die Entwicklung eh zu aufwaendig.
Genau darum gings mir ja.

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.
ACK.

So ein Kinderkram wie der DCC kratzt nur an der Oberflaeche, das gibt's
natuerlich gratis.
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.

MfG
Johannes
 
Johannes Bauer <dfnsonfsduifb@gmx.de> schrieb im Beitrag <bkq3sj$nvl$01$1@news.t-online.com>...
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.
Nun, du musst akzeptieren, das in der NG falsche Aussagen (oder
Einschaetzungen, dein Posting war ja eine Einschaetzung), nicht
unkommentiert durchgehen.

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.
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.
 
"MaWin" <me@privacy.net> wrote:

Noe. Compiler sind doof. Du erkennst die Muster von IF, WHILE,
CASE, etc. sofort wieder.
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...

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"
LOL

Dann gibt es Microsoft-Aktien fuer 1 EUR.
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
 

Welcome to EDABoard.com

Sponsor

Back
Top