Ein mir unbekannter Assembler (integriert in einer IDE) erzeugt in der
Ausgabedatei große Änderungen obwohl im Programm selber nur eine
einzelne Ziffer geändert wurde. Zum Testen hab ich folgendes Programm
verwendet:
1
main:
2
mov a,0x01
3
goto main
0x01 wird jeweils um 1 erhöht und die Ausgabe des Assemblers in 12
einzelnen Dateien abgespeichert (also mov a,0x01 bis mov a,0x12).
Ich hätte vermutet, dass sich eventuell die Instruktionen im Klartext
(bzw. Hexformat) wiederfinden lassen, allerdings ändern sich 2050 Byte
(die Ausgabedatei ist immer 2303 Byte groß).
Der einzige Grund, der mir spontan einfällt, warum sich aus einer
minimalen Änderung im Code große Änderungen in der Datei ergeben, wäre
der Einsatz von Verschlüsselung.
Ich weiß, dass ist so ziemlich im Nebel stochern aber vielleicht hat
jemand Kenntnisse darüber, in welcher Form Assembler üblicherweise das
Programm abspeichern.
Die IDE mit Assembler: http://www.padauk.com.tw/products.php?item=14
(IDE v0.81)
Max M. schrieb:> Der einzige Grund, der mir spontan einfällt, warum sich aus einer> minimalen Änderung im Code große Änderungen in der Datei ergeben, wäre> der Einsatz von Verschlüsselung.
Auch Assembler können unterschiedlich optimieren.
Horst schrieb:> Auch Assembler können unterschiedlich optimieren.
Aber was gibt es denn aufgrund einer Zahl zu optimieren?
Roland P. schrieb:> Kompression könnte auch schuld sein.
Gute Idee, allerdings macht das meine Idee zunichte, etwas über die
Instruktionen rauszufinden bzw. in welchem Format das Programm in den µC
geladen werden muss, damit es korrekt funktioniert.
Roland P. schrieb:> Kannst du das selbe Programm 2x assemblieren? Kommt dann das gleiche> raus?
Ja, wenn das Programm das gleiche ist wird auch exakt die gleiche Datei
erzeugt.
Edit: Wenn man weiß, welches Kompressionsverfahren eingesetzt wird, kann
man die Datei auch wieder dekomprimieren - oder? Vorausgesetzt es ist
kein proprietäres Verfahren, das nicht öffentlich verfügbar ist.
Edit_2:
"Executable compression is also frequently used to deter reverse
engineering or to obfuscate the contents of the executable (for example,
to hide the presence of malware from antivirus scanners) by proprietary
methods of compression and/or added encryption. Executable compression
can be used to prevent direct disassembly, mask string literals and
modify signatures. Although this does not eliminate the chance of
reverse engineering, it can make the process more costly."
Na vielen Dank auch :D
"Not a valid PE file".
Gibt es überhaupt eine Möglichkeit zu erkennen, ob die Datei
verschlüsselt oder komprimiert ist?
Wie wahrscheinlich ist es, dass der Hersteller ein komplett eigenes
Verschlüsselungs- bzw. Kompressionsverfahren einsetzt?
Max M. schrieb:> Ein mir unbekannter Assembler (integriert in einer IDE)
Das Ziel dieses Assemblers scheint kein herkömmlicher µC zu sein,
sondern ein "programmierbares Prozessor-Array", das aus 8 Prozessoren zu
bestehen scheint.
Die Ausgabedatei enthält daher vermutlich auch noch ganz andere
Informationen als das eigentliche Programm.
Rufus Τ. F. schrieb:> Das Ziel dieses Assemblers scheint kein herkömmlicher µC zu sein
Doch, das Ziel ist ein µC, das Unternehmen stellt nicht nur diese Arrays
her, kann man auch im Assembler-File definieren:
1
.CHIP PMS150C
2
//{{PADAUK_CODE_OPTION
3
.Code_Option Bootup_Time Slow
4
.Code_Option Drive Normal
5
.Code_Option Security Disable // Security Disable
6
.Code_Option LVR 3.5V
7
//}}PADAUK_CODE_OPTION
8
9
.ADJUST_IC DISABLE
10
11
main:
12
mov a,0x12
13
goto main
Das die Ausgabedatei noch andere Informationen neben dem Programm
enthält, ist damit natürlich nicht auszuschließen.
Rufus Τ. F. schrieb:> Was möchtest Du damit machen?
Naja, ganz normal damit basteln und gleichzeitig versuchen, das Vorgehen
des Programmiergeräts bzw. die Toolchain zu "reverse engineeren" damit
man sie einfacher benutzen kann.
Mein Ziel wäre es, die vom Assembler generierte Datei über eine
UART-Brücke an einen µC zu senden, der wiederum per Bit-Banging das
Programmiergerät simuliert und den OTP-Speicher des eigentlichen
Controllers damit beschreibt.
So ähnlich wie avrdude, nur dass Atmel (glaube ich) das Vorgehen, wie
sie ihre Controller programmieren, offen gelegt hat.
Ich finde, solche µC haben auch für Bastler ihren Sinn und werden hier
gar nicht verwendet, weil es kaum Doku gibt bzw. die Hardware nur schwer
zu beschaffen ist.
Irgendwie bin ich aber jetzt erstmal an einem Punkt, an dem es nicht
weiter geht.
Max M. schrieb:> Ich finde, solche µC haben auch für Bastler ihren Sinn
Das mit dem OTP hast Du verstanden? Dann hat so etwas für Bastler nur
dann einen Sinn, wenn die Dinger unglaublich billig zu bekommen sind,
denn jeder Programmiervorgang braucht einen neuen Controller.
Da ist ein ATtiny schon deutlich komfortabler, weil der wiederholt
beschrieben werden kann. Spartanisch können ATtinies auch, der ATtiny13
beispielsweise hat auch nur 1 kB Programmspeicher und 64 Bytes RAM.
Christian M. schrieb:> Du meinst aber nicht etwa das HEX-File!
Ich verstehe nicht, was du meinst? Die IDE bzw. der Assembler erzeugt
kein HEX-File, die Dateien tragen die Endung ".PDK" (wahrscheinlich ein
Kürzel für den Hersteller).
Christian M. schrieb:> Das hat noch Checksummen und so.
Guter Hinweis, der Assembler zeigt nach dem Assemblieren eine Checksumme
an. Danach suche ich mal in der Datei.
Kann jetzt mobil die Datei nicht anschauen, aber ist der Inhalt Text
1:1? wie zitiert:
0x12, 0x66, 0xAA, 0xFF, 0x01, 0x00, 0x00, 0x00, 0x14, 0x00, 0x00, 0x00
Gruss Chregu
Christian M. schrieb:> Kann jetzt mobil die Datei nicht anschauen, aber ist der Inhalt Text> 1:1?
Nein, das ist die binäre Darstellung der Datei. Wenn ich die Datei mit
dem Texteditor öffne, sieht das ungefähr so aus wie Chinesisch :D
Eine Konstante zu ändern kann dazu führen, dass eine längere Instruktion
gebraucht wird.
Wenn man einen Befehl einfügt ist es das gleiche. Da Programm wird
größer. Damit ändern sich die relativen und absoluten Adressen und damit
das ganze Programm.
Thorsten schrieb:> Damit ändern sich die relativen und absoluten Adressen und damit> das ganze Programm.
Ich seh das ehrlich gesagt nicht so. Für 0x02 braucht man binär genauso
viele Bits wie für 0x03. Wo sich Adressen ändern erschließt sich mir
auch nicht ganz. Wie genau meinst du das?
PittyJ schrieb:> Pack doch einfach einen ASCII-String mit in das Program.
Ich weiß ehrlich gesagt nicht, wie ich das in Assembler machen soll :(
So?
@Max MMM (maxmicr)
>> Pack doch einfach einen ASCII-String mit in das Program.
Eben.
>Ich weiß ehrlich gesagt nicht, wie ich das in Assembler machen soll :(
RTFM?
>So?
Nö, das sind mov-Befehle, da findet man HALLO niemals als String wieder.
Eher sowas hier, keine Ahnung wie der Syntax von deinem Assembler dazu
aussieht.
.db "Hallo Welt"
Max M. schrieb:> Ich seh das ehrlich gesagt nicht so. Für 0x02 braucht man binär genauso> viele Bits wie für 0x03.
Wenn das als separate Konstante im Programmcode steht, ja. Wenn das aber
RISC-Code ist, dann können unterschiedliche Konstanten unterschiedliche
Codegrößen und Laufzeiten zur Folge haben, da Konstanten gegebenenfalls
aus mehreren Opcodes zusammengesetzt werden. So ist's beim ARM, so
könnte es theoretisch auch hier sein.
Ich wiederhole nochmal meine Frage an Dich:
Bist Du Dir im klaren darüber, was OTP bedeutet, und welche Konsequenzen
das beim Programmieren eines µC hat?
Falk B. schrieb:> keine Ahnung wie der Syntax von deinem Assembler dazu> aussieht.
Ich leider auch nicht so recht :(
Das:
1
.CHIP PMS150C
2
//{{PADAUK_CODE_OPTION
3
.Code_Option Bootup_Time Slow
4
.Code_Option Drive Normal
5
.Code_Option Security Disable
6
.Code_Option LVR 3.5V
7
//}}PADAUK_CODE_OPTION
8
9
.ADJUST_IC DISABLE
10
11
abcd db "A"
12
main:
13
goto main
erzeugt
1
main.ASM(9): Loss following code at here
2
main.ASM(13): The code is never used. 0x5 to 0x5
Das:
1
.CHIP PMS150C
2
//{{PADAUK_CODE_OPTION
3
.Code_Option Bootup_Time Slow
4
.Code_Option Drive Normal
5
.Code_Option Security Disable
6
.Code_Option LVR 3.5V
7
//}}PADAUK_CODE_OPTION
8
9
.ADJUST_IC DISABLE
10
11
abcd db "AB"
12
main:
13
goto main
erzeugt:
1
main.ASM(11): The value over range !!!
Sagt das jemandem was?
Ich gucke mal nach einer Beschreibung zum Assembler, wenn die Homepage
vom Hersteller wieder online ist.
Rufus Τ. F. schrieb:> Bist Du Dir im klaren darüber, was OTP bedeutet, und welche Konsequenzen> das beim Programmieren eines µC hat?
Man kann den µC wegwerfen, wenn man sein Programm ändern möchte.
Max M. schrieb:> Die IDE mit Assembler: http://www.padauk.com.tw/products.php?item=14> (IDE v0.81)
Ich krieg da nur Error 404.
Bist Du Dir sicher, daß der Chip überhaupt noch hergestellt wird?
Ich verwende etwa seit 1993 keine OTPs mehr, da kamen von Atmel die
ersten Flash AT89C51 raus.
Ich hatte mir auch mal von 2 Exoten Samples schicken lassen:
- Fairchild ACE1202
- Scenix SX18
Glücklicher Weise habe ich sie nicht eingesetzt, sind nämlich beide
wieder von der Bildfläche verschwunden.
Der SX18 war extrem hart zu programmieren, da PIC12 Architektur. Davon
kriegte man Knoten im Gehirn.
Für den ACE1202 hatte ich mir selbst nen Programmer gebastelt. Hab dann
aber gemerkt, daß er bei langsamen Anstieg der VCC kein Reset machte,
also unzuverlässig anlief.
Peter D. schrieb:> Für den ACE1202 hatte ich mir selbst nen Programmer gebastelt.
Wie bist du da vorgegangen? Die Programmier-Pins mit einem
Logic-Analyzer bzw. Oszilloskop gemessen?
Eventuell löst die "OTP-Writer"-Software, die Teil der IDE ist, die
Verschlüsselung / Komprimierung und überträgt das Programm "in Klartext"
an den µC.
Max M. schrieb:> Wie bist du da vorgegangen? Die Programmier-Pins mit einem> Logic-Analyzer bzw. Oszilloskop gemessen?
Es gab von Fairchild die AN-8005:
How to In-Circuit Program the ACEx™ Family of Microcontrollers
Die IDE erlaubt Programme in "Mini-C" zu schreiben, ich hab sowas
probiert:
1
#include"extern.h"
2
3
voidFPPA0(void)
4
{
5
.ADJUST_ICSYSCLK=IHRC/2// SYSCLK=IHRC/2
6
7
WORDTEST[5];
8
TEST[0]='H';
9
TEST[1]='A';
10
TEST[2]='L';
11
TEST[3]='L';
12
TEST[4]='O';
13
14
while(1)
15
{
16
17
}
18
}
und nach den Hexzahlen 0x48414C4C4F und 0x4F4C4C4148 gesucht -
leider keine Ergebnisse.
Die Ausgabedateien mit "HALLE" anstatt "HALLO" unterscheiden sich erneut
zu großen Teilen.
Max M. schrieb:> und nach den Hexzahlen 0x48414C4C4F und 0x4F4C4C4148 gesucht - leider> keine Ergebnisse.
Das überrascht nicht unbedingt. Dein Array ist vom Typ WORD (was recht
wahrscheinlich ein 16-Bit-Typ ist) und Du befüllst es mit einzelnen
Operationen, statt es zu initialisieren.
Was passiert bei
char test[] = "HALLO"?
Gegebenenfalls musst Du nur noch den Optimierer überlisten, indem Du
irgendwo noch lesend auf das Array zugreifst.
niedlich! ;-)
Meine Tutorin hat sich das mal angesehen, und
meint, das da Dein Code in ein kleines "RTOS"
eingebunden und abgearbeitet wird.
Dieses "RTOS" ist zumindest in der IDE gepackt, und da bis jetzt
nur ein kleiner Code programmiert ist, fällt dieser
in den verhältnismäßig großen "Overheadcode" nicht auf.
In den Controller wird dann alles, entpackt, geladen.
mfg
.
Danke für deine Antwort! Magst du das mit dem RTOS genauer ausführen?
Eigentlich müsste sich doch mein ASM Code immer noch in der generierten
Datei befinden? Das widerlegt imho nicht den Einsatz eines
Kompressionsalgorithmus.
Außerdem bezweifle ich, dass ein RTOS auf 1KB und 64 Byte RAM Platz
findet. Ich denke weiterhin, dass das Writer-Tool den Inhalt der
generierten Datei in Klartext übersetzt, wenn das Ding (hoffentlich) bei
mir heil ankommt, werde ich genaueres wissen (oder auch nicht).
Das RTOS ist die Programmsaasammlung um deine "Main"
herum.
Dein Programm ist die "Main" und kommt zusammen mit den
Biblitheksroutinen in den Flash.
Die IDE linkt quasi das "RTOS" mit den assemblierten Routinen
von Dir zusammen und schreibt alles ins Flash.
Ist ähnlich wie beim Kopierschutz - Dongle!
Da sind Teile in Deiner EXE verschlüsselt und werden dann während
des Programmlaufes "on the fly" entpackt und mit der EXE verlinkt.
Das Packen oder die Verschlüsselung in der IDE ist nur
dafür da, das Du nicht mitbekommst, wies funktioniert. ;-P
Der Lader dürfte als unverschlüsselt / ungepackt ins Flash schreiben.
Nur die Daten kommen ins RAM!
Du willst wirklich Chips bestellen?
mfg
Das liest sich etwas verrückt für mich - so eine Firma verdient doch
nichts an ihren Programmiergeräten bzw. ihrer Software sondern an dem
Verkauf ihrer Controller in sehr hohen Stückzahlen. Wieso dieser Aufwand
alles geheim zu halten?
Aber hab ich dich richtig verstanden: Mit dem Writer vor Ort könnte ich
es hinbekommen, den Opcode herauszufinden?
Max meinte:
> Aber hab ich dich richtig verstanden: Mit dem Writer vor Ort könnte ich> es hinbekommen, den Opcode herauszufinden?
Wenn du den Lader oder die Verbindung
Lader ---> Chipprogrammer anzapfst, ja.
Wenn erst der Programmer entschlüsselt und
eine härtere Gangart eingelegt wird, ja. ;-D
Ich glaub nicht, das der Chip entschlüsselt.
mfg
Aber falls der Weg von der IDE bis zum Writer verschlüsselt ist würde
das bedeuten, dass ich einen neuen Assembler schreiben müsste, der die
Mnemonics in den richtigen Opcode des uCs übersetzt den auch der Writer
erzeugen würde. Dann müsste ich diesen Satz an Infos per UART vom PC zu
einem uC senden, der den Writer simuliert und dann schlussendlich den
Chip programmiert?
Max meinte:
> Aber falls der Weg von der IDE bis zum Writer verschlüsselt ist würde> das bedeuten, dass ich einen neuen Assembler schreiben müsste, der die> Mnemonics in den richtigen Opcode des uCs übersetzt den auch der Writer> erzeugen würde. Dann müsste ich diesen Satz an Infos per UART vom PC zu> einem uC senden, der den Writer simuliert und dann schlussendlich den> Chip programmiert?
Was wissen wir Beide jetzt?
Ist das Demoprogramm vollständig / lauffähig?
Ist jetzt ein anderes Osterei drinne als im entgültigen Programm?
Der Writer muß entschlüssen.
Dazu muß er eventuell mit dem Chip kommunizieren.
Wie funktioniert die Kommunikation? Wie bei ner
Chipkarte <---> Terminal?
Ist jeder Chip personalisiert oder nur der Writer?
Ist dann der "Private Key" im Writer gespeichert?
Oder wird er durch eine Lizenzmimik erst vom Lader geladen?
Fakt ist, die Hardware ist nur "Pfennigartikel",
das einzige Hindernis zum Opcode ist die Verschlüsselung.
Wenn diese verwuschelt wurde, kommt der Opcode aus dem Writer.
mfg
Ja, noch was:
Ein Osterei könnte sein, das ihre Chips nur
umgelabelte AVR mit firmeneigenem Bootloader sind,
das also der verschlüsselte Programmierstrom
AVR - Opcode ist, der mit dem Assembler generiert wird?
Wenn man so bedenkt, das die IDE ja einen Assembler
und einen kleinen Tiny C - Compiler enthält, und die Vollversion
einen Debugger zum Testen / Simulieren braucht, da ja Fehler
im Vorfeld gefunden werden müssen...
Ist der Opcode der Schatz der Firma, der verschlüsselt gehört.
mfg
~Mercedes~ schrieb:> Meine Tutorin hat sich das mal angesehen, und> meint, das da Dein Code in ein kleines "RTOS"> eingebunden und abgearbeitet wird.
Wie genau erkennt man sowas anhand einer Binärdatei?
~Mercedes~ schrieb:> Ist der Opcode der Schatz der Firma, der verschlüsselt gehört.
Ich kann mir ehrlich gesagt nicht vorstellen, dass sie die 8-Bit
Architektur neu erfunden haben. Nachbauen wird die bei dem Preis denke
ich auch keiner, wer sollte es billiger machen als die Chinesen?
~Mercedes~ schrieb:> Du willst wirklich Chips bestellen?
Ja
Rufus Τ. F. schrieb:> Was passiert bei>> char test[] = "HALLO"?
Das kann das "Mini-C" leider nicht :(
Rufus Τ. F. schrieb:> Gegebenenfalls musst Du nur noch den Optimierer überlisten, indem Du> irgendwo noch lesend auf das Array zugreifst.
Habs mal so probiert:
1
#include"extern.h"
2
3
voidFPPA0(void)
4
{
5
.ADJUST_ICSYSCLK=IHRC/2// SYSCLK=IHRC/2
6
7
WORDTEST[5];
8
TEST[0]='H';
9
TEST[1]='A';
10
TEST[2]='L';
11
TEST[3]='L';
12
TEST[4]='E';
13
14
while(1)
15
{
16
if(TEST[0]=='H')
17
continue;
18
}
19
}
leider auch ohne Ergebnis.
~Mercedes~ schrieb:> Ein Osterei könnte sein, das ihre Chips nur> umgelabelte AVR mit firmeneigenem Bootloader sind,> das also der verschlüsselte Programmierstrom> AVR - Opcode ist, der mit dem Assembler generiert wird?
Denke ich eher nicht, der µC hat 79 Instruktionen. Gibt es einen AVR der
die gleiche Anzahl an Instruktionen hat?
Die PICs wurden recht häufig kopiert, von AVR weiß ich nichts.
(selbst die OTP-PIC-Klone sind noch teurer)
Max meinte:
> Wie genau erkennt man sowas anhand einer Binärdatei?
Das macht man mittels Faktorenanalyse - Schätzverfahren
mit der Maximum - Likelihood - Methode nach R.A. Fisher. ;-)))
Na, Spaß beiseite, dazu benötigt man viel Erfahrung.
Und Gefühl!
Ich denk, ich lern das nie fließend hexadezimal zu lesen
aber meine Tutorin meint, jeden Tag 2 Stunden "Klavierunterricht"
werden mich in 3 Jahren dahin führen. Naja, :-O
> Ich kann mir ehrlich gesagt nicht vorstellen, dass sie die 8-Bit> Architektur neu erfunden haben. Nachbauen wird die bei dem Preis denke> ich auch keiner, wer sollte es billiger machen als die Chinesen?
Warum schützen die ihren Opcode so abenteuerlich?
Weil vielleicht nur Geld verdient wird, wenn der Opcode geheim bleibt?
Weil man diese Firma sonst nicht brauchen würde?
> Denke ich eher nicht, der µC hat 79 Instruktionen. Gibt es einen AVR der> die gleiche Anzahl an Instruktionen hat?
Vielleicht ists ein umgelabelter Z180? ;--P
Es gibt ja noch so viele Möglichkeiten...
Irgendwas ist da faul und der Opcode ist der Schlüssel.
Und der Bankrott der Firma. ;-D
mfg
~Mercedes~ schrieb:> Meine Tutorin hat sich das mal angesehen, und> meint, das da Dein Code in ein kleines "RTOS"> eingebunden und abgearbeitet wird.
Ich glaube, daß sich Deine Tutorin da vertut. Dieser Controller hat nur
1 kByte OTP-ROM, da wird abgesehen vom normalen C-Startup-Code (der nur
eine Handvoll Bytes groß sein wird) ganz sicher nichts zu einem
C-Programm dazugepackt. Ein RTOS ist das ganz sicher nicht, und da ist
auch nichts da, was verschlüsselten Programmcode irgendwie auspackt --
wohin denn auch, dieser Controller hat gerade mal 64 Bytes RAM.
@Rufus:
Deshalb hab ich ja auch RTOS in Anführungsstrichelchen
geschrieben. ;-P
> Ich glaube, daß sich Deine Tutorin da vertut.
Die hat ein absolutes Gespür für sowas. Natürlich sind
das bis jetzt Vermutungen.
Versuche an den vorhandenen Dateien sind "verlorende Liebesmüh"
da nicht alles da ist.
Irgend eine Bibliothek muß ja dabei sein, der Startcode
initialisiert ja "nur".
Vielleicht stellt Max dann mal die Vollversion zur Verfügung,
Ich würd' sie dann gern mal fleddern ;--P
Wie sind die EXEn gegen Debugging gesichert?
Fehlen noch DLLs?
Wie kommuniziert der Lader mit dem Prommer?
mfg
@Max,
Was mich interessiert:
Warum willst Du dich nun auf das Abenteuer einlassen,
Dich an diese Firma zu binden?
Warum benutzt Du nicht gängige Chips, wo es dann auch
gängige IDEs und andere Unterstützung gibt?
Wenn man ein größeres Projekt vor hat,
ist es dann nicht schlecht, sich von dieser Firma
mit ihrem properitären Konzept abhängig zu machen?
Ist es wirklich nur der Preis des einzelnen Chips?
mfg
~Mercedes~ schrieb:> Vielleicht stellt Max dann mal die Vollversion zur Verfügung,> Ich würd' sie dann gern mal fleddern ;--P
Was genau meinst du? Die IDE inklusive Writer-Software gibt es auf der
Homepage zum runterladen: www.padauk.com.tw (geht allerdings bei mir
gerade nicht).
~Mercedes~ schrieb:> Weil man diese Firma sonst nicht brauchen würde?
Ich denke eher, die Firma "braucht" man, weil sie so gnadenlos günstig
ist.
~Mercedes~ schrieb:> Wie sind die EXEn gegen Debugging gesichert?
Ich habs mit einem gängigen Tool geschafft, die Writer-Software zu
de-assemblieren. Mit x86-Assembler kenne ich mich allerdings nicht aus
:(
~Mercedes~ schrieb:> Warum willst Du dich nun auf das Abenteuer einlassen,> Dich an diese Firma zu binden?
Ich finde die µCs alleine deswegen interessant, weil sie so extrem
günstig sind. Das ist alles. Und meine Idee war es, einen eigenen
Programmieradapter zu entwickeln, damit man die Dinger auch ohne die
Programmiergeräte der Firma flashen kann.
~Mercedes~ schrieb:> Deshalb hab ich ja auch RTOS in Anführungsstrichelchen> geschrieben.
Ja gut, du schreibst etwas in Anführungszeichen, meinst es aber gar
nicht so?
Max meinte:
> Ja gut, du schreibst etwas in Anführungszeichen, meinst es aber gar> nicht so?
Ich weiß.
Vater meint auch, das meine Denke viel zu verschlungen ist.
Aber seit dem Zuzug von meiner Tutorin, die bei der
vorherigen Firma wegen Hacking rausgeflogen ist, ist er
eines Besseren belehrt. Es geht noch schlimmer, viel schlimmer. ;-D
Die hat in einer Nacht mit Delphi nach seiner Vorgabe ein Progamm
geschrieben, wozu ein Anderer Wochen brauchte! ;-O
> Ich finde die µCs alleine deswegen interessant, weil sie so extrem> günstig sind. Das ist alles. Und meine Idee war es, einen eigenen> Programmieradapter zu entwickeln, damit man die Dinger auch ohne die> Programmiergeräte der Firma flashen kann.
Schon klar.
Hast Du schon Ideeen, was Du dann damit machen wirst?
Interressant.
Ich werd am Wochenende mal auf die Seite www.padauk.com.tw
( liest sich wie eine Hackersite ;-P ) gehen und mich da mal
umsehen.
mfg
Der günstige Preis wird hier durch drei Dinge negiert:
- miese Dokumentation
- OTP, d.h. nach jedem Programmierversuch wegwerfen und neuen Controller
verwenden
- obskures Entwicklungssystem
~Mercedes~ schrieb:> Ich weiß.
Was meinst du denn dann?
~Mercedes~ schrieb:> Hast Du schon Ideeen, was Du dann damit machen wirst?
Erstmal versuchen, mit dem Assembler klar zu kommen :)
Dann typische erste Gehversuche: Serielle Übertragung, dann vllt.
Display über SPI ansteuern etc.
~Mercedes~ schrieb:> Ich werd am Wochenende mal auf die Seite www.padauk.com.tw> ( liest sich wie eine Hackersite ;-P ) gehen und mich da mal> umsehen.
Freut mich! 4 Augen sehen mehr als 2 :)
Rufus Τ. F. schrieb:> miese Dokumentation
Da gebe ich dir im Grunde recht, allerdings hat das bisher noch keinen
davon abgehalten, Hardware einzusetzen (siehe ESP8266, Raspi
Bare-Metal).
Das Datenblatt ist brauchbar, finde ich.
Rufus Τ. F. schrieb:> OTP, d.h. nach jedem Programmierversuch wegwerfen und neuen Controller> verwenden
Dafür gibt es einen ICE, der den µC zu 99% abbildet.
Der µC ist dafür auch einfach sehr günstig.
Rufus Τ. F. schrieb:> obskures Entwicklungssystem
100% Zustimmung.
Max M. schrieb:> Dafür gibt es einen ICE, der den µC zu 99% abbildet.
Verfügbar? Bezahlbar?
Wenn ich mir ansehe, zu welchen Preisen man einen Attiny13 bekommen
kann, nämlich für unter 30 Cent, vermag ich die Begeisterung nicht so
recht nachzuvollziehen.
Willst Du das Ding in irgendeinem Massenprodukt einsetzen? Für einfache
Basteleien erscheint es mir ... überaus umständlich.
@Max:
Hab mir die Seite mal angesehen:
Obskur, obskur!
Eine Firma, die die Chips nicht selber herstellt
sondern quasi ein Standard "FPGA" hat und darauf
offenbar verschiedene Cores programmiert, die
sie dann anbietet.
Das heißt, auf dem Chip könnte mehr als der
gewünschte Prozessor sein. ;-P
Welchen Core (also welchen Chip) willst Du versuchen?
mfg
Gibt es nur 8bit Datentypen? Hast Du Dir im hex alle Stellen an denen 3
(bei mov a,0x03) steht (ca 10 Stueck) gemerkt und verglichen wenn Du
0x04 schreibst?
~Mercedes~ schrieb:> Das heißt, auf dem Chip könnte mehr als der> gewünschte Prozessor sein. ;-P
Wie soll das bei 2 Cent wirtschaftlich funktionieren? Für fremde
Verschlüsselung müsste man eventuell auch noch Lizenzgebühren zahlen,
geschweige denn, dass ganze in Hardware zu gießen.
Dumdi D. schrieb:> Hast Du Dir im hex alle Stellen an denen 3> (bei mov a,0x03) steht (ca 10 Stueck) gemerkt und verglichen wenn Du> 0x04 schreibst?
Was auch immer das nun bedeutet :(
Dumdi D. schrieb:> Gibt es nur 8bit Datentypen?
Es gibt einen ldt16 Befehl, der den 16-Bit Zähler eines Timers im RAM
speichert.
Max M. schrieb:> umdi D. schrieb:>> Hast Du Dir im hex alle Stellen an denen 3>> (bei mov a,0x03) steht (ca 10 Stueck) gemerkt und verglichen wenn Du>> 0x04 schreibst?>> 0x03 in main.PDK_03 at: [37, 91, 290, 304, 596, 1097, 1335, 2243]> 0x03 in main.PDK_04 at: [37, 91, 831, 1450, 1961, 1993, 2149, 2285]>> Was auch immer
Mit Vergleich meinte ich, such die Positionrn wo 4 steht bei mov a, 0x04
Dann Vergleichen, dann weisst Du u.U. wo der Code steht.
Dumdi D. schrieb:> Dann Vergleichen, dann weisst Du u.U. wo der Code steht.
1
Found 0x3 in main.PDK_03 at: [37, 91, 290, 304, 596, 1097, 1335, 2243]
2
Found 0x4 in main.PDK_04 at: [33, 63, 836, 1509]
Leider nicht, zumindest sehe ich da keinen Zusammenhang.
Wenn die Instruktionen z.B. 16-Bit lang sind, kann die 0x04 auch erst im
nächsten Byte stehen, da ich mir das ganze byteweise anschaue. Wenn aber
im Byte, in dem 0x04 steht, noch Teile vom Opcode mit dabei sind, finde
ich das auch nicht.
Max meinte:
> Wie soll das bei 2 Cent wirtschaftlich funktionieren? Für fremde> Verschlüsselung müsste man eventuell auch noch Lizenzgebühren zahlen,> geschweige denn, dass ganze in Hardware zu gießen.
Spinnen wir mal absolut:
Ein Geschäftsmodell wäre, ein "Rockefeller - Chip" zu konstruieren.
Der wird wie die berühmten Petroleumlampen ( fast ) verschenkt und breit
gestreut.
Wenn jetzt ein Anwender das absolute Ding,
den absoluten Hit hat, etwa ein kleines Spielzeug
oder Ähnliches kopiert die Firma dies und
macht den Reibach. ;-D
Einfach ein Gerät kaufen, den Chip auslesen und ein
eigenes "entwickeln".
mfg
ich danke euch beiden!
@Max, hast Du mit dem IAR - Compiler, wo sich da die Beiden streiten ;-P
schon ein anderes Projekt erstellt, das lief?
ich hatte nämlich ähnliches beim 8052 Prozessor,
da hat die IDE das Startup und das Linker - File jeweils
von einem andren Device genommen, Neuinstallation der IAR
ide hat da geholfen.
mfg
Auf Taobao kann man die Anzahl flexibel einstellen und der Preis bleibt
der gleiche. Ich behaupte daher mal, dass die 2 Cent auch für 1 Stück
gelten, ansonsten wäre das verwirrend für alle Käufer.
Eventuell kauft Yoycart die Dinger direkt beim Hersteller und auf Taobao
steht ein Lager mit 100.000 Stück dahinter, die die Teile für 1 Cent
bekommen haben (ähnlich STM32F103 & STM8S aus China).
Sich nur ein Stück zu kaufen wäre hinsichtlich der Versandkosten wenig
sinnvoll. 100 Stück sollten es dann schon sein.
Max M. schrieb:> Auf Taobao kann man die Anzahl flexibel einstellen und der Preis bleibt> der gleiche.
Zeig mal den Link bitte.
> 100 Stück sollten es dann schon sein.
Du unterschätzt die Anzahl der nötigen Versuche, bis Du Dein erstes
lauffähiges Programm hast, mit dem Du dann auch zufrieden bist und es so
auch in Deiner Anwendung nutzen willst.
Bis dahin hast Du die 100 Stück schon in der Tonne versenkt...
Merke: OTP lohnt sich wirklich nur bei großen Stückzahlen und ist für
den Hobbybereich unbrauchbar.
Frank M. schrieb:> Zeig mal den Link bitte.
Um ehrlich zu sein fällt mir gerade auf, dass in der Beschreibung
darunter wohl so etwas steht wie, dass der Preis ab 20.000 Stück bei
0.13RMB und ab 40.000 bei 0.12RMB liegt:
https://item.taobao.com/item.htm?spm=a230r.1.14.13.1edd4394aWnHE2&id=543284539006&ns=1&abbucket=2#detail
Warum man dann die Anzahl variabel einstellen kann ist mir ein Rätsel.
Ich bin gespannt was passiert, wenn man da nur 100 Stück bestellt.
Frank M. schrieb:> OTP lohnt sich wirklich nur bei großen Stückzahlen und ist für> den Hobbybereich unbrauchbar.
Du musst mich von nichts überzeugen, genauso wenig werde ich dich von
irgendwas überzeugen. Außerdem hab ich schon begründet, warum man auch
bereits mit einem einzigen OTP uC ein lauffähiges Programm hinbekommen
kann (siehe ICE).
Max M. schrieb:> Um ehrlich zu sein fällt mir gerade auf, dass in der Beschreibung> darunter wohl so etwas steht wie, dass der Preis ab 20.000 Stück bei> 0.13RMB und ab 40.000 bei 0.12RMB liegt:
Du siehst das ziemlich blauäugig.
Wenn ich unter https://www.yoycart.com/Product/544765213336/ mit der
Anzahl spiele (Menge eingeben, dann TAB-Taste), sieht man, dass man erst
ab mehreren hundert Stück 3 Cent bezahlt. So ähnlich wird das auch
woanders sein - egal wo.
> Außerdem hab ich schon begründet, warum man auch bereits mit einem> einzigen OTP uC ein lauffähiges Programm hinbekommen kann (siehe ICE).
Leider hast Du auch auf Nachfrage verschwiegen, was so ein ICE u.a.
kostet:
Rufus Τ. F. schrieb:> Verfügbar? Bezahlbar?
Das einzige was Du zum ICE geschrieben hast, ist das:
> Dafür gibt es einen ICE, der den µC zu 99% abbildet.
Was zur Hölle ist das? Ein Simulator? Der könnte Dir helfen, klar. Aber
es ersetzt nicht den Echttest mit real existierender Hardware.
> warum man auch bereits mit einem einzigen OTP uC ein lauffähiges> Programm hinbekommen kann
Ein Blinkprogramm vielleicht. Aber eine ernstzunehmende Anwendung: Nein,
das glaube ich nicht. Deine Blauäugigkeit ist offenbar nicht nur auf
Deine Preisvorstellungen beschränkt.
> Du musst mich von nichts überzeugen
Will ich auch gar nicht.
Nicht schwätzen, sondern machen. Wieso musst Du noch lange über einen
Chip diskutieren, der Dich lediglich 2 Cent kostet? Kauf Dir EINEN und
MACH es vor.
Der Versuch wird sicher sehr lehrreich sein. Und nachher wird der Poster
auch begriffen haben, dass bei einem vernuenftigen Projekt, mit etwas
mehr als einer LED, ein Controller auch fuer eine 100er Stueckzahl 5
Euro kosten kann wenn man sich ein paar (Stunden)Tage spart.
Und dass man sich Sparuebungen mit Tiny oder so gar nicht erst antun
sollte.
@Max,
Du willst das Experiment wirklich wagen? ;-P
Hast Du schon Verbindung zur Firma aufgenommen?
Mich würden jetzt die Bedingungen und der Preis des
Programmierequipments interessieren, vor allen Dingen:
Bekommst Du dann eine Vollversion des Writers und der IDE?
Ist diese anders / vollständiger als die Version auf der Site?
Was ist an der Hardware dranne?
Wie funktioniert die Lizenzierung?
ich setz am Wochenende dann mal eine VM auf und würde das
Ganze dann anschauen.
mfg
Schau mal auf S. 79 im chinesischen Handbuch zur IDE - da sind einige
wenige Assembler-Befehle mit den zugehörigen Opcodes angegeben (im
Kontext der Optimierung durch den C-Compiler, wenn google translate
nicht lügt):
5E0A MOV A BB1
1B21 COMP A #0x21
2040 T0SN CF
5C0B MOV BB2 A
Weiter vorne finden sich noch (S. 73):
C028 GOTO 0x28
0030 WDRESET
1F00 MOV A #0x0
0082 MOV SP A
Vielleicht finden sich einige davon im Binary wieder, wenn du versuchst,
diese Instruktionen zu assemblieren. Es sieht auch so aus, also ob es
eine Option geben könnte, ein Listing-File mit Mnemonics und Opcodes vom
Compiler zu erhalten, das könnte helfen. S. 38 könnte einen Hinweis
darauf geben, da steht "Drücken Sie im Fenster Inverted Decode die
rechte Maustaste, um die LIST-Datei zu speichern."
Ansonsten evtl. auch mal bei
https://reverseengineering.stackexchange.com posten, vielleicht hat da
noch jemand Ideen.
-- Michael
Ich finde das was der TE macht eigentlich recht interessant.
Es ist sehr lehrreich, so ein Thema mal durchzukauen.
Dass es ökonomisch sinnfrei ist ist ja offensichtlich, erst recht als
Privatmann ohne 7-stelligen Stückzahlen.
Aber ist halt Hobby.
In wie weit handelt es sich denn bei den Padauk um exakte Klone der PIC
(abgesehen von OTP statt Flash)? Im EEVBlog Forum war zu lesen, dass der
PMS150C Bit-kompatibel zum PIC10F200 sei.
Christopher J. schrieb:> In wie weit handelt es sich denn bei den Padauk um exakte Klone der PIC> (abgesehen von OTP statt Flash)? Im EEVBlog Forum war zu lesen, dass der> PMS150C Bit-kompatibel zum PIC10F200 sei.
Der Padauk ist viel besser als ein einfacher PIC, wie ein kurzer Blick
ins Datenblatt zeigt.
Ein Beispiel: Der PIC10F200 hat einen Hardware-Kellerspeicher, nur zwei
Einträge tief. Der PMS150C hat einen 8-bit-Stapelzeiger, und kann damit
den gesamten RAM als Kellerspeicher verwenden.
Der Padauk sieht im Vergleich zu den kleinen PIC nach einer deutlich
besseren Zielarchitektur für C-Compiler aus. Aber bei Padauk fehlt es an
Dokumentation.
Philipp
P.S.: Die Padauk-µC haben anscheinend alle grob die gleiche Architektur.
Interessante Unterschiede der Varianten sind: OTP vs. MTP, Single- vs.
Dual-Core, RAM von 60B bis 256B. Manche Varianten haben auch einen
Hardwaremultiplizierer (8x8->16, Ausführung in 1 Takt).
Wenn die Dokumentation etwas besser wäre, und jemand ein freies
Flashprogramm schreiben und asxxxx und ucsim portieren würde, könnte man
wohl auch ein SDCC-backend für die Padauk schreiben.
Philipp Klaus K. schrieb:> Kellerspeicher
Ich hätte nicht gedacht, diesem Begriffsfossil nach 1990 noch mal
irgendwo in freier Wildbahn zu begegnen. Holla!
Michael Engel schrieb:> Schau mal auf S. 79 im chinesischen Handbuch zur IDE - da sind einige> wenige Assembler-Befehle mit den zugehörigen Opcodes angegeben (im> Kontext der Optimierung durch den C-Compiler, wenn google translate> nicht lügt):>> 5E0A MOV A BB1> 1B21 COMP A #0x21
Was aber auch etwas verwirrend ist, denn ein comp finde ich im
Datenblatt nicht. Es wäre naheliegend, auch von der Verwendung im
Beispiel her, dass es eine Variante von sub, die nur Flags setzt, ist.
Aber ein undokumentierter Befehl im Beispiel?
Philipp
> Du unterschätzt die Anzahl der nötigen Versuche, bis Du Dein erstes> lauffähiges Programm hast, mit dem Du dann auch zufrieden bist und es so> auch in Deiner Anwendung nutzen willst.
Also ich finde das ja super. Dann bekommen wir endlich wieder
Programmierer die echte MaennerInnen sind und nicht solche
Versuch&Irrtum-Coder. :-)
In der Anfangszeit mussten wir ja auch mit externem Eprom coden. Da sah
das so aus.
1. Sehr gruendlich nachdenken ob der Code fehlerfrei ist.
2. 1min Eprom brennen. (50ms pro Byte Programmcode)
3. Ausprobieren.
4. Fluchen.
5. Fehler finden.
6. 10-15min Eprom loeschen.
7. zurueck auf 1.
Hier nochmal ein Tip aus der Vergangenheit: Am besten den Code so
schreiben das er weiter oben im Programmspeicher anfaengt. Und dann
jeder neue Versuch etwas tiefer im Speicher. Dann hab habt ihr immerhin
mehrere versuche pro OTP bis ihr unten angekommen seid.
Olaf
Olaf schrieb:>> Du unterschätzt die Anzahl der nötigen Versuche, bis Du Dein erstes>> lauffähiges Programm hast, mit dem Du dann auch zufrieden bist und es so>> auch in Deiner Anwendung nutzen willst.>> Also ich finde das ja super. Dann bekommen wir endlich wieder> Programmierer die echte MaennerInnen sind und nicht solche> Versuch&Irrtum-Coder. :-)
Oder eine Quelle für die Varianten mit mehrfach beschreibbarem Speicher
finden.
Philipp
P.S.: https://detail.1688.com/offer/562502806054.html, eine Variante mit
doppelt so viel RAM und Programmspeicher (diesmal nicht OTP). Aber ob
die nach Europa liefern weiß ich nicht.
Olaf schrieb:> Hier nochmal ein Tip aus der Vergangenheit: Am besten den Code so> schreiben das er weiter oben im Programmspeicher anfaengt.
Und hinter jeder Funktion etwas Luft lassen. Dann kann man bei Fehlern
die Funktion aus-NOP-en (mit 0x00 überschreiben) und dahinter den Sprung
zur korrigierten Funktion schreiben.
Ach nee, darauf kann ich dankend verzichten. Ein heutiges Gerät muß per
Bootloader umprogrammierbar sein, ohne es zu öffnen.
> dahinter den Sprung zur korrigierten Funktion schreiben.
Und die relativen Sprungziele im Kopf berechnen. Jep, so fangen die
kleinen Hacker an. :-D
Olaf
Olaf schrieb:> Hier nochmal ein Tip aus der Vergangenheit: Am besten den Code so> schreiben das er weiter oben im Programmspeicher anfaengt. Und dann> jeder neue Versuch etwas tiefer im Speicher. Dann hab habt ihr immerhin> mehrere versuche pro OTP bis ihr unten angekommen seid.
Wenn der Prozessor einen fixen Einsprungpunkt hat, funktioniert das nur
dort, wo 0xffff (das "leere" EPROM) ein NOP (oder ein anderer,
"unschädlicher" Opcode) ist (das Programm also die "leeren"
Speicherstellen ohne Stolperer überlaufen kann).
Bei m68k z.B. löst Du damit nur eine Line-F Exception aus, bei ARM einen
UsageFault (illegal instruction) und selbst beim Z80 bewirkt 0xff einen
RST 38H und nicht das gewünschte Verhalten.
Für mich bleibt die Frage, bei welchem Prozessor das funktioniert hat?
> Für mich bleibt die Frage, bei welchem Prozessor das funktioniert hat?
MCS48 und MCS51. Die hatte ich zu der Zeit am Wickel. Koennte auch noch
ST6 gewesen sein.
Olaf
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten