Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #252678 > unrolled thread

nochmal Frage zum Raspberry

Back to article view | Back to de.sci.electronics

Contents

  nochmal Frage zum Raspberry Stefan <df9bi@gmx.de> - 2019-02-04 08:57 +0100
    Re: nochmal Frage zum Raspberry Thorsten Böttcher <thorsten_nospam@gmx.net> - 2019-02-04 09:06 +0100
    Re: nochmal Frage zum Raspberry Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-02-04 09:10 +0100
      Re: nochmal Frage zum Raspberry Stefan <df9bi@gmx.de> - 2019-02-04 11:33 +0100
    Re: nochmal Frage zum Raspberry Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2019-02-04 17:15 +0100
      Re: nochmal Frage zum Raspberry Marcel Mueller <news.5.maazl@spamgourmet.org> - 2019-02-04 19:54 +0100
        Re: nochmal Frage zum Raspberry Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-02-04 20:06 +0100
          Re: nochmal Frage zum Raspberry Stefan <df9bi@arcor.de> - 2019-02-04 20:40 +0100
            Re: nochmal Frage zum Raspberry Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-02-04 20:57 +0100
            Re: nochmal Frage zum Raspberry olaf <olaf@criseis.ruhr.de> - 2019-02-04 20:53 +0100
            Re: nochmal Frage zum Raspberry Marcel Mueller <news.5.maazl@spamgourmet.org> - 2019-02-04 21:26 +0100
              Re: nochmal Frage zum Raspberry "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2019-02-05 08:33 +0100
              Re: nochmal Frage zum Raspberry Stefan <df9bi@gmx.de> - 2019-02-05 08:41 +0100
                Re: nochmal Frage zum Raspberry "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2019-02-05 09:37 +0100
                Re: nochmal Frage zum Raspberry Michael Schwingen <news-1513678000@discworld.dascon.de> - 2019-02-06 17:49 +0000
                  Re: nochmal Frage zum Raspberry Stefan <df9bi@arcor.de> - 2019-02-06 19:10 +0100
                    Re: nochmal Frage zum Raspberry Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-02-06 19:12 +0100
                      Re: nochmal Frage zum Raspberry Stefan <df9bi@arcor.de> - 2019-02-06 20:24 +0100
                        Re: nochmal Frage zum Raspberry Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-02-07 03:26 +0100
                          Re: nochmal Frage zum Raspberry Stefan <df9bi@gmx.de> - 2019-02-08 14:50 +0100
                            Re: nochmal Frage zum Raspberry Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-02-08 15:17 +0100
                            Re: nochmal Frage zum Raspberry Thorsten Böttcher <thorsten_nospam@gmx.net> - 2019-02-08 17:37 +0100
                              Re: nochmal Frage zum Raspberry Stefan <df9bi@arcor.de> - 2019-02-08 20:08 +0100
                                Re: nochmal Frage zum Raspberry Carla Schneider <carla_sch@yahoo.com> - 2019-02-12 13:02 +0100
              Re: nochmal Frage zum Raspberry "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2019-02-05 07:46 +0000
          Re: nochmal Frage zum Raspberry Marcel Mueller <news.5.maazl@spamgourmet.org> - 2019-02-04 21:22 +0100
            Re: nochmal Frage zum Raspberry Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2019-02-05 18:24 +0100
              Re: nochmal Frage zum Raspberry Marcel Mueller <news.5.maazl@spamgourmet.org> - 2019-02-07 17:55 +0100
                Re: nochmal Frage zum Raspberry Michael Schwingen <news-1513678000@discworld.dascon.de> - 2019-02-08 20:11 +0000
                  Re: nochmal Frage zum Raspberry Marcel Mueller <news.5.maazl@spamgourmet.org> - 2019-02-08 22:22 +0100
                    Re: nochmal Frage zum Raspberry Michael Schwingen <news-1513678000@discworld.dascon.de> - 2019-02-09 16:15 +0000
        Re: nochmal Frage zum Raspberry Josef Moellers <josef.moellers@invalid.invalid> - 2019-02-05 09:27 +0100
          Re: nochmal Frage zum Raspberry Michael Schwingen <news-1513678000@discworld.dascon.de> - 2019-02-06 17:52 +0000

Page 2 of 2 — ← Prev page 1 [2]

#252779

