Das Buch an sich kenne ich nicht, allerdings sagt mir der Autor "Kofler" sehr viel.

Der hat das beste deutschsprache Standardwerk zu Linux geschrieben, und war - falls ich mich nicht täusche - an den Trainingsbüchern aus dem Rheinwerk-Verlag für die LPIC-Zertifizierung beteiligt.

Also wenn das DER "Kofler" ist, dann ist dein verlinktes Buch sicherlich ganz gut.

Allerdings gehört zum "Hacken" viel viel mehr, als ein Buch übers "Hacken" zu lesen. Betrachte das Buch hinter deinem Amazon-Link also bitte als "erweiterten Leitfaden" dessen, was du noch alles lernen musst.

Zu den meisten Unterkapiteln in diesem Buch, wirst du vermutlich ein ganzes weiteres Fachbuch lesen müssen.

Alleine Netzwerktechnik ist ein seeeehr großes Thema, bei dem ein Buch alleine kaum ausreichen wird. Wenn du wirklich verstehen willst, wie ein reverser SSH-Tunnel zur Umgehung von Firewalls funktioniert, reicht es nicht, ein paar Kommandozeilenparameter auswendig zu lernen.

Also ja, das Buch ist sicher gut, aber a) bin ich mir nicht sicher, ob es Anfängertauglich ist, und b) ist es - auch wenn es dick zu sein scheint - nur eine Art grober Einstieg. Danach hast du zumindest mal einen Überblick und weißt, in welche Richtung du noch mehr lernen musst.

Viel Spaß beim Lernen! :)

Vorweg: Ich spreche aus praktischer Erfahrung und es handelt sich nicht um ein "Was wäre wenn ... Szenario".

Ich habe in der Vergangenheit schon viele Lücken in Software und Webdiensten gefunden und früher auch immer gemeldet. Das mache ich aber nicht mehr.

Der Grund dafür ist, dass die meisten Chefs oder Admins gelinde gesagt einfach nur total inkompetent oder einfach bescheuert sind.

So etwas wie Dank erfährt man fast nie. In ca. 70% wird mit Anzeige gedroht und in ca. 10% bis 20% wird auch tatsächlich eine Anzeige gestellt.

Dieser völlig sinnlose Papierkram und die Rumrennerei, nur weil man helfen wollte und bestimmte Firmen einfach zu schlechte Entwickler und Administratoren anstellen ... nee, das mach ich nicht mehr.

Sollen von diesen Firmen ruhig die Kunden- und Geschäftsdaten entwendet werden, denn aus eigener Erfahrung weiß ich, dass es die meisten davon wirklich verdient haben.

Geld bekommt man sowieso nie, und die Frage danach wird schnell als Erpressung ausgelegt. Dankesschreiben vom Chef sind höchst selten.

Bei Bugbounties habe ich zwar recht viel Geld verdient, aber langfristig fühlt man sich dabei über den Tisch gezogen, wenn man sich die Schwarzmarktpreise anschaut und vergleicht.

Leider bin ich moralisch zu sehr gefestigt, um meine Entdeckungen an Kriminelle (dazu gehören auch Geheimdienste) zu verticken.

Von daher: Ich behalte es für mich, wenn ich über Lücken stolpere. Und je älter man wird und je mehr Erfahrungen man sammelt, über desto mehr Lücken stolpert man beim "rumspielen" ganz automatisch.

Aber die Art und Weise wie im Allgemeinen mit ehrlichen Findern von Sicherheitslücken umgegangen wird ist zum Mäuse melken. Die meisten Firmen fühlen sich bei so einer Meldung sofort angegriffen und schicken ihre Anwälte vor.

Sollen die von mir aus alle an ihren Sicherheeitslücken ersticken und den Imageschaden selbst tragen. Ich setze mich für diese Trottel nicht mehr in die Nesseln.

Das ist dann zwar schade für die paar wenigen vernünftigen Firmen, die damit super cool und dankbar umgehen, aber im Grunde steht man immer mit einem Bein im Gerichtssaal. Darauf habe ich überhaupt keine Lust mehr, auch wenn am Ende immer die Unschuld raus kommt, aber das schnallen Schlipsträger nicht, die nur Buzzwords wie "Cyber" aus den Medien kennen.

Bei Opensource-Software ist das etwas ganz anderes, aber auch hier gibt es schwarze Schafe, an die ich niemals Lücken melden würde. (Systemd, ImageMagick, z. B.)

Wenn du eine tolle Lücke gefunden hast, dann sei stolz drauf, aber lass dir gesagt sein, dass diese Ausnahme zur Regel werden wird, sobald du mehr lernst und erfahrener wirst. Irgendwann wirst du vor lauter gefundenen Lücken gar nichts anderes mehr machen können, wenn du die alle melden wollen würdest.

Auch GF hat übrigens offene Lücken ... die habe ich zwar schon vor über 3 Jahren gemeldet und die wurden damals als "nicht so schlimm" abgetan, aber offen sind sie immer noch. Aber wenn "die ganze Plattform lahmlegen" als "nicht so schlimm" interpretiert wird, ist das nicht mein Problem.

Fazit: Die Lücken anderer sind mir inzwischen total egal. Ganz besonders Webmüll und Closed-Source-Schrott. Melden tue ich nichts mehr ... ich ignoriere das einfach. :)

Das ist kein C.

Mal völlig vom Geschlecht abgesehen, steht es völlig außer Frage, dass die meisten Politiker für ihren Job ungeeignet sind. Das sind meistens alles Juristen, die ihren "Fachbereich" so häufig wechseln wie ihre Unterwäsche.

Die können gar nicht ausreichend kompetent sein. Zum Beispiel: Jeder Grundschulbiolehrer wäre für das Umweltministerium besser geeignet.

