Jump to content

wthie

Members
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    16

  • Benutzer seit

  • Letzter Besuch

 Inhaltstyp 

Posts erstellt von wthie

    OSX ARM Toolchain für Firmware

    in Allgemeine Diskussionen

    Geschrieben

    Nochmals eine neue Version der Anleitung auf http://trac.thie.ch/wiki/ARMToolChain

     

    cmake in der Version 2.8.8 auf dem Mac baut ein Makefile auf, welches beim Linken des Targets auf ein nicht existierendes Verzeichnis verweist. Nachdem die Datei CMakeCache.txt mit touch berührt wird, läuft der Bau der Firmware problemlos durch. Vorerst habe ich master-brick und servo-brick gebaut, geflasht habe ich nur den master-brick, die Firmware läuft tadellos.

    OSX ARM Toolchain für Firmware

    in Allgemeine Diskussionen

    Geschrieben

    https://launchpad.net/gcc-arm-embedded/4.7/4.7-2013-q3-update/+download/gcc-arm-none-eabi-4_7-2013q3-20130916-src.tar.bz2, auf dem Mac mit gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) XCode 4.6.3 gebaut. Ich habe mir bzr vorerst erspart, da die Gruppe eine sehr rigide Releasepolicy hat. Wie in meinem Wiki erklärt, stolpert der cmake Compiler Test über _exit() und behauptet dann, dass er mit diesem ARM Compiler nichts anfangen kann. Zum Glück gibt's INCLUDE(CMakeForceCompiler), damit kann diese Hürde gut übersprungen werden. Schön, dass diese Arbeit Anklang findet :-)

    Ich habe die Toolchain mal an Eclipse CDT gebunden, läuft soweit gut, ich werde nächstens dann versuchen, entweder mit Turtelizer oder Busblaster und OCD eine saubere Debuggingsituation zu erreichen. Es wäre für mich hilfreich, wenn ich von euch wüsste, ob ihr die Binaries über OCD/JTAG flasht oder ob ich das gleich sein lassen soll. Gibt es da irgendwelche Tricks? Des weiteren denke ich daran, eine um FORTH erweiterte Firmware zu bauen, so dass ein direktes Einklinken über die serielle Schnittstelle möglich wird. Naja, das Leben bleibt spannend, have fun, enjoy, hang loose! Werner

     

    Security issues

    in General Discussion

    Geschrieben

    Hi

     

    Just to describe this information transfer correctly, all data is of course transmitted in the clear over the network, only on WiFi infrastructure is it encrypted if whatever provided security is enabled.

     

    And of course must the user be able to set the security relevant parameters, I'm not questioning this.

     

    To be a bit more specific, good programming practice would call for the sensitive information only requested from the brick, if the user actually wants to adjust it. This is usually handled in a two staged modal dialog situation with the secondary dialog being the only one requesting and storing the sensitive information bits.

     

    Of course would a protocol stack like SSH help to keep sensitive information much more safe on the wire, but on this level of processor this stretches resources way too far.

     

    Amazing work your doing, keep it up - cheers, Werner

    Security issues

    in General Discussion

    Geschrieben

    Hi all

     

    did some tinkering with a stack equipped with the WiFi extension and was stunned to see, that the SSID and WPA2 password was transmitted over the network when connecting to the stack with brickviewer?

     

    [size=8pt][font=courier]sudo tcpflow -i en0 -C -B port 4223 | hexdump -C