On 2/8/19 2:50 PM, Stefan wrote:
> Am 07.02.2019 um 03:26 schrieb Hans-Peter Diettrich:
>> Am 06/02/2019 um 8:24 PM schrieb Stefan:
>>> Am 06.02.2019 um 19:12 schrieb Gerrit Heitsch:
>>
>>>> Dann könntest du doch einfach mit der Hardware via RS232 reden und
>>>> wenn die nicht die richtige Antwort liefert läuft die Software nicht.
>>>> Irgendein nicht allzu leichtes Challenge/Response-Verfahren.
>>>
>>> Schon klar, aber es soll nicht möglich sein, die SD-Karte zu kopieren,
>>> diese in einen anderen Raspi zu stecken und schon kann der mit der k
>>> Hardware kommunizieren.
>>
>> Dann nimmt der Bösewicht einfach den ganzen RasPi mit :-]
> 
> Das wäre noch nicht so schlimm.
> 
> Er soll nur nicht in der Lage sein, Konfigurationsdaten zu ändern.
> 
> Bestimmte Funktionen des Systems können nur bedient werden, wenn ein 
> Admin-Passwort bekannt ist. Wenn man nun die Datei, in der sich das 
> Passwort befindet einfach austauscht und damit Zugriff auf das System 
> bekäme, wäre das schlecht.
> 
> Deshalb sollte es auch nicht möglich sein, dass jemand, der ein System 
> besitzt, dessen Admin Code er kennt, den dazugehörigen Raspi in einem 
> fremden System ans Laufen bekommt und so mit seinem Admin Code Zugriff 
> auf das fremde System bekommt.

Es ist allerdings kein Problem die SD-Karte aus dem Raspi zu entnehmen, 
zu kopieren und dann den Inhalt in Ruhe zu analysieren.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#252785

Am 08.02.2019 um 14:50 schrieb Stefan:

>> Dann nimmt der Bösewicht einfach den ganzen RasPi mit :-]
> 
> Das wäre noch nicht so schlimm.
> 
> Er soll nur nicht in der Lage sein, Konfigurationsdaten zu ändern.

Dann verschlüssel die Dateien, oder berechne einen Hash um 
Manipulationen zu erkennen.

[toc] | [prev] | [next] | [standalone]

#252789

Am 08.02.2019 um 17:37 schrieb Thorsten Böttcher:
> Am 08.02.2019 um 14:50 schrieb Stefan:
> 
>>> Dann nimmt der Bösewicht einfach den ganzen RasPi mit :-]
>>
>> Das wäre noch nicht so schlimm.
>>
>> Er soll nur nicht in der Lage sein, Konfigurationsdaten zu ändern.
> 
> Dann verschlüssel die Dateien, oder berechne einen Hash um 
> Manipulationen zu erkennen.

Änderung der Konfigurationsdaten kann auch bedeuten, dass man 
Konfigurationsdaten von einem System auf ein anderes kopiert.

Unterm Strich ist das alles kein Problem, wenn der Raspi eindeutig über 
seine Seriennummer identifizierbar ist. Insofern wurde meine Frage 
inzwischen beantwortet.

[toc] | [prev] | [next] | [standalone]

#252883

Stefan wrote:
> 
> Am 08.02.2019 um 17:37 schrieb Thorsten Böttcher:
> > Am 08.02.2019 um 14:50 schrieb Stefan:
> >
> >>> Dann nimmt der Bösewicht einfach den ganzen RasPi mit :-]
> >>
> >> Das wäre noch nicht so schlimm.
> >>
> >> Er soll nur nicht in der Lage sein, Konfigurationsdaten zu ändern.
> >
> > Dann verschlüssel die Dateien, oder berechne einen Hash um
> > Manipulationen zu erkennen.
> 
> Änderung der Konfigurationsdaten kann auch bedeuten, dass man
> Konfigurationsdaten von einem System auf ein anderes kopiert.
> 
> Unterm Strich ist das alles kein Problem, wenn der Raspi eindeutig über
> seine Seriennummer identifizierbar ist. Insofern wurde meine Frage
> inzwischen beantwortet.
Bleibt noch die Frage wie man die Seriennummer ausliest ohne Umweg ueber
/proc/cpuinfo

[toc] | [prev] | [next] | [standalone]

#252715

Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
>Am 04.02.19 um 20:40 schrieb Stefan:
>> könnte man nicht die Systemdateien auf Änderungen checken?
>> Also eine oder mehrere Checksummen über die entsprechenden Bin-Dateien 
>> berechnen und diese im Anwendungsprogramm überprüfen?

>Du glaubst gar nicht, wie viele Fehlalarme das gibt.

>Lass den Quatsch, nimm die Seriennummer, und gut. Das ist mehr als Du 
>auf jedem handelsüblichen PC bekommen kannst.

>Wenn Du paranoid bist, dann rufe die Mailbox der Firmware selber auf. 
>Siehe auch meine Antwort auf Gerrit. Ansonsten tut es /proc/cpuinfo, wie 
>vorgeschlagen.