Hinzu kommt, dass Politiker nicht nur größtenteils völlig inkompetent sind, sondern sich auch viel zu oft partout weigern, auf Expertengremien zu hören. Wofür brauchen die eigentlich noch Berater?

Deshalb ist deine Frage leicht zu beantworten: Sowohl männliche, als auch weibliche Politiker sind i. d. R. gleichermaßen höchst inkompetent. :)

Das ist mit C und C++ überraschend schwierig, wenn es zuverlässig funktionieren soll und man muss sich sehr lange und sehr intensiv mit eingebetteten Systemen beschäftigt haben, um Dinge umschiffen zu können, die du nicht mal erahnen würdest.

Beispiel:

a = *ptr_a;
b = *ptr_b;

Danach enthält "a" den Wert, auf den "ptr_b" gezeigt hat, und "b" den Wert, auf den "ptr_a" gezeigt hat!

Das klingt erst mal unglaublich, ist aber recht häufig, wenn man Peripherie von ARM Prozessoren ansprechen will. Und die Art und Weise, wie man den Zugriff synchronisiert, ist nicht trivial!

Von daher solltest du nach Möglichkeit bei der Python-API bleiben, die intern alles für dich regelt. Denn alle anderen mir bekannten C und C++ Bibliotheken für Raspi GPIO synchronisieren nämlich ÜBERHAUPT NICHT, und berücksichtigen das Problem gar nicht erst.

Daran sieht man, dass die Entwickler nicht aus dem Bereich kommen, und sich auch nicht die ARM-Handbücher durchgelesen haben.

Fazit: Falls du wirklich fit im embedded-Bereich bist, bau dir selber eine Lösung, weil es faktisch nur verbuggte C/C++ Bibliotheken für die GPIO gibt, die zwar meisten funktionieren, aber in seltenen Fällen extrem schwer nachvollziehbare Fehler verursachen. (Stichwort Heisenbug!)

Ansonsten bleib bei der Python-API, auch wenn die viele hundert mal langsamer ist, als der direkte Zugriff via mmap() ... denn die dort eingebauten Schutzmechanismen sind wichtiger als eine hohe Geschwindigkeit!

Also dann ... vergiss C und C++, falls du sicheren Code haben willst! ;)

Also genau genommen lernt man eigentlich ganz normal eine Hand voll Programmiersprachen, beschäftigt sich je nach Interesse mit Netzwerktechnik, Betriebssystem- und Rechnerarchitektur, und dann kommt das irgendwann fast von alleine.

Wenn man dann irgendwann mal bei den Themen Assembler und insbes. Reversing angekommen ist, übt man mit sog. "Crackmes" und lernt dabei recht praktisch Schutzmechanismen von Software zu umgehen.

Im Netzwerkbereich stolpert man früher oder später über OWASP und der Rest ist eigentlich nur lesen, lesen und nochmal lesen.

Eigentlich nur verdammt viel lesen und lernen. :)

Also mit herkömmlichem C++ würde man das so machen:

#include <iostream> // cout, endl

#include <cstdlib> // size_t

int main() {
  using namespace ::std;

  using array_type = int;
  constexpr size_t array_size { 20ul };

  array_type arr[array_size] {};

  constexpr array_type start { 10 };
  for (size_t i {}; i < array_size; ++i) {
    arr[i] = static_cast<array_type>(start + i);
  }

  for (const auto elem : arr) {
    cout << elem << endl;
  }
}

Die Initialisierungsschleife kannst du auch völlig anders gestalten:

array_type i { 10 };
for (auto & ref : arr) {
  ref = static_cast<array_type>(i++);
}

So, das wäre so die Art, wie man es mit C++ machen würde.

Aber da die meisten Lehrer unter C++ eigentlich nur mehr oder weniger "ANSI C mit ein paar Zusätzen" verstehen, wird dein Lehrer vermutlich eher so etwas sehen wollen:

#include <iostream> // cout, endl

#include <cstdlib> // size_t

int main() {
  using namespace ::std;

  int arr[20] = { 0 };

  for (size_t i = 0; i < 20; ++i) {
    arr[i] = 10 + i;
    cout << arr[i] << endl;
  }

  return 0;
}

Das ist aber, wie gesagt, kaum C++, sondern tendiert eher in Richtung C. Aber vermutlich wird dein Lehrer damit zufrieden sein. :)

Falls der Fokus aus "modernem C++" (11/14/17) wie in SelfEnergys Antwort liegt, geht das nochmal deutlich eleganter:

// g++ -std=c++17 -Wall -Wextra -Wpedantic -Werror foo.cpp && ./a.out

#include <algorithm> // copy
#include <array> // array
#include <iostream> // cout
#include <iterator> // ostream_iterator
#include <numeric> // iota

#include <cstdlib> // size_t

int main() {
  using namespace ::std;

  using array_type = int;
  constexpr size_t array_size { 20ul };

  array<array_type, array_size> arr {};
  iota(arr.begin(), arr.end(), 10);

  using oit = ostream_iterator<array_type>;
  copy(arr.begin(), arr.end(), oit { cout, "\n" });
}

Bei diesem Code entfällt das unnötige aufdröseln des ::std-Scopes ins Globale, es wird konsequent die universelle Initialisierung seit C++11 genutzt, und da ::std::array eine Art POD ist, wird auf nicht initialisierten Speicher des unterliegenden Arrays geachtet.

Ab C++20 geht das sogar noch viel kürzer und größtenteils zur Kompilierzeit (ca. die Hälte des obigen Codes), aber das wird jetzt zu viel.

Ansonsten will dein Lehrer vermutlich nur eine simple Schleife sehen, mit der über ein herkömmliches Array iteriert wird ... und das packst du sicher auch ohne weitere Antworten hier auf GF. ;)