Podcasts about programmablauf

Moritz, Urs und Daniel, alle drei Softwareentwickler bei andrena, berichten von ihren Erlebnissen mit emergenten Testarchitekturen. Jeder der drei hat seine eigenen Erfahrungen gemacht: Im ersten Beispiel trugen Tests dazu bei, den Programmablauf in einem Legacysystem verständlich werden zu lassen. Im zweiten Fall hatte die Einführung von Performance-Tests deutlichen Einfluss auf den Entwickleralltag. Und bei Nummer Drei tauchte die Frage auf, wo bei Tests die Grenze liegt zwischen "viel" und "zu viel" und welche Auswirkungen es hat, wenn mehr nicht immer mehr ist.

Carla Hinrichs hat bei Anne Will unsere Mediengesellschaft schachmatt gesetzt. Leider ist das Fernsehen wie es ist, und sendete einfach weiter. Selbst als Verfassungsminister Marco Buschmann den Programmablauf aufhalten wollte, wie sonst die Klimakleber nur den Straßenverkehr. Es geht drunter und drüber! Genießen wir also Mathias Musik.

Egal ob auf, vor oder hinter der Bühne - auf unseren Fabian Zimmermann ist immer Verlass! In der #20. Folge erzählt uns unser Kulissen-Chef Fabi, was bei den Hühnerläusen für einen reibungslosen Programmablauf und Umbau auf der Bühne alles zu beachten ist. Und natürlich wird wie immer gegackert, gelacht und gesungen - viel Spaß!