Man könnte die Konfigurationsdatei(en) der eigenen Anwendung mit Hilfe der
Seriennummer verschlüsseln, indem man die Seriennummer als Seed eines PRNG
verwendet. Das macht es noch ein bisschen schwieriger. Letztendlich hilft
es aber nichts, wenn der Benutzer auf dem Gerät root werden kann.

-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

[toc] | [prev] | [next] | [standalone]

#252705

Am 04.02.19 um 20:06 schrieb Gerrit Heitsch:
>> Natürlich könnte man den Linux-Kernel so manipulieren, dass er 
>> irgendetwas in /proc/cpuinfo schreibt. Spätestens aber, wenn man die 
>> VC Kommandos, die diesem als Grundlage dienen, direkt aufruft, wird es 
>> eng. vcgencmd otp_dump spuckt die Serial direkt aus.
> 
> Ja... und was ist wenn ich ein eigenes vcgencmd davorschalte welches das 
> echte aufruft und alles ausser der Ser# sauber durchreicht und die 
> passend umschreibt?

Das war nur als Beispiel gedacht. Man kann die API problemlos selber 
aufrufen. Siehe
https://github.com/raspberrypi/firmware/blob/master/opt/vc/include/interface/vmcs_host/vcgencmd.h
https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface
-> Get board serial (0x10004)

> Ist ja nicht so, daß das eine neue Idee wäre.


Marcel

[toc] | [prev] | [next] | [standalone]

#252729

On 2/4/19 9:22 PM, Marcel Mueller wrote:
> Das war nur als Beispiel gedacht. Man kann die API problemlos selber 
> aufrufen. Siehe
> https://github.com/raspberrypi/firmware/blob/master/opt/vc/include/interface/vmcs_host/vcgencmd.h 
> 
> https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface
> -> Get board serial (0x10004)

Und zusammen mit den Headern kann ich in kürzester Zeit eine kompatible 
*.so kompilieren die an das Original ankoppelt. Dann einmal alle Befehle 
ans Original weitergeben bis auf die, die ich übersteuern will.

Oder noch besser: Direkt nur das exportieren was ich übersteuern will 
und meine Lib via LD_PRELOAD zuladen.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#252771

Am 05.02.19 um 18:24 schrieb Manuel Reimer:
> On 2/4/19 9:22 PM, Marcel Mueller wrote:
>> Das war nur als Beispiel gedacht. Man kann die API problemlos selber 
>> aufrufen. Siehe
>> https://github.com/raspberrypi/firmware/blob/master/opt/vc/include/interface/vmcs_host/vcgencmd.h 
>>
>> https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface
>> -> Get board serial (0x10004)
> 
> Und zusammen mit den Headern kann ich in kürzester Zeit eine kompatible 
> *.so kompilieren die an das Original ankoppelt. Dann einmal alle Befehle 
> ans Original weitergeben bis auf die, die ich übersteuern will.

Ähm, die Header definieren im Wesentlichen nur das Message-Format. Die 
Interpretation der Messages sowie die Bereitstellung der Antwort macht 
nicht die ARM-CPU. Die Kommunikation erfolgt über Hardware-Register. Es 
wird schwierig, da etwas zu überladen.


Marcel

[toc] | [prev] | [next] | [standalone]

#252795

On 2019-02-07, Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
>
> Ähm, die Header definieren im Wesentlichen nur das Message-Format. Die 
> Interpretation der Messages sowie die Bereitstellung der Antwort macht 
> nicht die ARM-CPU. Die Kommunikation erfolgt über Hardware-Register. Es 
> wird schwierig, da etwas zu überladen.

Bist Du im Kernel- oder im Userspace?

Wenn Du im userspace die Mailbox-Register mit mmap zugreifbar machen willst,
kann ich Dir mit einem passend gepatchten Kernel da auch Speicher mit einer
Mailbox-Emulation hinmappen. Wobei: per LD_PRELOAD geht das vermutlich sogar
ohne Kernelmanipulationen.

Auch, wenn es so aussehen mag: im userspace hast Du keinen direkten Zugriff
auf die Hardware.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#252797

Am 08.02.19 um 21:11 schrieb Michael Schwingen:
> On 2019-02-07, Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
>>
>> Ähm, die Header definieren im Wesentlichen nur das Message-Format. Die
>> Interpretation der Messages sowie die Bereitstellung der Antwort macht
>> nicht die ARM-CPU. Die Kommunikation erfolgt über Hardware-Register. Es
>> wird schwierig, da etwas zu überladen.
> 
> Bist Du im Kernel- oder im Userspace?

> Wenn Du im userspace die Mailbox-Register mit mmap zugreifbar machen willst,
> kann ich Dir mit einem passend gepatchten Kernel da auch Speicher mit einer
> Mailbox-Emulation hinmappen.

