Beiträge von Manawyrm

    Der ESP ist der falsche Prozessor für ein solches Vorhaben, du könntest mit viel Gefriemel zwar bestimmt ne halbwegs akzeptable IEC Implementation bauen, aber spätestens bei den Fastloadern wäre schluss.
    Auf dem ESP läuft normalerweise ein RTOS, und wenn du WLAN haben möchtest (was ja der wahrs. einzig sinnvolle Grund wäre, einen ESP zu nehmen) kommst du um dieses nicht herum. Damit wird das mit den strikten Timing-Anforderungen nichts mehr...

    Ein großes Problem mit WinXP ist auch der alte SSL/TLS-Support.
    WinXP / Outlook Express kann nur SSL3, damit wird ein guter E-Mail-Provider dich heute nicht mehr verbinden lassen.
    Google Mail oder die Webhosting-Pakete, welche meine Firma verkauft, z.B. lassen dich mit SSL3 überhaupt nicht mehr verbinden, um die anderen Kunden zu schützen.

    Hmm... Ich muss schon sagen, das ist ein ungemein ungewöhnlicher Aufbau -- HF-Schaltungen ohne ordentliche Groundplane, ohne Schirmung und mit Schraubklemmen für ~400-1000 MHz Signale.
    Bin gespannt, ob das wirklich klappt und eine praktische Verbesserung bewirkt. Ganz vorstellen kann ich mir das aber noch nicht.

    Joo, das schaut ganz gut aus.

    Zuerst nen paar Dependencies: sudo apt-get install git build-essential

    git clone "Bitte melde dich an, um diesen Link zu sehen."
    cd acme/src
    make -j5

    Hab das jetzt nicht ausprobiert, aber das müsste so eig. klappen.
    Wenn das alles klappt, kann man das in nen .deb Paket packen oder zur Not sudo make install'en.

    So ein RF-Power-Meter bringt dir da wenig. Damit kann man die Leistung von Sendern bestimmen...

    Praktisch ist das bei dir mit höchster Wahrscheinlichkeit ein Verkabelungsproblem.
    Prüfe die Kabel in den Dosen, evtl. berührt irgendwo die Schirmung den Signalleiter, vllt. ist der Signalleiter rausgerutscht/abgebrochen, sowas.

    Du möchtest dich beim Prüfen nach dem SNR/CNR richten, nicht nach der Signalstärke oder ähnlichen Indikatoren.

    Viel Erfolg beim Suchen ;)

    Solange der Server HTTPS kann, sollte das klappen...
    Wird von nem einfachen PHP-Skript erzeugt....

    PHP
    <?php 
    $text = date("H:i:s") . " - Commodore!";
    header('Content-Type: image/png');
    $im = @ImageCreate (400, 18);
    $background_color = ImageColorAllocate ($im, 255, 255, 255);
    $text_color = ImageColorAllocate ($im, 233, 14, 91);
    ImageString ($im, 3, 2, 2, $text, $text_color);
    ImagePNG ($im);

    Deswegen habe ich stagefright ja oben auch schon angesprochen und ebenso bereits gesagt, dass dir AV-Software nicht mehr hilft.
    Ein Angreifer würde eine solche Lücke nahezu immer mit einer entsprechenden Local-Privilage-Escalation-Lücke z.B. im Linux-Kernel nutzen, welche leider zahlreich vorhanden sind. Mit root-Rechten ist es dann ein leichtes, die AV-Software aus dem System zu kegeln.
    Praktisch kommen solche Drive-by-Angriffe/Exploits gegen Android wirklich selten vor, die einzigen, die ich mal in der Wildbahn gesehen habe, waren Exploits gegen den eingebauten Browser in Samsungs verbasteltem Android 2.3. Und auch bzw. gerade da hilft keine AV-Software.
    Wenn dein OS anfällig für RCE ist, hast du schlicht verloren.
    Erschwerend kommt noch hinzu, dass (gerade die alten) Mobile-CPUs und Systeme im Gegensatz zu modernen Computern oft mittlerweile normale Schutzmechanismen nicht nutzen. Stichwörter NX-Bit, ASLR, PIE.


    EDIT:
    Ein weiteres Thema sind nochmal Sicherheitsbetrachtungen der AV-Software selbst. Ich habe da schon "Firewall"-Apps für Android gesehen, welche ohne root-Rechte auskommen wollten und daher auf localhost einen VPN-Deamon bzw. einen HTTP-Proxy aufgemacht haben.
    Haben dabei aber leider auf 0.0.0.0 gelauscht und jedem im Netzwerk oder im schlimmsten Falle sogar im Internet einen Open-Relay-Proxy angeboten. Ist immer besonders lustig für Spammer.

    "Virenschutz"-Software auf Android ist tatsächlich in fast jedem Falle Schlangenöl.

    Es gibt 2 Methoden, wie man sich auf Android-Geräten Probleme einhandeln kann:
    a) unsignierte Apps zulassen und dann aus dubiosen Quellen Software installieren
    -> hierbei hilft auch kein AV-Programm mehr, im besten Falle erkennt es erst, was der Nutzer da installieren möchte, wenn es schon zu spät ist.

    b) Exploits gegen Systemkomponenten (siehe Stagefright)
    -> sorgen in den meisten Fällen direkt für komplette Privilege Escalation also vollen Systemzugriff.
    Da kann dann auch kein AV-Programm mehr was gegen sagen, da es nicht "gegen das System" ankommen kann.

    Für den sehr seltenen Fall, dass man tatsächlich mal Malware im Google PlayStore findet, dieser auch noch volle Berechtigungen gegeben hat, ist man relativ selbst schuld, und außerdem sind solche Apps im Normallfall schneller aus dem Store raus, als irgendeine AV-Bude Signaturupdates veröffentlicht hat.

    AV-Software müsste theoretisch auf dem Gerät als root laufen, was aber selbst nur möglich ist, wenn man das Gerät rootet und sich damit weiteren Risiken aussetzt.


    Zitat

    KEINER Email JEMALS auf einen unbekannten Anhang

    Eben auch bei E-Mails sind wieder die 2 Infektionsmöglichkeiten vorhanden. Exploits gegen Medienbibliotheken sind mir in der freien Wildbahn noch nicht begegnet. .apk-Dateien kommen sehr selten mal vor, aber auch die installieren sich nicht selbst und schon gar nicht, wenn man die Betriebssystems-Signaturen entsprechend aktiviert lässt.

    Kurzum: AV-Software auf Mobilgeräten verbrät nur unnötig Akku und RAM. Updates von Betriebssystem und das Nicht-Zulassen unsignierter .apk-Dateien sind wirkliche Sicherheitstipps.

    Viele Grüße,
    Tobias

    Nicht zwingend benötigte Chips wie den SID würde ich auf jeden Fall erstmal entfernen.

    Du sprichst von "Kurzschluss beseitigt", wo war der Kurzschluss?
    Kann es sein, dass da irgendwie mit 12V die PLA gehimmelt wurde?
    Mal mit dem Multimeter alle PLA-Sockel Pins durchgegangen, und gecheckt das nirgends mehr als 5V drauf sind?

    Zitat

    3 Sicherungen hat es mich aber schon gekostet. Die gehen reproduzierbar über den Jordan wenn ich am 7805 die 5V messen will. Bitte melde dich an, um dieses Bild zu sehen.

    Warte, du schließt das Multimeter an, und dann fliegt die Sicherung?
    Dann misst du falsch :smile:

    Wo sind die Messspitzen bei deinem Multimeter eingesteckt?

    Hi,

    du kannst auf mehrere Arten an das Problem rangehen.
    a) wäre eine Timer-Routine, welche jede Sekunde ausgelöst wird. Darin könnte man dann die Uhrzeit hochzählen. Wenn du einen Arduino mit 16MHz Quarz hast (eig. alle), ist das genau genug.
    b) Nimm eine der vielen Zeit-Bibliotheken: Bitte melde dich an, um diesen Link zu sehen. oder ähnliche
    c) Versuch die Zeit über millis() herauszubekommen. Hab ich aber noch nicht gemacht, und weiß nicht, wie kompliziert das ist.

    Wenn ich deinen Code richtig lese, hast du ja eine gemultiplexte Anzeige, es leuchtet also immer nur eine Ziffer und das sollte entsprechend schnell geschehen.
    Ich würde folgendes machen:
    Mach dir 3 uint8_t Variablen, "hour", "minute", "second".
    Mach dir noch eine uint8_t Variable "digit" in welcher du speicherst, bei welcher Ziffer du gerade bist
    Nimm eine Timer-Bibliothek: Bitte melde dich an, um diesen Link zu sehen. (habe mit dieser gute Erfahrungen) und lasse eine Funktion z.B. 100x in der Sekunde ausführen (kann man später easy erhöhen).
    Darin schreibst du jeweils die aktuelle digit auf die Anzeige (mit Modulo 10 und Teilen durch 10 geht das easy), und machst die Kathoden dazu auch an. Und die digit hochzählen und prüfen, ob sie bei 6 angekommen ist, dann wieder auf 0 setzen.

    Also quasi die Anzeige und die Zeiterfassungslogik trennen. Wenn sich in der Timer1 Routine drum gekümmert wird, dass die Zeit angezeigt wird, kannst du in deiner loop() machen, was du möchtest, auf irgendwelchen Userinput reagieren oder sich um die eigentliche Uhrzeit (siehe oben) kümmern.

    Hoffe das hilft und war nicht allzu unverständlich ;)
    Viele Grüße,
    Tobias

    Zitat

    Das ist mal ne Ansage in nem Retro-Forum Bitte melde dich an, um dieses Bild zu sehen.

    Jau, ich bin ja auch ein Fan davon, alles und jeden alten Rechner ans Netz zu hängen, aber Android 2.x hat leider noch nicht das "magische" Alter erreicht, ab dem ich sage: "Gibts eh keine Bedrohungen für", sondern die Gefahr ist leider noch überall gegeben.
    Vernünftiges TLS schützt halt alle anderen Nutzer des Forums, daher bin ich den Admins hier sehr dankbar, dass sie eine vernünftige Konfiguration ausgerollt haben :smile:

    Dafür braucht man keine 150€ ausgeben:

    Beim Chinesen gibt es heutzutage GSM Module mit IP-Stack und Serial Port für unter 10€.
    Nur irgendeine Form der Pegelwandlung von 3.3V auf 5V wäre wichtig.

    Das Modul macht Autobauding, mit 9600 Baud habe ich das schon gemacht, ob das Modul freiwillig auch 2400 Baud macht weiß ich leider nicht, aber einen Versuch ist es wert.

    Have fun,
    Tobias