 | Disassembler für MIPS-CPUs |  |
 Verfasst am: Mo 25. Apr 2005, 23:27 |
 |
|
| Acade |
| Erfahrener Benutzer |
 |
| |
| Anmeldungsdatum: 19.04.2005 |
| Beiträge: 56 |
| Wohnort: Bayern |
|
|
|
 |
|
 |
|
Weil
ja schon öfters nachgefragt wurde und so ein Teil anscheinend
tatsächlich nicht so einfach zu bekommen ist, habe ich am Wochenende
mal eben dieses praktische Tool programmiert (http://acade.au7.de/disasmips.htm).
Man dumpt sich also per TAP das RAM auf die Platte (um das Entpacken
der FW braucht man sich dann auch nicht mehr zu kümmern), gleichzeitig
auch noch die Adressen der API-Tabelle in ein separates File, und schon
kann man in den Innereien wühlen.
Allerdings sollten schon etliche MIPS-Kenntnisse vorhanden sein, es empfiehlt sich die Lektüre des Befehlssatz-Manuals
<Suchmaschine: "Load and store instructions transfer data between the memory system">
und auch vieler guter allgemeiner Infos in
<Suchmaschine: "The MIPS register use convention provides">.
Also nicht wundern, wenn z.B. unmittelbar nach Jump- und
Branch-Instruktionen ein Befehl kommt, der aber noch vor dem Sprung
ausgeführt wird ...
Viel Spaß beim Stöbern,
Acade |
|
|
|
|
| | |
| Verfasst am: Di 26. Apr 2005, 11:16 |
|
|
| jk |
| Team topfield.de |
 |
| |
| Anmeldungsdatum: 14.11.2003 |
| Beiträge: 1055 |
| Wohnort: Jennerdorf, Österreich |
|
|
|
|
|
|
|
 WOW
danke für das spielzeug! |
|
_________________
Es gibt Menschen, die in Erfahrungswelten leben, die wir nicht betreten können. (John Steinbeck)
 |
|
|
|
| Verfasst am: Di 26. Apr 2005, 12:36 |
|
|
| Aldarin |
| Timeshifter |
 |
| |
| Anmeldungsdatum: 06.04.2004 |
| Beiträge: 691 |
| Wohnort: Wien |
|
|
|
|
|
|
|
 Richtig Hardcore
das Spielzeug 
Gruß
Aldarin |
|
|
|
|
| Verfasst am: Di 26. Apr 2005, 16:11 |
|
|
| Kimi |
| Guru |
 |
| |
| Anmeldungsdatum: 16.11.2002 |
| Beiträge: 1180 |
| Wohnort: Schweiz |
|
|
|
|
|
|
|
@Acade:
können wir dann bald mit einem Werk ala "Inside inofficial TAP API?" rechnen ? |
|
|
|
|
| Verfasst am: Di 26. Apr 2005, 22:44 |
|
|
| Acade |
| Erfahrener Benutzer |
|
| |
| Anmeldungsdatum: 19.04.2005 |
| Beiträge: 56 |
| Wohnort: Bayern |
|
|
|
|
|
|
|
| Kimi hat folgendes geschrieben:: | @Acade:
können wir dann bald mit einem Werk ala "Inside inofficial TAP API?" rechnen ? |
Hi Kimi,
den Gefallen würde ich uns allen sehr gerne tun, bloß fehlt mir dazu leider doch die Zeit  . Für so eine Arbeit geht es eher um Monate als Wochen Fulltime.
Aber ich bin sicher, daß es hier einige Cracks gibt, die mit dem
Tool die eine oder andere Perle entdecken können, wenn sie ... eben
Zeit haben.
Vielleicht kommt punktuell auch von mir etwas ...
Ansonsten: Wer möchte es probieren?? (Kann auch Teamwork sein!)
Ciao,
Acade |
|
|
|
|
| Wo ist das TAP? | |
| Verfasst am: Do 28. Apr 2005, 13:34 |
|
|
| Mr.GUI |
| Vielfrager |
|
| |
| Anmeldungsdatum: 26.01.2004 |
| Beiträge: 10 |
|
|
|
|
|
|
|
|
| Hast du ein Tap für das Speichern des Memory geschrieben? |
|
|
|
|
| Re: Wo ist das TAP? | |
| Verfasst am: Do 28. Apr 2005, 23:46 |
|
|
| Acade |
| Erfahrener Benutzer |
|
| |
| Anmeldungsdatum: 19.04.2005 |
| Beiträge: 56 |
| Wohnort: Bayern |
|
|
|
|
|
|
|
| Mr.GUI hat folgendes geschrieben:: | | Hast du ein Tap für das Speichern des Memory geschrieben? |
Ja klar, aber das kann ich momentan nicht auf die Menschheit loslassen, weil da zusätzlich jede Menge anderer Kram drin ist.
Schreib' doch einfach kurz selber eins, 64 MB ab 0x8000 0000, und
zwar als 4 x 16MB-Häppchen (mehr kann TAP_Hdd_Fwrite() nicht auf
einmal), also z.B.:
| Code: |
/*-------------------------------------------------------------------------*/
static void dump (char *file, long addr, long size, long chunk)
{
TYPE_File *fp;
TAP_Hdd_Delete (file);
TAP_Hdd_Create (file, ATTR_NORMAL);
if ((fp = TAP_Hdd_Fopen (file)) == NULL)
return;
TAP_Hdd_Fwrite ((void*) addr, chunk, size / chunk, fp);
TAP_Hdd_Fclose (fp);
}
/*-------------------------------------------------------------------------*/
int TAP_Main (void)
{
...
dump ("DUMP.80", 0x80000000, 0x1000000, 0x4000, -1);
dump ("DUMP.81", 0x81000000, 0x1000000, 0x4000, -1);
dump ("DUMP.82", 0x82000000, 0x1000000, 0x4000, -1);
dump ("DUMP.83", 0x83000000, 0x1000000, 0x4000, -1);
...
return (0);
}
/*-------------------------------------------------------------------------*/
|
Vielleicht stelle ich am Wochenende auch etwas auf meine Webpage ...
Oder gibt's da evtl. Ärger mit Topfield???
Ciao,
Acade |
|
|
|
|
| Danke! | |
| Verfasst am: Fr 29. Apr 2005, 9:07 |
|
|
| Mr.GUI |
| Vielfrager |
|
| |
| Anmeldungsdatum: 26.01.2004 |
| Beiträge: 10 |
|
|
|
|
|
|
|
|
| Der Source reicht vollkommen! |
|
|
|
|
| | |
| Verfasst am: Fr 29. Apr 2005, 11:19 |
|
|
| Eber |
| TAP-Guru |
 |
| |
| Anmeldungsdatum: 07.05.2004 |
| Beiträge: 1696 |
| Wohnort: Mainz |
|
|
|
|
|
|
|
| Zitat: | | Oder gibt's da evtl. Ärger mit Topfield??? |
Ob das nun hier im Forum steht oder auf Deiner homepage macht wohl keinen großen Unterschied.
Einerseits bin ich zwar begeistert von der Chance evt. hinter die
Kulissen der Firmware schauen zu können - andererseits glaube ich, das
das Topfield ab einem bestimmten Punkt nicht mehr ganz so lustig finden
wird - denn letztlich steckt der größte Kostenfaktor bei einem
High-End-PVR wohl in der Entwicklung der Software und da läßt man die
Konkurrenz wohl eher nicht so gerne reinschauen.
Der Aufwand um aus dem MIPS Maschinencode verwertbare Infos zu gewinnen wird allerdings enorm sein...
Da Topfield uns momentan API-seitig recht gut unterstützt (es
dauert zwar etwas, aber nach und nach kommen die fehlenden Funktionen
und ingesamt fehlt sowieso nur noch recht wenig) werde ich daher jetzt
nicht anfangen, MIPS-Assembler zu lernen 
Grüße
Eber |
|
|
|
|
| | |
| Verfasst am: Fr 29. Apr 2005, 23:08 |
|
|
| Acade |
| Erfahrener Benutzer |
|
| |
| Anmeldungsdatum: 19.04.2005 |
| Beiträge: 56 |
| Wohnort: Bayern |
|
|
|
|
|
|
|
| Zitat: |
... glaube ich, das das Topfield ab einem bestimmten Punkt nicht mehr ganz so lustig finden wird ...
|
Hi,
die Frage ist halt, wo dieser Punkt liegt. Das RAM dumpen wird ja wohl
noch ok sein (oder ist schon die Anfangsadresse Top Secret?) und ein
TAP dafür zu veröffentlichen (na schön, das laß' ich jetzt bleiben!)
kann doch auch nicht so schlimm sein. Aber das "Inside Inofficial API
Functions" kann man sich dann abschminken, höchstens im stillen
Kämmerlein.
Was meinen die Korea-Gurus dazu?
Ciao,
Acade
PS: Waren das noch Zeiten, als Data Becker im "Atari ST Intern" das
(fast) komplette kommentierte TOS-Listing abgedruckt hat, einzig mit
dem Hinweis: "Die in diesem Buch wiedergegebenen Schaltungen, Verfahren
und Programme werden ohne Rücksicht auf die Patentlage mitgeteilt. Sie
sind ausschließlich für Amateur- und Lehrzwecke bestimmt und dürfen
nicht gewerblich genutzt werden." |
|
|
|
|
| | |
| Verfasst am: Sa 30. Apr 2005, 0:32 |
|
|
| DeadBeef |
| Erfahrener Benutzer |
|
| |
| Anmeldungsdatum: 28.03.2005 |
| Beiträge: 90 |
| Wohnort: am Schwäbischen Meer |
|
|
|
|
|
|
|
Hi,
ich hatte in den letzen paar Wochen in die Firmware hier und da
reingeschaut. Für die Sachen, die mich interessiert hätten (Tuner
abfragen, Tuner setzen, Dauer einer laufenden Aufnahme ändern etc.),
konnte ich überhaupt keine Funktionen finden. Damit will ich sagen,
dass viele interne Datenstrukturen irgendwo global im Speicher liegen
und dass auf ihre Elemente von überall zugegriffen wird, ohne dass man
eine Funktion identifizieren kann, die bestimmte Daten nur liest oder
nur schreibt. Es mag zwar Performancevorteile bei echzeitkritischen
Sachen bringen, ist jedoch nicht besonders gut erweiterbar/wartbar
insbesondere dann, wenn man die Adressen für jede Firmware-Version neu
suchen muss.
Daher glaube ich nicht, dass man die API signifikant erweitern
kann, es sei denn man entscheidet sich für eine Firmware-Version, trägt
die Speicheradresen von nützlichen Daten zusammen und schreibt eine
eigene Bibliothek, um diese Daten zu manipulieren. Außerdem wäre ein
User Manual für den Chip erforderlich, um Hardware-Adressen/Register
besser mit der Software-Funktionalität korrelieren zu können. Ich
konnte bis jetzt keine Doku zum eingesetzten Chip im Web finden, weil
diese wohl nur unter NDA zugänglich gemacht wird.
Gruß
DeadBeef |
|
|
|
|
| | |
| Verfasst am: Sa 30. Apr 2005, 11:44 |
|
|
| Eber |
| TAP-Guru |
|
| |
| Anmeldungsdatum: 07.05.2004 |
| Beiträge: 1696 |
| Wohnort: Mainz |
|
|
|
|
|
|
|
| Acade hat folgendes geschrieben:: |
die Frage ist halt, wo dieser Punkt liegt. Das RAM dumpen wird ja
wohl noch ok sein (oder ist schon die Anfangsadresse Top Secret?) und
ein TAP dafür zu veröffentlichen (na schön, das laß' ich jetzt
bleiben!) kann doch auch nicht so schlimm sein. Aber das "Inside
Inofficial API Functions" kann man sich dann abschminken, höchstens im
stillen Kämmerlein.
Was meinen die Korea-Gurus dazu?
Ciao,
Acade
... |
Ich bin keiner der Korea-Gurus...und letztlich würde natürlich
jemand der wirklich den Code "ausspionieren" möchte recht schnell auf
dieselbe Idee wie Du kommen. Ich frage mich halt, ob es Sinn macht, da
viel Arbeit zu investieren, um evt. neue Erkenntnisse zu gewinnen dabei
aber Gefahr zu laufen, Topfield zu verärgern.
Außerdem gibt es ja die Problematik der Firmwareänderungen.
Grüße
Eber |
|
|
|
|
| | |
| Verfasst am: Sa 30. Apr 2005, 19:06 |
|
|
| Hatsenichalle |
| Guru |
|
| |
| Anmeldungsdatum: 20.02.2002 |
| Beiträge: 1998 |
| Wohnort: Land Brandenburg |
|
|
|
|
|
|
|
| Kann
nicht verstehen warum Topf sich ärgern sollte. Die verkaufen doch die
Kiste sowieso mit Soft. Sollte von aussen `ne Bessere kommen, werden
sie noch mehr Geräte verkaufen. Diejenigen die sich selbst mit der
Produktion solcher Geräte beschäftigen und spionieren oder klauen
wollen, haben das sicher schon längst gemacht. Die D-Box 2 war auch
erst richtig gefragt nachdem es `ne bessere Soft gab. |
|
_________________
Zitat (auszugsweise) "eMail= von gerhhu
An: Hatsenichalle
Verfasst am: 09 Mai 2005 16:49
Titel: Typisch Ossi Nachricht zitieren:
Typisch Ossi!
Gruß Gerhard"
Das ist die Nachricht auf die ich gewartet habe. Sie zeigt die Geisteshaltung von ??? Leider bin ich kein "Ossi.
_________________
Gruß Gerhard. |
|
|
|
| | |
| Verfasst am: So 01. Mai 2005, 2:25 |
|
|
| Aldarin |
| Timeshifter |
|
| |
| Anmeldungsdatum: 06.04.2004 |
| Beiträge: 691 |
| Wohnort: Wien |
|
|
|
|
|
|
|
Ich
verstehe die ganze Diskusion nicht, ob Korea damit einverstanden sein
soll oder nicht. Dekompilieren einer Software ist doch keine illegale
Strafhandlung. Wenn man Sie verändert oder publiziert schon.
Ich möchte einmal hier den ersten erleben, der etwas brauchbares
aus der Erkenntnis vom Dekompilat zustande bringt. Dann reden wir
weiter.
Gruß
Aldarin
Edit:
Die Betonung liegt auf "brauchbar". |
|
|
|
|
| Verfasst am: So 01. Mai 2005, 23:52 |
|
|
| Acade |
| Erfahrener Benutzer |
|
| |
| Anmeldungsdatum: 19.04.2005 |
| Beiträge: 56 |
| Wohnort: Bayern |
|
|
|
|
|
|
|
Ok, der Disassembler wird jedenfalls weiter ausgebaut, ist ja auch für andere Zwecke als Topfield brauchbar . Außerdem geht's mich ja nicht unbedingt was an, was die Leute damit machen ...
Die interessanten Stellen muß halt jeder selbst finden.
Ciao,
Acade |
|
|
|
|
| | |
| Verfasst am: Mo 02. Mai 2005, 15:07 |
|
|
| Eber |
| TAP-Guru |
|
| |
| Anmeldungsdatum: 07.05.2004 |
| Beiträge: 1696 |
| Wohnort: Mainz |
|
|
|
|
|
|
|
| Aldarin hat folgendes geschrieben:: | Ich
verstehe die ganze Diskusion nicht, ob Korea damit einverstanden sein
soll oder nicht. Dekompilieren einer Software ist doch keine illegale
Strafhandlung. Wenn man Sie verändert oder publiziert schon.
|
ich glaub das war einmal:
http://www.heise.de/tp/r4/artikel/5/5728/1.html
wobei natürlich niemand weiß, was Du in Deinem stillen Kämmerchen alles programmierst 
| Aldarin hat folgendes geschrieben:: |
Ich möchte einmal hier den ersten erleben, der etwas brauchbares
aus der Erkenntnis vom Dekompilat zustande bringt. Dann reden wir
weiter.
Gruß
Aldarin
Edit:
Die Betonung liegt auf "brauchbar". |
Das sehe ich genauso - es sei den es gibt außer einem Disassembler
alternativ auch einen Decompiler. Da die Firmware vermutlich mit dem
GCC kompiliert wurde könnte es doch theoretisch sein, das auch ein Tool
existiert, das umgekehrt wieder rudimentären C-Code erzeugt - darin
ließe sich schon eher eine Struktur ausmachen - wäre aber vermutlich
immer noch sehr mühsam.
Grüße
Eber |
|
|
|
|
| | |
| Verfasst am: Mo 02. Mai 2005, 16:06 |
|
|
| Miq |
| TV-Junkie |
 |
| |
| Anmeldungsdatum: 01.09.2003 |
| Beiträge: 105 |
| Wohnort: bei FRA |
|
|
|
|
|
|
|
| Eber hat folgendes geschrieben:: |
Das sehe ich genauso - es sei den es gibt außer einem Disassembler
alternativ auch einen Decompiler. Da die Firmware vermutlich mit dem
GCC kompiliert wurde könnte es doch theoretisch sein, das auch ein Tool
existiert, das umgekehrt wieder rudimentären C-Code erzeugt - darin
ließe sich schon eher eine Struktur ausmachen - wäre aber vermutlich
immer noch sehr mühsam.
Grüße
Eber |
Gibt's zumindest ansatzweise: http://lcamtuf.coredump.cx/fenris/devel.shtml |
|
|
|
|
| | |
| Verfasst am: Mi 04. Mai 2005, 22:41 |
|
|
| Acade |
| Erfahrener Benutzer |
|
| |
| Anmeldungsdatum: 19.04.2005 |
| Beiträge: 56 |
| Wohnort: Bayern |
|
|
|
|
|
|
|
| Aldarin hat folgendes geschrieben:: |
Ich möchte einmal hier den ersten erleben, der etwas brauchbares
aus der Erkenntnis vom Dekompilat zustande bringt. Dann reden wir
weiter.
|
Stammt jetzt zwar nicht direkt aus den Tiefen des Codes, aber trotzdem aus der Beschäftigung damit und ist sehr
brauchbar: Die Abfrage der Firmware-Version. Hat das eigentlich schon
jemand gelesen (im Parallelthread)? Es gab bisher keine Reaktionen ...
Ciao,
Acade |
|
|
|
|
| Verfasst am: Do 05. Mai 2005, 5:42 |
|
|
| Erdnussnase |
| Dauerglotzer |
|
| |
| Anmeldungsdatum: 24.11.2004 |
| Beiträge: 273 |
|
|
|
|
|
|
|
|
Supi, fehlte mir schon lange.
Fehlt mir jetzt nur noch die Stelle and der die Länge der aktuellen
Aufnahme abgelegt wird. Übers Menue kann man die ja ändern, aber leider
per API nicht. |
|
|
|
|
| | |
| Verfasst am: Do 05. Mai 2005, 14:41 |
|
|
| DeadBeef |
| Erfahrener Benutzer |
|
| |
| Anmeldungsdatum: 28.03.2005 |
| Beiträge: 90 |
| Wohnort: am Schwäbischen Meer |
|
|
|
|
|
|
|
@Erdnussnase:
Die Länge der aktuellen Aufnahme wird an folgenden Stellen im Speicher abgelegt:
| Code: | in der Version vom 13.01.05
für Aufnahme 1 - 0x81a360cc
für Aufnahme 2 - 0x81a36154 (+0x88)
in der Version vom 24.03.05
für Aufnahme 1 - 0x81a3dea4
für Aufnahme 2 - 0x81a3df2c (+0x88) |
Die Kurzfassung der Datenstruktur ist:
| Code: | typedef struct
{
word duration; // Total Recording Time ( minutes )
dword startTime; // (MJD << 16) | (hour << 8) | min
dword endTime; // (MJD << 16) | (hour << 8) | min
} RecTime; |
Die Datenstrukturen fangen eigentlich bei 0x81a360c8/0x81a3dea0 an und enthalten ein paar weitere Daten.
Sobald eine Aufnahme läuft, können die Aufnahmedaten frei modifiziert
werden. Anpassen der Endzeit an die geänderte Dauer scheint nicht
erforderlich (aber empfehlenswert) zu sein. Eine Aufnahme wird beendet,
wenn die Firmware beim Dekrementieren des Minutenzählers einen Nullwert
vorfindet.
Gruß
DeadBeef |
|
|
|
|
TOPFIELD.de Board Foren-Übersicht » TAP
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst Deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst Deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
Alle Zeiten sind GMT + 2 Stunden
Seite 1 von 3
Gehe zu Seite 1, 2, 3 Weiter
|
|
|
|
  |
|
|
|
