@eProfi:
in meiner Wetterstation habe ich den Decoder IC in einem 8 Pin Gehäuse,
dass von den Abmessungen dem MSOP vom PIC12F509 entspricht (0.65 Pin
Pitch). Den PIC12C509x scheint es in diesem Gehäuse nicht zu geben
sondern nur eine Nummer größer (1.27 Pin Pitch).
Im Rahmen meiner geplanten Tests werde ich einen Decoderbaustein
(versuchen zu) löschen, da wird es sich ja dann herausstellen ob C oder
F ;-)
Hallo Walter,
stimmt, Gehäuse MSOP8 spricht für den PIC12F508-I/MS. Genauso die
Tatsache, dass er sicherer ist (löscht mehr nach einem Reset).
Außerdem lädt meiner beim Reset den OscCal-Wert FA (11111010), d.h. Bit
1 ist gesetzt. Beim C wäre das Bit not used.
Habe ein wenig simuliert, weiß aber nicht, in welcher Reihenfolge die 80
Bits gespeichert werden. Der Code ist echt tricky.
Du hast Post.
@Micha:
klar würde das helfen, besonders, wenn man als Referenz dazu einen
"echten" PIC12F509 röntgt. Das wäre schon mal ein erster Hinweis.
Schöner allerdings wäre, das Teil "funktionsfähig zu öffnen"
(Salpetersäure), dann würde man es ganz genau sehen.
Walter.
Ja, PIC12F509-I/MS wollte ich schreiben.
>zumal da auch ja hkw581 druf gedruckt
Du meinst 8+1=9 ??
Was steht bei Dir genau drauf?
An Röntgen dachte ich auch schon. Meinst Du, um Details des DIE zu sehen
oder um ihn zu löschen / anzulöschen? Die Bits wird man leider auf dem
Bild nicht sehen.
> Ich habe das letzte Bit in einem Telegramm gekippt und die ersten 14 ...
Welches erste Bit genau?
Im Patent / Wiki-Artikel steht doch, dass 42 Datenbits in den ersten
beiden Minuten und 40 Prüfbits in den letzten beiden Minuten gesendet
werden.
Zur Simulation: bin gerade dabei, herauszufinden, wie sich das
zurückgekoppelte Bit berechnet.
ok, ich habe eine WM5000 aber noch nicht nachgeschaut welcher Chip oder
Klecks da drinnen ist. Als Referenz hab ich leider blos einen PIC12C509P
Röntgen könnte ich warscheinlich nächste Woche.
Beim Röntgen meine ich das man etwas von dem Chip erkennen könnte, wird
er dadurch gelöscht oder beschädigt ?
Bei Bildern im Internet von geröntgen Chips sieht man nicht soviel von
der Die man sieht vielleicht die Bondingdrähte und wo die hingehen, bei
einer gleichen Die könnte man vielleicht trotzem mit einem 509er
vergleichen.
@eProfi,
bei dem Codeausschnitt handelt es sich um ein 80 Bit Schieberegister mit
14 Abgriffen.
Ablauf:
Adressen 0005 - 0011:
Es wird einmal nach rechts geschoben (Bit 0 springt dabei in Bit 79)
Adressen 0012 - 0020:
Es werden die Rückkopplungsbits geholt und XOR auf Bytebreite verknüpft
Adressen 0021 - 002F:
Die 8 Bit werden miteinander XOR verknüft und mit Bit 0 XOR verknüpft
Ab Adresse 0032:
Mit dem Bit 0x04,5 wird zwischen 2 Registerbänken umgeschaltet
Nachdem der erste Befel "bcf 0x04,5" ist gehe is davon aus, dass
bisher auf Register Bank 1 gearbeitet wurde.
Es wird also auf Register Bank 0 umgeschaltet, ein Byte geholt und mit
"bsf 0x04,5" wieder auf Bank 1 zurückgeschaltet.
Das zuvor aus Bank0 geholte Byte wird mit dem korrespondierenden
Schieberegister Byte XOR verknüpft.
Das wird in dem für uns sichtbaren Bereich für die ersten 4 Byte es
Schieberegisters durchgeführt, geht wahrscheinlich nach Byte 0x40
weiter.
Pro Byte werden 4 Befehle benötigt.
Wenn man jetzt weiterrechnet und das für alles Bytes des
Schieberegisters fortsetzt (2 + 6 x 4 = 26 -> 0x1A) und den Sprungbefehl
vom Anfang an Adresse 0x60 als Obergrenze berücksichtigt, so bleibt noch
für 6 Befehle Platz, z.B.:
decfsz 0x10,f
goto 0003
ret
der Code könnte also ab Adresse 0x40 so aussehen:
003e 04a4 bcf 0x04,5
003f 0215 movfw dcf+3
0040 05a4 bsf 0x04,5
0041 01b5 xorwf dcf+3,f
0042 04a4 bcf 0x04,5
0043 0216 movfw dcf+4
0044 05a4 bsf 0x04,5
0045 01b6 xorwf dcf+4,f
0046 04a4 bcf 0x04,5
0047 0217 movfw dcf+5
0048 05a4 bsf 0x04,5
0049 01b7 xorwf dcf+5,f
004a 04a4 bcf 0x04,5
004b 0218 movfw dcf+6
004c 05a4 bsf 0x04,5
004d 01b8 xorwf dcf+6,f
004e 04a4 bcf 0x04,5
004f 0219 movfw dcf+7
0050 05a4 bsf 0x04,5
0051 01b9 xorwf dcf+7,f
...
005x 02f0 decfsz 0x10
005x 0a03 goto 0003
...
005F .... retlw ..
Kann aber auch sein, dass auf Bank 0 gearbeitet wird, dann der
Momentanzustand des Schieberegisters mit Daten auf Bank1 XOR verknüpft.
In der Patentschrift ist von einem Schieberegister die Rede, dass (Laut
Patentschrift) bekannt sein darf, würde ja passen, da diese Teil der SW
sichtbar ist.
Walter
PS: Post gelesen, Post beantwortet ;-)
Zu den 42 Bit:
ja, die kommen von den 3x 14 Bit auf DCF77.
Anmwerkung: Ich zähle die Bit von 0 bis 79 und ich entferne die Bit 0
und 7 aus meinen Betrachtungen, gehe also von 80 Bit aus.
Wie sich aber bei den Antwortzeiten des Decoderchips gezeigt hat, wird
zumindest auf Bit 7 (ich zähle die Bit von 0 an) sehr schnell reagiert.
Man kann auch Bit 0 und Bit 7, die normalerweise immmer auf 0 stehen
auch auf 1 setzen, ändert nichts am Ergebnis. Daher gehe ich davon aus,
dass diese beiden Bits verworfen werden (Werden soweit ich das
verstanden habe für Katastrophenalarm verwendet).
Es bleiben also 40 Bit Daten und 40 Bit Zeit.
Die Zeit (also die hinteren 40 Bit) kann man klar zuordnen, da ist auch
keine Prüfung drin.
Ich habe das letzte Zeitbit (Obersters Bit von der Jahreszehnerstelle)
gekippt, also das Jahr 2089 eingestellt.
Das letzte Bit deshalb, da ich in den ersten 12 Bit eine CRC vermutet
habe.
Die CRC wird gebildet, indem der CRC Wert um ein Bit geschoben wird und
ne 1 rausfällt wird nen XOR mit dem Generatorpolynom gemacht.
Wenn ich nun das letzte Bit von 0 auf 1 setze und die CRC von dem
Original Telegramm habe (letztes Bit 0), kann ich die beiden Werte XOR
verknüpfen und habe das Generator Polynom (so in etwa, evtl. nochmal
schieden).
@Micha:
man sollte zumindest die Chip (DIE) -Größe erkenn und ob ggf. noch ein
EEPROM drangeflanscht ist (war glaube ich bei den 12CE509 so).
Von der Struktur wird man eher nix sehen.
Walter.
PS:
nochmal zu den Telegrammen:
Nach diversen Vergleichen und Zählungen zeigt sich, dass sich die ersten
12 Bit irgendwie anders verhalten als die folgenden 28 Bit.
Beim Vergleichen habe ich keine Telegramme gefunden, die in den ersten
40 Bit weniger als 3 Abweichungen haben.
Ich habe aber Telegramme gefunden, die in den ersten 12 Bit keine
Unterschiede aufweisen, genauso andere Telegramme, die in den folgenden
28 Bit keine Unterschiede aufweisen.
Somit sind die ersten 12 Bit genau wie die folgenden 28 Bit anscheinend
abhängig von den 40 Zeitbits.
Bonddrähte und Chip kann man durchaus auf Film auflösen, man sieht sogar
die Pads auf dem DIE an die die Drähte angeschlossen sind.
Der Zahnarzt hilft ;-)
@Walter
Kannst du mal deinen Versuch wiederholen und über Brute-Force versuchen
die ersten 12 Bit (Prtüfbit ?) zu ermitteln, indem du eine gültigen
80Bit Frame heraussuchst, der möglicht viele '0' im Chipher-Teil hat und
dann im Chipher-Teil nur 1 Bit z.B. das Erste in einem größeren '0'-er
Block kippst.
Wenn unsere Vermutungen stimmen, und die ersten 12 Bit die Prüfbits
sind, dann könnte das funktionieren.
@Thomas
Falls Walter mit seinem Versuch Erfolg hat, könntest du dann ein
Programm bauen, dass deine beiden am PC hängenden Dekoder in der freien
Zeit dafür benutzt weitere Brute-Force Angriffe auf die Prüfbits mit
leicht veränderten gültigen Frames macht. So könnte man schneller
gültige Frames erzeugen und versuchen zu ermitteln, wie sich einzelne
Bits des Chipherteils auf die Prüfbits auswirkt.
uzi
das bezweifle ich, das die Geräte schaden nehmen.
Sowas wird doch ständig beim Flughafen geröngt und nimmt keinen schaden,
die strahlen sind m.W. stärker als die der medizinischen Röntgengeräte.
Nachtrag
@ Uzi,
Machbar ist vieles, nur da die Decoder hier über eine ASP.NET
Webanwendung angesprochen werden kann ich diese nicht ohne weiteres in
einer anderen anwendung nutzen.
Wenn ich eine Datei bekomme mit Telegrammen, kann ich diese (nach
abänderung meiner decoder-anwendung) durch die beiden Decoder laufen
lassen.
Die Dosisleistung der Geräte am Flughafen ist wesentlich geringer als
die eines Diagnostischen Röntgengerätes. Auserdem arbeitet man nicht im
gleichen Wellenlängenbereich.
Beim Röntgen der feinen Strukturen im Chip ist es auserdem erforderlich
andere Verstärkerfolien/Sintilatoren einzusetzen. Auch zum
Diagnostischen Röntgen gibt es eine Bandbreite an unterscheidlich
empfindlichen und auflösenden Verstärkerfolien um die Exposition wenn
möglich gering zu halten.
Langsam verliere ich jede Übersicht ;-) Bin damit vermutlich nicht der
Einzige.
Darf ich das mal zusammenfassen? Wenn Walter auf der richtigen Spur ist,
sind also nur noch 6 Code-Bytes('Wörter') auf sinnvollen Inhalt zu
bringen und es bleibt dann als letzte Unbekannte: Die Frage, wie der
Initialisierungsvektor fürs Schieberegister aus den Zeitdaten gewonnen
wird?
Ist das so richtig?
Das Röntgen wird wenig bringen. Kenne solche Fotos. Problem ist auch,
das die Hersteller gerne mal die Chiptechnologie updaten, das Die damit
kleiner wird, aber der Chip ansonsten laut Spec gleich bleibt. Neue
Features, wie das Abdecken der Fuse-Bits, werden dabei gerne mal
verschwiegen.
Von daher ist selbst ein Größenvergleich des Die nicht sehr
aussagekräftig.
Aber laß dich nicht aufhalten.
Hallo,
seid mir nicht böse, wenn ich dumme Fragen stelle, aber ich habe einiges
noch nicht verstanden:
I) Woher weiß die Wetterstation (der Dekoder), wann gerade welches der 3
Wetter-Datenpakete angekommen ist? Einen Startpunkt gibt es ja jede
Minute (Bit 59), aber nicht zusätlich jede dritte Minute. Aus dem Log
von gestern erkennt man zum Beispiel, dass das Paket 1 erst ab der
ersten Minute, nicht schon ab der nullten beginnt. Wird das erste
Wetterpaket dann verworfen, oder gehört das zu letzten Tag?
II) Woher wisst ihr eigentlich, welche Zeitinformation zu den 3
Wetterpaketen angehängt wird? Im log ist stets die Zeitinfo des
2.Paketes angehängt worden. Warum nicht die des 3.Paketes, das wäre doch
einleuchtender?
III) DCF77 sendet folgende Zeitinfo-Reihenfolge: Minute - Stunde - Tag -
Wochentag - Monat - Jahr. Der Dekoder bekommt aber laut dem der
Logdateien folgende Reihenfolge: Minute - Stunde - Tag - Monat -
Wochentag - Jahr. Warum? Tauscht das der Hauptprozessor der
Wetterstation um?
IV) Der Dekoder bekommt 82 Bit. 3*14 Bit = 42 Bit Wetterinformationen.
Desweiteren: 7 Bit Minuten (ohne Prüfbit), 6 Bit Stunden (ohne Prüfbit),
6 Bit Tag, 5 Bit Monat, 3 Bit WoT, 8 Bit Jahr (auch ohne Prüfbit) = 35
Bit Zeitinfo. Warum werden aber bei Minute, Stunde und Tag Nullen bis
sie 8 Bit lang sind angehängt? Hängt der Hauptprozessor das an?
Bitte helft mir das zu Verstehen.
Grüße PG.
http://service.gmx.net/de/cgi/g.fcgi/mail/index?folder=inbox&first=0&extsearch=&sfid=&allfolders=&header_query=&sid=babhdde.1304686269.2913.0wqjemzgd1.73.dec
1. Es ist genau festgelegt, wann welches Paket kommt.
2. Ich vermute, dass die Daten nach der 14. Sekunde der 3. Minute an den
DCIC übertragen werden. Da ist die Zeitinfo der 3. Minute noch nicht
vorhanden.
3. Warum ?? k.A. Ja, der Hauptprozessor sammelt die Daten und übergibt
sie.
4. Ja, es werden Nullen eingefügt. Zuerst dachte ich, es würde das
Parity mit übertragen, scheint aber nicht der Fall zu sein. k.A.
Weil es einfacher ist, wenn Byte-weise übertragen wird?
@Abdul:
nein, das ganze beruht nur auf Vermutungen. Wir haben nur die ersten 64
lesbaren Worte disassembliert und analysiert. Es kann genauso gut sein,
dass der Code nur zur Verwirrung der Hacker dient (=Honeypot) und nie
ausgeführt / zur Dekodierung verwendet wird.
Außerdem: wenn der Code so kurz wäre, hätten sie einen 508er (512 Words)
verwendet. Der 509 hat 1024.
Hat jemand eine Cresta oder IROX ?
Scheinbar ist Cresta MT-03 = Irox Mete-On7
CRESTA PMT-980 = Irox Pro-X2
@Thomas: danke! Klartext HKW581 725268 oder 7252G8
Hast Du extra eine Platine gemacht? Respekt!
> ok, dann müssen wir uns echt ran halten ;-)
Ja, der momentan gültige DCF77-Vertrag läuft auch bald wieder mal aus,
aber die Wahrscheinlichkeit ist groß, dass er verlängert wird. Es gab
schonmal ernsthafte Gedanken, ihn abzuschalten.
Ja, Strom habe ich auch gemessen, man sieht schon was, aber worauf soll
ich achten? Ich glaube, dass er die ca. 276 ms voll durchrechnet.
Das falsch dekodierte Telegramm (12.01.2010 17:00)
000000000011011100010011
lautet richtig dekodiert
011011100010011011011010
6 e 2 6 d a
01101110 0010011 ist also um 9 Bits verschoben und abgeschnitten.
was ich noch bemerkt habe: das Busy wird "eine Runde" (2,4s) inaktiv,
wenn man mehr als 24 Bits abfragt. Allerdings bleibt die Zwangspause.
Gerade nochmal probiert: Wenn man bei Busy ein korrektes Telegramm
reinschickt, kommt das not-valid-Ergebnis 100000000000000000000100
zurück.
Galep 3: IC-Richtung beachten, nicht wie aufgedruckt, sondern Kerbe nach
oben.
Zu den Schieberegister-Abgriffen:
1b: 19 00011001
18: 06 00000110
17: d4 11010100
14: 08 00001000
13: 3c 00111100
--------
BitZahl 11133311
Ich habe den Thread nicht komplett durchgelesen, weiß daher nicht ob
dieses Dokument schon bekannt ist, die Informationen darin erscheinen
jedenfalls interessant für alle Dekodierungsversuche:
http://www.hkw-elektronik.de/pdf/DB%20W-Protokoll-V%201.pdf
(es ist direkt von Wikipedia aus verlinkt)
Jeder Schmeisst hier diese PDF rein,
Die ist doch schon ein alter Hut, und bringt leider garnix..
@eProfi,
Ich habe 4 Platinen machen lassen, 2 sind noch unbestückt.
und ich habe einen Prototypen (Umgebauter USB Serial Converter, in
Heißkleber eingegossen)
Und ich weiß beim besten Willen nicht wieso da doch so viele fehlerhafte
Datenätze sind...
@ Arno Nyhm: danke, das PDF ist seit 31.01.2007 09:02 bekannt und wurde
inzwischen 17 mal genannt. Du hättest nur nach www.hkw suchen brauchen,
nicht lesen.
@ Thomas:
kann es sein, dass Du mit der Abfrage des Ergebnisses zu lange wartest,
so dass ein 2,4s-WakeUp stattfindet, der die Synchronisation
durcheinander bringt? Dann gehen alle Ausgänge für 20µs auf High (falls
sie einen PullUp haben ??). Ich war auch sehr verwundert, als ich diese
Spikes sah.
An Walter:
Wie kommst Du voran? Beachte, dass das End-Programming evtl. bei
bulk-erase nicht wirkt (internal timing)! --> Vdd (und alle anderen
Pins) abschalten.
Bin gerade dabei, das asm in C zu konvertieren. Die ersten 4 Runden
laufen schon, aber die outer Loop (64 mal ???) hakt noch. Ich denke, sie
sollte nor ca. 10 - 20 mal laufen (4*10=40, 4*20=80).
Zu Simulation / Timing:
Die inner Loop dauert 4 * 46 = 184 µs
Die outer Loop dauert 64 * 227 = 14,53 ms
Das Dekodieren dauert 276 ms, / 14,53 = 19
Genug Zeit, andere beliebig komplizierte Verwürfelungen zu
bewerkstelligen.
An Walter:
Opfere den HKW581 erst, wenn es mit den Mustern sicher klappt.
Was mich noch interessiert:
Ob die Entwickler von unserem Treiben hier wissen und wie sie darüber
denken? Ob sie sich denken: hätte nie gedacht, dass die Hacker so weit
kommen, oder ob sie sich inf Fäustchen lachen, wie stümperhaft wir hier
agieren (seit 4,25 Jahren).
Ich bin guter Dinge, dass der 581 in den nächsten Wochen sein Geheimnis
preisgibt.
eProfi schrieb:> @ Thomas:> kann es sein, dass Du mit der Abfrage des Ergebnisses zu lange wartest,> so dass ein 2,4s-WakeUp stattfindet, der die Synchronisation> durcheinander bringt? Dann gehen alle Ausgänge für 20µs auf High (falls> sie einen PullUp haben ??). Ich war auch sehr verwundert, als ich diese> Spikes sah.
Ich warte darauf, das CLK_OUT auf High_pegel wechelt und dann lese ich
die daten aus. es kann sein das der Pegel dort durch den WDT kurzzeitig
auf HIgh geht und deshalb schon vorher mit dem auslesen angefange wird.
Der gesamte vorgang (Daten Reinschieben, dekodieren, daten rausholen)
dauert weniger als eine sekunde.
Ich warte nach dem einlesen der daten maximal 5s, wenn der decoder den
ausgang nicht auf high schaltet, dann wird von meinem geschriebenen
Modul 111111111111111111111100 Zurückgegeben, als Zeichen das etwas
nicht stimmt.
Habs herausgebracht, wie das Rückkopplungsbit aus den 14+1 Bits
berechnet wird. Das Carry geht nicht mit ein!
Die Zeile oben hat einen Fehler in Bit 50:
Hallo Leute,
ich habe mal den aus dem HKW Chip frei auslesbaren Code-
Schnippsel (die ersten 64 Byte der Code-Sektion) in C umgesetzt.
Ihr könnt ja mal etwas damit rumspielen, wenn ihr Ideen habt,
wie der kodierte input-Datenstrom in den Algorythmus
eingesetzt werden könnte.
Achtung, der Algorythmus ist natürlich unvollständig,
da ja nur die ersten 64 Byte des Programms bekannt sind!
-------------------------------------------------------
Hier noch eine Idee wie wir dem Entschlüsselungsalgorythmus
weiter auf die Spur kommen könnten:
Wir brauchen einen HKW Chip, einen PIC 12F509 und ein Oszilloskop.
Wir nehmen nun den bekannten Code-Schnipsel und
ergänzen ihn so, dass er immer wieder durchlaufen wird
und jeweils am Ende eines Durchlaufs ein Pin getogged wird.
Diesen Code lassen wir in einem PIC12F509 mit gleicher Frequenz (4MHz ?)
laufen und messen mit dem Oszilloskop hochauflösend die Stromaufnahme
z.B. indem ein 10 Ohm Widerstand in die Spannungsversorgung
des Pic eingeschleift wird und darüber die Spannung
zum oszillografieren abnehmen.
Durch den toggle-Pin haben wir einen definierten Trigger
und haben nun einen Strom-Fingerabdruck des Code-Schnippsels.
Jetzt machen wir die gleiche Messung am HKW-Chip, während er
einen Datenblock entschlüsselt. Wenn wir Glück haben,
erkennt man den Fingerabdruck des Codeschnippsel wieder
und es lässt sich möglicherweise abzählen wie oft er durchlaufen
wird. Damit könnte man dann die noch offene Anzahl der
Schleifendurchläufe dieses Codeschnippsels ermitteln.
Mal ganz blöd gefragt, als jemand, der davon nicht so wirklich eine
Ahnung hat: Wenn ich jede mögliche Kombination von nullen und einsen in
den Chip schiebe, und jede Kombination im Ausgang dazu gegenüberstelle,
dann erhalte ich ja eigentlich unterm Strich eine komplette Logik,
welche ich dann in einem FPGA nachbilden kann. Oder sehe ich das falsch?
Martin Schwaikert schrieb:> Wenn ich jede mögliche Kombination von nullen und einsen in> den Chip schiebe
Prinzipiell ja, aber das Problem liegt darin, dass - wie Du selbst
schreibst - "jede mögliche Kombination von nullen und einsen" ziemlich
viele sind. Sehr viele sogar!
Dazu kommt, dass die Zeit ja auch mit drinnensteckt, das heißt eine
Rainbow-Table aus der Vergangenheit bilden wird das Problem auch nicht
lösen.
MfG
P.Wassi
um mal die Menge an möglichen Kombinationen zu verdeutlichen:
selbst wenn du eine MILLIARDE Kombinationen PRO SEKUNDE (1GHz) rein
schiebst, macht das bei 64 Bit ganze 584 Jahre, die man damit
beschäftigt ist das ganze durchzugehen.
und bei 80 Bit sind das nochmals 2^16mal so viel.
dann mal viel Spaß :)
Uzi, das gibt es doch nicht, warum haben wir ausgerechnet heute exakt
das selbe gamacht?
btw.
{
if(lfsr[0] & 0x01) //Ergebnisbit der vorherigen Runde...
{
carry_in=1;
}
geht einfacher und richtger:
carry_in = lfsr[0] & 0x01;
Du setzt es nämlich nicht auf 0 (das wäre der else-Fall).
Im Anhang meine Version. Der Simulator berechnet exakt die selben
Ergebnisse.
Die Idee mit der Strommessung ist gut. Ob sie auch funktioniert?
An Martin:
das Problem sind die 36 Sekunden Zwangspause bei jedem Durchlauf.
Hallo
Ich lese auch schon eine Weile interessiert mit, auch wenn ich mehr oder
weniger nur Bahnhof verstehe.
Was mir hier aufgefallen ist, dass ihr zwar die Daten hin und her
verschickt, als Anhang usw, aber habt ihr denn auch alle den selben
Regionscode ? Denn sonst koennen die Daten ja garnicht uebereinstimmen.
Je nach Regionscode, haette man ja ein anderes Ergebnis.
Wie fliesst dieser Regionscode ueberhaupt ein ? Gibt es da schon
naeheres.
Wenn ich es ueberlesen haben sollte, sry, aber der Thread ist ja nun
wirklich schon unglaublich lang, da kann man nicht alles behalten.
@IchBins
Tut mir leid das ich das nun so Schroff sage, aber du hast wirklich nur
Bahnhof verstanden.
Zu bestimmten Zeiten werden Bestimmte Regionen Übertragen, das hat die
Fa. Meteotime irgendwanneinmal so festgelegt,
Schau dir mal die Logdatei an, dort kannst du sehen wann was übertragen
wird.
http://www.dcf77logs.de/ViewLog.aspx?mode=meteo&file=DCFLog01035.log
Das ist jeden Tag gleich. Dazu muss man sagen das es nur Unterschiede
bei Sommer und Winterzeit gibt. Die Aufteilung der Regionscodes
funktioniert nach UTC.
Hi,
ist doch voellig okay, ich habe ja gefragt und schroff finde ich Deine
Antwort garnicht.
Es ist halt nicht so einfach, sich in ein Thema einzuarbeiten, von dem
man ueberhaupt keine Ahnung hat, es aber verstehen moechte. Da muss man
halt manchmal dumme Fragen stellen, weil gerade hier ist es ja nun
wirklich sehr komplex geworden.
Zum besseren Verständnis die Zuordnung der d.c[] zu den Ram-Adressen:
zuerst wollte ich 3 longints für die 80 Bits verwenden (96-80=16 Bits
wären not used). Dann kam mir die Idee, 5 longints zu verwenden und pro
longint nur 16 Bits zu verwenden, und die 5 Carrys in Bit16 zu
speichern.
Auch möglich wäre: unsigned int u[10], d.h. pro Byte ein uint zu
verwenden und das Carry in Bit 8 zu speichern. Dann bräuchte man die
union nicht, aber man müsste 10 mal Carry extrahieren und schieben.
u.c[19] not used \
u.c[18] Carry von Ram12:0 \ = u.l[4]
u.c[17] Ram1b /
u.c[16] Ram1a /
u.c[15] not used \
u.c[14] Carry von Ram1a:0 \ = u.l[3]
u.c[13] Ram19 /
u.c[12] Ram18 /
u.c[11] not used \
u.c[10] Carry von Ram18:0 \ = u.l[2]
u.c[ 9] Ram17 /
u.c[ 8] Ram16 /
u.c[ 7] not used \
u.c[ 6] Carry von Ram16:0 \ = u.l[1]
u.c[ 5] Ram15 /
u.c[ 4] Ram14 /
u.c[ 3] not used \
u.c[ 2] Carry von Ram14:0 \ = u.l[0]
u.c[ 1] Ram13 /
u.c[ 0] Ram12 /
d^=u.c[17]&0x19;//12 Ram1b
d^=u.c[12]&0x06;//15 Ram18
d^=u.c[ 9]&0xd4;//18 Ram17
d^=u.c[ 4]&0x08;//1b Ram14
d^=u.c[ 1]&0x3c;//1e Ram13
Die Routine von 21 - 2e berechnet die gerade Parität von d (=Ram1c).
Ich habe den Eindruch, dieses Codeschnipsel ist nicht (nur) die
Dekodierroutine, sondern (auch) die Prüfung, ob ein Telegramm gültig
ist.
Was ist mit unserem Walter? Seit 2 Tagen kein Post von ihm...
Thomas Berends schrieb:> um mal die Menge an möglichen Kombinationen zu verdeutlichen:> selbst wenn du eine MILLIARDE Kombinationen PRO SEKUNDE (1GHz) rein> schiebst, macht das bei 64 Bit ganze 584 Jahre
Thomas, du machst einen Gedankenfehler, du gehst von einem singulären
System aus, welches die Lösung errechnen könnte. Ich weiss zwar nicht,
wieviele Hobbyisten und Möchtegernwetterfrösche hier mitlesen, aber
während im Internet tausende ihren Rechner im Verbund zur Verfügung
stellen, um die Wahrscheinlichkeit der Existenz von Fröschen auf anderen
Sonnensystemen zu berechnen, könnten wir doch unsere geballte
Rechenleistung auf dieses Problem loslassen. Das wäre denn auch ein
Interessenbarometer für dieses Forum.
Notwendig dazu wäre nur jemand, der die Jobs dazu vergibt. Sozusagen ein
Administrator.
Sorry, aber die Idee kam mir (wie kann es anders sein ;-) auf'm Klo...
"Im Mai 1999 wurde das Projekt SETI@home von der UC Berkeley gestartet,
das die Daten von SERENDIP IV benutzt. Dieses Projekt benutzt die
Rechenleistung von vielen Computern im Internet, die von Benutzern
freiwillig zur Verfügung gestellt wird."
Quelle:
http://de.wikipedia.org/wiki/Search_for_Extraterrestrial_Intelligence
meinereiner schrieb:> ...aber während im Internet tausende ihren Rechner im Verbund zur Verfügung> stellen...., könnten wir doch unsere geballte Rechenleistung auf dieses> Problem loslassen. Das wäre denn auch ein Interessenbarometer für dieses> Forum.
Nicht nur fuer dieses Problem. Also ich bin dabei, so lange es auch auf
Linux laeuft.
Die Idee finde ich gut, vielleicht sollte mal jemand einen neuen Thread
dazu starten. Nein, ich nicht, ich habe keine Ahnung davon.
Editieren ging nicht mehr.
Ich habe eben mal nach Seti@home gesucht und bin auf BOINC gestossen.
Damit laesst sich das Vorhaben eigentlich recht einfach ralisieren.
Im Anhang zwei Dateien, die beide 64*4 Durchläufe (nach der Dekodierung
leerer) Wetterdaten enthalten.
jede 5. Zeile zeigt den Inhalt von Ram32-3b und den Countdown.
Ich kann beim besten Willen keine Übereinstimmung erkennen.
Die Verwürfelung kann beliebig kompliziert sein. Z.B. habe ich oben bei
der Zeitberechnung gesagt, es wäre genug Zeit, 19 solcher "files" zu
erzeugen.
D.h. wenn jetzt aus irgendeiner Zeile jeweils nur ein Bit herausgenommen
wird, könnte so das Ergebnis (es sind 22+2 Bits) erzeugt werden.
Da hat man einfach keine Chance.
Ich sehe nur eine Möglichkeit: den Chip mit Glitches o.ä. zu kitzeln, um
an den Code zu kommen.
@eProfi & uzi:
ich fürchte, Ihr habt beide den hinteren Teil der "outer loop" falsch
implementiert:
Im PIC wird zuerst auf Bank 0 umgeschaltet, ein Byte geholt und wieder
auf Bank1 (zurück ?) geschaltet und mit dem Schieberegister verknüpft.
Es liegen also anscheinend Daten auf Bank0 die nach jedem 4.Schieben mit
dem Schieberegister verknüpft werden und nicht umgekehrt.
Hier könnten wir die Idee von Chris (den RAM Monitor) gut gebrauchen,
damit könnte man ein bischen unter den Rock schauen.
Mit dem Programmer:
das mit dem "Anschreiben" scheint nicht weiterzuführen. Wenn ich nach
ca. 3us das Schreiben abbreche sind nur einzelne Bits gekippt - ich sehe
aber keinen Zusammenhang mit dem ursprünglichen Inhalt. Ich glaube, die
Sache mit den Glitches ist da besser. Mal sehen...
@Walter
ich hab mir den Code nochmal angesehen und du scheinst recht zu haben,
es wird auf Bank 0 umgeschaltet, dort ein Wert geholt zurück auf Bank1?
geschaltet und dort das Schieberegister mit diesem Wert ge-XOR-t.
Liegt hier auf der Bank0 vielleicht ein geheimer Schlüssel
(Zeit/Datum, Prüfbits oder sonstiger Schlüssel ??)
Wie sieht es mit deinen Brute-Force-Versuchen mit den 12 Prüfbit aus?
Bist du weiter gekommen? Hast du mal den Vorschlag aus meinem Post vom
06.05.2011 19:40 ausprobieren können?
@Thomas
ja, das hab ich gesehen, aber er hat meines Erachtens das manipulierte
Bit ungünstig gewählt, indem er ein Bit im Zeitstempel manipuliert
hat.Ich vermute dass man nur die Wetterdaten (chiper-Bits) manipulieren
darf und mit den geeigneten Prüfbits und der entsprechenden Zeit-Info
einen gültigen Frame erzeugen kann. Denn wenn man die Zeitinformation
manipuliert, ist keine Dekodierung möglich. Jedoch wenn man die
Chipher-Bits manipuliert, gibt es anscheinend Dekoder die mit hilfe der
Prüfbits den "Fehler" korrigieren können. Dies legt die Vermutung nahe,
dass die Prüfbits im wesentlichen den Chipher-Bereich abdecken und ggf
noch vielleicht ein paar wenige Bit als Parity o.ä den gesamten
80Bit-Frame abdecken.
@Thomas bestände die Möglichkeit einen Webservice, z.B. WSDL oder per
HTTP-GET für deine Decoder zu implementieren, sodass man nicht alles per
Hand in das Textfeld eintragen muss? Wobei die Priorität auf dem
Webfrontend liegen sollte. Wenn Du dafür Hilfe benötigst, melde dich.
Mach doch einfach alles per ftp-Freigabe. Kommt eine neue Datei rein,
wird sie abgearbeitet als CSV oder so. IE hat übrigens einen ftp-Client
bereits integriert.
Ihr habt vielleicht Wünsche ;)
eine FTP-Freigabe scheint wohl das einfachste zu sein, zumal ich keinen
blassen dunst von wsdl habe...
Zur Info, die ganze Webseite ist in c# geschrieben, .NET 4.0 basis.
ftp -> Datei reinschrieben -> abarbeiten
jede zeile 82 Bit (Bit 0 und Bit 7 bitte drinne lassen)
Ich habe diese Woche jedoch wenig zeit, von daher kann es sein das ich
erst am Wochenende dazu komme.
Zugangsdaten für den FTP gibts erst wenn ich fertig bin.
Gruß
Thomas
So ich könnte Heute den Chip röntgen lassen. Ich möchte aber nicht das
er davon kaputt geht. Damit die Leiterbahnen nicht stören löte ich ihn
aus.
Habe nur bedenken beim Röntgen, hat das schonmal wer gemacht und dabei
einen Löschbaren Chip nicht gelöscht ?
Hi Micha,
gute Idee mit dem Runterlöten.
Ich denke nicht, dass der Chip oder die SW im Flash Schaden nehmen.
Der Chip wird sicher nicht mehr als 1 Sekunde den Strahlen ausgesetzt
werden.
Zum Vergleich: unter UV muß man nen Eprom ein paar Minuten liegen
lassen, bis es gelöscht ist.
Walter.
So hier nun die Bilder, wir sind durch den HKW aie auch bei dem 12c509
niuccht richtig durchgekommen auch bei der stärksten Einstellung.
Zum testen noch ein Mega8, da gings ganz gut.
Man kann jedoch schemenhaft die DIE erkennen, im vergleich zu einem
12c509 ist die vom hkw viel kleiner.
Ober noch geht werde ich sehen, hab leider nur eine Uhr zum testen im
Moment.
Wenn ich die Schatten in dem Bild richtig deute, ist der kleine Chip
stark asymmetrisch gebondet, es sieht fast so aus, als wären die beiden
rechten Pins unbelegt.
Die Frage ist, ob es vom 12C509 verschiedene Revisionen gibt, die sich
in der Die-Größe unterscheiden.
Der 12c509 soll ja sowiso nicht dem hkw entsprechen, es müsste ein
12f508 sein habe ich aber nicht.
Der PIC von mir ist auch schon sehr alt, also älter als 2006 sicher.
@Micha: danke für die Arbeit
ich habe keinen C-Typen zum Vergleich, hab aber mal nen PIC12F509
aufgeschliffen, das kommt schon hin von der Größe.
Unten drunter ist ein Shield oder eine Groundplane, von oben denke ich
kann man den DIE sehen, ca. 3x3 mm, also ähnlich wie im HKW.
Der PIC12C509 ist EPROM und älter, also wahrscheinlich eine größere
Struktur. Beim F-Typen hat evtl. ein Shrink stattgefunden.
Ausserdem gibt es den C-Typen anscheinend nicht im MSOP Gehäuse, den
F-Typen schon (der C -DIE würde da ja auch garnicht reinpassen).
Es wird hier immer wieder zwischen 508 (kleiner Speicher) und 509
("großer" Speicher) hin und hergesprungen.
Die lesbaren Adressen im HKW (movlw ... an 0x3FF und configword an
0x7FF, backup des oscillator Korrekturwertes...) deuten auf den 509 hin
und schließen den 508 aus.
Es muß den Chip auch schon Anfang 2008 gegeben haben (da habe ich meine
Wetterstation gekauft), das schließt neuere Typen aus.
Ich werde heute mit der Bearbeitung der Weboberfläche beginnen,
Ich habe entschieden dies per HTTP-Upload zu realisieren, wann ich damit
fertig bin kann ich nicht sagen.
Ich nutze diesen post als Ankündigung das ich nun beide Decoder zu
Entwicklungszwecken nutze. Falls jemand noch Datensätze dekodieren
möchte, bitte ich dies innerhalb der nächsten 90min zu tun.
thomas
wollte keine Verwirrung schaffen ich weiß nicht ob es ein 508 oder 509
ist, ich habe nur nach der Bezeichnung in dem Thread gesucht und das was
ich gefunden hab war ein 508. Also meine Vermutungen bzgl. Typ
ignorieren.
Leider ist mir das zu spät eigefallen wie man evtl. doch ein besseres
Bild bekommen könnte. Nicht nur einmal schießen auf den Film sondern 2-3
mal dann wäre vielleicht der Kontrasst besser geworden.
@Abdul K.:
ja, der EM6580 ist anscheinend in meiner DV323 verbaut. Dort ist ein
unbestückter Footprint, anscheinend eine alternative Möglichkeit für den
auf meiner Platine vorhandenen "schwarzen Klecks".
Habe keinen anderen Controller gefunden, der auf diesen Footprint passt.
Auch sind die Timings etwas anders als bei dem vermutlichen PIC.
Der EM6580 hat soweit ich weiß keinen Ausleseschutz.
Allerdings setzt der Hersteller auf "Security by Obscurity" indem er die
Befehle für das InCircuitProgramming nicht offenlegt. Dies lässt sich
aber vermutlich durch das Mitschneiden bei einem offiziellen Programmer
herausfinden.
Eine weitere Hürde in meinem Fall ist, dass der Testpin nicht aus dem
Klecks herausgeführt ist. Somit lässt sich der Controller nicht in den
Programming Mode versetzen. Evtl. kann man das Ding aber röntgen o.Ä.
und dann geziehlt ein Loch in den Klecks bohren, um an den Testpin zu
kommen (theoretisch ;-)
Walter
Bei mir sind zwei Barigo MT300 eingetrudelt, ziemlich riesige Teile.
http://www.barigo.de/module/uploads/download_file_20.pdf
Hinten sind 6 Schrauben, aber ich kann sie trotzdem nicht öffnen.
Sind auf der Vorderseite hinter dem Chromrahmen weitere Schrauben?
Ich vermute, es ist die MeteOn3 oder MeteOn7, die DIET aus dem alten
Thread schon untersucht hat.
Autor: Didi Barth ({diet}) Datum: 16.03.2007 10:49
Beitrag "Re: AVR: Wetterinformationen über DCF77"
"noch einer" hat sie evtl. auch.
Sie hat auf der Rückseite den Deckel, hinter dem sich der 2x8=16-polige
Wannenstecker verbirgt.
Leider sind die Fotos nicht mehr online, hat die jemand?
@eProfi, wie es der Zufall will, Ja...
Ich habe damals zur Sicherheit den kompletten Thread inklusive der
Verlinkten Dateien gespeichert, zumal das mit der Begründung geschlossen
wird, das es vielleicht rechtlich nicht ganz okay ist..
Anbei die Bilder...
thomas
ElectronicMarin (EM) hat µC (dürfte noch ein 4-Bitter sein)
als "Flash" für die Entwicklung des Programms, für die
Serie wird dann ein Maskenprogramm verwendet.
Letzteres kann nicht ausgelesen werden.
Für geringe Stückzahlen ist die Flashversion sicher sinnvoll,
ab einer Stückzahl, ich schätze ein paar k, wird die Maskenversion
deutlich günstiger. Die Einmalkosten für die ROM-Maske
sind gar nicht so hoch, man darf sie aber nicht vergessen.
Die aktuellen Preise muß man erfragen.
Wenn ich mein Programm schützen möchte, würde ich ggf. auch
bei kleineren Stückzahlen zur Maskenversion tendieren.
Natürlich: Ein Bug, neue Maske (=Einmalkosten) wird fällig!
Ob das Spielchen Maskenversion auch beim PIC möglich ist weiß
ich nicht, dafür kenne ich die Teile zu wenig.
Danke, Thomas.
Hab es endlich geschafft: im Gehäuse ist ein schwarzer Rahmen, der mit
der Vorderseite verschraubt ist.
Mit der Hinterseite ist er nur geklipst.
Diese Clip-Verbindung muss man trennen, dann geht es ganz leicht.
Ich hatte versucht, den Rahmen von der Vorderseite zu trennen.
Es ist die Hideki DV323, die auch Walter hat.
Nach einem Reset zeigt sie SW V1.2 und DB V0.5 an.
U1: Spannungsregler
U2: kleiner Klecks
U3: nicht bestückt (Alternativ-Bestückung zu U4)
U4: ATMEL 702 24C512N 5U27 A
U5: nicht bestückt (Alternativ-Bestückung zu U2)
großer Klecks mit 4*26=144 Pins (Platine sagt 141)
Der Temp- und Feucht-Sensor ist mit SHT01L beschriftet.
Es sind 8 Platinen:
1: E-PC-D323-0F0V0 DV323-MAIN-PCB REV:0.1 07.6.13 (13.06.2007)
2: E-PC-6015-0F0V0 REV 0.2 060829 DCF-HBG-Empfänger mit IROX-Logo
3: E-PC-D323-2-0V0 DV323-LED-PCB mit 4 blauen LEDs
4: SV2 für 16-pol-Programmieradapter
5: Sensorplatine SHT01L
6: E-PC-T530-2F0V0 433RX-100M REV0.3 433MHz-Empfänger
7: E-PC-D323-1-0V0 DV323-KEY-PCB REV 0.0 07.5.18
8: E-PC-R820-2-0V0 Licht-Taster RC82-SNZ REV: 0.1 020427
51 TestPunkte
6 gelötete Jumper
Micha (Gast) Datum: 13.05.2011 20:41
Schau auf den Wiki-Artikel DCF77 Wetterinformationen .
8 Platinen, kommt mir persönlich etwas viel vor..
Das mit der Seite zum Dekodieren von ganzen Sätzen an Daten verzögert
sich etwas, u.A. familiäre Gründe...
Gruß
Thomas
das mit den 8 Platinen kann ich bestätigen, zu mindest in etwa:
DCF77, 433MHz, Feuchtesensor sind bei mir auch auf eingenen Platinen,
Hauptplatine und eine Platine für die Tasten (hinten).
Habe jetzt auch 2 Chips parallel laufen ;-)
Hab nochmal nen 2ten Test mit den ersten 12 Bit gemacht, dieses Mal habe
ich weiter vorne ein Bit gekippt - leider auch keinen Erfolg.
Mit ist noch etwas bei dem PIC aufgefallen:
Wenn Pin5 high ist (busy) geht er ca. alle 2-3 Sekunden für ca.11us auf
low, 2us vorher kommt er anscheinend von hochohmig (Busy_high.png,
Busy_high2.png)
Umgehekrt: Wenn Pin 5 low ist (nicht busy) geht er ca. alle 2-3 Sekunden
für ca 13 us auf high, dann kommt ein wieder ein Knick und ca.2us später
geht er auf low. (Busy_low.png).
Ich werde mir jetzt eine Mete-On3 besorgen, da kann der Chip angeblich
korregieren - vielleicht bringt uns das weiter.
Schau ins Datenblatt und finde dort heraus, wann Pins automatisch
hochohmig werden. WDT, Sleep usw. wären abzuklappern. Eventuell bekommst
du dadurch Querinformationen.
bei PIC12F509:
man kann den Speicher an den Adressen 0x405-0x43F beschreiben. Im
Datenblatt sind sie als "reserved" gekennzeichnet.
Leider ist es mir (noch) nicht gelungen, den Code an dieser Stelle
auszuführen.
Wäre dies möglich, so wäre es ein Leichtes den von Chris vorgeschlagenen
RAM-Monitor zu implementieren.
Weiß jemand, wozu dieser reservierte Bereich gedacht ist ? Das Bit PA1
scheint nicht implementiert zu sein. Ein "goto" verhält sich so, als ob
PA1 gleich 0 ist.
Der PIC scheint alle 2,3 Sekunden (WDT) aufzuwachen. Dann schaltet er
PIN5 (Busy) für ca. 12us auf invertierten Zustand: wenn er Busy ist
(PIN5 normal high) -> low, wenn er Telegramme decodieren kann (PIN5
normal low) -> high.
Es wurde im alten Thread von einem Testmodus berichtet in welchem man
(zumindest bestimmte) Telegramme wesentlich häufiger zum DCIC schicken
kann als im "normalen" Betrieb.
Vielleicht war das eine Option, damit der Entwickler selber seinen Code
effizienter testen konnte? Vielleicht hat er einen vorgefertigten Pack
von Wetterdaten häufiger durchgeschickt...
Kann mich allerdings nicht an einen Testmode erinnern.
Beschreibbare Bereiche benutzt man z.B. für Seriennummern.
Eventuell gibt es auch noch einen Encoder-Mode? Z.B. weil der Entwickler
seinem Kunden Meteo-Time den Algorithmus nicht geben wollte...
'nabend allerseits,
Beim encodermode müsst man dann aber wetterdaten und Zeittelegramm
sinnvoll reinschieben, wobei hier keinerlei infos zu finden sind...
möglich wäre das der Decoder dann automatisch in diesen "modus" wechslet
...
ich bezweifle das jedoch...
An der Decoder-seite bin ich bei, vermutlich werde ich morgen oder
sonntag fertig sein...
Dann könnt ihr ganze dateien hochladen, maximal 10MB am stück, das
sollte reichen, aber dann auch sehr lange dauern...
2 Decoder, mehr hab ich nicht zur freien verfügung, der dcf-reciever
muss ja auhc noch seine daten dekodieren.
Walter Freywald schrieb:> bei PIC12F509:> man kann den Speicher an den Adressen 0x405-0x43F beschreiben. Im> Datenblatt sind sie als "reserved" gekennzeichnet.> Leider ist es mir (noch) nicht gelungen, den Code an dieser Stelle> auszuführen.>> Wäre dies möglich, so wäre es ein Leichtes den von Chris vorgeschlagenen> RAM-Monitor zu implementieren.>> Weiß jemand, wozu dieser reservierte Bereich gedacht ist ?
Hallo Walter,
ich vermute das sind Testregister, die dazu dienen nach der Produktion
den Chip zu testen. Sie sind für den internen Gebrauch bei der
Produktion gedacht. Code kann man da vermutlich nicht ausführen.
Du kannst ja mal etwas mit den einzelne Bits in diesen Testregistern
spielen, vielleicht gibt der Chip ja ein Geheimnis preis....;-)
ist der 12f509 debugfähig?
wenn ja, kann man dann nicht den chip mehr oder weniger sein geheimnis,
zumindest bruchstückhaft entlocken,
indem man in alle register definierte werte schreibt, und dann den
instruction-pointer immer per hand um 1 erhöht und dann nachschaut was
da ausgeführt wird (änderung der register)
natürlich kann man dann nicht alle befehle herausholen, aber manches
sollte möglich sein, sofern das teil debugfähig ist...
Thomas Berends schrieb:> 'nabend allerseits,>> Beim encodermode müsst man dann aber wetterdaten und Zeittelegramm> sinnvoll reinschieben, wobei hier keinerlei infos zu finden sind...> möglich wäre das der Decoder dann automatisch in diesen "modus" wechslet> ...> ich bezweifle das jedoch...>
Ich eigentlich auch :-) Wäre untypisches Vorgehen des Entwicklers. Eher
so wie ich es mache - ich bin ja nicht normal.
Es war nur als Hinweis für folgendes gedacht:
1. Warum ist der PIC größer als vermutlich notwendig?
2. Eventuell ist das gefundene freiliegende Schieberegister das welches
encodiert.
Guten Abend,
Ich habe soeben die neue Seite online gestellt, es gab ziemliche viele
Probleme, hoffe dass es nun einigermaßen stabil ist...
An diesn Post habe ich eine Beispieldatei angehängt, wie eine Datei
aussehen muss damit die Verarbeitet wird.
alles wichtige steht auf der Seite selbst. Die Angehängte Beispieldatei
habe ich dort zum Testen hochgeladen, damit ihr das Ergebnis anschauen
könnt wie das aufgebaut ist.
Bevor ihr eine Datei hochladet, achtet auf den Dateinamen, damit dieser
Sinnvoll ist und Ihr den nachher auhc wiederfinden könnt. Ich weiß ja
nicht wie groß der Ansturm ist. Doppelte Dateiname sind kein problem, da
die Anwendung intern mit GUIDs arbeitet.
Desweiteren gibt es noch kleine Probleme mit dem Zeichensatz in der
Ausgabedatei. Darum keine Umlaute, sonderzeichen etc. verwenden.
Ansonsten gibts Zeichensalat (Siehe ergebnisdatei im anhang).
Sollten noch Fragen sein, einfach schreiben.
Wenn Datensätze schonmal dekodiert wurden, werden diese aus der
Datenbank genommen, um die Dekoder nicht unnötig zu belasten.
Dann wird ein Kommentar vor dem Datensatz hinzugefügt, der darauf
hinweist.
Der Link bleibt wie gehabt:
http://www.dcf77logs.de/DecoderAccess.aspx
nochmal zum PIC:
ich habe das jetzt mal mit einem "normalen" PIC12F509 probiert:
(VCC bleibt immer an)
- SW1: schreibt Daten ins RAM
- Baustein löschen
- SW2 reinprogrammieren: liest das RAM und gibt den Inhalt sync seriell
aus
Ergebnis: der RAM Inhalt bleibt auch nach dem Flash löschen erhalten
Das bedeutet:
man könnte den PIC z.B. nach Einlesen der Daten mittels Reset anhalten,
mit der ReadRam neu flashen und das RAM auslesen.
Oder beim dem ominösen Schieberegister am Anfang eine Endlosloop (mit
WDT reset) einbauen. Dann hätte man die Daten, die man vorher
reingeschoben hat in der korrekten Form im SR liegen und auf Page 0
würde man die Daten bekommen, die XOR nach jedem 4.Schieben auf das SR
abgebildet werden.
Der PIC ist danach allerdings tot (also (vorerst ;-)) nicht mehr als
DCIC zu gebrauchen)...
Also sollte wohl überlegt werden, welche Daten reingeschoben werden und
wann die Kiste angehalten und ausgelesen wird.
Thomas, Du hast Post (Formular und snail).
Weitere Möglichkeit:
Nach einem Reset wird nach 3ff gesprungen. Dort steht ein MOVLW mit dem
Calibrierwert. Diesen Befehl kann man ändern / einen NOP draus machen.
D.h. man sieht die oberen 6 Bits des W zu dem Augenblick, bevor der
Reset ausgelöst wurde, anhand der Frequenz, mit der der µC dann läuft.
Man kann nun eine Schaltung bauen, die den DCIC immer wieder mit den
selben Daten füttert und dann sukzessive einen Zyklus später resettet.
Wir wissen also, was in 0x060 steht:
MOVW OscCal
Ausgänge konfigurieren, da sie durch den Reset/WDT Eingänge wurden
Entscheiden, ob es ein POR oder ein WDT war
Alternativ könnte man die sichtbare Routine so ändern, dass sie W und
die zu schiebenden Daten seriell ausgibt, das Geschiebe ein externer µC
übernimmt und wieder seriell zurückschreibt (ähnlich wie Chris' Ansatz).
Damit hätte man alle 8 Bits von W.
Wir schaffen es !
Hallo eProfi,
guter Vorschlag. Das W-Register wird beim Reset tatsächlich nicht
verändert (ich habs ausprobiert - ich hätte es nicht gedacht !). Sollte
funktionieren, sofern der Wert wirklich ins OSCCAL Register geschrieben
wird.
PA5 im Statusregister (zur Auswahl der RAM Page) wird beim Reset wohl
auf 0 gesetzt - zumindest laut Datenblatt.
Das mit dem Monitor habe ich schon mehrfach versucht - ich bekomme es
einfach nicht hin - will aber nicht ausschließen, dass es möglich ist.
Chris hatte ja angedeutet, dass er es geschafft hätte.
Ich habs immer noch nicht aufgegeben, Software im Bereich 0x405+
auszuführen. Beschreiben kann ich den Bereich ja und der Program Counter
ist 12 bit breit, sollte das also abdecken.
Und ich werde mal nach "versteckten" ICSP Befehlen suchen. Evtl. gibt es
da etwas, was uns weiterbringt (z.B. Read RAM ;-)
Für mich zeigt sich zumindest immer mehr, dass dieser PIC nicht wirklich
gut für Sicherheitsanwendungen geeinet ist.
Walter.
PS: klar - wir bekommen das hin.
eProfi schrieb:> Ob die Entwickler von unserem Treiben hier wissen und wie sie darüber> denken? Ob sie sich denken: hätte nie gedacht, dass die Hacker so weit> kommen,
Wie weit denn? Ihr ratet herum, aber rausgekommen ist dabei genau
nichts.
eProfi schrieb:> oder ob sie sich inf Fäustchen lachen, wie stümperhaft wir hier> agieren (seit 4,25 Jahren).
Wir liegen schon alle auf dem Boden vor Lachen. Wenn ihr so weitermacht,
habt ihr in 10 Jahren immer noch nichts.
Also:
ich habe ein bisschen herumprobiert mit den ICSP Befehlen.
Dokumentiert sind:
0x02: load data (um sie danach zu schreiben)
0x04: read data
0x06: inc PC
0x08: start programming
0x0E: end programming
0x09: bulk erase
ich habe eine Komnination gefunden, mit welcher ich Code im Bereich
0x405+ ausführen kann.
der Bereich dort sie so aus:
0400 00F 00F 00F 00F C32 FFF FFF FFF CDF 002 A0A FFF FFF FFF FFF FFF
0410 FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF
0420 FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF
0430 1D7 01B E4A 00D FFF FFF FFF FFF FFF FFF 003 FFF CFE C32 C24 AF0
ab 0x40B habe ich also 37 worte "frei", wenn ich den beschriebenen
Bereich mit "0" überschreibe komme ich sogar auf insgesamt 47 Worte.
Meine momentane RAM-Read Routine hat 24 Worte, pass also gut rein
(s.Anhang).
Ich kann damit also den Controller an "beliebiger" Stelle anhalten
(/MCLR -> Vpp) und dann mit einer kleinen Befehls-Sequenz den Code
ausführen um das RAM auszulesen. Der Baustein sollte weiterhin
funktionieren, evtl. muß ich noch den Watchdog während des Auslesens
zurücksetzen (2 Worte mehr, passt aber immer noch).
Somit kann ich z.B. das RAM direkt nach dem reinclocken anschauen oder
während des Rausclocken oder sonst wo.
Ich habe das ganze allerdings bisher nur mit "normalen" PIC12F509
probiert, weiß also nicht sicher, ob das auch mit DCIC funktioniert.
Hat jemand hier einen PIC InCiruit debugger. Evtl. lassen sich da noch
ande Befehle herausfinden (messen). Da kann man das ganze ggf. noch
einfacher gestalten.
Bevor ich das mit dem DCIC probiere hätte ich gerne ein paar Meinungen
dazu gehört.
Danke schon mal im Voraus.
Walter.
Viele neue Gedanken:
ist es schon mal jemandem gelungen, einen neuen (=nicht gesendeten)
gültigen Datensatz zu finden?
Meine Überlegung war folgende:
An jedem Datum muss jede Wetterinfo codiert werden können.
d.h. aus den ersten 40 Bits werden 22,
d.h. Korrektur und Verifizierung auf Gültigkeit sind 40-22=18 Bits
Ich habe 2**12=4096 Datensätze (gleiches Datum) decodieren lassen, d.h.
die Wahrscheinlichkeit ist 1/ 2**(18-12) = 1/64, dass ein gültiger
Datensatz dabei ist.
Und tatsächlich gibt es bereits einen Treffer:
> guter Vorschlag. Das W-Register wird beim Reset tatsächlich nicht> verändert (ich habs ausprobiert - ich hätte es nicht gedacht !).> Sollte funktionieren, sofern der Wert wirklich ins OSCCAL Register> geschrieben wird.
Ich habe damals, als ich Argumente sammelte, ob es ein 12C oder 12F ist,
mir notiert, dass dieses Vorgehen beim 12F nicht funktionieren würde.
Momentan fällt mir der Grund jedoch nicht ein.
Zur Mete-On7: Laut ei08_09_064.pdf ist sie baugleich mit der Hideki
DV323, die ich habe.
Bisher dachte ich, dass die 3 Hersteller Origon, IROX und Hideki jeweils
eigene Produkte fertigen würden, aber wie mir scheint, stecken zumindest
die beiden letzten unter einer Decke (in der Hideki DV323 sitz ein
IROX-Empfänger).
Ist jetzt auf einer Mete-On3 ein Chip (wie ist er beschriftet?) oder ein
Klecks?
Moment mal, der OscCal hat beim 12F ja 7 Bits (bei 12C sind es 6).
Bei den späteren (z.B. 12F628) kam man davon ab, evtl. weil es bekannt
wurde, dass das eine Sicherheitslücke ist.
12F510 hat nicht mehr Speicher, sondern ADCs.
> Das bedeutet:> man könnte den PIC z.B. nach Einlesen der Daten mittels Reset> anhalten, mit der ReadRam neu flashen und das RAM auslesen.
Daran dachte ich auch schon.
Brainstorm:
60 rekonstuieren und WDT schneller machen, um die Wartezeit zu verkürzen
OPTION ist nach Reset FF 1 = Prescaler assigned to the WDT
OscCal: in welchem Frequenz-Bereich trimmbar?
Erratum:
Bits <7:2> of W register contain oscillator calibration values due to
MOVLW XX instruction at top of memory.
Muss <7:1> heißen
Walter:
Zum Cmd 0 und anderen Cmds habe ich in der Programieranleitung für die
12f6xx DS41204D (page 11) was gefunden:
Load Configuration x x 0 0 0 0 0,(14),0
Da dürfte es einige Analogien geben.
Deine neuen Erkenntnisse führe ich mir gleich mal zu Gemüte.
Es klingt zwar alles gut, aber scheinbar können nur noch
PIC-Enthusiasten mitmachen. Was hat ein Oszillator-Trimmregister mit der
Sicherheit zu tun?
Kannst du das mit dem Datensatzbeispiel nochmal simpler erklären?
Zumindest bei der Kodierung muß man ja kein PIC-Kenner sein.
@Abdul:
Der Pic hat ne Zwangspause nach dem Dekodieren, damit man keinen
BruteForce durchführen kann. Reduziert man die Werte, muss man nicht
mehr so lang warten...
@all:
Idee: Man könnte in den bereits dekodierten Datensätzen suchen, ob
irgendwelche Wetterinfos "0" oder "1" (0000000000) sind. Damit wäre der
Schlüssel quasi sichtbar, da man den Anfangswert kennt!
Du willst die Zeit verringern mit Trimmen? Von 40 Sekunden auf 38
Sekunden? Versteh ich nicht ganz. Ist doch nicht die Mühe wert. Oder
kann man das Teil durch illegale Einstellungen komplett verbiegen?
Was ich über deinen zweiten Absatz denken muß, ist mir auch nicht so
recht klar. Vielleicht bin ich einfach zu spät und bettreif. Sorry.
Hallo Abdul,
Aus den am 21.01.2011 versehentlich gesendeten Leerdatensätzen habe ich
mir einen (20:08) herausgesucht, weil er nur 22 gesetzte Bits hat.
Von diesem habe ich Byte 3 und 4 geändert: einfach von 0000 - 0fff alles
durchprobiert (momentan läuft gerade 1000 - 1fff). Ein Wert hat eine
gültige Antwort geliefert.
Dadurch, dass ich die anderen Bits gleichgelassen habe, ist der
Schlüssel (zumindest teilweise) der selbe wie im Original-Datensatz.
Das mit dem OscCal ist eine PIC-Eigenart:
Beim Reset wird der ProgramCounter auf 3ff gesetzt. Dort steht von
Hersteller reinprgrammiert ein MOVLW (Lade Accu = W = WorkRegister) mit
einem individuellen Wert, der bei Herstellertest die 4 MHz RC-Frequenz
ergab. Diesen Wert kannst Du im Anwenderprogramm in die Speicherstelle
OscCal schreiben (oder auch nicht).
Die Adresse 3ff ist nicht geschützt, d.h. man kann z.B. einen NOP (00)
reinprogrammieren. Wenn die Entwickler diesen Wert (gutgläubig, es sei
der ausgemessene Wert) ins OscCal reinschreibt, W wurde aber nicht mit
dem MOVLW geändert, sondern der NOP hat ihn nicht verändert, spiegelt
die Frequenz, mit der der µC dann läuft, den W zum Zeitpunkt vor dem
Reset hatte, wider. Man muss die Frequenz nur hinreichend genau messen,
um den Wert (die obersen 7 Bits) von W zu wissen.
Nun liegt es an Dir, wann Du einen Reset auslöst.
Jede Änderung des Strobe-Einganges (zumindest während der Wartezeit)
löst einen PinChange-Reset aus (der F509 hat keinen
PinChange-Interrupt).
> Der Pic hat ne Zwangspause nach dem Dekodieren, damit man> keinen BruteForce durchführen kann. Reduziert man die Werte,> muss man nicht mehr so lang warten...
Das ist eine andere Baustelle. Deswegen habe ich oben gefragt, um
wieviel man den RC trimmen kann. Ich vermute, dass man die Frequenz und
damit die Wartezeit um 50% ändern kann.
> Oder kann man das Teil durch illegale Einstellungen komplett verbiegen?
Da sind wir gerade dran.
von geschafft sind wir noch weit, weit entfernt.
Wenn das mit dem RAM Monitor funktionieren sollte (das ist noch nicht
sicher), dann haben wir ein Mittel an der Hand mit dem wir dem DCIC ein
bisschen unter den Rock schauen können (hier können die MCU-Nerds den
Crypto-Nerds mal helfen ;-)
Sorry, mal etwas "off-topic":
Und daher auch an dieser Stelle die Bitte an die "Verantwortlichen":
Anhand dieses Threads lässt sich durchaus lernen, wie man "es nicht
macht". Auf der anderen Seite wir hier deutlich, dass trotz "popligem
PIC", vermutlich properitärem Crypto und haufenweise Datensätzen es
dennoch nicht mal eben so "geknackt" werden kann (auch wenn hier
vermutlich nicht die Crypto-Experten unterwegs sind und keiner Vollzeit
daran arbeitet...)
Und: es geht hier um Wetterdaten (hallo: es sind nicht die Lottozahlen
oder die Launchcodes für Atomraketen - obwohl...;-)
- Man kann diese Daten nur sinvoll in Europa nutzen (siehe Karten der
Wetterstationen)
- das ganze ist Patentgeschützt -> kommerziell lässt es sich nicht legal
nutzen, auch wenn man "den Schlüssel" hat
Ich denke daher, die Gefahr ist nicht sehr groß, dass hier jemand
geschädigt wird. Und wie eingangs erwähnt: es ist noch ein weiter Weg.
Walter.
Walter Freywald schrieb:> Anhand dieses Threads lässt sich durchaus lernen, wie man "es nicht> macht". Auf der anderen Seite wir hier deutlich, dass trotz "popligem> PIC", vermutlich properitärem Crypto und haufenweise Datensätzen es> dennoch nicht mal eben so "geknackt" werden kann (auch wenn hier> vermutlich nicht die Crypto-Experten unterwegs sind und keiner Vollzeit> daran arbeitet...)
Sobald wir verstanden haben, wie die Crypt funktioniert, können wir
unsere eigenen Systeme bauen, welche genauso geschützt sind. Immerhin
gehts ja nicht darum Meteo zu knacken, sondern aus dem Schutzmechanismus
zu lernen, da er offenbar sehr gut funktioniert...
Ehrlich gesagt Walter, ich habe es nicht im Detail verstanden. Aber in
etwa den Sinn dahinter. Danke.
Die leeren Datensätze sind also die, die mal gesendet wurden als
offenbar keine Daten online von Meteo verfügbar waren. Richtig?
Für eine eigene unabhängige Verwendung des Systems für eigene Projekte
benötigt man aber dann einen einen neuen Schlüssel UND die
Verschlüsselungsroutine. Dafür lohnt der Aufwand sicherlich nicht und
man findet bestimmt genug Ideen im Internet.
Ansonsten ist es aber ein echter Elektronik-Krimi. Ganz ohne Blut, nur
Schweiß ;-)
Bei ebuy.at ist ein Posten MeteOn3 Mete-On 3 aufgetaucht für 5490+980.
Ich würde eine Sammelbestellung machen, da geht bestimmt was mit dem
Preis. Wer hat Interesse?
Ist eine weitere Uhr mit korrigierendem Decoder bekannt?
Gute Nachricht: Thomas baut demnächst 2 weitere Decoder an seinen
Rechner --> doppelte Decodierrate --> halbe Wartezeit.
Außerdem besteht eine gute Chance, dass die Wartezeit übersprungen
werden kann. Dann schaffen wir sicher deutlich mehr als 7200 Sätze pro
Stunde (momentan 3600/36*2=200, bald 3600/36*4=400).
Der oben genannte gefundene gültige Datensatz war wohl ein
Glückstreffer, bisher sind über 10000 Sätze decodiert, kein weiterer
Hit.
Autor: Katzenschreck! (Gast) Datum: 27.05.2011 09:31
> Und wenn ihr es geschafft habt? Schmunzeln und Schweigen? Taucht> die Dekodierroutine irgendwo auf? Wird auch dieser Thread gesperrt?
Das verbietet die Hacker-Ethik.
Abdul:
> Die leeren Datensätze sind also die, die mal gesendet wurden als> offenbar keine Daten online von Meteo verfügbar waren. Richtig?
Es wurden schon Datensätze geliefert, denn es sind ja gültige Daten,
aber es wurde vergessen, Wetterdaten in den ENCODER zu füttern.
> Autor: Katzenschreck! (Gast) Datum: 27.05.2011 09:31>> Und wenn ihr es geschafft habt? Schmunzeln und Schweigen? Taucht>> die Dekodierroutine irgendwo auf? Wird auch dieser Thread gesperrt?> Das verbietet die Hacker-Ethik.Was verbietet die Hacker-Ethik?
@eprofi: danke für den Hinweis. Ja, bin dabei - eine für mich bitte.
Mit dem RAM-Monitor dauert es leider noch ein bisschen - ich will mir
den Chip nicht zerschießen.
Hab mir nen Microchip-Debugger geordert, evtl. finde ich darüber etwas
mehr heraus und es ist ggf. garnicht mehr nötig, den PIC zu beschreiben.
Ich hoffe auf einen Debugger Befehl wie "Read RAM" o.ä.
Wenn jemand mitexperimentieren will:
folgende Fakten gibt es:
- RAM Inhalt und W-Register bleiben nach einem Reset erhalten
- man kann den PIC anhalten und in den Programmier Modus (Debugmodus ?)
wecheseln, indem man /MCLR von VCC auf VPP zieht. Senkt man /MCLR wieder
von VPP auf VCC ab läuft der PIC (anscheinend) an gleichen Stelle weiter
- es scheint undokumentierte Befehle im ICSP zu geben (Bedarf noch
näherer Untersuchung, z.B mitschreiben beim Debugger)
- Wenn man den PIC anhält kann man den Programcounter versetzten und den
PIC weiterlaufen lassen. Damit ist es möglich, Code an 0x405+
auszuführen. Der Code dort liest dann z.B. das RAM aus oder ändert den
"Watchdog Counter" ;-)
Die Idee ist folgende:
Es sieht so aus, dass der PIC 15x auf einen WDT Reset wartet, danach ist
er bereit, einen Datensatz zu decodieren und setzt anscheinend den
Counter wieder auf 0.
Wenn man also einen Datensatz decodieren will läuft das etwa so:
- PIC laufen lassen (für init, etc.)
- PIC anhalten, Code an 405+ ausführen -> der setzt den WDT counter auf
den richtigen Wert und lässt den WDT einmal kommen
- PIC ist bereit (Counter Wert stimmt ja) -> Telegram decode.
Damit käme man auf ca. 5 Sekunden pro Telegramm.
Soweit die Theorie.
Das Problem, dass ich noch habe, ist, dass ich 2 Byte RAM für Bitcounter
und Datenwort brauche, diese Positionen kann ich also nicht auslesen.
Habe für den ersten Test die Adressen 0x0f und 0x0e verwendet.
Diese kann ich in einem 2.Schritt auf andere Adressen setzen (1 -> 0
schreiben geht immer), z.B. 0x08 und 0x07.
Hat jemand einen PICKIT oder ähnliches an dem er ein bisschen
mitschneiden kann (ICSP Befehle) ?
Walter.
So, erstmal vielen dank an eProfi, für die 2 Decoder.
Diese habe ich nun soweit an den Server dran, und seine
Verbesserungsvorschläge umgesetzt. Ich weiß aber jetzt nicht in wie weit
die Prognose passt, wann das ganze fertig ist. Müsste man mal schauen.
Ich habe das nämlich etwas einfach berechnet, ich nehme pro Datensatz
38s Wartezeit an und teile dies durch die Anzahl der dekoder.
Ein DCIC war etwas Problematisch weil die Pins etwas verbogen waren,
habe es aber hinbekommen.
Sollten noch Fehler auf der Seite sein, also das z.b. Der Status da
falsdch angezeigt wird, oder irgendwas anderes nicht stimmt, einfach
mailen -> Kontaktformular oder PN
Anbei ein paar fotos vom Aufbau.
Gruß Thomas
Micha schrieb:> So hier nun die Bilder, wir sind durch den HKW aie auch bei dem 12c509> niuccht richtig durchgekommen auch bei der stärksten Einstellung.> Zum testen noch ein Mega8, da gings ganz gut.> Man kann jedoch schemenhaft die DIE erkennen, im vergleich zu einem> 12c509 ist die vom hkw viel kleiner.> Ober noch geht werde ich sehen, hab leider nur eine Uhr zum testen im> Moment.
Ich könnte auf der Arbeit Bilder mit einem Elektronenmikroskop machen,
wenn mir jemand den Chip und etwaige vergleichsmodelle zur Verfügung
stellt.
Walter Freywald schrieb:> - Wenn man den PIC anhält kann man den Programcounter versetzten und den> PIC weiterlaufen lassen. Damit ist es möglich, Code an 0x405+> auszuführen. Der Code dort liest dann z.B. das RAM aus oder ändert den> "Watchdog Counter" ;-)
Mal eine Frage als PIC-unkundiger:
Kann man da nicht vielleicht auch Code unterbringen der das Program
Memory ausliest? Oder geht das wegen irgendwelcher Protection-Features
nicht?
Viele Grüße,
Simon
Hallo Simon,
gute Idee, aber: Soweit ich weiß (also offiziell) geht das nicht.
Das hat keine Protection- sonder eher Bus- oder Architektur-Gründe.
Der Adressraum ist beim PIC12F509 nicht linear. RAM und Flash hängen an
unterschiedlichen Bussen. Man kann also keinen Zeiger verbiegen und das
Flash auslesen. Auch ist der RAM 8Bit breit, der Flash 12 Bit.
Walter
Walter Freywald schrieb:> Hallo Simon,>> gute Idee, aber: Soweit ich weiß (also offiziell) geht das nicht.> Das hat keine Protection- sonder eher Bus- oder Architektur-Gründe.>> Der Adressraum ist beim PIC12F509 nicht linear. RAM und Flash hängen an> unterschiedlichen Bussen. Man kann also keinen Zeiger verbiegen und das> Flash auslesen. Auch ist der RAM 8Bit breit, der Flash 12 Bit.
Beim AVR gibt es spezielle Assembler-Instruktionen um auf das
Program-Memory zuzugreifen, bei denen ist das auch kein einheitlicher
Adressraum.
Ich würde vermuten, dass das auch bei PICs gehen sollte. Nutzdaten ins
Program-Memory zu speichern, die man zur Laufzeit irgendwann ins Ram
lädt um sie weiterzuverarbeiten ist ja durchaus eine sinnvolle
Anwendung...
Ist natürlich die Frage, ob man den Code in die paar verfügbaren Zellen
reinpacken kann...
Viele Grüße,
Simon
Simon, die PICs haben eine strenge Harvard-Architektur, es gibt keine
Verbindung zwischen Programm- und Datenbus (bis auf die MOVLW, RETLW-
etc. Befehle).
To begin with, the PIC12F508/509/16F505 devices
use a Harvard architecture in which program and data
are accessed on separate buses. This improves
bandwidth over traditional von Neumann architectures
where program and data are fetched on the
same bus. Separating program and data memory further
allows instructions to be sized differently than the
8-bit wide data word. Instruction opcodes are 12 bits
wide, making it possible to have all single-word
instructions.
> Beim AVR gibt es spezielle Assembler-Instruktionen um auf das> Program-Memory zuzugreifen, bei denen ist das auch kein> einheitlicher Adressraum.
Hat der PIC nicht.
Habe gerade versucht, vom Programm aus in den 400er-Bereich zu springen,
indem ich vor dem GOTO mit BSF STATUS,6 das undokumentierte Program Page
Preselect bit PA1 setze.
Geht nicht!
Gestern habe ich den Trimmbereich des interen RC-Oszillators
(Original-OscCal war 0x22) getestet, geht von 800ns bis 1600ns
Befehlszeit (entspricht 2,5 - 5 MHz).
d.h. eine Anderung um 1/128 (7 Bits) bewirkt geschätzte 3-6 ns, muss ich
noch genauer messen, ist nicht linear.
Aber: der WDT hat einen eigenen RC-Oszillator, ob der mitgetrimmt wird?
Thomas: die 4 Decoder arbeiten fleißig. Vielen Dank, dass Du die
Erweiterung so schnell umgesetzt hat!
Leider ist bisher kein neuer gültiger Datensatz aufgetaucht, habe gerade
nachgeschaut.
Kannst Du noch eine Spalte einbauen, wie viele gültige Datensätze
enthalten sind?
Wenn ein Satz aus der DB entnommen wurde, reicht es z.B. in die 4 Spaces
DB reinzuschreiben, ohne extra Kommentarzeile.
Walter, welchen Debugger hast du bestellt?
Bei ibuy gibt es ein Pickit1 für 39,99 und ein Pickit3 für 59,95 (bei
MC-direct kostet es 44 USD).
Versuche bitte mal, mit OPTION den Prescaler des WDT zu ändern.
Insider:
>Ich könnte auf der Arbeit Bilder mit einem Elektronenmikroskop> machen, wenn mir jemand den Chip und etwaige vergleichsmodelle> zur Verfügung stellt.
Kannst Du damit durch das Gehäuse schauen (Röntgenblick) oder muss das
Gehäuse entfernt werden? Was interessant wäre, die CodeProtection-Fuse
zu löschen. Wird aber nicht so einfach sein, weil wir 1. nicht wissen,
so sie ist, und 2. sein kann, dass sie abgedeckt ist.
Um Gültige Datensätze hinzuzufügen msus ich die Webseite eingie minuten
vieleicht eine stunde anhalten, damit ich das so ohne weiteres umsetzen
kann, damit ich in der Datenbank keine inkonsistenzen habe.
Machbar ist es aber.
Ich weiß nicht ob ich das heute schaffe.
Gruß
Thomas
@eProfi,
das mit PA1 hatte ich auch erst probiert - wie Du schon sagst, geht
leider nicht.
Ich habe mir das PICKIT2 bestellt - dauert aber wohl noch etwas.
MDT prescaler:
Abdul K. hatte so richtig geschrieben:
"Ansonsten ist es aber ein echter Elektronik-Krimi. Ganz ohne Blut, nur
Schweiß ;-)", Tote gibt es aber trozdem.
RAM Monitor habe ich soweit fertig. Habe aber bei einem DCIC das erste
Wort gelöscht (by accident) und beim anderen läuft anscheinend der WDT
nicht mehr.
Hab aber noch ne Wetterstation, die wird heute noch geschlachtet ;-)
Bisher habe ich folgendes gesehen:
- die Daten werden anscheinend im Bereich 0x36-0x3F abgelegt.
- der Zähler für den WDT liegt anscheinend bei 0x0E oder 0x0F (Murphy,
genau da habe ich die beiden Byte für den Bitcounter und das zu sende
Wort platziert ;-)
- der Kalibratorwert für den OnChip Oscillator wird eingetragen (war ich
mir nicht sicher)
Beim Thomy im Forum werde ich mal die Details bezüglich des PIC und
0x405+ einstellen, ist hier doch etwas "off topic".
Das mit dem WDT prescaler ist eine gute Idee, werde ich ausprobieren,
solbald ich wieder einen DCIC am Laufen habe. Ich fürchte allerdings,
dass es nicht funktiert, weil:
- Das OPTION Register wird laut Datenblatt (ja, ich bin vorsichtig
geworden) nach einem Reset auf 0xFF gesetzt
- GPIO,2 wird als Ausgang (Busy) verwendet. Dazu muß aber OPTION.5 auf
'0' gesetzt werden.
Daraus schließe ich, dass das OPTION Register nach einem Reset (auch
nach einem WDT Reset) neu gesetzt wird und damit auch der WDT Prescaler.
Ich verspreche mir mehr davon, den Zähler für die WDT resets so zu
setzen, dass er nach dem nächsten WDT Reset wieder bereit ist.
Walter.
Ich bin noch nicht ganz funktionsfähig:
0408 0CDF movlw 0xDF (bin 1011 1111)
-->
0408 0CDF movlw 0xDF (bin 1101 1111)
disable GPWU: Enable Wake-up on Pin Change bit (GP0, GP1, GP3)
disable GPPU: Enable Weak Pull-ups bit (GP0, GP1, GP3)
T0CS: Timer0 Clock Source Select bit not Pin T0CKI, sondern 1MHz
040A 0A0A goto 0x0A das kann auch 020A sein, wenn PA0 gesetzt
0430 01D7 addwf 0x17,W (dez 35)
-->
0430 01D7 addwf 0x17,W (dez 23)
> Daraus schließe ich, dass das OPTION Register nach einem Reset> (auch nach einem WDT Reset) neu gesetzt wird und damit auch der> WDT Prescaler.
Das stimmt leider.
> - der Zähler für den WDT liegt anscheinend bei 0x0E oder 0x0F> (Murphy, genau da habe ich die beiden Byte für den Bitcounter> und das zu sende Wort platziert ;-)
Habe ich nicht 1E und 1F vorgeschlagen?
Nochwas, Walter,
Hast Du die DV323 schonmal decodieren lassen? Kann die korrigieren?
Es ist ja vermutlich (wg. Pinout) kein PIC, und ich vermute, dass der
Nicht-PIC decodieren kann.
Thomas:
wenn es so großer Aufwand ist, lass es. Wäre ein NiceToHave gewesen.
> Walter, du müsstest 3e ins OPTION schreiben, um die WDT-Zeit> zu halbieren.
Das muss nicht 3E, sondern 5E (ohne PullUp) oder 1E (mit PullUp)
heißen.
Ist eh momentan hinfällig.
> Nicht-PIC decodieren kann.
--> korrigieren kann.
0431 001B sleep sagt mein altes MPLAB, sleep ist normal 03
> Habe ich nicht 1E und 1F vorgeschlagen?
Mist, habe ich gestern bereits getippt, dann ist mein PC abgeschmiert.
Walter:
Kannst Du bitte einen MemDump posten?
Welche Reihenfolge haben die 80 Bits?
@eProfi, ich habe es nun umgesetzt, kann aber nicht garantieren ob die
Werte von den bereits hochgeladenen Dateien korrekt sind.
Neue Dateien, oder welche die noch nicht bearbeitet wurden dürften keine
Probleme bereiten.
die Kommentare, das ein Datensatz von einer datenbank stammt wurde
rausgenommen, stattdessen ist nun " DB " zwischen Cipher und Plain..
Ich habe das ganze nun anders Umgesetzt als ich es eigentlich vor hatte.
Daher gings schneller...
gruß
Thomas
Sehr schön, Respekt!
Wenn der Platz knapp wird, kannst Du das Wort "Datensätze" (3. Spalte
trennen, damit es zweizeilig wird.
Was noch praktisch wäre, wenn man auch die Original-Dateien runterladen
könnte, damit man sieht, was als nächstes auf der Todo-Liste steht.
Der neue Treffer in Byte34-3000-3fff.txt ist der Original-Wert mit dem
Plain 000000000000000000000010.
Im Anhang mein 25-Zeiler, der die Datensätze generiert.
>> Autor: Katzenschreck! (Gast) Datum: 27.05.2011 09:31>>> Und wenn ihr es geschafft habt? Schmunzeln und Schweigen? Taucht>>> die Dekodierroutine irgendwo auf? Wird auch dieser Thread gesperrt?>> Das verbietet die Hacker-Ethik.>Was verbietet die Hacker-Ethik?
Ich bitte darum, dass keine Details veröffentlicht werden, damit andere
(Außendstehende) Schaden anrichten können.
> Beim Thomy im Forum werde ich mal die Details bezüglich des PIC> und 0x405+ einstellen, ist hier doch etwas "off topic".
Wo? URL?
eProfi schrieb:> damit andere> (Außendstehende) Schaden anrichten können.
Welcher Schaden? Durch die Entschlüsselung von Wetterdaten werden keine
Menschenleben oder wessen auch immer Sicherheit gefährdet. Allenfalls
wird das Geschäftsmodell von Meteodata kaputt gemacht.
@eProfi:
[ URL entfernt auf Wunsch des Forenbetreibers ]
Auf das bin ich gerade gestoßen (s.Anhang). Bin ja mal gespannt, was da
so kommt.
Nachdem ich gerade den 3.DCIC gerillt habe (SW-Fehler...Schei*e !)
brauche ich jetzt glaube ich ein bisschen Abstand.
Werde mich jetzt mal wieder auf das PIC debug Interface konzentrieren...
Walter.
eProfi schrieb:> Autor: Katzenschreck! (Gast) Datum: 27.05.2011 09:31>> Und wenn ihr es geschafft habt? Schmunzeln und Schweigen? Taucht>> die Dekodierroutine irgendwo auf? Wird auch dieser Thread gesperrt?> Das verbietet die Hacker-Ethik.>
Der Thread hier wird sicherlich auch bald stehen. Hatten wir ja
schonmal.
>> Abdul:>> Die leeren Datensätze sind also die, die mal gesendet wurden als>> offenbar keine Daten online von Meteo verfügbar waren. Richtig?> Es wurden schon Datensätze geliefert, denn es sind ja gültige Daten,> aber es wurde vergessen, Wetterdaten in den ENCODER zu füttern.
Uih. Kann mich nicht erinnern es gelesen zu haben. Interessant. Danke.
@eProfi:
eProfi schrieb:> Die Entwickler wissen, dass man in 400 Code ausführen kann.m
nein, der Code ist bei diversen PIC12F509 der gleiche (steht schon drin,
wenn man ihn kauft. Bislang habe ich keine Möglichkeit den Code 0x405+
ohne /MCLR = VPP auszuführen.
(Näheres: s. Thomys Forum, Link weiter oben.)
eProfi schrieb:> Nochwas, Walter,> Hast Du die DV323 schonmal decodieren lassen? Kann die korrigieren?> Es ist ja vermutlich (wg. Pinout) kein PIC, und ich vermute, dass der> Nicht-PIC decodieren kann.
ja, hab ich schon getestet -> leider nein.
Eine Mete-On3 ist aber auf dem Weg zu mir, die kann wohl korregieren.
Soweit ich weiß ist da ein Chip drin, keine Bare DIE (Klecks). Bin mal
gespannt, was das für einer ist.
Wie oben schon erwähnt habe ich mittlerweile 3 DCICs gegrillt (nein, die
schmecken nicht !) und sitzte zur Zeit von dieser Seite auf dem
Trockenen (vielleicht kann mir jemand den Hex-Code mailen, dann kann ich
sie neu flashen...haha).
@Thomy: Danke für die Arbeit !
Walter.
> nein, der Code ist bei diversen PIC12F509 der gleiche (steht schon> drin, wenn man ihn kauft.
Also meine waren bis auf 3ff und 0404 ganz leer.
Ich habe damit gemeint, dass sie es zu Debug-Zwecken (mit Vpp)
verwenden.
Lohnt es sich, sich im o.g. Forum anzumelden? Oder kommt man da ohne
Regisitrierung rein? Wer ist da mit im Boot?
> Eine Mete-On3 ist aber auf dem Weg zu mir, die kann wohl korregieren.
Was ist mit der Sammelbestellung - bleibt Deine "Bestellung"?
> Walter:> Kannst Du bitte einen MemDump posten?> Welche Reihenfolge haben die 80 Bits?
Oder mir mailen?
Abdul:
> Uih. Kann mich nicht erinnern es gelesen zu haben. Interessant. Danke.
siehe Autor: Thomas Berends (thomy-pc) Datum: 21.01.2011 23:13
Was ist eigentlich mit den Herren aus dem alten Thread (Diet, Dexter,
Iranian, ...) wo stecken die? Wissen die überhaupt, dass wir hier
weitermachen, nachdem der alte Thread geschlossen wurde.
Das Oben genannte Forum hatte ich eingerichtet, um den alten Thread
fortzuführen.
Wer jetzt ausser Walter und mir davon noch aktiv ist weiß ich so ausm
Kopf nicht.
Registrierung ist Pflicht, es ist ein geschlossenes Forum und es wird
nicht jeder hinein gelassen.
Gruß
Thomas
@eProfi:
Dump hängt an, sind aber ggf. Bitkipper drin, wie gesagt, ich hatte noch
Probleme mit dem Timing. Aber man kann etwa sehen, wo die Bits liegen.
Das letzte Bit habe ich (soweit ich mich erinnere) nicht eingeschoben,
zu einem definierten Zeitpunkt anhalten zu können. Also evtl. alles um 1
Bit verschoben. Beachte bitte auch, dass Bit 0 und Bit 7 nicht
ausgewertet werden (das könnte dann z.B. die 0x95 an Adresse 0x3B sein.
Nur um sicherzugehen: wie hast Du den Bereich > 0x404 ausgelesen ?
Ich habe eine Hand voll PICs bei Reichelt bestellt. Die haben alle
dieses Muster, auch die 3 DCIC hatten das. Deswegen bin ich davon
ausgegangen, dass das bei jedem drin ist. Lasse mich aber gerne eines
Besseren belehren ;-)
Ein paar Dumps von meinen Controller habe ich auch mit reingeschrieben.
Hier sollten alle Bits stimmen.
Walter.
habe ich gerade gesehen:
Meteotronic La Crosse Wetterinfo Center by TFA bei Amaz*n für 8,46 Euro
;-)
Hab mir mal nen Schwung geordert, hoffe, da ist auch nen PIC drin, dann
hab ich wieder was zum Grillen...
Gruß,
Walter.
PS: nicht dass der niedrige Preis ein Zeichen für das baldige auslaufen
des Systems ist...
eProfi schrieb:>> Eine Mete-On3 ist aber auf dem Weg zu mir, die kann wohl korregieren.> Was ist mit der Sammelbestellung - bleibt Deine "Bestellung"?
Ja, prinzipiell schon. Kommt auf den Preis drauf an. Beim Am*zon kostest
das teil ca.59 Euro.
Gruß,
Walter.
Wenn das System ausläuft wirds langweilig^^, nur dann stehen viele leute
ohne Wetterdaten da, und dann kann man die Teile auch wieder vergessen.
Wenn du die Stationen hast, kannst mal eben Bescheid geben ob die
Platine identisch zum TFA Meteotronic Start/Pro ist?
Das Display ist ja schonmal identisch zum Start.
PS.: Schickt mir bitte keine weiteren ICs, ich habe keine Platinen mehr
wo ich die Dinger drauflöten könnte, bevor mir jemand weitere ICs
schickt.
Gruß
Thomas
Wau, dass wir das nicht eher gesehen haben. Gibt es schon seit Januar.
Witzig, dass Amazon die baugleiche WM5100 für 25,95 verkauft.
Die Pro gibt es für 49,89 und für 57,50.
> PS.: Schickt mir bitte keine weiteren ICs, ich habe keine Platinen> mehr wo ich die Dinger drauflöten könnte, bevor mir jemand weitere> ICs schickt.
Walter kann jetzt welche brauchen ;-)
Ich warte mit der Mete-On3-Bestellung, bis Walter sagen kann, was drin
ist.
> PS: nicht dass der niedrige Preis ein Zeichen für das baldige> auslaufen des Systems ist...
Die Stationen sind generell billiger geworden. Die Bewertungen sind ja
auch nicht gerade berauschend.
Meteotime hat ja noch große Pläne, klingt nicht nach Auslaufen.
> Nur um sicherzugehen: wie hast Du den Bereich > 0x404 ausgelesen ?
Ich habe 10 St. vom Bürklin mit einem GQ-4X-Programmer ausgelesen, der
kann mit dem Config-Menü und DDM? (direct memory access?) jede Adresse
lesen und schreiben.
Allerdings wird der Bereich 405 - 43f nicht gelöscht. Wie machst Du das?
@eProfi:
zum Löschen des oberen Bereiches setze ich den PC auf 0x400 (erste ID)
und start dann Bulk Erase. Laut Datenblatt unterscheidet der PIC
zwischen:
- PC zeigt auf Config Word (0x7FF) -> wird nur Config und Programm
gelöscht
- PC zeigt auf ID0 (0x400) -> wird alles gelöscht
@Thomy:
Ich sag Bescheid, sobald ich die Teile habe.
Walter.
Walter Freywald schrieb:> Wie oben schon erwähnt habe ich mittlerweile 3 DCICs gegrillt (nein, die> schmecken nicht !) und sitzte zur Zeit von dieser Seite auf dem> Trockenen (vielleicht kann mir jemand den Hex-Code mailen, dann kann ich> sie neu flashen...haha).>
Laß sie liegen. Nun hast du einen Grund für deine Arbeit ;-)
Wichtig dabei ist, daß du dir alles genauestens dokumentierst. Hinterher
kann man sich sonst nicht mehr erinnern und Zusammenhänge schreibt man
meist nicht auf...
Hallo,
>habe ich gerade gesehen:>Meteotronic La Crosse Wetterinfo Center by TFA bei Amaz*n für 8,46 Euro>;-)
Es ist ein HKW581 verbaut, ziemlich kleines Gehäuse.
Gruß Rene
Hallo,
@Thomas Berends: hatte mich in deinem Board registriert, man hört aber
so garnichts.
Hat jemand die Anschlußbelegung vom HKW518? Dann kann ich den LA
eingepackt lassen.
Gruß Rene
und schwups kostet das Teil jetzt 9,56 Euro ;-)
Hab nur schnell mal nen Test gemacht und den Chip ausgelesen.
Sieht identisch zu meinen bisherigen aus...
Das Gehäuse müsste ein SSOP8 sein! Ich glaub ich kauf mir auch so ne
Wetterstation (bzw zwei! Eine zum experimentieren, die Andere für meine
Wand/Tisch)
Im reinraum das IC-Gehäuse oben mit Salpetersäure benetzen, auf 80-90°C
anwärmen und dann das angelöste Gehäuse im Ultraschallbad oben ablösen.
Wenn es Bonddrähte aus Gold und nicht z.B. aus Kupfer sind, bleiben
die genauso intakt, wie der Die selbst.
-> Fuses ausfindig machen und irgendwie überbrücken? Dann regulär
auslesen?
-> Flash/ROM-Interface kontaktieren und die Zugriffe plus Inhalt
tracen?
Keine Chance?
Wenn Bonddrähte aus Kupfer o.ä., vorher röntgen. Bonddrähte und
Kontaktierungsstellen werden identifiziert.
Danach mit neuen Bonddrähten wieder kontaktieren.
u7pid8ef schrieb:> Fuses ausfindig machen und irgendwie überbrücken
Das ist kein LKW, da kann man nicht mit Muttis Haarnadel schnell mal ne
Sicherung überbrücken!
Zumal die Fuses offensichtlich sogar mittlerweile in der allgemeine
Matrix versteckt werden und mehrfach sind. Also nicht gaaaanz so
einfach. Ich glaub, dieser Weg ist nicht der günstigste.
Ich bin nicht der Meinung, dass der µC-Hersteller die Fuses
absichtlich versteckt.
Meiner Meinung nach sieht der Hersteller keine Notwendigkeit,
die Fuses absichtlich zu verstecken oder die gleiche Funktionalität
auf mehrere Fuses zu verteilen (immer auch Sicht des Schutzes heraus
gesehen).
Lediglich das Finden der Fuses auf dem Die mag etwas schwer werden,
vielleicht durch einen Vorher-/Nachher-Vergleich des selben Dies
(der µC scheint ja schon identifiziert worden zu sein). Nebenbei
kann man gleich noch verifizieren, ob es sich tatsächlich um den
vermuteten µC handelt.
Ich bin mir nicht sicher, ob es Mikro-Nadeln gibt, mit denen man
auf dem Die entsprechende Stellen kontaktieren kann.
Ich würde es nicht schreiben wenn ich es nicht gelesen hätte. Warum wird
das angezweifelt? Komische rhetorische Kommentiererei!
Einzig kann ich nicht mehr sagen, ob es für den PIC bzw. welchen PIC
überhaupt, beschrieben war. Es waren auch Die-Fotos dabei.
Übrigens, die großen regelmäßigen Flächen auf den DIEs sind oft RAM oder
ROM (FLASH). Wenn man es schafft diese Flächen z.B. mit einem kleinen
Stück schwarzem Tape zu bedecken, und dann Versuche macht UV-Licht in
verschiedenen Winkeln auf den DIE auftreffen zu lassen sind die Chancen
die FUSES mittels Streulicht zu löschen und den FLASH-Inhalt intakt zu
lassen vielleicht gar nicht mal so schlecht ...
Moin zusammen!
eProfi schrieb:> Was ist eigentlich mit den Herren aus dem alten Thread (Diet, Dexter,> Iranian, ...) wo stecken die? Wissen die überhaupt, dass wir hier> weitermachen, nachdem der alte Thread geschlossen wurde.
Seit gerade eben weiß ich es - danke für den Hinweis von eProfi ;-)
Leider fürchte ich, daß ich derzeit nicht allzuviel beitragen kann. Mir
fehlt einfach die Zeit, mich mit dem Schätzchen (METE-ON 3) zu
beschäftigen - außerdem ziert es unser Wohnzimmer ...
Aber sehr interessant, was Ihr inzwischen schon alles herausbekommen
habt!
Gruß, Didi
1. Didi war so nett, mir die Original-Fotos zu schicken, und was sehe
ich auf dem Decoder im SO8-Gehäuse?
6580001 811800 R1A6G klingelt es bei Euch?
^^^^
2.
> und schwups kostet das Teil jetzt 9,56 Euro ;-)
und schwups nochmal +0,10 = 9,66 - geht der Preis mit der Nachfrage ?
Noch 15 Stück da.
Walter,
1. wie viele hast Du genommen?
2. Ist die Mete-On 3 schon da?
3.
Rene:
> Hat jemand die Anschlußbelegung vom HKW518?> Dann kann ich den LA eingepackt lassen.
Ja kannst Du, Protokoll etc. ist alles bekannt (und einfach).
siehe Datum: 30.04.2011 15:50 und im alten Thread. Ich habe es noch
einfacher gemacht: ohne Handshake, funktioniert zuverlässig.
4.
Vorgestern gab es einen weiteren Treffer, es sind jetzt 3:
12 3 4 5 6 780123456789abcdef 9 0 1 2 3 4 56 7 0123456 78 9abc d ef
Die Zahlen dazwischen geben die Zahl der Einsen an.
beim 2. und 3. sind 14 der 22 Bits (63,6%) identisch.
5.
Thomas, bitte korrigiere den Kommentar im File 9000-9fff, es steht
8000-8fff drin.
Vielleicht willst Du die eine nicht decodierte Zeile aus 4000-4fff
einfach ins File einfügen.
In den ganzen Logfiles gab es ab und zu Empfangsstörungen. Eine
2008'1231 habe ich mir herausgepickt und rekonstruiert. Kannst Du auch
ins Original-File als rekonstruiert eintragen.
Vielen Dank an Alle, die mittüfteln. Es macht riesig Spass.
h65a7ie3 schrieb:> Meiner Meinung nach sieht der Hersteller keine Notwendigkeit,> die Fuses absichtlich zu verstecken oder die gleiche Funktionalität> auf mehrere Fuses zu verteilen (immer auch Sicht des Schutzes heraus> gesehen).
Die Fuses werden von den Chipherstellern mittlerweile als
Hauptangriffspunkt angesehen und entsprechend geschützt.
@eProfi:
hab mir Sicherheitshalber 10 Stück geordert ;-)
Mete-on3 dauert wohl noch 2 Wochen.
Bitte für mich noch mal langsam:
Welche Bit probierst Du durch ? Ich hatte es mit den ersten 12 gemacht
und bin zu keinem Ergebnis gekommen. Du arbeitest mehr im hinteren Teil.
Auch hier geht es weiter: Der RAM Monitor läuft. Ich kann dem Teil jetzt
beim "denken" zuschauen. Ist ja alles prima soweit. Nur scheint der
wirklich die 270ms zu rechnen, also ca.270'000 Befehle.
Momentan gehe ich so vor:
PIC starten -> Daten reinschieben -> delay (einstellbar) -> RAM
auslesen.
Leider kann ich den PIC nach dem RAM Auslesen nicht weiterlaufen lassen,
da ich ein paar Sachen verändern muß. Also starte ich jedes mal neu und
verlängere das Delay zur Zeit immer um 2us. Wenn sich im RAM was
geändert habe bekomme ich das dann entsprechend angezeigt.
Ein paar Ergebnisse:
Wie schon mal vor längerer Zeit gefunden: nach einem Reset wird an
Adresse 0x33 ein Zähler auf 0x0F (15) gesetzt, der bei jedem
Watchdogreset um eins verringert wird.
Die Daten werden in die letzten 10 Byte im Speicher eingeschoben. Dabei
werden (wie bereits vermutet) Bit 0 und Bit 7 verworfen.
Der Cypher (Bit 0-42 \0,7) liegt von 0x3B bis 0x3F, die Zeit von 0x36
bis 0x3A. Dann werden alle Byte von 36-3F nach 16-1F umkopiert.
Jetzt kommen anscheinend immer wieder 5Byte Schieberegister zum Einsatz.
Dazu kann ich aber noch nichts festes sagen.
Die 0x40 an Adresse 0x30 (oder 0x10) und die 0x04 an Adresse 0x31 (oder
0x11) (wie im Disassembly der ersten 64 Worte) habe ich bisher noch
nicht gesehen.
Ein weiterer Ansatz ist die Suche nach "RETLW xx". Das ist der übliche
(und meines wissens einzige) Weg um Look-Up Tables im PIC12F509 zu
realisieren. Dazu packe ich wieder etwas SW in den oberen Flash Bereich.
Diese SW nimmt eine Adresse entgegen und führt einen "CALL" dahin aus.
Befindet sich dort ein RETLW, so wird sehr schnell wieder in meine SW
verzweigt. Meldet sich meine SW innerhalb einer gewissen Zeit nicht,
gehe ich davon aus, dass dort kein RETLW steht und ich fahre mit der
nächten Adresse fort.
Vielleicht geben uns diese Informationen noch mehr Hinweise.
Und noch ein Ansatz, um das Ausprobieren zu beschleunigen:
PIC starten, anhalten und 0x33 auf 1 (oder 0, wird sich zeigen) setzen
und auf den Watchdogreset warten. Dann sollten sich die Telegramme sehr
schnell reinschieben lassen. Hab ich bisher aber noch nicht versucht.
Walter.
Habs mal die Nacht durchlaufen lassen.
Anfangs funktioniert der Monitor noch ganz gut.
Wenn das Delay länger wird (100ms) wird der Jitter anscheinend zu groß,
sprich nach nächste RAM Abbild liegt teilweise "vor" dem vorherigen
Abbild.
Ich werde einen Weg finden müssen, PIC Zyklen zu zählen oder einen
Single-Step zu machen etc.
Aber wenigstens Snapshots sind möglich ;-)
So wie es aussieht ändern sich bisher (ca.100ms) nur folgende Bytes:
0x07-0x0E
0x10-0x1E
0x10: schein oft als Zähler verwendet zu werden
0x12-0x14 wird (soweit ich das bisher gesehen habe) das Ergebnis
berechnet (3x8 = 24 Bit)
0x16-0x1F: stehen die 80 Bit
0x0F, 0x1F und 0x30-0x3F bleiben bisher gleich.
(0x20-0x2F sind nicht physikalisch vorhanden, 0x00-0x0F wird da
reingespiegelt).
Walter.
Walter Freywald schrieb:> Ich werde einen Weg finden müssen, PIC Zyklen zu zählen oder einen> Single-Step zu machen etc.
Oder Du findest eine Möglichkeit, den Takt langsamer zu machen?
Viele Grüße,
Simon
uzi schrieb:> Sorry,> Link hat nicht ganz funktioniert.> Jetzt sollte es gehen...>> [[http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-630.pdf]]
Genau das Dokument meinte ich. Fuse-Architektur bspw. mit dem restlichen
FLASH verschmolzen.
Wenn der hier betreffende Chip wirklich genau dem Foto entspricht, wäre
es natürlich sehr schön (einfach). Manchmal werden Chips aber neu
designet und unter der gleichen Bezeichnung weiterverkauft.
DU BIST GENIAL! o_O
Zu deinem Timingproblem:
Ich habe mit einem Atmega mal Versuche gemacht wo ich ihn
heruntergekühlt und beheizt habe und die Frequenz des internen
RC-Oszillators änderte sich dabei deutlich. Wird prinzipbedingt beim PIC
nicht anders sein (oder?). Evtl. kannst du die Temperatur stabilisieren
(Nachts sinkt sie weil Heizungsabschaltung/Abkühlung, Tags steigt sie,
weil sonne) und somit die Differenz noch minimieren.
Zum Clock-Cycles zählen noch eine Idee: Lässt sich da evtl. was über die
Versorgungsspannung machen? Stromverbrauch über 10Ohm Widerstand
abgreifen, zwischendrin noch nen Komparator und dann an den
Zählereingang legen und beim gewünschten Zählerstand reseten.
Wenns dir zu viel wird bei der Analyse der Daten die du bekommst, dann
wäre ich bereit dich zu unterstützen.
eProfi schrieb:> Insider:>>Ich könnte auf der Arbeit Bilder mit einem Elektronenmikroskop>> machen, wenn mir jemand den Chip und etwaige vergleichsmodelle>> zur Verfügung stellt.> Kannst Du damit durch das Gehäuse schauen (Röntgenblick) oder muss das> Gehäuse entfernt werden? Was interessant wäre, die CodeProtection-Fuse> zu löschen. Wird aber nicht so einfach sein, weil wir 1. nicht wissen,> so sie ist, und 2. sein kann, dass sie abgedeckt ist.
Offen muss er schon sein, ist aber unproblematisch.
@aaaaa:
Eventuell kann man diesen PIC auf externen Clock umstellen. Vermute, es
geht nicht.
Ein Komparator zur Strommessung: Vergeß es schnell. Mach eine FFT auf
deinem Scope des Stromes und du siehst, wieviel Rauschen da vorhanden
ist. Allenfalls aus Sleep startend, geht das.
@all:
Aber es wurden ja schon Ansätze gebracht:
1. Clock-Trim Register ändern.
2. WDT Post-Teiler Speicheradresse preloaden auf nahe dem Endwert. Sodaß
neue Daten gleich nach der letzten internen Berechnung neu geladen
werden können.
3. Externe Temperaturänderung (Heizung/Peltier).
Eine Idee wäre noch einen Timer fest an den Clock zu koppeln und diesen
auszugeben als Timingreferenz bzw. Interrupt-Quelle. Pins sind wohl nur
schlecht verfügbar (Kann man irgendwas von der normalen Funktion
umbiegen, z.b. die gerade beim Debuggen nicht benötigten I/O-Pins die
das Ergebnis an den anderen Chip weitergeben?. Wird ja momentan nicht
gebraucht.), aber interner Interrupt ist sicherlich machbar.
Ich kann leider nicht mitmachen, aber vielleicht bringt euch eine meiner
Ideen weiter. Viel Spaß!
Glückwunsch, Walter!
Nicht nur RETLW lassen sich so finden, auch normale RETURNs sollten zu
erkennen sein.
Wenn man alle RETURNs im Programm gefunden hat, kann man rückwärts
anfangen zu analysieren. Man springt genau einen Befehl vor dem RETURN
an und sollte nach 3 Zyklen wieder zurück sein. Dann kuckt man, was sich
verändert hat und errät so den Befehl vor dem RETURN. Und das Ganze
iteriert sollte das Geheimnis lüften.
Ist hochinteressant und in der Umsetzung nicht trivial. Hätte total Lust
selbst mitzumachen. Welche Wetterstation muss ich denn nun kaufen, wo
ein PIC drin ist, den man gut kontaktieren kann?
PIC-Entwicklungswerkzeuge sind vorhanden.
Gruß
HerrSchrader
Hallo HerrSchrader,
Dieser PIC hat nur 2 Stack-Ebenen. Ich denke mal, da wird es nicht all
zu viele Unter-Routinen geben :-( Ausserdem lassen sich bei diesem PIC
nur Routinen aufrufen (über call oder PCL-Modifizierung) bei deren
Startadresse Bit 8 gelöscht ist (Bit 0-7 kommen vom Befehl, Bit 8 wird 0
gesetzt, Bit 9 kommt von STATUS,PA0,..und Bit 10, wenn man > 0x3FF
arbeitet, von STATUS,6)
Aber unter diesem Aspekt hatte ich das noch garnicht gesehen.
Meine Hoffnung war vielmehr, LookUp-Tabeles zu finden.
Der PIC ist z.B. in der Meteotronic LaCrosse bei Amazon für ca. 10 Euro
zu haben.
Die Teile habe ich mir "auf Halde" gelegt, ich habe nämlich leider noch
keinen Weg gefunden, den Bereich 0x400-0x4FF getrennt zu löschen (ja,
laut Datenblatt geht das nicht, aber lauf Datenblatt geht ja so einiges
nicht ;-)
Interessant wäre, beim Debuggen eines PIC mal mitzuschneiden, was da für
Befehle zum Einsatz kommen, z.B. SingleStep ;-)
Walter.
Hallo Walter
unter folgendem Link gibt es den Source-Code zum PICkit2,
vielleicht findest du dort etwas passendes bezüglich SingleStep etc.
[http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1960&fragment3_NextRow=1]
Ich habe mir mal den Code angesehn, vielleicht ist die Funktion
"CoreInstruction" interessant. Ich habe aber keine Ahnung, ob das mit
dem 12F509 geht. Ebenso scheint es einen Programmiermode ohne BulkErase
zu geben. Stichwort Begin Programming (Externally Timed).
Was ist denn bisher an Sachen möglich die du ausführen kannst? Also wenn
ichs jetzt richtig verstanden habe machst du folgendes:
Du hast einen Bereich des PICs so überschrieben, dass er das macht was
du willst. Du lässt den Code ein paar µs laufen und unterbrichst dann
und liest den RAM aus?
Inwiefern "arbeitet" der Chip noch korrekt? Kommen da auch dekodierte
Daten raus?
Kannst du sonst noch auf was zugreifen wie den Stackpointer,
Programcounter, Register, Flags?
Was bestimmt interessant wäre, das wäre der Zustand des RAMs in dem
Augenblick, kurz bevor die Daten ausgegeben werden. Dann könnte man
sehen ob die Daten weiterhin im Datenbereich des Schieberegisters stehen
oder anderweitig erzeugt werden, da noch ein anderer Algorithmus
nachgeschalten ist.
Kannst du selbst an Stellen springen? Also einen CALL auf eine Adresse
machen die du willst? Wird nach dem Reset sofort deine Funktion
aufgerufen? Falls ja könntest du ja mal sowas machen wie: PIC starten,
an Adresse springen, 1 Befehl ausführen lassen, RAM inhalt auslesen.
Damit könnte man evtl. schon einige Stellen/Befehle erraten.
Nur so meine Ideen ;-)
> Dieser PIC hat nur 2 Stack-Ebenen. Ich denke mal, da wird es nicht all> zu viele Unter-Routinen geben :-(
Stimmt. Vielleicht nur RETFIE. Schade.
> Ausserdem lassen sich bei diesem PIC> nur Routinen aufrufen (über call oder PCL-Modifizierung) bei deren> Startadresse Bit 8 gelöscht ist (Bit 0-7 kommen vom Befehl, Bit 8 wird 0> gesetzt, Bit 9 kommt von STATUS,PA0,..und Bit 10, wenn man > 0x3FF> arbeitet, von STATUS,6)
Aber GOTO an eine beliebige Adresse sollte doch gehen? Man muss dann
eben den PIC nach 1 us wieder anhalten und nach Veränderungen suchen.
Wenn man vorher das RAM mit aussagekräftigen Mustern beschreibt, lassen
sich auf jeden Fall Register-Veränderungen gut erkennen. Schwierig sind
sicherlich Veränderungen am PC und Stack, weil die sich nicht auslesen
lassen.
> Der PIC ist z.B. in der Meteotronic LaCrosse bei Amazon für ca. 10 Euro> zu haben.
Danke für die Info.
> ich habe nämlich leider noch keinen Weg gefunden, den Bereich 0x400-0x4FF> getrennt zu löschen
Das heißt, du kannst den Bereich nur ein einziges Mal beschreiben (und
später nur noch Bits von 1 auf 0 kippen)? Das bedeutet, der RAM-Monitor
muss auf Anhieb fehlerfrei sein?
> Interessant wäre, beim Debuggen eines PIC mal mitzuschneiden, was da für> Befehle zum Einsatz kommen, z.B. SingleStep ;-)
Ist der 12F509 überhaupt debug-fähig? SingleStep funktioniert m.W. so,
dass in einem speziellen Debug-Register ein Bit gesetzt wird. Nach einem
RETURN im Debug-Modus führt der PIC genau einen normalen Befehl aus und
geht dann wieder in den Debug-Modus.
Sorry, hatte den Thread noch offen aber nicht aktualisiert.
Hatte nicht gesehen dass jemand die Frage nach der
SingleStep-Möglichkeit beim 12F509 schon gestellt hatte.
Hallo Walter,
Gute Nachrichten: Der PIC12F509 ist debugfähig! (Sigle Step,
Breakpoint,..)
Ich habe das in der Help zum MPLAB ICD3 gefunden.
Siehe angehängte Datei
Hier noch ein paar Infos zum Debuggen von Pics:
Beim MPLAB ICD2 wird ein kleines "Zusatzprogramm" zusätzlich zur
eigentlichen Applikations in den PIC geladen und dann der Debug-Mode
aktiviert und das Zusatzprogramm angesprungen.
(Entnommen aus der Hilfe zum MPLAB ICD2)
Das "Zusatzprogramm" und ein paar weitere Files befinden sich in der
angehängten Zip-Datei.
Soweit ich das verstanden habe funktioniert das aber nicht mit
Code-Protection :-((
Wird uns also vermutlich nicht viel weiter bringen.
Es sei den der Debug-Mode lässt sich trotzdem irgendwie sinvoll
nutzen...
Hier noch zwei Ideen:
1. Wars nicht so, daß ein RESET nicht das RAM löscht? Also könnte man
ihn an einem beliebigen Zeitpunkt unterbrechen und nach dem RESET das
RAM lesen mittels Walters Monitor auf 0x400 .
2. Es gibt aus Fernost noch diverse PIC-Clones, die wohl mehr oder
weniger kompatibel sind. Es könnte also sein, das die Uhr so einen
besitzt und dieser vielleicht im Bereich Code-Schutz anders/schlechter
geschützt ist.
@eProfi:
Kannst du das auflösen? Was soll da klingeln? Eine Typennummer?:
1. Didi war so nett, mir die Original-Fotos zu schicken, und was sehe
ich auf dem Decoder im SO8-Gehäuse?
6580001 811800 R1A6G klingelt es bei Euch?
^^^^
Das Ding scheint keine Codeprotection zu haben, zumindest gibt das
Datenblatt nichts dazu her. Wenn es Codeprotection hätte, dann würden
die es schon groß draufschreiben ;-)
Zum Programmieren muss man an einen Pin 15 Volt anlegen soweit ichs
jetzt gelesen habe. Mehr Details gibts leider nicht.
Hab mal gesucht welche Programmer man da verwenden kann. Hab eine Seite
gefunden wo es offenbar auch ein Softwareupdate zu den Programmern gibt:
http://www.elnec.com/download/
Da offenbar immer wieder neue Chips dazukommen, müssen die Ansteuerdaten
im Programm integriert sein.
Mal schaun ob man da was rausziehen kann. So kompliziert kann das ja
nicht sein das Programmieren...
Nur ein paar Ideen, vorrausgesetzt es ist wirklich ein EM6580...
Schreibt bitte in Zukunft zum Posting auf welchen Controller es sich
bezieht. Die Sache ist eh schon sehr unübersichtlich geworden und der
Thread zu lang. Wollen wir einen neuen aufmachen?
Zeit zum Speichern des Threads...
Ich denke das wäre das Beste wenn man da einen neuen Thread erstellt,
und den LInk dahin am besten hier postet, damit nicht all wieder neue
Fragen aufkommen, wo ist das denn und so weiter.
Nundenn, ich mach dann mal Feierabend,
Gute Nacht!
ich hab die Idee mit dem Auslagern mal Aufgegriffen und hier einen
neunen Thread angefangen für alles was den PIC12F509 angeht:
Beitrag "PIC12F509 hidden features und "High Flash""
Ich habe da nochmal zu Beginn alles zusammengefasst, was bisher so
bekannt ist.
Sonst wird es hier wirklich zu unübersichtlich.
Wir könnten auch mal damit anfangen, die RAM-Dumps zu analysieren.
Auch dafür habe ich mal einen neuen Thread angefangen:
Beitrag "Meteotime Crypt"
In der Mete-On3 ist ein "großer" 8 Pinner drin (Bezeichnung wurde oben
schon erwähnt). Nach der Lage von VCC und GND scheint es wirklich der
EM6580 zu sein. Ich hatte EM Microelektronik schon mal auf die
Codeprotection angesprochen. Die meinten, es gäbe keine. Der Controller
hat keine direkte möglichkeit, das Flash auszulesen. Dazu wird eine SW
in das RAM geladen und ausgeführt. Diese kann dann das Flash auslesen.
Wie es in der Maskenversion (ROM, also kein Flash) aussieht, weiß ich
nicht.
Den Elnec-Programmer hatte ich mir auch schon mal angeschaut. Kostet
aber so im die 1000 Euro. Ist mir dann doch zu teuer. Aber es dürfte
keine Problem sein, die Progrmmierung mitzuschneiden und zu analysieren.
Walter.
"Der Controller
hat keine direkte möglichkeit, das Flash auszulesen. Dazu wird eine SW
in das RAM geladen und ausgeführt."
Ist das eine Auskunft der Sekretärin? Wie sollte eine Software OHNE CPU
das Flash auslesen? Gibts da einen Spezialbefehl, der nur im RAM
ausführbar ist. Bei Harvard geht das aber nicht.
Das kann so nicht stehenbleiben!
Abdul K. schrieb:> "Der Controller> hat keine direkte möglichkeit, das Flash auszulesen. Dazu wird eine SW> in das RAM geladen und ausgeführt.">> Ist das eine Auskunft der Sekretärin? Wie sollte eine Software OHNE CPU> das Flash auslesen? Gibts da einen Spezialbefehl, der nur im RAM> ausführbar ist. Bei Harvard geht das aber nicht.> Das kann so nicht stehenbleiben!
Es geht um den EM6580 ? Ich bezweifle ebenfalls dass es so einfach
ist an den Flash/ROM Inhalt zu kommen. Die Assemblerbefehle des EM65xx
scheinen auf den ersten Blick keinen Zugriff auf Flash/ROM zu
ermöglichen.
Ausserdem schaut es laut der AppNote "Programming an EM6540" so aus
als ob kein Zurücklesen des programmierten Codes möglich ist sondern
lediglich die Checksumme des Codes abgefragt werden kann.
Ob es undokumentierte Möglichkeiten gibt um an den Flash/ROM Inhalt zu
kommen ist natürlich ein anderes Thema.
Eventuell schreiben die einen Key ins RAM, den die CPU beim Reset
abprüft. Nach dem Test des Chips, wird der Key wieder gelöscht und
niemand kann ihn finden und mißbrauchen. Dazu zweigt die CPU beim Reset
erstmal in ein internes Schatten-ROM. Sowas in der Art ist z.B. beim
Cypress PSoC1 wohl vorhanden.
Wenns so wäre, wäre obige Aussage der 'Sekretärin' die halbe Wahrheit.
Hab mir mal das ELNEC-Programm installiert. Dann auf DEMO gegangen und
den Chip ausgewählt.
Bei den Details steht:
"General Info:
This device can not be blank checked. It is not allowed to read Sector1.
Read operation (F7): read CRC of Sector1, data on the last address of
Sector1 and read Sector2.
Verify operation (F8): check CRC of Sector1 and verify Sector2.
Program operation (F9): program of device.
..."
Das gibt bei diversen anderen Controller auch.
Der Controller hat einen Bootloader oder ähnliches. Dieser hat Befehle
um das Flash zu schreiben, eine Checksumme zu bilden etc. aber keinen
Befehl um das Flash zu lesen.
Mit den Befehlen des Bootloaders ist es direkt nicht möglich, Code aus
dem Flash zu lesen.
Also muss man SW schreiben, sie ins RAM (oder auch ins Flash laden) und
ausführen. Die SW liest dann das Flash aus und gibt die Daten nach
aussen weiter. Ich kenne dieses Vorgehen bei ST Controllern.
Wenn man den Code nicht direkt ausführen kann, kann man evtl. den
Stackbereich beschreiben und dadurch den Code ausführen. Muss man bei
einigen Controllern so machen.
Der Controller (also die Assemblerbefehle) muß grundsätzlich (also
anders als beim PIC12F509) auf den Programm Speicher zugreifen können.
Nicht ganz. Man könnte sich per Stack einen geeigneten Befehl im
Hauptprogramm indizieren und diesen dann beim RET ausführen lassen.
Allerdings kommt nach diesem Befehl ja ein weiterer und was wird der
dann machen?? Also schwierig und ineffizient.
Den Stack gezielt überlaufen zu lassen, fällt mir noch ein. Was macht
die CPU, wenn sie am Ende des Flash angelangt ist. Geht sie auf Adresse
0 ? Ist das der Reset-Startpunkt?
Walter Freywald schrieb:> Der Controller (also die Assemblerbefehle) muß grundsätzlich (also> anders als beim PIC12F509) auf den Programm Speicher zugreifen können.
Warum muss er das ? Bei den Befehlen des EM66xx ist kein Befehl
dabei der Daten aus dem Programm-Speicher lesen kann (oder ich
habe etwas übersehen). Und wenn man sich anschaut wie beispielsweise
die Seriennummer in Sektor 2 des Flash realisiert ist (Befehlscode, der
die Seriennummer in den RAM überträgt) dann spricht das ebenfalls dafür
dass es keine Befehle gibt die auf den Programm-Speicher zugreifen
können (zumindest keine dokumentierten).
Würde die folgende Methode nicht funktionieren?
- Gewünschtes Ziel auf den Stack pushen
- RET
- Einen Befehl warten
- RESET
- RAM ansehen und schauen was der Befehl gemacht hat
Man könnte zumindest schonmal ein paar Sachen rausfinden. ein shift
müsste man erkennen, ein schreiben ins RAM auch, die RAM-Adresse würde
man rausfinden.
Was man nicht finden würde sind Sprünge, RET(?) und CALL(?)
Oder hab ich da drinnen noch nen denkfehler?
Abdul K. schrieb:> Den Stack gezielt überlaufen zu lassen, fällt mir noch ein. Was macht> die CPU, wenn sie am Ende des Flash angelangt ist. Geht sie auf Adresse> 0 ? Ist das der Reset-Startpunkt?
Laut Doku ist der EM66xx ein wirklich sehr einfacher 4-Bit
Mikrocontroller. Der Stack hat maximal 3 Ebenen, die nicht
im RAM liegen. Verändert wird der Stackpointer durch Befehle
wie CALL und RET, direkte Manipulation des Stackpointer oder
Stack gibt es nicht (zumindest nicht dokumentiert).
Abdul K. schrieb:> Ich denke, diese Ideen gelten für beide Controller. Sind beides> Harvard-Maschinen.
Ein grundsätzliches Problem beim EM66xx mit ROM Maske, also ohne
Flash: wie soll man dort eigenen Code hineinbekommen und
ausführen ?
Ist bekannt welche Variante verbaut wurde ? Vermutlich aus
Kostengründen die ROM Variante...
eProfi schrieb:
1. Didi war so nett, mir die Original-Fotos zu schicken, und was sehe
ich auf dem Decoder im SO8-Gehäuse?
6580001 811800 R1A6G klingelt es bei Euch?
^^^^
Das Datenblatt schreibt:
21.1 Package Marking
8-pin SOIC marking:
First line: 6 5 8 0 0 1
Second line: P P P P P P
Third line: R 1 A Y
Where: PP…P = Production identification (date & lot number) of EM
Microelectronic-Marin SA
Y = year of assembly
Walter schreibt:
=> Baujahr 2006, Flash Version
;-)
Hallo leute,
Kurze Info:
Gerade kommt bei uns ein ganz dickes Gewitter an, ich werden gleich die
Telefonleitung kappen,
Also bitte keine Panik schieben wenn dcf77logs.de nicht erreichbar ist.
Gruß Thomas
Moin!
Walter Freywald schrieb:> Das Datenblatt schreibt:
Exakt das wollte ich auch gerade schreiben ;-)
Vielleicht noch als Ergänzung der Link zum Datenblatt:
http://www.dataman.com/Datasheets/Emmarin/EM6580.pdf
Und einen Ausschnitt des Fotos vom IC hab ich auch noch rangehängt.
Jetzt bin ich nur mal gespannt, ob man den Flash-Inhalt aus dem Teil
tatsächlich irgendwie rausbekommt. Auch ich hab keinerlei Infos dazu
gefunden - nur zum Programmieren des Flashs.
Gruß, Didi
Ich bin noch auf der suche nach dem "Instruction set" des EM6580 (EM66xx
Kern ?). Ich dachte, das hätte ich schon mal gehabt - hab mich da aber
wohl geirrt. Habe auch in den AppNotes keinen Befehl gefunden der einen
Zugriff auf das Flash zuälsst - will aber nix heissen.
In der Entwicklungsentgebung ist ein Disassembler integriert - also das
Hex- (oder Bin-) File ließe sich analysieren.
Walter.
eProfi: Third line:
> First line: 6 5 8 0 0 0 1 R 1 A 6 G
Walter:
> First line: 6 5 8 0 0 1 R 1 A Y> Walter schreibt:> => Baujahr 2006, Flash Version
Woher leitest Du die Flash-Version ab?
Habe mir gerade 8 St. von Amazon geordert, der Preis ist auf 9,44
gefallen, ist ja wie an der Börse.
Autor: h65a7ie3 (Gast) Datum: 01.06.2011 14:24
> Ich bin nicht der Meinung, dass der µC-Hersteller die> Fuses absichtlich versteckt.> Meiner Meinung nach sieht der Hersteller keine Notwendigkeit,> die Fuses absichtlich zu verstecken oder die gleiche> Funktionalität auf mehrere Fuses zu verteilen (immer auch> Sicht des Schutzes heraus gesehen).
Tut mir leid, da täuschst Du Dich gewaltig.
> Ich bin mir nicht sicher, ob es Mikro-Nadeln gibt, mit denen> man auf dem Die entsprechende Stellen kontaktieren kann.
Gibt es, nennt sich micro probing.
Such mal nach dem Russen-Pdf "breaking code protection on
microcontrollers". Da ist haargenau beschrieben, wie es geht.
@eProfi:
Du hast Recht. Sorry, da hab ich mich geirrt (vor lauter Freude die 3.
Null übersehen ;-)
Lauf Datenbaltt habe ich aber verstanden, dass die EM6580 die Flash-,
die EM6680 die ROM-Version ist.
Walter.
Moin zusammen!
Zum EM6580 habe ich noch folgendes gefunden:
On the ELNEC programmers, you are able to select 2 programming modes.
• First one is called "sector 1" : read-back the flash sector 2
(trimming information) + erase both sectors + write the sector 1 +
re-write the previous trimming information in the sector 2.
• Second mode is called "sector1 + sector 2" : both sectors are erased
and replaced by the content of the programmer buffer (Caution : with
this mode the trim values are lost).
(Auszug aus AppNote 26:
http://www.emmicroelectronic.com/webfiles/Product/MCU/an/AN26.pdf )
Könnte also ein Problem geben, den "sector 1" mit dem gesuchten
Programmcode auszulesen. Zumindest ist diese Möglichkeit nirgends
dokumentiert.
Gruß, Didi
Hallo
Ich habe mal eine allgemeine Frage zu den Wetterempfaengern. Ich habe
mir drei von diesen Amazon Dingern fuer 9.- besorgt, die ich auch schon
eine Weile habe. Meteotronic WM 5000
Wenn ich die Geraete starte dauert es etwa drei Minuten bis die
Zeitanzeige & Datum kommen. Dann, und das ist mir in mehreren Versuchen
aufgefallen, dauert es MINDESTENS einen Tag, oft 36h bis alle
Wetterdaten da sind. Empfang ist bei mir sehr gut, daran liegt es nicht.
Besonders aufgefallen ist mir dabei das die Daten immer in der selben
Reihenfolge kommen, was auch immer mehrere Stunden dauert.
Heute: Hoechste Temperatur
Tag 2: Hoechste Temperatur
Tag 3: Hoechste Temperatur
Tag 4: Hoechste Temperatur
Heute: Niedrigste Temperatur
Tag 2: Niedrigste Temperatur
Tag 3: Niedrigste Temperatur
Tag 4: Niedrigste Temperatur
Weiter ist mir aufgefallen, dass wenn ich drei Uhren in einem Abstand
von 3h Starte (passte mir zeitlich gerade so in den Kram) sie sich exakt
gleichzeitig aktualisieren. Also:
Uhr 1 hat schon die Hoechstwerte von HEUTE und TAG 2. Dann kommt ja der
Hoechstwert fuer Tag 3 und im SELBEN Moment auf der zweiten UND dritten
Uhr auch ein Wert dazu.
Druecke ich auf Location und gehe die mal durch, sind alle Werte die
fuer meine Region gelten, also meinetwegen HEUTE und TAG 1 auch fuer
alle anderen 59 Regionen da. Sie werden also abgespeichert.
Wann die Wetterdaten auf den naechsten Tag umspringen habe ich noch
nicht getestet, da ich selten bis 24h aufbleiben kann. Heute werde ich
einmal darauf achten was genau passiert.
Meine eigentliche Frage ist also: Warum dauert es so immens lange bis
die Daten komplett da sind, wenn doch die Wetterdaten jede Minute mit
uebermittelt werden ?
Und warum kommen die Daten in so einer komischen Reihenfolge ?
Nein, das muss jetzt nicht beantwortet werden, aber Kleinigkeiten helfen
oft und vielleicht ist das ja noch nicht wirklich aufgefallen.
Das sind so meine ersten Erfahrungen mit diesem Geraet und ich hoffe das
es vielleicht irgendwo weiter helfen kann.
Morgen werde ich dann mal ran setzen und beide Threads gruendlich lesen
und mal den Loetkolben anwerfen.
Nebenher. Waere es nicht klueger diesen Thread mal zu beenden und einen
neuen anzufangen, es wird doch sehr unuebersichtich hier.
Hallo Peter, es gibt bereits zwei neue Threads:
http://www.mikrocontroller.net/topic/goto_post/2211071http://www.mikrocontroller.net/topic/goto_post/2211105
Im ersteren geht es speziell um den verwendeten PIC und dessen
undokumentierten "High Flash" in dem auch der RAM-Monitor läuft
Der zweite Thread geht um "Meteocrypt", also der Verschlüsselung der
Daten.
Deine Versuchsergebnisse sind übrigens soweit richtig, aber schon lange
bekannt.
Es werden jeden Tag zur selben UTC-Zeit die Daten für ein Gebiet
übertragen. Daher dauert der Sync so lange bis die Daten eben übertragen
werden die zu DEINER Region gehören. Deine Uhren müssten sich also immer
zur selben Zeit auf das neue Wetter einstellen.
Danke fuer die Antwort, kam genau zum richtigen Zeitpunkt. Denn eben
habe ich mal darauf geachtet, wann genau die Wetterdaten umschalten. Das
passiert GENAU um 12:01:30 bei allen drei Uhren. Und das fuer alle 60
Regionen, jedenfalls so schnell ich blaettern konnte.
Das es bereits bekannt war wusste ich nicht, denn wie gesagt, die
Threads sind extrem lang und viele davon sind fuer den "Normalanwender"
unbrauchbar, da es viel zu sehr in's Detail geht. Ich versuche da
mitzuhalten, was mir aber ehrlich gesagt ziemlich schwer faellt da man
sich vieles erst ergoogeln muss und weil die "Freaks" einfach
voraussetzen das man versteht was die meinen.
Ich fuer meinen Teil blicke nicht durch wie es wirklich funktioniert
trotz Wiki und Verfolgung dieser Threads. Nun gut, ich habe auch nicht
alles wirklich gelesen und erst recht nicht verstanden. Wenn ich aber
morgen mal eine Uhr zerlege und dann alles ausprobieren und lesen kann,
hoffe ich, zumindest einen Teil verstanden zu haben. Es interessiert
mich ja schon sehr wie man sowas angeht. Die Wetterdaten selbst
interssieren mich dabei eigentlich kaum. Ich wohne in Koeln (Im
Rheingebiet ist das Wetter eh anders) und die naechte Region ist
Duisburg. Macht also von den Wetterdaten her ueberhaupt keinen Sinn.
Internetdienste sind da wesentlich genauer.
Danke fuer die Links. Die werde ich mir morgen alle mal zu Gemuete
fuehren.
Hallo,
Ich habe soeben noch einen Vorschlag umgesetzt, was die
Massendekodierung angeht.
Jetzt können dateien Priorisiert werden. So können Dateien mit hoher
Priorität schnell zwischendrin eingeschoben werden, während zum Beispiel
sehr größe Dateien die Viel Zeit beanspruchen pausiert werden.
vor allem jetzt an eProfi:
Du kannst nun mehr als 4096 Datensätze pro datei reinschieben, wenn
jemand anderes was dekodiert haben möchte kann dieser das auf hohe
Priorität stellen.
Große Datensatzdateien möglichst niedrige, sehr kleine hohe Priorität,
und wenn das egal ist, einfach auf Standard stellen.
Die Dateien werden Vorrangig nach Priorität, dann nach Hochladezeit
zuerst bearbeitet, frühere Dateien zuerst.
und dann zum Abschluss noch den link
http://www.dcf77logs.de/DecoderAccess.aspx
Bisher wurden rund 124.000 Datensätze dekodier, Ich habe Pro Datensatz
38s angenommen,
das passt sehr gut, (ich mache die Fertigstellungsprognosen damit)
Demnach würde das mit einem Decoder gerundet 54 Tage, 12 Stunden dauern.
Gruß
Thomas
Wäre es nicht sinnvoll bereits dekodierte Daten vor dem Decoder zu
schützen, falls zwei Leute das gleiche dekodieren möchten?
Also quasi eine "hab ich schon"-Routine einfügen?
Alex W. schrieb:> Wäre es nicht sinnvoll bereits dekodierte Daten vor dem Decoder zu> schützen, falls zwei Leute das gleiche dekodieren möchten?>> Also quasi eine "hab ich schon"-Routine einfügen?
So wie ich die Website verstehe, gibt es so etwas bereits.