Heute dreht sich alles um das Thema: „Was ist eigentlich eine API?”   Der Begriff API stammt aus dem Englischen und ist die Kurzform von „Application-Programming-Interface". Frei ins Deutsche übersetzt bedeutet das, so viel wie „Schnittstelle zur Anwendungsprogrammierung“. Allerdings wird die API umgangssprachlich meistens als Programmierschnittstelle bezeichnet und ist für das moderne Programmieren unerlässlich. Generell dienen Programmierschnittstellen zur Kommunikation, zum Austausch sowie zur Weiterverarbeitung von Daten und Inhalten zwischen verschiedenen Geräten, Programmen, Websites oder Anbietern. So ermöglichen APIs zum Beispiel die Fernsteuerung der heimischen Heizung, indem sie die Temperaturwerte, die von einem Thermostat gemessenen wurden, über eine Cloud zum Smartphone des Endverbrauchers übermitteln. Im Gegensatz zu einer Benutzerschnittstelle kommunizieren die Anwendungen direkt miteinander und nicht der Menschen mit einem System. Mal angenommen ein Internetnutzer bestellt einen Fernseher im Webshop. Dann kommuniziert er nur über die Weboberfläche des Onlineshops. Das Shopsystem selbst kann über die Programmierschnittstelle die Kundenbonität erfragen, die Zahlung per Kreditkarte oder Paypal veranlassen, bei einer Versicherung eine Garantieverlängerung abschließen und einen Spediteur beauftragen. In anderen Unternehmensprozessen gewährleisten Programmierschnittstellen beispielsweise den Austausch sowie die Weiterverarbeitung von Daten und Inhalten zwischen Customer Relationship Management (CRM), Dokumentenmanagementsystem (DMS) und Enterprise-Resource-Planning (ERP) über die Cloud. Aber wie funktioniert die API nun genau? Die Programmierschnittstelle dient wie bereits erwähnt dazu, Soft- und Hardwarekomponenten wie Anwendungen, Festplatten oder Benutzeroberflächen zu verbinden, sprich mit einer API können zwei Anwendungen, die voneinander unabhängig sind, problemlos interagieren und Inhalte, Ressourcen und Daten austauschen. Die Übergabe von Daten und Befehlen erfolgt dabei strukturiert nach einer zuvor definierten Syntax*. Hierzu werden einzelne Programmteile, die spezifische Funktionen erfüllen, vom Rest des Programmes abgekapselt. Die Module kommunizieren untereinander lediglich über die festgelegte API. Dort werden ausschließlich die Daten übergeben, die für den weiteren Programmablauf benötigt werden. Die API definiert dabei, in welcher Form Daten vom Anwendungsmodul entgegengenommen und wieder zurückgegeben werden. Der eigentliche Programmablauf innerhalb des Moduls ist für die API unwichtig. Im Gegensatz zu einer Binärschnittstelle, kurz ABI, findet in der API die Programmanbindung rein auf der Quelltext-Ebene statt. Zur Bereitstellung einer API gehört meist eine ausführliche elektronische oder aber eine papiergebundene Dokumentation, in der die einzelnen Schnittstellenfunktionen, der genauen Syntax und die möglichen Parameter aufgeführt sind.     Grundsätzlich können Programmierschnittstellen in verschiedene Typen unterteilt werden: funktionsorientierte APIs, dateiorientierte APIs, objektorientierte APIs, protokollorientierte APIs und die RESTful-API-Schnittstelle. Funktionsorientierte APIs: Die funktionsorientierten Programmierschnittstellen reagieren nur auf Funktionen, wahlweise mit oder ohne Rückgabewert. Auf den Aufruf einer Funktion folgt die Ausgabe eines Referenzwertes (Handle). Dieser Wert dient zum Aufruf weiterer Funktionen, sind alle Funktionen verfügbar, wird das Handle geschlossen. Dateiorientierte APIs: Die dateiorientierten Programmierschnittstellen werden über die Befehle open, read, write und close angesprochen. Gesendete Daten werden mit write geschrieben, sollen Daten empfangen werden, sind diese mit dem read-Kommando einzulesen. Objektorientierte APIs: Die objektorientierten Programmierschnittstelle adressieren definierte Schnittstellen-Pointer, was diesem Schnittstellentyp gegenüber funktionsorientierten Schnittstellen eine erhöhte Flexibilität verleiht. Oft wird mit den Daten auch eine Typ- oder Klassen-Bibliothek übergeben. Protokollorientierte APIs: Die protokollorientierten Programmierschnittstellen befinden sich in keinerlei Abhängigkeit von Betriebssystem oder Hardware, allerdings ist das Übergabeprotokoll stets neu zu implementieren. Um diesen Vorgang zu erleichtern, werden protokollorientierte Schnittstellen im Regelfall von interface- oder funktionsorientierten Schnittstellen gekapselt. RESTful-API-Schnittstelle: Die RESTful-API-Schnittstelle stellt einen Sonderfall dar. Hierbei handelt es sich um eine Schnittstelle für Anfragen im HTTP-Format, der Datenzugriff erfolgt über GET-, PUT-, POST- und DELETE-Befehle. Programmierschnittstellen sind mittlerweile in vielen Bereichen unterschiedlichster Softwareanwendungen vorzufinden. Im Web-Umfeld kommen APIs häufig bei Online-Shops und Content-Management-Systemen zum Einsatz. Es können dadurch unterschiedliche Bezahldienstleister, Online-Marktplätze, Shop-Bewertungssysteme oder Versanddienstleister und weitere Services mit wenig Aufwand standardisiert an die verschiedenen Systeme angebunden werden. Beispielsweise existieren APIs zu Services wie: Wikipedia, Google Maps, Facebook, Twitter, PayPal, DHL etc. Bevor wir nun zum Ende unseres heutigen Podcasts kommen, möchte ich auf die Frage eingehen: Welche Vorteile ergeben sich nun durch die Verwendung von Programmierschnittstellen?   Einer der vielen Vorteile ist es, die Entwicklung von Software zu vereinfachen, indem komplizierte und zeitaufwendige Aufgaben automatisiert werden. Das bedeutet, dass bestimmte Aufgaben, die mehrere Stunden in Anspruch nehmen, nun in wenigen Sekunden durchgeführt werden können. Zudem sind die angebundenen Programme weniger fehleranfällig und leichter wartbar, da modulare Programmcodes verwendet werden. Arbeiten einzelne Funktionen fehlerhaft, müssen lediglich die betroffenen Module und die an der API übergebenen Daten genauer geprüft werden.   Ein weiterer Vorteil, dass sich aus einer sauber dokumentierten Programmierschnittstelle ergibt, ist die Möglichkeit der Auslagerung von Programmierarbeiten. Die Entwicklung einzelner Teilbereiche einer Software kann dank der Programmierschnittstelle mit geringem Aufwand an eine externe Softwareunternehmen oder freie Entwickler übertragen werden.   Zudem können Drittanbieter selbst Funktionen für das System entwickeln. Dadurch steigert sich die Attraktivität und Flexibilität des Gesamtprodukts und es ergeben sich klare Wettbewerbsvorteile. Allerdings gibt es neben den genannten Vorteilen auch Nachteile: Um andere Anwendungen, Festplatten oder Benutzeroberflächen individuell anbinden zu können, braucht man Programmierkenntnisse. Hat man also keinen Entwickler im Unternehmen, muss man jemanden extern beauftragen. Außerdem benötigt das Entwickeln einer Anbindung Zeit. Kontakt: Ingo Lücker, ingo.luecker@itleague.de