tcpflow[21967]: listening on en0
00000000  00 fe 04 00 0a 00 fd 36  00 31 35 30 31 36 30 31  |.......6.1501601|
00000010  34 4d 61 73 74 65 72 20  42 72 69 63 6b 20 31 2e  |4Master Brick 1.|
00000020  30 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |0...............|
00000030  00 00 00 00 00 00 00 00  00 01 01 0a 00 ff 0c 00  |................|
00000040  31 35 30 31 36 30 31 34  0a 00 fd 36 00 ab c9 98  |15016014...6....|
00000050  de be 20 6f 39 52 6f 74  61 72 79 20 50 6f 74 69  |.. o9Rotary Poti|
00000060  20 42 72 69 63 6b 6c 65  74 20 31 2e 30 00 00 00  | Bricklet 1.0...|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 02 01 00  |................|
00000080  fd 36 00 40 65 00 00 00  00 00 00 41 6d 62 69 65  |.6.@e......Ambie|
00000090  6e 74 20 4c 69 67 68 74  20 42 72 69 63 6b 6c 65  |nt Light Brickle|
000000a0  74 20 31 2e 30 00 00 00  00 00 00 00 00 00 00 00  |t 1.0...........|
000000b0  00 00 00 03 01 0a 00 ff  38 00 31 35 30 31 36 30  |........8.150160|
000000c0  31 34 01 04 04 4d 61 73  74 65 72 20 42 72 69 63  |14...Master Bric|
000000d0  6b 20 31 2e 30 00 00 00  00 00 00 00 00 00 00 00  |k 1.0...........|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 01 0a 01  |................|
000000f0  05 04 00 0a 01 05 05 00  00 0a 01 12 04 00 0a 01  |................|
00000100  12 05 00 00 0a 01 1a 04  00 0a 01 1a 05 00 01 0a  |................|
00000110  01 1c 04 00 0a 01 1c 33  00 SS ID SS ID SS ID SS  |.......3.SSIDSSI|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000140  00 00 00 00 00 00 7f 10  0a 01 22 06 00 ff ff 0a  |..........".....|
00000150  01 22 25 00 00 00 00 00  00 00 00 00 00 00 00 00  |."%.............|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000170  00 00 00 00 00 0a 01 22  06 00 fe ff 0a 01 22 25  |......."......"%|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001a0  00 00 0a 01 24 04 00 0a  01 24 05 00 00 0a 01 27  |....$....$.....'|
000001b0  04 00 0a 01 27 05 00 01  0a 01 1e 04 00 0a 01 1e  |....'...........|
000001c0  3f 00 00 pw pw pw pw pw  pw pw pw pw pw pw pw pw  |?..pwpwpwpwpwpwp|
000001d0  pw pw pw pw pw pw pw pw  pw pw pw pw 00 00 00 00  |pwpwpwpwpwpw....|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 01 00 00  00 00 00 00 00 0a 00 ff  |................|
00000200  0c 00 ab c9 98 de be 20  6f 39 0a 00 ff 38 00 ab  |....... o9...8..|[/font][/size]

     

    Why is this happening? I assume that the brick extension is storing the password in a sensible way (meaning not lying around in some flash memory in the clear).

     

    Is this so, or is the master storing the config/pw?

     

    The stack being perfectly capable to register itself alone in a WiFi environment, there seems to me absolutely no necessity to transmit such information when only connecting.

     

    Transmitting such sensible information over the network in the clear seems to me to much a risk taken, assuming that a rather naive usage of bricks could lead to very prominent security holes.

     

    What is the stance of the development team towards these questions.

     

    Password only transmittable when being connected to the stack via wire?

     

    Cheers, Werner

    Firmware master-brick rekompiliert, hängt im Auslesen der uid

    in Software, Programmierung und externe Tools

    Geschrieben

    Zentral ist die Wahl für den CORTEX_M3, dazu ist zu sagen, dass ich die Toolchain nur mit gcc 4.7.1 und newlib 1.19 hingekriegt habe. gcc 4.6 und newlib 1.17 produziert zwar Code, der auf dem Brick soweit anläuft, dass er die Blinkerei mit den LED's noch hinkriegt, die Kommunikation über RS-485 ist dann aber tot. Ich habe das nicht weiter untersucht weil ich keine schlaue Debug Möglichkeit habe. So nebenbei, debuggt ihr mit dem Debug Brick mit dem JTAG Interface wenn neuer Code entwickelt wird?

    Firmware master-brick rekompiliert, hängt im Auslesen der uid

    in Software, Programmierung und externe Tools

    Geschrieben

    Hah, da haben wir doch mit Sicherheit ein 16 <-> 32bit Problem. Wie habe ich das in die Toolchain eingeschleppt?

     

    borg-master-brick.dis:

     

    20000924 <__malloc_trim_threshold>:

    20000924: 0000 0002                                  ....

     

    20000928 <lc_ctype_charset>:

    20000928: 5341 4943 0049 0000 0000 0000 0000 0000

     

     

    my-master-brick.dis

     

    20000c6c <__malloc_trim_threshold>:

    20000c6c: 00020000                                ....

     

    20000c70 <lc_ctype_charset>:

    20000c70: 49435341 00000049 00000000 00000000

     

    Immerhin eine Erklärung für das Hängen, damit geht der 'unverdächtige' Zugriff wohl daneben.

     

    Thxs, Werner

    Firmware master-brick rekompiliert, hängt im Auslesen der uid

    in Software, Programmierung und externe Tools

    Geschrieben

    Hmm, habe mit den Compiler Optimierungen rumgespielt, binaries zwischen

    55k bis 83k, alle zeigen denselben Effekt, scheint etwas systematisches und nicht Compiler-technisches zu sein. Das disassembly des .elf zeigt relativ vieles aus dem Code sauber strukturiert und dargestellt. Mir fehlt jedoch ein .elf der brick_master_firmware_latest.bin.

     

    Ich wäre froh um ein laufendes Paar (.bin & .elf) der brick_master_firmware_latest, dann wäre ein Codevergleich wesentlich einfacher.

     

    TIA, Werner

    Firmware master-brick rekompiliert, hängt im Auslesen der uid

    in Software, Programmierung und externe Tools

    Geschrieben

    Diverse Toolchains ausprobiert, generell dasselbe Problem. Mich erstaunt, dass der Code so empfindlich reagiert :-(

     

    master-brick frisch von der Presse aus git, keine Änderungen an den gcc Optionen

     

    CodeSourcery Toolchain macht dieselben Probleme momentan wie

     

    TIA, Werner

     

    binutils-2.22

    gcc version 4.7.0

    newlib-1.20

     

    arm-none-eabi-gcc -v

    Using built-in specs.

    COLLECT_GCC=arm-none-eabi-gcc

    COLLECT_LTO_WRAPPER=/usr/local/arm-none-eabi/libexec/gcc/arm-none-eabi/4.7.0/lto-wrapper

    Target: arm-none-eabi

    Configured with:

    ../configure

    --target=arm-none-eabi

    --prefix=/usr/local/arm-none-eabi

    --build=i686-apple-darwin11

    --host=i686-apple-darwin11

    --with-gnu-as

    --with-gnu-ld

    --with-newlib

    --enable-extra-sgxxlite-multilibs

    --enable-lto

    --enable-poison-system-directories

    --enable-threads=single

    --enable-languages=c,c++

    --disable-decimal-float

    --disable-libffi

    --disable-libquadmath

    --disable-libssp

    --disable-libgomp

    --disable-shared

    --disable-libmudflap

    --disable-libstdcxx-pch

    --disable-nls

    --disable-libitm

    --disable-libatomic

    --with-gmp=/usr/local

    --with-mpfr=/usr/local

    --with-mpc=/usr/local

    --without-headers

    Thread model: single

    gcc version 4.7.0 (GCC)

     

    Firmware master-brick rekompiliert, hängt im Auslesen der uid

    in Software, Programmierung und externe Tools

    Geschrieben

    Hi all

     

    letzter Stand Source Code master-brick aus git, Firmware rekompiliert, Länge des binaries divergiert ganz leicht (40 Bytes), Neue Firmware läuft an, bleibt aber in der Funktion uid_get_uid64() in uid.c auf Zeile 15:

     

    EFC->EEFC_FCR = (0x5A << 24) | EFC_FCMD_STUI;

     

    hängen. Getestet mit Code, welcher die rote LED (bei Start gesetzt) nach/vor dieser Zeile wieder löscht.

     

    brick_master_firmware_latest.bin flasht und läuft ohne Probleme.

     

    Übersehe ich da etwas Offensichtliches?

     

    TIA, Werner

×
×
  • Neu erstellen...