http://satellite-board.de

ASM->C/C++ ?
Gibts überhaupt sowas? Müßte man mal die Jungs von Humfree fragen: Planet Hemp, Großer Nagus, Alfredo usw.
Das was ich von Maschinensprache noch in Erinnerung habe ist schon ein paar Jahre her und da ging es nur um Registerschieberei und meine C Kenntnisse sind rudimentär...
Das beste wäre die Originalsource zu bekommen, aber das halte ich für unmöglich.



------------------
Lostech

Visit my homepage

hi

Also ich bin mir ziemlich sicher, das es solche progs gibt zum umwandeln (wenn ich asm habe kann ich ja auch c(++) draus machen (nur halt aus hex/bin nicht).
an die originalsoft wird man nicht herankommen wegen der copyrights usw. (ich glaube alleine schon die disassemblierung der datei stellt n verstoß gegen die eigentumsrechte dar oder so ähnlich, aber das ist wohl das kleinste problem)
dann frag doch mal die leutz, die sich n bissl besser damit auskennen (ich kenn sie net aber du anscheinend ja).
und nebenbei: ich denke das man nicht einfach so die pad datei disassemblieren darf (es kommt zwar was bei raus, aber das muß nicht der originalcode sein), da sich die source sicherlich in mehrere dateien aufsplittet wie bilder, menues, usw. und beim zurückwandeln erhält man ja nur eine datei.

oki

gruß BigStephan

Sollte ich nochmal Zeit kriegen für den Chat werd ich die Jungs mal fragen.

Was die Grafiken angeht findest du z.B. im Binärfile die Grafiken ziemlich weit hinten (z.B. das Doppelpfeilsysmbol unten in der EPG Leiste etc.)
Sieht aus wie ein Negativ Bild aus Zahlen (z.B. viele 3en):

<FONT face="Courier New">
3333333333333333333333333333
33333333333.331...3333331.3.
.....333331.........33331...
.331..33331..333333..3331..3
333331.3331...333331.3331...
.333333333333333333333333333
3331....3331.33333....3331.3
33333...3331.333333...3333..
.331....33331.......1.33333.
.....31.3333331...3313333333
3333333333333333333333333333
</FONT f>

Sieht hier zwar kurios aus aber im Hex Editor wirds deutlicher.

------------------
Lostech

Visit my homepage


[Dieser Beitrag wurde von Lostech am 20. Juni 2001 um 08:24 Uhr editiert.]

schon klar...man erkennts. allerdings hätte ich nicht gedacht, das sich die zeichen rein binär zusammensetzen...??? aber vielleicht versteh ich das auch nur falsch.
egal.
hab mir die soft von den jungs für den humi mal angeschaut...und ich muß zugeben, das die unserer soft natürlich nicht entpackt...grins...aber das zeigte mir, das trotzdem mehrere dateien entstehen. ich werde mal bei den technileutz fragen ob sie mir nicht doch den source code zur verfügung stellen...melde mich dann wieder.

gruß bigstephan

asm -&gt; c? sehr schwierig und wird nicht viel bringen

verschiedene c(++) compiler uebersetzen nicht gleich. man kann in c ein programm schreiben und dieses mittels verschiedener c-compiler nach maschinencode uebersetzen. die laenge der dateien wird zu 99,999..% unterschiedlich sein. das haengt eben damit zusammen, wie der
compiler uebersetzt.
wenn man jetzt den c-compiler kennt, muss man wissen, wie dieser for, while usw. construkte uebersetzt.
ein sehr muehsamer weg!

wichtiger ist zuerst, das der dis-asm nur das uebersetzt, was auch code ist. bilder, zeichenketten und der gleichen muessen halt anders rueckuebersetzt werden.
nach dem das halbwegs ok ist muss bei einem uebersetzen nach masch-code auch wieder exakt der mach-code rauskommen, der vor dem dis-asm dawar.
wenn das ok ist, dann braucht man genaue technische unterlagen (registerbelegungen usw) ueber alle chips in der kiste.
und wenn man sich nach wochenlanger arbeit reingefummelt hat, bringt der hersteller eine neue firm heraus
und das spiel faengt fast wieder von vorne an.

toi,toi toi. wer das richtig hinbekommt, vor dem habe ich echten respekt.

netfan

ps: ich habe das vor einigen jahren einmal durchgezogen. ich wusste jedoch, das der source
in asm und nicht nicht in c war. trozdem hat das ewig gedauert!!

@BigStephan:
Das mit dieser Zeichenfolge aus 3en und 0en etc. muß du dir in mehreren Zeilen untereinander vorstellen. Im Hexeditor (z.B. Hex Workshop) sieht mans richtig. Dann siehst du im Prinzip eine Matrix, die aus ein bischen Entfernung genauso aussieht wie ein Icon.
Die Humax Tools nützen dir bei der Technisat Firm überhaupt nichts, nicht nur weils ein anderes Gerät ist, sondern weil die Technisat Firmware schon unkomprimiert vorliegt. Da brauchst du nix mehr entpacken
Bei Digenius oder Humax ist die Software schon komprimiert und deswegen mußt du die Software vorher entpacken. Bei der Technisat Firmware muß du lediglich das BIN in einem Stück aus dem PAD rausschneiden.



------------------
Lostech

Visit my homepage

Ich mal weiter oben das Bild aus den Zahlen mal etwas anders gepostet. Ich hoffe jetzt kann man das vielleicht etwas deutlicher erkennen (es ist das Doppelpfeilsymbol von der "zurück" Taste wie es in den Menüs öfters in der untersten Zeile dargestellt wird)


------------------
Lostech

Visit my homepage

hi

@lostech

das war mir schon klar mit dem pfeil und was das darstellen sollte. hatte ich auch geschrieben! nur hatte ich mich gewundert, dass sich dieser pfeil eben ausgerechnet aus dreien zusammensetz und das er im hex direkt sichtbar ist, da ja in diesem fall nirgends dir eigenschaften der einzelnen pixel (3-en) festgelegt zu sein scheint (wie z.b. farbe , höchsten vorher für den gesamten pfeil...is der einfarbig?)
das man die soft nicht entpacken kann hab ich mir ja schon gedacht. nur konnte ich mir wie gesagt nicht vorstellen, das der gesamte firmwareaufbau nur aus einem code (asm oder c) besteht. wenn ich in c++ z.b. n prog schreibe, dann greife ich auf bilder usw. schließlich auch auf externe dateien zu. und das sie nicht gepackt ist, wußte ich nicht (hätte ja klappen können mit dem humi-tool

@netfan

dass beim decompilieren immer andere sources (abhämgig von decomp.) rauskommen ist mir klar *grins*, und im prinzip legen wir ja auch nicht soviel wert darauf, den passenden gleichen hexcode nach dem zurückcompilieren wieder herzustellen. Ich wollte lediglich mal den allgemeinen aufbau der soft sehen und verstehen. und wenn ich daß habe, zerbech ich mir den kopf, wie man das direkt im hex verändern kann (dann kennt man zumindest den ort für gewisse sachen wie z.b. farben, logos usw.). und nebenbei: das file (das disassemblierte) zu bearbeiten ist echt nicht möglich, da dieser asm file locker 10 mb groß ist! wie groß war dein bin file damals?

oki

gruß BigStephan

Diese Matrizen für diese kleinen Icons kommen doppelt vor im Binärfile. Ich hatte testweise auch mal die Werte geändert und ein wesentlich dunkleres Icon bekommen.
Außerdem gibt es zwischendrin immer wieder reine binäre Passagen aus 0en und 1en, in denen noch weitere Grafikinformationen stecken könnten.
Ganz einfarbig sind die Icons aber nicht, bei einigen scheint sowas wie ein dunkler Rand an einer oder mehreren Seiten vorhanden zu sein (-&gt;Tiefeneffekt). Aber genuer sieht man das nicht an dem Beispiel, das ich gepostet hab, sondern an der 2. vorhandenen Matrix für ein Icon (hier tauchen häufig Rautensymbole auf #)

Der Aufbau sieht im BIN grob gesagt so aus:

die ersten 4/5 der Firmware:
-Firmware/Funktionalität/Treiber etc.

gefolgt von
-Systeminterne Meldungen, die aber nicht vom Receiver angezeigt werden (wahrscheinlich für eine Debugging Umgebung?!)
-Fonts
-OSD Texte (verschiedene Sprachen)
-Programmdaten (Frequenz+PID Daten)
-Programmnamen
-wieder Programmcode (unbekannt wofür)
-Icons, kleine Grafiken
-wieder systeminterne Meldungen


Das ist zumindest das was ich bis jetzt rausgefunden hab. Disassembliert hab ich es (bis jetzt) noch nicht.


------------------
Lostech

Visit my homepage


[Dieser Beitrag wurde von Lostech am 20. Juni 2001 um 16:57 Uhr editiert.]

aha...wie haste das alles rausbekommen (wo was im prog-code steht)?
auf jeden fall denke ich, daß die programmierer die soft nicht in asm programmiert haben (selbst der perfekte progger verliert nach maximal 3 mb die übersicht. Also müßte es schon sowas (wie du bereits sagtest) wie c++ sein (ob nun auf MIPS, ALPHA oder 68HC11 sei erstmal egal. nebenbei: der MIPS, welcher warscheinlich drinsteckt, steckt auch im Nintendo64 ?)
Das mit den Matrizen is auch klar. aber ich kann mir beim besten willen nicht vorstellen, das die progger das mittels bin erstellt haben (höchstens picture-&gt;ascii).

Mal was anderes: Hat Technisat keine E-Mail oder hab ich sie übersehen auf deren HP?

oki...gruß BigStephan

@BigStephan
nur zur info. das bin file (ein mini-os mit shell, aehnlich cpm) war knapp 120kb gross. es war fuer den mc68000. das oeffentliche api hatte knapp 80 funktionsaufrufe. es wurde in c und asm erstellt. ich hatte ausser dem dis-asm noch einen c-compiler, der asm und nicht bin files produzierte. dadurch konnte ich einiges ableiten. meine source-asm files lagen bei ca 1,5MB ohne kommentare.

weiterhin viel erfolg!

Man sieht doch im Hexeditor nicht nur die Bytes, sondern auf der rechten Seite (zumindest bei den meisten Hex Editoren) auch den entsprechenden ASCII Code und wenn z.B. die OSD Texte da in Plain ASCII sauber drinstehen merkt man doch direkt womit mans zu tun hat
Anhand dessen, daß ASCII Texte klar lesbar sind ist auch erkennbar, das die Firmware nicht gepackt ist

Da halt ASCII lesbar ist sieht man auch die Compiler Informationen:

pSOS+/MIPS V2.1.4.COPYRIGHT 1995, INTEGRATED SYSTEMS, INC.

und

pREPC+/MIPS V2.1.1 .COPYRIGHT 1995, INTEGRATED SYSTEMS, INC.



------------------
Lostech

Visit my homepage

[Dieser Beitrag wurde von Lostech am 21. Juni 2001 um 08:30 Uhr editiert.]

Was den Compiler angeht dürfte der von dieser Firma stammen: http://www.isi.com/


------------------
Lostech

Visit my homepage

Schön zu sehen, dass hier Vorarbeit für einen Allcam-Patch zur demnächst erscheinenden Digibox Irdeto geleistet wird

------------------
Lostech

Visit my homepage