"Es kann zu beeinträchtigungen im Programmablauf kommen". Der SWR streikte am 18.09.2019 u.a. auch in Stuttgart. Ingesammt haben 500 Beschäftige die Arbeit nieder gelegt. Das Arbeitsweltradio-Podcast war dabei und hat die Rede von Martin Groß dokumentiert.

Aus aktuellem Anlass unterbrechen Timo und Denny den normalen Programmablauf von Spectral Radio und besprechen eingehend die nervenaufreibenden und zahlreichen News der vergangenen Woche. Mit dabei: Die neuen Playmobil Sets, Das Remaster des 2009er Video Games, Zuwachs bei GB2020 uuuund Bill Murray sagt endlich JA zu Ghostbusters 3!

Seit acht Stunden und fünfzehn Minuten sitzt ihr vor euren Smartphones und aktualisiert eure Podcatcher in der Hoffnung einer neuen Folge #REALLIFE. Wunschort: Smartphone, wa? Nun es haben sich Änderungen im Programmablauf aufgetan. An einem jeden Montag, im zwei Wochen Turnus zur besten Sendezeit wird #REALLIFE zukünftig erscheinen. Jawohl, die morgendliche Primetime ist die unsere +++ 8:15 Uhr +++. Ein Premiumformat verdient einen Premiumsendeplatz! Sonst ändert sich nicht viel. Es darf weiterhin auf dem Schulhof und in den Fünfminutenpausen über die aktuellsten Inhalte und neusten #REALLIFEHACKS von #REALLIFE gesprochen werden. Und wie man auf legalem Wege an alkoholische Produkte kommt, auch ohne das Mindestalter erreicht zu haben, erfahrt ihr in dieser Episode #REALLIFE - Folge 53 - Wunschort: IN MEINEN HÄNDEN! Wenn ihr keine Folge eures Lieblingspodcasts mehr verpassen wollt, könnt ihr #REALLIFE jetzt abonnieren. Liket die Facebook-Seite und folgt #REALLIFE auf Twitter und ihr verpasst garantiert keine Neuigkeiten mehr.