Viel Spaß beim Emulation schreiben. Das gibt viele Funktionen. Und da 
liegen viele Register. Der Aufwand ist sicher höher, als aus dem 
betreffenden Programm die Abfrage raus zu patchen.

Für den Hausgebrauch tut es wie schon gesagt cpuinfo, und für die eins 
schwierigere Nummer reicht mutmaßlich IOCTL_MBOX_PROPERTY. Danach kommt 
man schon in den Bereich, wo Anwendung patchen ins Spiel kommt.

> Auch, wenn es so aussehen mag: im userspace hast Du keinen direkten Zugriff
> auf die Hardware.

Das ist so, aber da du nur 4k-weise mappen kannst, musst du nahezu den 
ganzen Raspi emulieren. Das wird bei der lahmen CPU sehr schnell 
inpraktikabel. Selbst eine reine Mailbox-Emulation ist mutmaßlich schon 
kritisch, da ja jeder einzelne Zugriff über eine Exception laufen muss.
Spätestens wenn in der Anwendung noch ein simples Timing-Limit enthalten 
ist, ist die Sache mit der Emulation rum.


Marcel

[toc] | [prev] | [next] | [standalone]

#252806

On 2019-02-08, Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
>
> Viel Spaß beim Emulation schreiben. Das gibt viele Funktionen. Und da 
> liegen viele Register. Der Aufwand ist sicher höher, als aus dem 
> betreffenden Programm die Abfrage raus zu patchen.

BTDT (auf dem Milan für die Chips, die ein original-Atari halt so hatte).
Insbesondere, wenn das nicht mit beliebiger, sondern nur dieser einen
Software funktionieren soll, sollte es relativ einfach sein, alles bis auf
diede eine Funktion durchzureichen.

Im einfachsten Fall macht der Prozess nur diesen einen Request und man kann
sich die komplette restliche Emulation schenken ...

> Das ist so, aber da du nur 4k-weise mappen kannst, musst du nahezu den 
> ganzen Raspi emulieren. Das wird bei der lahmen CPU sehr schnell 
> inpraktikabel. Selbst eine reine Mailbox-Emulation ist mutmaßlich schon 
> kritisch, da ja jeder einzelne Zugriff über eine Exception laufen muss.

Nur für die direkten Hardware-Zugriffe, die dieser Prozess macht. Der Kernel
hat eigene, direkte mappings ohne Emulation dazwischen.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#252716

On 04.02.19 19:54, Marcel Mueller wrote:
> Am 04.02.19 um 17:15 schrieb Manuel Reimer:
>> On 2/4/19 8:57 AM, Stefan wrote:
>>> Welche Möglichkeit gibt es noch? Gibt es die Möglichkeit, die
>>> Seriennummer der CPU oder eines anderen Bausteins auszulesen?
>>
>> Ja.
>>
>> Gibt es eine Möglichkeit jemanden mit fundierten Linux-Kenntnissen
>> daran zu hindern diese zu manipulieren?
>>
>> Nein.
> 
> Das stimmt so nicht wirklich. Die Seriennummer wird vom /Hauptprozessor/
> des Pi, der VCU verwaltet. Die Firmware dafür ist aber /nicht
> Open-Source/. Der ARM Core ist eigentlich nur ein Coprozessor,
> gleichwohl er mittlerweile mehr Rechenleistung hat.
> 
> Natürlich könnte man den Linux-Kernel so manipulieren, dass er
> irgendetwas in /proc/cpuinfo schreibt.

/proc ist ein ge-mount-etes Pseudo-Dateisystem. Zum Einen könnte man,
für eine kurze Zeit, etwas anderes dort mount-en, zum Anderen kann der
kompetente Linux-Benutzer sich einen eigenen Dateisystem-Treiber für
procfs schreiben ...

Josef

[toc] | [prev] | [next] | [standalone]

#252752

On 2019-02-05, Josef Moellers <josef.moellers@invalid.invalid> wrote:
> /proc ist ein ge-mount-etes Pseudo-Dateisystem. Zum Einen könnte man,
> für eine kurze Zeit, etwas anderes dort mount-en, zum Anderen kann der
> kompetente Linux-Benutzer sich einen eigenen Dateisystem-Treiber für
> procfs schreiben ...

IIRC kann man mit einem bind-mount eine einzelne Datei nach /proc/cpuinfo
mounten - der Inhalt ist ja statisch.  Das habe ich vor einiger Zeit mal
gemacht, um Ubuntu beizubringen, daß der Pentium-M im Notebook PAE kann,
auch, wenn er das in /proc/cpuinfo nicht meldet.

cu
Michael

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | de.sci.electronics

csiph-web