Zur GPN17 des Entropia e.V. im ZKM - Zentrum für Kunst und Medien und der Hochschule für Gestaltung (HfG) hat Florian Magin (@0x464d) einen Vortrag zu Automated Binary Analysis gehalten und war bereit uns auch im Podcast zu erzählen, wie er mit mathematischen Verfahren Software auf Schwachstellen analysiert. Florian studiert Informatik an der TU Darmstadt und engagiert sich im CTF-Team Wizards of Dos seiner Universität. Sein Interesse an der Computersicherheit hat ihn auch zur Firma ERNW Research geführt, wo er als Werkstudent in der IT-Sicherheitsforschung tätig ist. Wie wichtig die Suche nach Schwachstellen und deren Absicherung ist, wurde kürzlich bei der weltweiten Verbreitung der WannaCry/WannaCrypt-Schadsoftware bewusst, die die Aufmerksamkeit von einer anderen und lukrativeren Schadsoftware Adylkuzz ablenkte. Unter der Binary Analysis versteht man die quellenlose Analyse eines Programms alleine auf den Daten im Maschinencode auf einem Speichermedium. Ein erster Schritt der Analysis ist die Wandlung der Maschinensprache in Mnemonic durch einen Disassembler. Dieser Programmcode kann sich deutlich von einer ursprünglichen Quelltext des Programms unterscheiden, da der Maschinencode erzeugende Compiler eine Vielzahl von Optimierungsmöglichkeiten umsetzt, die den Ablauf und das Abbild des Programms im Maschinencode deutlich verändern können. Eine Herausforderung stellt sich inzwischen in der Größe der Programme: Während es inzwischen zahlreiche Wettbewerbe gibt, Programme unter extremen Platzbeschränkungen umzusetzen, wächst die Größe klassischer Programme stark an. Ein Maschinensprache-Befehl kann in einem Byte kodiert sein, wie früher etwa hexadezimal C9 auf dem Z80 eine Unterroutine beendet, so können in 4 Bytes Operationen wie eine Addition samt Parameter definiert sein. Die automatisierte Binäranalyse hat besonders durch die Darpa Cyber Grand Challenge im Jahr 2016 großes Interesse geweckt, wo die Teams autonome Software entwickeln sollten, die für sich alleine den CTF-Wettbewerb bestreitet. Eine Anwendung solcher automatisierten Programme ist die schnelle Überprüfung von neuer Software auf bekannte oder typische Schwachstellen oder Implementierungsfehler. Eine sehr allgemeine Methode zur Detektion von Sicherheitslücken ist das Fuzzing: Das Open Source Tool AFL modifiziert beispielsweise korrekte Eingabewerte und prüft bei welcher Modifikation das Programm vom zuvor aufgezeichneten Programmablauf abweicht und damit einen Hinweis auf eine mögliche Schwachstelle gibt. Es kann dabei idealerweise auf dem Sourcecode operieren oder auch das Programm in einem Emulator wie QEMU ausführen und analysieren. Wie schwer aber selbst Source Code zu verstehen sein kann, zeigen die Wettbewerbe International Obfuscated C Code Contest (IOCCC), zu möglichst schwer verständlichen sinnvollen Code, und der Underhanded C Contest, wo ein scheinbar sinnvoller Code für Menschen möglichst unvorhersehbare Zusatzfunktionen aufweist. Ebenso können sehr beliebte Programmiersprachen wie Python sehr unvorhersehbar reagieren, wenn man versehentlich Tabulatoren und Space vermischt, oder gleich die Programmiersprache Whitespace benutzt. Ein weiteres Beispiel ist, dass das Breitenlose Leerzeichen in neuen C++-Standards erlaubt ist, und für den Menschen ununterscheidbaren Code ermöglicht, der unterschiedliche Dinge tut. Aber auch Computer können getäuscht werden, wenn zum Vergleich unsichere Hash-Funktionen genutzt werden, wie jüngst die Shattered-Attacke auf die SHA-1 Hash zeigte. Eine automatisierte Analysemöglichkeit ist die Control Flow Graph Recovery, die beispielsweise mit IDA , radare2, binary ninja durchgeführt werden kann, um aus einer eindimensionalen Speicherdarstellung zu einem Programmnetz, wo zusammengehörige Programmblöcke miteinander vernetzt werden. Hier kann auch schon sichtbar werden, ob beschränkte Bereiche ohne Authentifikation erreicht werden können. Ein weiteres automatisierbares Verfahren ist die Datenflussanalyse, wo die Verarbeitung und Auswirkungen von Variablen und Daten im Verlauf des Programms analysiert wird. Hier kann der Verlauf von beispielsweise vertraulichen Daten kontrolliert werden. Bei einer Symbolischen Auswertung wird das Programm abstrakt mit einem Interpreter auf beliebigen variablen Daten bzw. symbolischen Ausdrücken auf allen Pfaden gleichzeitig ausgeführt. Für die Pfaderkundung benötigt man hier eine Strategie zwischen der Breitensuche und Tiefensuche, um die relevanten Teile des Ausführungsgraphen möglichst schnell abzudecken. In der automatisierten Analyse werden dabei offene Sprungmöglichkeiten zu nahezu beliebigen Adressen sehr interessant, da dies einen starken Indikator für einen Angriffsvektor liefern. Mit Return-oriented Programming kann man so bestehenden Code gezielt anspringen und für eigene Zwecke missbrauchen. Das Open-Source Framework Angr wurde von Forschern des Computer Security Lab at UC Santa Barbara entwickelt und belegte mit Shellphish auf der Darpa-Challenge den dritten Platz. Ein weiteres Open-Source Analyseframework ist Triton, welches man leicht in eigene Projekte einbinden kann. Sehr verbreitet ist auch das Framework S2E der École Polytechnique Fédérale de Lausanne. Ein weiterer Finalist der Cyber Grand Challenge ist das Team CodeJitsu von der University of California at Berkeley, Cyberhaven, and Syracuse. Die Binary Analysis Platform wurde vom Team um Professor David Brumley am Cylab der Carnegie Mellon University entwickelt. Funktionale Programmiersprachen wie OCAML oder Haskell haben für den Anwendungsfall der symbolischen Auswertung ganz besondere Vorteile. Ebenso werden Programmiersprachen auch auf ihre inherente Unsicherheit im Sinne der Language based security untersucht, sowie fertige Programme versucht auch auf ihre Korrektheit zu verifizieren. Ein Tool, das dies vereinfachen soll ist der Z3 Prover. Hier kommt die Suche nach Sicherheitslücke zur Mathematik: In der formalen Darstellung einer Routine kann das Verhalten als Abbildung aus symbolischen Variablen beschrieben werden, und die Suche nach einer Lösung führt auf die entsprechenden Logik oder Optimierungsverfahren. Literatur und weiterführende Informationen Florian Magin: Introduction to Automated Binary Analysis, Vortrag auf der GPN17, 2017. Program Analysis reading list D. Brumley: Analysis and Defense of Vulnerabilities in Binary Code, PhD thesis, School of Computer Science Carnegie Mellon University, 2008. Podcasts M. Musch: Steganographie, Gespräch mit S. Ritterbusch im Modellansatz Podcast, Folge 57, Fakultät für Mathematik, Karlsruher Institut für Technologie (KIT), 2015. J. Breitner: Incredible Proof Machine, Gespräch mit S. Ritterbusch im Modellansatz Podcast, Folge 78, Fakultät für Mathematik, Karlsruher Institut für Technologie (KIT), 2016. GPN17 Special Sibyllinische Neuigkeiten: GPN17, Folge 4 im Podcast des CCC Essen, 2017. M. Lösch: Smart Meter Gateway, Gespräch mit S. Ritterbusch im Modellansatz Podcast, Folge 135, Fakultät für Mathematik, Karlsruher Institut für Technologie (KIT), 2017. F. Magin: Automated Binary Analysis, Gespräch mit S. Ritterbusch im Modellansatz Podcast, Folge 137, Fakultät für Mathematik, Karlsruher Institut für Technologie (KIT), 2017.

In unserer neuen Reihe 'Coopers Kaffeesatz' stellt ein Mitglied unseres Teams eine These auf, welche von den übrigen Teilnehmern eifrig diskutiert wird. Als erstes liest Julian Miller in Coopers Kaffeesatz und prognostiziert, dass Scripted Reality bald zum alltäglichen Programmablauf des ZDF gehören wird. Sebastian Lätsch, Glenn Riedmeier und Jan Schlüter diskutieren nun gemeinsam mit Julian, wie realistisch diese Zukunftsvision ist. Was als große Blödelei um geeignete Formate mit wirren Plotideen beginnt, entwickelt sich bald zu einer Analyse, ob das öffentlich rechtliche Fernsehen bereits jetzt vor Trends der großen privaten Konkurrenz eingeknickt ist. Auf welche anderen Züge ist das ZDF bereits aufgesprungen und wo hat die ARD zuerst gescholtene Formate schließlich selbst adaptiert? Und kam es bereits in der langen Geschichte beider Fernsehanstalten zu einer dubiosen Vermischung von Fiktion und Realität? Ist vielleicht sogar das ZDF schuld am scripted Reality Boom in Deutschland? All das und einiges mehr in diesem Podsplit von Coopers Kaffee. Die Podsplits* sind vorproduzierte Kurzversionen unseres Podcasts, die in loser Reihenfolge erscheinen werden. Feedback zu dieser und den vorigen Ausgaben wird es im kommenden aktuellen Podcast geben. *Der Name 'Coopers Quickie' war uns viel zu albern. Lade die Folge hier direkt herunter