Anmelden
(Bild: Desintegrator/Shutterstock.com)
Alle Welt redet darüber, wie gefährlich Anthropics neue KI sein könnte. Jürgen Schmidt von heise security konzentriert sich lieber darauf, was jetzt zu tun ist.
Anthropics Mythos und die Kommentare und Analysen rund um diese (Nicht-)Veröffentlichung dominieren das Security-Geschehen – und das zu Recht: Wir befinden uns aktuell mitten in einer Singularität, wie sie die IT-Security in den vergangenen 10 Jahren nicht gesehen hat. Allerdings produziert das auch Hype, der von den eigentlich wichtigen Dingen ablenkt. Nicht zuletzt deshalb, weil Anthropic sich entschieden hat, das Ganze vor allem als PR-Booster der eigenen Interessen zu nutzen. Deshalb möchte ich einen Schritt zurücktreten und nüchtern analysieren, was tatsächlich das Problem ist, mit dem wir uns konfrontiert sehen – und was daraus für die jetzt nötigen Schritte folgt.
Zunächst: Das Problem ist nicht Anthropics Mythos [1]. Auch andere LLMs hätten die von Mythos aufgedeckten Sicherheitslücken finden können; der aktuelle Vorsprung von Anthropic ist angesichts der sich abzeichnenden Entwicklung nicht relevant. Es ist auch nicht so, dass Angreifer jetzt plötzlich neue, nie dagewesene Fähigkeiten hätten, denen wir machtlos gegenüberstehen. Unser Problem ist Folgendes: LLMs haben jetzt die Fähigkeit, selbstständig echte Sicherheitslücken in Software zu finden. Sie können diese aber (noch?) nicht selbst beseitigen – und auch wenn sie das könnten, wären diese Fixes noch lange nicht beim Nutzer angekommen. Sprich: Das Finden und Ausnutzen von Sicherheitslücken lässt sich vollständig automatisieren und in industriellem Maßstab hochskalieren. Das Fixen dieser Lücken hingegen erfordert immer noch viel menschliche Beteiligung und wird deshalb auf absehbare Zeit deutlich langsamer erfolgen.
Und das alles wird rasant noch sehr viel schlimmer werden. Die existierenden Bug-Fixing-Kapazitäten werden bereits jetzt in die Sättigung getrieben, während die Fähigkeit, neue Bugs zu finden, auf absehbare Zeit weiter steigen wird. Denn die befindet sich aktuell noch in einer sehr frühen Phase. Daraus folgt unmittelbar, dass uns eine Zeit bevorsteht, in der KIs sehr viel mehr Bugs finden, als gefixt werden können. Jedes System, das für Angreifer erreichbar ist, wird angreifbar sein, es wird angegriffen werden und es wird zu einer lange nicht dagewesenen Zahl von Sicherheitsvorfällen kommen. Wie lange diese Phase andauern wird und was danach kommt, werde ich später noch diskutieren. Wichtig ist jetzt erst mal, was sich bereits daraus ableiten lässt. Das Allerwichtigste:
Die Situation ist akut und jede:r, der/die für die Sicherheit von IT verantwortlich ist, sollte unmittelbar handeln und sich darauf vorbereiten.
Das lässt sich nicht mehr wegdiskutieren und „erstmal abwarten“ führt zu absehbaren Katastrophen. Die jetzt dringend erforderlichen Maßnahmen fallen in folgende Bereiche:
Ja, genau – das ist nichts Neues. All das hätte man bereits vor sechs Monaten genau so empfehlen können – und tatsächlich habe ich das sogar. Das kommt unter anderem daher, dass die KIs bislang keine neuartigen Schwachstellen aufdecken. Ob das so bleiben wird, ist eine andere, spannende Frage, die ich mir für später aufhebe. Doch alles, was Mythos & Co derzeit finden, hätte vor sechs Monaten auch ein Mensch aufspüren können. Nur war eben die Wahrscheinlichkeit für jeden einzelnen Fund so gering, dass wir uns da an vielen Stellen auch mit faulen Kompromissen irgendwie durchmogeln konnten. In diesem Bewusstsein haben wir über viele Jahre eine große Menge an Security-Schulden angehäuft. Und die werden jetzt fällig. Also in den nächsten sechs bis zwölf Monaten – um da mal eine konkrete Zahl in den Raum zu stellen. Und die werden ganz bitter.
Deshalb ist es jetzt allerhöchste Zeit, sich darauf vorzubereiten. Also die oben aufgeführten Maßnahmen unter diesem Gesichtspunkt neu zu evaluieren und mit hoher Priorität auf die Agenda der nächsten Monate zu setzen. Da kann der Hype rund um Mythos sogar helfen. Selbst die Geschäftsführung hat vielleicht vom aufziehenden AI Vulnerability Storm [2] und der Notwendigkeit gehört, sich auf Mythos vorzubereiten. Das liefert Anknüpfungspunkte, eigene Vorschläge zur Neubewertung der IT-Sicherheit zu unterbreiten.
Die werden fast schon zwangsläufig auch die Nutzung von KI einfordern, weil man nur mit deren Unterstützung die notwendige Geschwindigkeit bei der Umsetzung und bei der Abarbeitung der neuen Prozesse hinbekommen kann. Doch vieles geht auch ganz oder weitgehend ohne KI. Und das ist deshalb nicht weniger wichtig – im Gegenteil. Denn wie man etwa KI möglichst robust in den Update-/Patch-Zyklus einbaut, ist noch längst nicht wirklich klar. Wir können aktuell nur hoffen, dass die IT-Security-Industrie gemeinsam mit den KI-Firmen und Software-Entwicklern praktikable Lösungen findet und bereitstellt. Da kommen Anthropics Glasswing [3], OpenAIs Aardvark [4] und unzählige innovative Projekte von KI-Startups wie AISLE [5] und ZeroPath [6] ins Spiel.
Doch noch wichtiger sind jetzt die klassischen Security-Basics, die wir viel zu lange vernachlässigt haben. Für Maßnahmen wie Segmentierung, Least Privilege, MFA oder auch Monitoring mit Deception und so weiter gibt es nämlich bereits bewährte Konzepte und Leitfäden. Deshalb würde ich solche soliden Security-Grundlagen sogar höher priorisieren und kurzfristiger umsetzen als zukunftsweisende, wirklich KI-getriebene Prozesse.
Trotz all der Kassandra-Rufe sehe ich die Rolle von KI in der IT-Sicherheit langfristig eher positiv. Denn es ist ja nicht so, dass wir da aktuell ein gut funktionierendes Gesamtkonzept hätten – ganz im Gegenteil. Das knirscht und versagt bereits seit Jahren an allen Ecken und Enden. Langfristig habe ich die Hoffnung, dass wir einen Zustand erreichen, in dem Verteidiger mehr von den Fähigkeiten der LLMs profitieren als die Angreifer. Denn das Fixen von Bugs skaliert letztlich besser als das Ausnutzen mit Real-World-Exploits. Und damit wird es realistisch, dass Software und die darauf aufbauende IT weitgehend sicher und resilient wird. Doch da reden wir von einem Zeithorizont von mehreren Jahren – und einem langen Weg, mit vielen Unbekannten und zahlreichen Möglichkeiten, völlig falsch abzubiegen. Sprich: „Die Lage ist hoffnungslos, aber nicht ernst.“
Diese Analyse schrieb Jürgen Schmidt ursprünglich für den exklusiven Newsletter von heise security PRO [7], wo er jede Woche das Geschehen in der IT-Security-Welt für Sicherheitsverantwortliche in Unternehmen einordnet:
URL dieses Artikels:
https://www.heise.de/-11260797
Links in diesem Artikel:
[1] https://www.heise.de/news/Anthropics-neues-KI-Modell-Mythos-Zu-gefaehrlich-fuer-die-Oeffentlichkeit-11248034.html
[2] https://labs.cloudsecurityalliance.org/research/ai-vulnerability-storm-mythos-ready-security-program/
[3] https://www.anthropic.com/glasswing
[4] https://openai.com/index/introducing-aardvark/
[5] https://aisle.com/platform
[6] https://zeropath.com/
[7] https://pro.heise.de/security/
[8] https://pro.heise.de/security/?LPID=39555_HS1L0001_27416_999_0&wt_mc=disp.fd.security-pro.security_pro24.disp.disp.disp
[9] mailto:ju@heise.de
Copyright © 2026 Heise Medien
(Bild: heise online / dmk)
Die Updates für Windows Server im April haben Nebenwirkungen. Server starten unerwartet neu oder erlauben keine Admin-Anmeldungen.
Die Windows-Sicherheitsupdates insbesondere für Server aus dem April [1] haben teils schwerwiegende Nebenwirkungen. Einige Windows-Server starten unerwartet neu. Außerdem gibt es Hinweise, dass Domain-Admin-Logins unter Umständen gestört sein könnten. Ein Problem mit unerwarteten Migrationen zu Server 2025 hat Microsoft hingegen gelöst.
Microsoft [2] räumt im Message Center der Windows-Release-Health-Notizen einige der Probleme ein. Nach der Installation des Sicherheitsupdates KB5082063 können [3] „non-Global Catalog“ Domänen-Controller in Umgebungen mit privilegierter Zugangsverwaltung (Privileged Access Management, PAM) Abstürze des LSASS-Dienstes erleiden. In der Folge starten die Server wiederholt neu, wodurch Authentifizierung und Directory-Services nicht laufen – die Domäne ist dann nicht verfügbar. Betroffen sind alle Windows-Server ab Version 2016. Ein Gegenmittel rückt der Microsoft-Business-Support nur auf Anfrage raus. Die Entwickler arbeiten jedoch an einem automatischen Update, um das zu korrigieren.
Uns erreichte ein Leserhinweis, demzufolge es nach den April-Sicherheitsupdates möglicherweise Probleme mit der Anmeldung als Domain-Admin gibt. Laut Fehlermeldung sei das Passwort falsch. Das trat auf mehreren Windows Server 2025 DCE auf. Ein Passwort-Reset mittels der „utilman.exe“-Methode hilft in der Situation. Dahinter verbirgt sich das Umbenennen der „utilman.exe“ aus dem Systemverzeichnis und das Umkopieren von „cmd.exe“ in „utilman.exe“ von einer Boot-DVD aus. Nach dem Systemneustart führt der Aufruf der Optionen zur erleichterten Bedienung dadurch zum Öffnen einer Eingabeaufforderung, an der sich mittels net user <username> <neues passwort> das Passwort ändern und anschließend nutzen lässt.
Es gibt aber auch gute Nachrichten. Microsoft hat die optionalen Upgrades auf Windows Server 2025 wieder scharfgeschaltet. Im November 2024 hatte das Unternehmen das Angebot gestoppt, da dadurch unerwartet und ungeplant einige Server selbständig [4] auf Windows Server 2025 migriert haben. Das betraf insbesondere Umgebungen, die die Softwareverwaltung mit Tools von nicht genannten Drittanbietern verwalten. Laut Eintrag im Message-Center [5] konnten die Entwickler das Problem jetzt aber lösen, Windows Server 2025 steht nun wieder als optionales Update zur Verfügung.
URL dieses Artikels:
https://www.heise.de/-11261652
Links in diesem Artikel:
[1] https://www.heise.de/news/Patchday-Angreifer-attackieren-Edge-und-Microsoft-SharePoint-Server-11257867.html
[2] https://www.heise.de/thema/Microsoft
[3] https://learn.microsoft.com/en-us/windows/release-health/status-windows-server-2025#4833msgdesc
[4] https://www.heise.de/news/Microsoft-Windows-Server-automatisch-auf-Version-2025-aktualisiert-10014288.html
[5] https://learn.microsoft.com/en-us/windows/release-health/status-windows-server-2025#3404msgdesc
[6] https://pro.heise.de/security/?LPID=39555_HS1L0001_27416_999_0&wt_mc=disp.fd.security-pro.security_pro24.disp.disp.disp
[7] mailto:dmk@heise.de
Copyright © 2026 Heise Medien
(Bild: solarseven/Shutterstock.com)
Derzeit nutzen Angreifer eine kritische Sicherheitslücke in nginx-ui aus. Davon sind auch Instanzen in Deutschland bedroht.
Sicherheitsforscher warnen vor weltweiten Attacken auf Nginx-Webserver. Dabei erlangen Angreifer die volle Kontrolle über Server. Ein Sicherheitspatch ist seit März dieses Jahres verfügbar, aber offensichtlich noch nicht flächendeckend installiert.
Auch hierzulande sind den Forschern zufolge noch verwundbare Server öffentlich über das Internet erreichbar. In welchem Umfang die Attacken ablaufen, ist aber derzeit unklar.
Die „kritische“ Schwachstelle (CVE-2026-33032) betrifft einer Warnmeldung zufolge [1] nginx-ui MCP (Model Context Protocol). Weil über /mcp_message erreichbare HTTP-Endpoints ohne Authentifizierung ansprechbar sind, können entfernte Angreifer mit präparierten HTTP-Anfragen an der Schwachstelle ansetzen. Im Anschluss können sie unter anderem Konfigurationen ändern und so die volle Kontrolle über Instanzen erlangen.
Vor den Attacken warnen unter anderem Sicherheitsforscher von Pluto in einem Bericht [2]. Darin zeigen sie ausführlich, wie Attacken ablaufen und wie sich das Sicherheitsproblem zusammensetzt. Zusätzlich geben sie an, dass sie über die Suchmaschine Shodan weltweit auf fast 2700 verwundbare, über das Internet erreichbare Instanzen gestoßen sind. Der Großteil davon ist in China und den USA. In Deutschland sind es dem Scan zufolge 235 Instanzen.
Die dagegen abgesicherte nginx-ui-Version v.2.3.4 steht seit Mitte März dieses Jahres zum Download [3]. Aktuell ist die Ausgabe v.2.3.6. Serveradmins sollten umgehend reagieren. Wer den Sicherheitspatch nicht sofort installieren kann, sollte für einen temporären Schutz MCP deaktivieren.
Im Beitrag der Sicherheitsforscher finden Admins Hinweise [4], woran sie bereits erfolgreich attackierte Systeme erkennen können.
URL dieses Artikels:
https://www.heise.de/-11261670
Links in diesem Artikel:
[1] https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-h6c2-x2m2-mwhf
[2] https://pluto.security/blog/mcp-bug-nginx-security-vulnerability-cvss-9-8/
[3] https://github.com/0xJacky/nginx-ui/releases/tag/v2.3.4
[4] https://pluto.security/blog/mcp-bug-nginx-security-vulnerability-cvss-9-8/
[5] https://pro.heise.de/security/?LPID=39555_HS1L0001_27416_999_0&wt_mc=disp.fd.security-pro.security_pro24.disp.disp.disp
[6] mailto:des@heise.de
Copyright © 2026 Heise Medien
(Bild: Pincasso / Shutterstock.com)
Ein Upgrade einer File-based App zu einem normalen C#-Projekt ist möglich.
Das direkte Übersetzen und Starten von C#-Dateien nennt Microsoft File-based Apps [1]. Wenn die Anforderungen höher werden, sind File-based Apps keine Sackgasse.
Entwicklerinnen und Entwickler können per Kommandozeilenbefehl aus einer File-based App ein C#-Projekt mit .csproj-Projektdatei machen:
dotnet project convert .\Dateiname.cs
Dabei wird ein neuer Ordner angelegt und eine Projektdatei angelegt, die die Präprozessor-Informationen aus der C#-Datei übernimmt.
Sollten die Dateien Dateiname.settings.json und Dateiname.run.json vorhanden sein, werden sie beim Konvertieren allerdings ignoriert.
URL dieses Artikels:
https://www.heise.de/-11257899
Links in diesem Artikel:
[1] https://www.heise.de/blog/Neu-in-NET-10-0-13-Kompilieren-und-Starten-einzelner-C-Dateien-11201372.html
[2] mailto:rme@ix.de
Copyright © 2026 Heise Medien
(Bild: SWstock / Shutterstock.com)
Die Foreign Function & Memory API bietet in Java einen deutlich einfacheren Zugang zu Funktionen in C-Libraries als das veraltete JNI.
Javas Foreign Function & Memory API (FFM) dient dazu, auf Code in einer Shared Library beziehungsweise DLL zuzugreifen, der in einer Programmiersprache wie C oder Rust geschrieben ist. Allerdings muss der Code dazu einige Voraussetzungen erfüllen. Diese dreiteilige Artikelserie zeigt anhand einer in C geschriebenen Demo-Library, wie eine Java-Anwendung die Funktionen der Bibliothek aufruft, welche Vorbereitungen erforderlich sind und welche Regeln zu beachten sind. Der Sammelbegriff „Shared Library“ steht in den Artikeln gleichermaßen für eine Shared Library unter Unix wie für eine Windows-DLL.
Der Ausgangspunkt der Arbeit mit FFM war meine Suche nach einem Weg, per Java auf ein Hardware-Sicherheitsmodul (HSM) zuzugreifen. Da aber noch kein physisches HSM vorhanden war, suchte ich nach einer softwaregestützten Umsetzung. Die Applikation SoftHSM2 lässt sich mit PKCS11 ansprechen, aber der Pkcs#11-Treiber von Sun ist veraltet. Da ich keine passende Open-Source-Anwendung gefunden habe, entwickelte ich selbst einen PKCS11-Wrapper für Java auf Basis der FFM-API.
Da das Projekt sehr umfangreich ist, steht für diese dreiteilige Artikelserie eine eigens entwickelte C-Library im Fokus, die dazu dient, die Konzepte der FFM-API zu erläutern. Die kleine Demo-Library [1] ist auf Windows und Linux getestet.
In Java gab es vor dem FFM mit dem Java Native Interface (JNI) seit Langem einen Weg, um auf in C geschriebenen Code zuzugreifen. Das JNI war allerdings sehr kompliziert und fehlerbehaftet.
Daher begannen im JDK 14 (Java Development Kit) die Arbeiten an einer neuen Schnittstelle: Foreign Function & Memory API [2]. Die Java-Community hat sie über einige JDK-Versionen und JEPs hinweg verfeinert und schließlich in JDK 22 finalisiert. Allerdings erschien sie im JDK 24 [3] nochmals in veränderter Form. Wegen einiger Breaking Changes ist die API aus Java 24 nicht zu der in Java 22 kompatibel. Dieser Artikel beschreibt die aktuelle Version aus dem JDK 24.
Um die FFM-API zu nutzen, gelten folgende Voraussetzungen:
Der Ausgangspunkt für FFM ist immer eine Header-Datei, die in C die Funktionen und gegebenenfalls Typen der Shared Library beschreibt.
Die in C entwickelte Beispiel-Library enthält nur wenige Funktionen und einen Datentyp:
FreshRSS #ifdef _WIN32
#define EXPORT __declspec(dllexport)
#else
#define EXPORT
#endif
typedef struct
{
double x;
double y;
} Point;
#define VERSION 1
EXPORT void initialize(void);
EXPORT int getVersion(void);
EXPORT void getVersion2(int *version);
EXPORT long add(long a, long b);
EXPORT double calcAverage(int *lvalues, int size);
EXPORT double distance(Point *p1, Point *p2);
Es gibt nur eine einzige Typdefinition (Point) und wenige Funktionen. Die Direktive #ifdef im Header-File sorgt dafür, dass sich der Code sowohl unter Linux als auch unter Windows kompilieren lässt.
Das Tool jextract [4] hilft beim Zugriff auf native Funktionen. Ausgangspunkt ist auch hier wieder eine Header-Datei, um die notwendigen Zugriffsmethoden für die Funktionen aus der Shared Library zu erzeugen.
jextract kämpft jedoch mit diversen Schwierigkeiten. Zunächst ist es nicht für jedes JDK verfügbar – nach JDK 22 erst wieder für JDK 25. Für die Demo-Library zum Artikel hat die Version aus JDK 22 zwei Klassen generiert: Point für den Zugriff auf die Datenstruktur und DemoLib_h, um auf die Funktionen zuzugreifen. Die Klasse Point hat einen Umfang von etwa 170 schlecht leserlichen Codezeilen, und die Klasse DemoLib_h hat weitere 390 Zeilen Code, die ebenfalls schwer lesbar sind.
Bei komplexen Header-Files ist der Einsatz von jextract noch schwieriger. Beim Versuch, einen Wrapper für PKCS11 zu erzeugen, brach jextract im Zusammenspiel mit dem JDK 22 ab. Die Header-Datei pkcs11.h lädt zwei weitere Header-Dateien nach. Das führte zum Abbruch mit Fehlermeldungen, dass inkompatible Typ-Redefinitionen vorhanden seien.
jextract ist derzeit nur für kleine Projekte einsatzbereit – und auch das mit Einschränkungen. Aufgrund des schwer lesbaren Codes ist es keine Vorlage für eigenen Code. Daher ist der deutlich bessere Ansatz, den Code selbst zu entwickeln und das entsprechende Know-how aufzubauen, um den Code zu verstehen.
Die Vorgehensweise ist ähnlich wie beim Einsatz von Reflection in Java. Um Funktionen aufzurufen, muss man ein MethodHandle erzeugen, das die Klasse Linker benötigt. Zusätzlich muss man die Shared Library laden.
Folgendes Listing zeigt die Vorbereitungen in der Klasse Main und den Aufruf der Demolib:
public class Main
{
private final Linker linker;
private final SymbolLookup lookup;
private final Path libPath;
private String pathWindows = "D:/DemoLib/DemoLib.dll";
private String pathLinux = "/opt/projects/c/DemoLib/DemoLib.so";
public Main()
{
linker = Linker.nativeLinker();
libPath = getLibPath();
lookup = SymbolLookup.libraryLookup(libPath, Arena.ofAuto());
}
public static void main(String[] args) throws Throwable
{
Main app = new Main();
app.runDemo();
}
public void runDemo()
{
int version;
try
{
initialize();
version = getVersion();
System.out.println("Version (1) DemoLib = " + version);
version = getVersion2();
System.out.println("Version (2) DemoLib = " + version);
int a = 7;
int b = 9;
int result = add(a, b);
System.out.println(a + " + " + b + " = " + result);
double average = calcAverage(new int[] {1, 2, 3, 4, 5});
System.out.println("Average : " + average);
Point p1 = new Point(1, 1);
Point p2 = new Point(3, 3);
double distanz = distance(p1, p2);
System.out.println("Distanz zwischen Punkt " + p1 + " und " + p2 + " : " +
distanz);
}
catch (Throwable e)
{
e.printStackTrace();
}
}
}
Die Methode libraryLookup() der Klasse SymbolLookup lädt die Shared Library. Mit SymbolLookup lassen sich anschließend die einzelnen Funktionen der Library bereitstellen.
Zum Laden der Library ist neben dem Pfad auch eine Arena erforderlich. Eine Arena ist analog zur Garbage Collection ein Memory Manager für fremden Speicher, den die Java Virtual Machine (JVM) nicht verwaltet. Es gibt mehrere Arten von Arenas:
| Arena-Methode | Lebensdauer | Typische Verwendung |
| Arena.ofConfined() | Der Speicher lässt sich nur im aktuellen Thread nutzen und wird beim Aufruf von close() freigegeben, beispielsweise bei try-with-resources. | Standardfall |
| Arena.ofAuto() | Der Speicher wird vom Garbage Collector freigegeben, wenn das Arena-Objekt nicht mehr erreichbar ist. | Wenn im Vorfeld nicht bekannt ist, wann der Speicher freigegeben werden soll und deshalb keine manuelle Freigabe möglich ist. Beispiel: SymbolLookup beim Laden der Library. |
| Arena.ofShared() | Der Speicher kann von mehreren Threads genutzt werden und muss manuell geschlossen werden. | Wenn mehrere Threads auf denselben nativen Speicher zugreifen müssen. |
| Arena.ofGlobal() | Der allokierte Speicher wird nie freigegeben und lebt bis zum Prozessende. | Für alle dauerhaften Daten |
| Arena.ofScope() | Ermöglicht benutzerdefinierten Scope. Die Freigabe des Speichers erfolgt, wenn der Scope endet. | Spezialfall, wenn eine komplexe Lebenszyklus-Steuerung erforderlich ist. |
Das Aufrufen von externen Funktionen erfordert folgende Schritte:
lookup.find() nach der gewünschten Funktion. Die Suche nach einer nicht vorhandenen Funktion löst eine NoSuchElementException aus.lookup.find() ein passendes MemorySegment zurück: eine Referenz, mit der man auf das Native Memory zugreifen kann.downcallHandle des Linkers erzeugt aus dem MemorySegment und einem FunctionDescriptor einen MethodHandle.FunctionDescriptor dient dazu, die Signatur der Funktion (Rückgabewert, Parameter) zu beschreiben.WrongMethodTypeException aus.MethodHandle kann die Java-Anwendung mit der Methode invoke die gewünschte Funktion mit den passenden Parametern aufrufen.Als Erstes soll die Beispielanwendung die einfachste Funktion der Library aufrufen: initialize hat weder einen Rückgabewert noch Parameter. Die Java-Methode in der Main-Klasse, die die Library-Funktion aufruft, heißt ebenfalls initialize():
public void initialize() throws Throwable
{
MethodHandle initialize =
linker.downcallHandle(lookup.find("initialize").orElseThrow(),
FunctionDescriptor.ofVoid());
initialize.invoke();
}
Die Systematik ist bei jedem Funktionsaufruf identisch und erfordert lediglich eine Anpassung der Namen und Signaturen. invoke() ruft die externe Funktion auf. Falls die Funktion einen Rückgabewert hat, muss die aufrufende Java-Methode ihn auf den richtigen Typ casten.
Da die Vorgehensweise immer dieselbe ist, lohnt sich eine kleine Helper-Methode, die den MethodHandle holt:
public MethodHandle getMethodHandle(String methodName,
FunctionDescriptor funcDescriptor) throws Throwable
{
MethodHandle method =
linker.downcallHandle(lookup.find(methodName).orElseThrow(),
funcDescriptor);
return method;
}
Dadurch vereinfacht sich die Methode initialize() zu
public void initialize() throws Throwable
{
MethodHandle method = getMethodHandle("initialize",
FunctionDescriptor.ofVoid());
return method.invoke();
}
Eine weitere Möglichkeit zur Vereinfachung wäre, in einer Methode invokeFunction das Throwable zu fangen und stattdessen eine eigene RuntimeException auszulösen. Dadurch muss nicht jeder Aufrufer das generische Throwable abfangen und behandeln.
Etwas komplizierter wird es, wenn man Funktionen aufrufen will, die Parameter benötigen, oder wenn die Anwendung die Rückgabewerte der Library-Funktion auswerten muss. Das nächste Beispiel zeigt anhand der Funktion getVersion(), wie sich zurückgegebene Werte auswerten lassen.
Dafür ist ein FunctionDescriptor erforderlich, der einen int-Wert zurückgibt:
public int getVersion() throws Throwable
{
MethodHandle method = getMethodHandle("getVersion",
FunctionDescriptor.of(ValueLayout.JAVA_INT));
return (int) method.invoke();
}invoke() ruft wieder die externe Funktion auf und erfordert diesmal einen Cast auf den korrekten Rückgabewert int.
Die Methode FunctionDescriptor.of() nimmt einen oder mehrere Parameter entgegen, die den Rückgabewert und die Parameter beschreiben. Der Rückgabewert steht dabei immer an der ersten Stelle. Im Beispiel hat die Funktion getVersion keine Parameter, sodass der FunctionDescriptor folgendermaßen lautet:
FunctionDescriptor.of(ValueLayout.JAVA_INT)
Das Interface ValueLayout beschreibt die Java-Datentypen, die den C-Datentypen entsprechen: ValueLayout.JAVA_INT ist das Pendant zum Datentyp int in C.
Die Entwicklerinnen und Entwickler sind selbst dafür verantwortlich, die korrekten Mappings für die Datentypen auszuwählen. Der Compiler hilft dabei nur wenig. Im obigen Beispiel würde er nur dann einen Fehler melden, wenn der Typecast und der Rückgabewert der Java-Methode getVersion() nicht zusammenpassen. Würde man dagegen fälschlicherweise einen long-Wert verwenden (FunctionDescriptor.of(ValueLayout.JAVA_LONG)), gäbe es keine Fehler beim Kompilieren, sondern eventuell eine ClassCastException zur Laufzeit.
Wenn in der Anwendung alle Werte als long gekennzeichnet sind, könnte die Exception jedoch ausbleiben und das Ergebnis je nach Plattform unterschiedlich und eventuell nicht korrekt sein.
Anhand der Funktion add zeigt der Artikel im Folgenden den Aufruf von Funktionen mit Parametern. add hat long als Rückgabewert und zwei long-Werte als Parameter. Zu beachten ist, dass es sich um long-Werte aus C handelt, die nicht unbedingt identisch mit den Datentypen in Java sind.
In C ist die Größe des Datentyps von der Plattform abhängig: In Windows hat ein long-Wert 4 Bytes, in Linux dagegen 8 Bytes. Das verursacht in der Regel keine Probleme, wenn es sich um Parameter handelt, die der Aufrufer als Wert übergibt (Call by Value). Wenn die C-Funktion die übergebenen Werte allerdings verändert, muss der Aufrufer die Adresse übergeben (Call by Reference). In dem Fall muss der Typ der übergebenen Variable unbedingt zur Angabe im FunctionDescriptor passen.
Das folgende Beispiel betrachtet zunächst die einfache Variante mit Call by Value:
public int add(int a, int b) throws Throwable
{
MethodHandle method = getMethodHandle("add", FunctionDescriptor.of(
ValueLayout.JAVA_INT, // return value
ValueLayout.JAVA_INT, // a
ValueLayout.JAVA_INT // b
));
return (int) method.invoke(a, b);
}
Auch wenn der FunctionDescriptor komplexer ist als die Deskriptoren ohne Parameter, ist er leicht zu verstehen: Der erste Parameter beschreibt wieder den Rückgabewert und die anderen beiden die Parameter der Funktion add(). Es handelt sich also um eine Funktion mit dem Datentyp int als Ergebnis und zwei Parametern, die ebenfalls int-Werte sind.
Die Typbeschreibung bezieht sich auf Java, hat also jeweils 4 Bytes. In C können das je nach Zielplattform Werte mit 4 oder 8 Bytes sein.
Der Aufruf von Funktionen in externen C-Libraries ist mit der Foreign Function & Memory API deutlich einfacher und weniger fehleranfällig als über das veraltete JNI. Wichtig ist eine exakte Beschreibung der aufzurufenden Funktion inklusive des Rückgabewerts und der Parameter.
Nachdem der erste Teil der dreiteiligen Artikelserie gezeigt hat, wie man in Java eine in C geschriebene Shared Library lädt und einfache Funktion dieser Shared Library aufruft, wird sich der nächste Teil komplexeren Szenarien widmen. Er wird zeigen, wie man aus Java C-Funktionen mit veränderbarem Parameter aufrufen und Arrays sowie Strukturen übergeben kann.
URL dieses Artikels:
https://www.heise.de/-11255043
Links in diesem Artikel:
[1] https://github.com/rz259/ffm-demo/
[2] https://openjdk.org/jeps/454
[3] https://www.heise.de/blog/Java-Die-nicht-so-bekannten-Features-des-OpenJDK-24-10322221.html
[4] https://github.com/openjdk/jextract
[5] mailto:rme@ix.de
Copyright © 2026 Heise Medien
Kräftige Antriebe, Kartenautomatik, cleverer Igelschutz und Randschnitt: Diese Luxusmähbots sollen trickreiche Alleskönner sein. Ob das stimmt, klärt der Test.
Die Ausstattungsliste von Luxusmährobotern ist in dieser Modellsaison so lang wie noch nie. Weil es in den Verkaufsregalen des boomenden Mähbotmarkts enger wird, versuchen die Hersteller mit Feature-Overkill ihren Platz im Rasenrevier zu sichern.
Zur Ausstattung zählen etwa Allradantrieb und Einzelradaufhängung für Fahrten über Stock und Stein, Kartierungsautomatik per Laser, Kamera und Satellit ohne Antennenballast, Igelkollisionsschutz mit KI und Messertricks für den Kantenschnitt. Das Testquartett Dreame A3 AWD Pro 3500, Ecovacs Goat A1600 Lidar Pro, Mammotion Luba 3 AWD 3000 und Segway Navimow X420 bündelt jeweils fast alle dieser Talente.
Für die genannten Modelle rufen die Hersteller entsprechend gehobene Preise zwischen 1500 und 2700 Euro auf. Varianten mit größeren Akkus und Flächenleistungen sind noch kostspieliger. Das Preisniveau ist damit zwar nicht höher als in den Vorjahren. Aber weil die Hersteller die Neuzugänge als Eier legende Wollmilchsäue anpreisen, steigen die Erwartungen. Ob die Geräte wirklich alle Tricks vorzüglich statt nur durchschnittlich beherrschen, haben wir in der Praxis getestet.
URL dieses Artikels:
https://www.heise.de/-11259259
Links in diesem Artikel:
[1] https://www.heise.de/tests/Dreame-Ecovacs-Mammotion-und-Segway-Vier-High-End-Maehbots-im-Haertetest-11259259.html
[2] https://www.heise.de/tests/Maehroboter-von-Segway-und-Mammotion-mit-Lidar-Navigation-im-Test-11163164.html
[3] https://www.heise.de/tests/Rasenroboter-fuer-alle-Faelle-die-wichtigsten-Trends-und-neuen-Modelle-10335854.html
[4] https://www.heise.de/tests/Kabelloser-Maehroboter-Mammotion-Luba-2-AWD-im-Test-9794427.html
[5] https://www.heise.de/hintergrund/Sichere-Maehroboter-Wie-bei-c-t-ein-Teststandard-entsteht-10215649.html
[6] https://www.heise.de/tests/Maehroboter-Dreame-Roboticmower-A1-im-Test-9974400.html
Copyright © 2026 Heise Medien
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
(Bild: Apple)
Apple schickt Siri-Entwickler laut einem Bericht in ein KI-Bootcamp, um sie im Einsatz von KI-Coding-Tools zu schulen und das Team zu modernisieren.
Apple [1] schickt angeblich eine größere Zahl von Entwicklern seiner Sprachassistenz Siri in einen mehrwöchigen KI-Lehrgang, damit diese lernen, wie sie KI-Coding-Tools für die Programmierung einsetzen können. Laut einem neuen Bericht will Apple dafür sorgen, dass das Team zu anderen Abteilungen im Hause aufschließt. Gerade die Arbeit des Siri-Teams steht in diesem Jahr besonders im Fokus der Öffentlichkeit, ist es doch bislang die im Jahr 2024 versprochene Weiterentwicklung des Sprachassistenten [2] schuldig geblieben.
Es gehe um weniger als 200 Personen aus einer Gruppe von insgesamt mehreren hundert Entwicklern. Nach dem Bootcamp sollen noch rund 60 Entwickler im Kern-Siri-Team verbleiben. Weitere 60 sollen für Qualitätssicherung und Sicherheits-Evaluierung verbleiben. Apple plant offenbar, ein kleineres, schlagkräftigeres Team zu bilden, das mithilfe von KI-Coding-Tools eine höhere Effizienz erreicht.
Der Bericht von The Information [3], der sich auf namentlich nicht genannte Quellen im Unternehmen stützt, knüpft an frühere Veröffentlichungen an, die ein eher betrübliches Bild der Siri-Abteilung [4] zeichneten. So soll das Siri-Team bei Apple intern seit Jahren als Nachzügler („laggard“) gelten. Es ist von aufgeblähten Strukturen und mangelnder Wettbewerbsfähigkeit die Rede.
Offiziell lassen sich die durchgesickerten Informationen nicht bestätigen, weil Apple zu solchen Interna schweigt. Allerdings deuten die Ergebnisse und personelle Umwälzungen der vergangenen Monate und Jahre darauf hin, dass es in der Siri-Abteilung Apples nicht rund läuft. Die im Jahr 2011 erstmals veröffentlichte Sprachassistenz [5] ließ schon vor dem Hype signifikante Weiterentwicklungen vermissen. Spätestens seit der Konkurrenz durch Chatbots wie ChatGPT, Claude und Gemini sieht Apples Siri aber richtig alt aus.
Das sollte sich mit der Einführung der Apple Intelligence, die auf der Entwicklerkonferenz WWDC im Jahr 2024 vorgestellt wurde, signifikant ändern – tat es aber nicht. Stattdessen musste Apple die Veröffentlichung der angekündigten KI-Siri öffentlich verschieben [6]. KI-Chef John Giannandrea nahm seinen Hut [7]. An seiner Stelle hat Softwarechef Craig Federighi das Zepter übernommen. Er hat Mike Rockwell, der für die Vision Pro verantwortlich zeichnete, mit der Verantwortung für die Weiterentwicklung von Siri betraut.
Mit der Bekanntgabe, dass Google mit seinem KI-Modell Gemini künftig die Grundlage für die KI-Siri [8] bildet, schien der erhoffte Neuanfang erreicht. Der jetzige Bericht von The Information deutet aber darauf hin, dass die zu bewältigende Arbeit für die Modernisierung offenbar doch viel umfangreicher ausfällt. Beobachter wundern sich, dass Apple Teile seines Siri-Teams zwei Monate vor der WWDC auf einen Lehrgang schickt. Es könnte aber darauf hindeuten, dass die für iOS 27 erforderlichen Arbeiten größtenteils abgeschlossen sind und sich der Blick des Teams teilweise schon auf die kommenden Schritte richtet.
Auf der Weltentwicklerkonferenz Apples, die am 8. Juni beginnt, werden mit iOS 27 erste konkrete Ergebnisse [9] des Siri-Neustarts erwartet. Die neue Siri soll besser mit natürlicher Sprache zurechtkommen, gesprächiger sein und auch komplexe Aufgaben übernehmen können. Dazu gehört laut Brancheninsidern auch ein echter Chatbot-Betrieb mit eigener App [10], der längere Konversationen und eine Suchfunktion ermöglichen soll.
URL dieses Artikels:
https://www.heise.de/-11261019
Links in diesem Artikel:
[1] https://www.heise.de/thema/Apple
[2] https://www.heise.de/news/Apple-Intelligence-Das-sagen-der-KI-und-der-Software-Chef-zum-Siri-Neubeginn-9757150.html
[3] https://www.theinformation.com/articles/apple-sends-siri-staffers-coding-bootcamp-latest-shakeup-organization
[4] https://www.heise.de/news/Siri-Chaos-Warum-Apple-seine-bessere-Sprachassistentin-nicht-hinbekommt-10347900.html
[5] https://www.heise.de/news/Was-Siri-versteht-1355676.html
[6] https://www.heise.de/news/Bericht-Neue-Siri-doch-nicht-in-iOS-26-4-11173689.html
[7] https://www.heise.de/news/Apples-frueherer-KI-Chef-John-Giannandrea-verlaesst-das-Unternehmen-11255446.html
[8] https://www.heise.de/news/Nach-Siri-Fail-Apple-setzt-fuer-KI-Modelle-auf-Google-Gemini-11138386.html
[9] https://www.heise.de/news/iOS-27-Apple-erwaegt-Siri-App-und-Siri-fragen-Knopf-11224654.html
[10] https://www.heise.de/news/iOS-27-Apple-erwaegt-Siri-App-und-Siri-fragen-Knopf-11224654.html
[11] https://www.heise.de/mac-and-i
[12] mailto:mki@heise.de
Copyright © 2026 Heise Medien
Nutzer von Apple Business: Keine Dienstleister mehr nötig?
(Bild: Apple)
Apple bündelt seine Angebote für Firmen und bringt die eingebaute Geräteverwaltung nach Deutschland – sogar kostenfrei. Die Details zum neuen Gesamtpaket.
Die neue Plattform für Geschäftskunden im Apple-Ökosystem ist da: Nach der Ankündigung von Apple Business im März [1] [1] geht es ab dieser Woche offiziell los. Das neue Paket kombiniert die bisher getrennten Dienste Apple Business Essentials, Apple Business Manager und Apple Business Connect in einer einzigen Oberfläche. Bestehende Daten migriert Apple automatisch. Kostenlose Geräteverwaltung, Markenmanagement auf Apple Maps plus Apple Mail und eine App-Verteilung für beliebig viele Geräte gehören zum Paket.
Nicht verfügbar sind in Deutschland vorerst die E-Mail-, Kalender- und Verzeichnisdienste, zusätzlicher iCloud-Speicher, AppleCare+ for Business (also eine Geräteversicherung für Geschäftskunden), Werbung in Apple Maps für Geschäftskunden sowie das Feature „Verifizieren mit Wallet im Internet“. Letzteres ist eine Funktion, mit der sich Nutzer über digitale Ausweisdokumente auf Websites identifizieren. Eine Übersicht der regionalen Verfügbarkeiten der einzelnen Dienste [2] [2] hat Apple in ein Supportdokument gepackt.
Für IT-Administratoren ist vor allem die eingebaute Geräteverwaltung interessant, die bislang als kostenpflichtiges US-Abo lief. Unternehmen, die Apple-Hardware einsetzen und bisher auf Mobile Device Management (MDM) verzichtet haben, erhalten damit erstmals ein Bordmittel. iPhones, iPads und Macs lassen sich per MDM von einem zentralen Ort aus konfigurieren, absichern und bei Verlust sperren.
URL dieses Artikels:
https://www.heise.de/-11260854
Links in diesem Artikel:
[1] https://www.heise.de/news/Apple-Business-Kostenlose-All-in-One-Plattform-fuer-Unternehmen-startet-11223070.html
[2] https://support.apple.com/de-de/126603
Copyright © 2026 Heise Medien
Angriff auf den Expressmodus: Visa sieht sich abgesichert.
(Bild: Veritasium / Screenshot YouTube)
Mit dem Expressmodus kann man in U-Bahn-Systemen wie in London oder New York schnell sein Ticket per NFC bezahlen. Besteht hier eine Sicherheitslücke?
iPhone und Apple Watch verfügen im Rahmen von Apple Pay über eine Funktion, die die Nutzung von Nahverkehrssystemen in aller Welt erleichtern soll. Mit dem sogenannten Expressmodus muss man sein Gerät nur noch an das Lesegerät an der Zugangssperre halten und löst dann automatisch sein Ticket über eine hinterlegte Kreditkarte. Das geht etwa in der New Yorker U-Bahn [1] oder in London. Ein Entsperren des Apple-Geräts per Fingerabdruck, Gesichtserkennung oder PIN ist nicht notwendig, sofern man den Expressmodus aktiviert hat.
Doch wie sicher ist das? Wäre es möglich, so auf fremde Kosten mit der bei Apple Pay hinterlegten Kreditkarte einzukaufen? Ein Video des bekannten Wissenschaftskanals Veritasium [2] hat das nun näher untersucht. Das Ergebnis: Mit (ziemlich viel) Mühe und spezieller Hardware sowie Karten eines bestimmten Kreditkartenausgebers konnte dem bekannten YouTuber MKBHD bei einem Testlauf eine größere Geldsumme entwendet werden.
Gänzlich neu ist der Ansatz nicht, bereits 2021 konnten Sicherheitsforscher der Hochschulen Surrey und Birmingham das Vorgehen demonstrieren [3]. Allerdings scheint sich seither wenig getan zu haben. Der Grund: Visa, der Kartenausgeber, der davon betroffen ist, meint, es sei unwahrscheinlich, dass es in der Praxis zu dem Angriff kommt. Zudem, sagte Apple gegenüber Veritasium, habe Visa mitgeteilt, dass der übliche Zahlungsschutz greift. Betroffene können die Kreditkartenbuchung also widerrufen, selbst wenn das mit viel Ärger verbunden sein dürfte.
Der Angriff selbst ist eine Man-in-the-Middle-Attacke: Das iPhone wird auf ein manipuliertes NFC-Lesegerät gelegt, das sich als legitimes ÖPNV-Terminal ausgibt. Es zieht Zahlungsdaten vom iPhone drahtlos ab, die dann wiederum an ein Notebook weitergereicht werden, auf dem sie mittels Python-Skript manipuliert werden. Die Informationen werden anschließend auf ein Burner-Gerät – offenbar ein Android-Telefon, das gerootet wurde – weitergeleitet. Letzteres führt dann die Transaktion auch tatsächlich aus, wenn es auf einen Kartenleser gelegt wird – mit den iPhone-Daten. Der manipulierte Leser musste die gleiche Terminal-ID haben wie ein legitimes Tap-to-Pay-Terminal in einer ÖPNV-Station. Die komplexe Methode funktioniert nicht mit MasterCard und American Express, da es hier offenbar weniger leicht ist, legitime Daten an das Android-Gerät weiterzuleiten.
Interessant: Eines der von den Forschern entdeckten Probleme war, dass iOS in der aktuellen Form offenbar darauf vertraut, dass das NFC-Lesegerät angibt, dass es sich bei der abgefragten Summe um eine geringe handelt. Tatsächlich gegen die Zahl geprüft wird das aber nicht, es wird nur ein Flag gelesen und diesem dann geglaubt. Bei Geräten anderer Hersteller sei das nicht so, sagt Veritasium. Das heißt: Es konnte dem iPhone vorgegaukelt werden, dass es sich um eine Kleinzahlung handelt, die für den Expressmodus üblich sind, während dann tatsächlich 10.000 US-Dollar abgebucht wurden.
Es ist unklar, ob Kriminelle die komplexe Methode tatsächlich einsetzen. Wer auf Nummer sicher gehen will, nutzt den ÖPNV-Expressmodus nicht mit Visa-Karten. Dann sollte die Angriffsform grundsätzlich nicht möglich sein.
URL dieses Artikels:
https://www.heise.de/-11260078
Links in diesem Artikel:
[1] https://www.heise.de/news/New-York-City-will-U-Bahn-Ticket-aufs-iPhone-bringen-10364410.html
[2] https://www.youtube.com/watch?v=PPJ6NJkmDAo
[3] https://www.heise.de/news/Apple-Pay-Funktion-erlaubt-angeblich-Geldklau-von-gesperrten-iPhones-6204960.html
[4] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[5] https://www.heise.de/mac-and-i
[6] mailto:bsc@heise.de
Copyright © 2026 Heise Medien
Michael O. Rabin
(Bild: Andrej Bauer, CC BY-SA 2.5 SI)
Im Alter von 94 Jahren ist Michael Oser Rabin gestorben. Er war der einzige Empfänger des Turing-Awards, der im Deutschen Reich geboren wurde.
Michael O. Rabin wurde als Sohn des Rabbiners Israel Rabin und der Schriftstellerin Ester Rabin am 1. September 1931 in Breslau geboren. Die Familie wanderte 1935 in das britische Mandatsgebiet für Palästina aus. Sein mathematisches Interesse wurde durch seinen Lehrer Elisha Netanyahu mit der Aufnahme in einen kleinen Kreis interessierter Schüler gefördert. Als er mit 16 Jahren 1948 im israelisch-arabischen Krieg in die Armee eingezogen werden sollte, setzte sich der berühmte Mathematiker Abraham Fraenkel für seine weitere Ausbildung an der Universität ein. 1952 schloss Rabin das Studium mit einer Masterarbeit über ein von Emmy Noether entdecktes Problem ab, was ihm ein Stipendium an der Universität Princeton einbrachte. Dort studierte er zusammen mit Dana Scott bei Alonzo Church [1], bei dem auch Alan Turing studiert hatte.
Rabin und Scott wurden im Sommer 1957 von IBM eingeladen und schrieben dort die Arbeit über „Finite Automata and Their Decision Problems“, in der sie sich mit den (heute so genannten) neuronalen Netzwerken von Warren McCulloch und Walter Pitts [2] beschäftigten. 1956 hatte der Logiker Stephen Cole Kleene mit seinem Theorem die Klasse der regulären Sprachen in die Informatik eingeführt und deshalb konnten Rabin und Scott mit ihrer Arbeit über nichtdeterministische Automaten Kleenes Annahmen bestätigen. „Wir hatten eigentlich keinen tieferen philosophischen Grund, diesen Nichtdeterminismus in Betracht zu ziehen, obwohl er, wie wir heute wissen, im Zentrum der P = NP-Frage steht – einem Problem von immenser praktischer und theoretischer Bedeutung. Für uns war das lediglich eine von mehreren Varianten“, sagte Rabin im Interview [3] über seinen Lebensweg, das er seinem Schüler Dennis Shasha gewährte. Im Jahre 1976 bekamen er und Scott für diese Arbeit den Turing Award [4], was bis heute Gegenstand von angeregten Diskussionen [5] ist.
Nach dieser Episode beschäftigte sich Rabin mit kryptographischen Problemen, angeregt über ein Problem, das ihm John McCarthy [6] gestellt hat: Wie kann ein Spion, der sein Passwort sagt, zuverlässig von einem Wächter erkannt werden, der das Passwort errechnen soll? Die Antwort war der Aufsatz „Probabilistic Algorithm for Testing Primality“ von Rabin. Der Primzahlentest, heute als Miller-Rabin-Test [7] bekannt, liefert nach sechs Tests bei langen Zahlen schnell mit einer Wahrscheinlichkeit von 99,9 Prozent die Antwort auf die Frage, ob eine Zahl eine Primzahl ist und wird deshalb in vielen kryptografischen Anwendungen eingesetzt. Mit seinem Aufsatz „Digitalized Signatures and Public-Key Functions as Intractable as Factorization“ lieferte Rabin 1979 die Grundlagen für das Rabin-Kryptosystem, das im Gegensatz zum Primzahlentest kaum genutzt wird.
Später war Rabin nach jahrelanger Forschung und Lehre an der Hebrew University, deren Rektor er zeitweilig war, ab 1982 wieder bei IBM und gehörte dort bis 1994 zum Science Advisory Committee. 1987 entwickelte er mit Richard M. Karp den Rabin-Karp-Algorithmus, der bei der Suche nach Plagiaten mit einem effizienten Hash-Verfahren aufwartet. Im Interview über seinen Lebensweg schildert er, wie wichtig die Rolle des Zufalls für seine Arbeit gewesen ist. „Das Einwirken von Zufall bei so vielen algorithmischen Problemen ist mir völlig rätselhaft. Es ist effizient, es funktioniert; aber warum und wie, ist mir ein absolutes Rätsel. Algorithmen benötigen in ihrer Reinform eine physikalische Zufallsquelle. Es handelt sich also um eine Art Zusammenarbeit zwischen uns Informatikern und der Natur als Quelle des Zufalls. Das ist einzigartig und wirft einige Fragen in der Physik und Philosophie auf.“
URL dieses Artikels:
https://www.heise.de/-11261362
Links in diesem Artikel:
[1] https://www.genealogy.math.ndsu.nodak.edu/id.php?id=8011
[2] https://www.heise.de/hintergrund/Zahlen-bitte-Von-2-AND-1-OR-0-NOT-die-wegweisende-McCulloch-Pitts-Zelle-6268289.html
[3] https://cacm.acm.org/news/an-interview-with-michael-rabin/
[4] https://amturing.acm.org/award_winners/rabin_9681074.cfm
[5] https://rjlipton.com/2023/01/19/rabin-scott-time/
[6] https://www.heise.de/news/Requiescat-in-pace-Zum-Tod-von-John-McCarthy-1366069.html
[7] https://asecuritysite.com/primes/rabintest?val=982451652
[8] https://www.heise.de/newsletter/anmeldung.html?id=ki-update&wt_mc=intern.red.ho.ho_nl_ki.ho.markenbanner.markenbanner
[9] mailto:mho@heise.de
Copyright © 2026 Heise Medien
(Bild: Bundeswehr/Dagmar Benner)
Wegen akuter Abhörgefahren durch Russland und China verschärft das Verteidigungsministerium die Regeln für Smartphones und Smartwatches in sensiblen Bereichen.
Im Bundesverteidigungsministerium herrscht Alarmstimmung. Das Haus von Minister Boris Pistorius (SPD) reagiert mit einer dringlichen Sicherheitsanweisung auf die wachsende Bedrohung durch ausländische Geheimdienste. Die Nutzung privater Mobilgeräte sei in sensiblen Bereichen des Wehrressorts sowie in den Dienststellen der Bundeswehr deutlich eingeschränkt worden, schreibt der Spiegel. Die Maßnahme ziele darauf ab, die Kommunikation innerhalb des Apparats vor den neugierigen digitalen Augen und Ohren fremder Mächte zu schützen. Denn das Spionagerisiko wird als so hoch wie selten zuvor eingestuft.
Kern der neuen Richtlinie ist ein striktes Mitbringverbot für private Smartphones, Tablets und sogar Smartwatches bei Besprechungen. Dies gilt laut dem Bericht [1] nicht nur für physische Treffen in den Konferenzräumen. Betroffen seien auch virtuelle Zusammenkünfte, sobald dort Informationen geteilt würden, die mindestens als „Verschlusssache – nur für den Dienstgebrauch“ eingestuft sind.
Im Fokus stehen dabei Runden, in denen es um die Einsatzbereitschaft der Truppe oder die konkrete Planung von Übungsvorhaben und Einsätzen geht. In solchen Fällen müssen die privaten Begleiter zwingend in Schließfächern auf den Fluren verweilen.
Die Tragweite der Entscheidung wird beim Blick auf die räumlichen Konsequenzen deutlich. Die Regelung beschränkt sich nämlich nicht auf explizite Sitzungssäle. Sie erstreckt sich auch auf sämtliche Amtsstuben, in denen als Verschlusssache eingestufte Dokumente lagern. Im Berliner Bendlerblock, dem Hauptsitz des Ministeriums, betrifft das fast jedes Dienstzimmer. Für die Beamten sowie das militärische Personal bedeutet das eine Rückkehr zur strikten Trennung von Privatem und Dienstlichem, die im digitalen Zeitalter vielerorts brüchig geworden ist.
Die Begründung der Sicherheitsabteilung lässt wenig Spielraum für Interpretation. Die Bundeswehr gilt derzeit als eines der prioritären Aufklärungsziele russischer Dienste. Doch nicht nur der Kreml bereitet Sorgen: Auch China wird in der internen Anweisung explizit erwähnt. Demnach verfolgt Peking einen strategischen und langfristigen Ansatz bei der nachrichtendienstlichen Informationsgewinnung.
Die privaten Geräte der Mitarbeiter werden dabei als Achillesferse identifiziert. Während dienstliche Mobiltelefone regelmäßig auf Schadsoftware geprüft werden und speziell abgesichert sind, entziehen sich Privatgeräte der staatlichen Kontrolle.
Das Risiko ist technischer Natur: Über manipulierte Apps oder gezielte Phishing-Angriffe lassen sich Abhörprogramme relativ simpel auf herkömmlichen Smartphones installieren. Da das Ministerium keinen Zugriff auf die privaten Geräte hat, könnten solche Infektionen über Monate oder Jahre unbemerkt bleiben. Das Smartphone in der Hosentasche wird so zum potenziellen Sender, der sensible Details über die Verteidigungsfähigkeit des Landes direkt an gegnerische Geheimdienste übermittelt.
Die Anweisung trifft eine Belegschaft, die sich an die ständige Erreichbarkeit gewöhnt hat. Zwar ist das Personal nahezu flächendeckend mit Dienst-Handys ausgestattet, auf denen auch die Bearbeitung eingestufter Dokumente möglich ist. Doch diese Geräte unterliegen strengen Software-Beschränkungen. Gängige Messenger wie WhatsApp sind dort aus Sicherheitsgründen tabu. Das führte dazu, dass von einfachen Angestellten bis hinauf in die Leitungsebene fast jeder sein privates Zweitgerät ständig bei sich trägt, um privat vernetzt zu bleiben. Damit soll nun in den sicherheitsrelevanten Zonen Schluss sein.
Andere Institutionen haben noch schärfere Vorgaben. Beim Bundesnachrichtendienst (BND) etwa ist das Mitführen privater Elektronik schon lange grundsätzlich untersagt. Auch die NATO setzt auf drakonische Einschränkungen.
URL dieses Artikels:
https://www.heise.de/-11261358
Links in diesem Artikel:
[1] https://www.spiegel.de/politik/deutschland/boris-pistorius-verbannt-privathandys-aus-den-amtsstuben-spionagegefahr-a-f3e7b805-fcf6-4c42-ab20-dbd1cd1fa683
[2] https://www.heise.de/newsletter/anmeldung.html?id=ki-update&wt_mc=intern.red.ho.ho_nl_ki.ho.markenbanner.markenbanner
[3] mailto:mma@heise.de
Copyright © 2026 Heise Medien
(Bild: Tero Vesalainen/Shutterstock.com)
Bundeskriminalamt und Generalstaatsanwaltschaft Frankfurt sind mit internationalen Partnern gegen sogenannte Stresserdienste vorgegangen. Es gab Festnahmen.
Die „Power Off“ genannte Operation sollte Betreiber von Stresserdiensten, mit denen auch technisch weitgehend ahnungslose Nutzer verteilte Überlastungsangriffe buchen konnten, unter Druck setzen. So ein Distributed-Denial-of-Service (DDoS) legt durch viele gleichzeitige Zugriffe Dienste lahm. Bei der Operation gingen das Bundeskriminalamt, die Zentralstelle zur Bekämpfung der Internetkriminalität und internationale Partner koordiniert vor, um Angebote auszuschalten und Tatbeteiligte zu erreichen. Die Zentralstelle ist Teil der Generalstaatsanwaltschaft Frankfurt am Main und bei solchen Verfahren in Deutschland oft federführend.
Die „Stressoren“ werden dabei aus ganz unterschiedlichen Gründen gebucht. „Haktivistische Gruppierungen versuchen unsere Gesellschaft unter Druck zu setzen, Online-Gamer versprechen sich Wettbewerbsvorteile“, erklärt Carsten Meywirth, der beim BKA die Abteilung Cybercrime leitet. Der Leiter der ZIT Benjamin Krause sieht hier ein Muster: „Gerade jüngere Beschuldigte, unter anderem in der Gaming-Szene, nutzen häufig Stresserdienste als vermeintlich harmlosen Spaß oder um sich Vorteile in Spielen zu verschaffen.“ Das Stören fremder Systeme sei jedoch kein Spiel, sondern eine Straftat, betonen die Behörden.
Ein Verfahren in dem Zusammenhang richtet sich laut den deutschen Behörden gegen einen deutschen Staatsbürger, der im Ausland lebt und mit „Fluxstress“ sowie „Netdowner“ zwei der größten Angebote betrieben haben soll. Der Deutsche wurde in Thailand festgenommen, die deutschen Strafverfolger werfen ihm gewerbs- und bandenmäßiges Betreiben einer kriminellen Handelsplattform vor. Bei insgesamt 150 Maßnahmen und 16 Durchsuchungen in 21 Ländern seien in Polen nun zudem zwei mutmaßliche Administratoren und ein weiterer Tatbeteiligter festgenommen worden.
Seit 2019 versuchen die Strafverfolgungsbehörden den Verfolgungsdruck auf derartige „Crime-as-a-Service“-Angebote im Rahmen internationaler Aktionen zu erhöhen und setzen auch auf Abschreckung: Warnhinweise und direkter Kontakt zu Kunden der kriminellen Dienste gehören zum Instrumentarium der Ermittler. Vier Verhaftungen und 53 Domain-Takedowns listet die Website der Operation Power Off [1] derzeit auf – die Behörden gehen davon aus, dass diese Zahlen nach dem heutigen Tag weiter steigen werden. Das Projekt besteht seit Jahren und richtet sich gegen verschiedene Cybercrime-Angebote, immer wieder auch gegen DDoS-Anbieter [2].
URL dieses Artikels:
https://www.heise.de/-11261177
Links in diesem Artikel:
[1] https://www.operation-poweroff.com/
[2] https://www.heise.de/news/Polizei-schliesst-Drogen-Marktplatz-und-DDoS-Booter-10002579.html
[3] https://pro.heise.de/security/?LPID=39555_HS1L0001_27416_999_0&wt_mc=disp.fd.security-pro.security_pro24.disp.disp.disp
[4] mailto:cku@heise.de
Copyright © 2026 Heise Medien
Michael O. Rabin
(Bild: Andrej Bauer, CC BY-SA 2.5 SI)
Im Alter von 94 Jahren ist Michael Oser Rabin gestorben. Er war der einzige Empfänger des Turing-Awards, der im Deutschen Reich geboren wurde.
Michael O. Rabin wurde als Sohn des Rabbiners Israel Rabin und der Schriftstellerin Ester Rabin am 1. September 1931 in Breslau geboren. Die Familie wanderte 1935 in das britische Mandatsgebiet für Palästina aus. Sein mathematisches Interesse wurde durch seinen Lehrer Elisha Netanyahu mit der Aufnahme in einen kleinen Kreis interessierter Schüler gefördert. Als er mit 16 Jahren 1948 im israelisch-arabischen Krieg in die Armee eingezogen werden sollte, setzte sich der berühmte Mathematiker Abraham Fraenkel für seine weitere Ausbildung an der Universität ein. 1952 schloss Rabin das Studium mit einer Masterarbeit über ein von Emmy Noether entdecktes Problem ab, was ihm ein Stipendium an der Universität Princeton einbrachte. Dort studierte er zusammen mit Dana Scott bei Alonzo Church [1], bei dem auch Alan Turing studiert hatte.
Rabin und Scott wurden im Sommer 1957 von IBM eingeladen und schrieben dort die Arbeit über „Finite Automata and Their Decision Problems“, in der sie sich mit den (heute so genannten) neuronalen Netzwerken von Warren McCulloch und Walter Pitts [2] beschäftigten. 1956 hatte der Logiker Stephen Cole Kleene mit seinem Theorem die Klasse der regulären Sprachen in die Informatik eingeführt und deshalb konnten Rabin und Scott mit ihrer Arbeit über nichtdeterministische Automaten Kleenes Annahmen bestätigen. „Wir hatten eigentlich keinen tieferen philosophischen Grund, diesen Nichtdeterminismus in Betracht zu ziehen, obwohl er, wie wir heute wissen, im Zentrum der P = NP-Frage steht – einem Problem von immenser praktischer und theoretischer Bedeutung. Für uns war das lediglich eine von mehreren Varianten“, sagte Rabin im Interview [3] über seinen Lebensweg, das er seinem Schüler Dennis Shasha gewährte. Im Jahre 1976 bekamen er und Scott für diese Arbeit den Turing Award [4], was bis heute Gegenstand von angeregten Diskussionen [5] ist.
Nach dieser Episode beschäftigte sich Rabin mit kryptographischen Problemen, angeregt über ein Problem, das ihm John McCarthy [6] gestellt hat: Wie kann ein Spion, der sein Passwort sagt, zuverlässig von einem Wächter erkannt werden, der das Passwort errechnen soll? Die Antwort war der Aufsatz „Probabilistic Algorithm for Testing Primality“ von Rabin. Der Primzahlentest, heute als Miller-Rabin-Test [7] bekannt, liefert nach sechs Tests bei langen Zahlen schnell mit einer Wahrscheinlichkeit von 99,9 Prozent die Antwort auf die Frage, ob eine Zahl eine Primzahl ist und wird deshalb in vielen kryptografischen Anwendungen eingesetzt. Mit seinem Aufsatz „Digitalized Signatures and Public-Key Functions as Intractable as Factorization“ lieferte Rabin 1979 die Grundlagen für das Rabin-Kryptosystem, das im Gegensatz zum Primzahlentest kaum genutzt wird.
Später war Rabin nach jahrelanger Forschung und Lehre an der Hebrew University, deren Rektor er zeitweilig war, ab 1982 wieder bei IBM und gehörte dort bis 1994 zum Science Advisory Committee. 1987 entwickelte er mit Richard M. Karp den Rabin-Karp-Algorithmus, der bei der Suche nach Plagiaten mit einem effizienten Hash-Verfahren aufwartet. Im Interview über seinen Lebensweg schildert er, wie wichtig die Rolle des Zufalls für seine Arbeit gewesen ist. „Das Einwirken von Zufall bei so vielen algorithmischen Problemen ist mir völlig rätselhaft. Es ist effizient, es funktioniert; aber warum und wie, ist mir ein absolutes Rätsel. Algorithmen benötigen in ihrer Reinform eine physikalische Zufallsquelle. Es handelt sich also um eine Art Zusammenarbeit zwischen uns Informatikern und der Natur als Quelle des Zufalls. Das ist einzigartig und wirft einige Fragen in der Physik und Philosophie auf.“
URL dieses Artikels:
https://www.heise.de/-11261362
Links in diesem Artikel:
[1] https://www.genealogy.math.ndsu.nodak.edu/id.php?id=8011
[2] https://www.heise.de/hintergrund/Zahlen-bitte-Von-2-AND-1-OR-0-NOT-die-wegweisende-McCulloch-Pitts-Zelle-6268289.html
[3] https://cacm.acm.org/news/an-interview-with-michael-rabin/
[4] https://amturing.acm.org/award_winners/rabin_9681074.cfm
[5] https://rjlipton.com/2023/01/19/rabin-scott-time/
[6] https://www.heise.de/news/Requiescat-in-pace-Zum-Tod-von-John-McCarthy-1366069.html
[7] https://asecuritysite.com/primes/rabintest?val=982451652
[8] https://www.heise.de/newsletter/anmeldung.html?id=ki-update&wt_mc=intern.red.ho.ho_nl_ki.ho.markenbanner.markenbanner
[9] mailto:mho@heise.de
Copyright © 2026 Heise Medien
Google testet in der Android Canary-Version vom April ein erweitertes Kontextmenü.
(Bild: Andreas Floemer / heise medien)
In der aktuellen Android-Canary-Version testet Google ein kompakteres, zweigeteiltes Kontextmenü für App-Icons sowie eine neue Benachrichtigungsanzeige.
Google veröffentlicht einmal pro Monat eine neue Version von Android Canary. Das ist ein hochexperimenteller Android-Build, der sich in erster Linie an Entwickler und Hardcore-Fans richtet und seit Juli 2025 die Developer-Previews ersetzt [1]. In der neuen April-Version steckt oberflächlich lediglich eine größere Veränderung, mit der das Kontextmenü von App-Icons aufgebohrt wird – und eine weitere winzige Änderung. Die Canary-Funktionen finden nicht zwingend ihren Weg in die finalen Versionen.
Die neue Canary-Version 2604 mit der Buildnummer ZP11.260320.007 steht zunächst für das Pixel 8 und neuer zum Ausprobieren bereit, ist aber nicht für den Alltagsgebrauch geeignet. Später soll der Canary-Release auch für ältere Modelle wie das Pixel 6 und weitere bereitgestellt werden, schreibt Google [2]. Das experimentelle Betriebssystem zeigt, woran Google arbeitet, beziehungsweise was der Konzern davon zeigen möchte.
Vieles – vor allem KI-Funktionen – enthüllt das Unternehmen erst dann, wenn es weitgehend fertig ist. Bestätigt hat Google, dass Android 17 und künftige Versionen mehr agentische Fähigkeiten bekommen [3] soll. Der Chef des Android-Ökosystems sagte dazu: „Wir bewegen uns weg von einem Betriebssystem hin zu einem intelligenten System, einer Plattform, die Sie wirklich versteht und für Sie arbeitet.“
In der Canary-Version backt Google kleinere Brötchen: Sie enthält ein überarbeitetes Kontextmenü für Apps, das sich durch einen Langdruck auf ein App-Icon öffnen lässt. Das Menü ist zum einen etwa kompakter gestaltet und zum anderen zweigeteilt. Nach dem Öffnen zeigt das Menü zuerst die Schnellzugriffe, ein weiterer Button öffnet eine Übersicht mit Aktionen. Die in der März-Version getestete App-Lock-Funktion, mit der man einzelne Apps mit einer Sperre versehen kann, ist in dieser Version verschwunden.
(Bild: Andreas Floemer / heise medien)
Eine weitere kleine Änderung ist die Anzeige nach dem Entfernen sämtlicher Benachrichtigungen: Hier heißt es nun „Du bist auf dem aktuellen Stand“ begleitet von einem Pokal statt „Keine Benachrichtigungen“. Die neue Anzeige orientiert sich dabei an Wear OS 6 etwa auf der Pixel Watch, sodass es über das Ökosystem hinweg einheitlicher anmutet.
(Bild: Andreas Floemer/ heise medien)
Ob das neue Kontextmenü Teil von Android 17 wird, ist zwar noch offen. Allerdings flossen einige Features, die Google erst im März im Canary-Channel [4] getestet hatte, kurz danach in die Betaversion des großen Updates ein. Dazu gehören etwa App-Bubbles, um Android eine neue Multitasking-Option zu verpassen. Außerdem sind seit der Beta 3 von Android 17 WLAN- und Mobilfunkempfang wieder getrennt. Google hatte im Jahr 2021 mit Android 12 [5] eine einzige „Internet“-Kachel für beide Konnektivitäts-Optionen in die Schnelleinstellungen integriert, sodass es umständlicher war, eine der beiden Funktionen abzuschalten.
Wer sich die Canary-Version auf einem Gerät installiert, sollte sich im Klaren darüber sein, dass es nicht sonderlich einfach ist, zur stabilen Version zurückzukehren. Um keine Canary-OTA-Updates mehr zu erhalten, muss man einen Nicht-Canary-Build flashen, was eine vollständige Löschung aller Daten nach sich zieht. Hierfür bietet Google sein Android-Flash-Tool an.
URL dieses Artikels:
https://www.heise.de/-11260688
Links in diesem Artikel:
[1] https://www.heise.de/news/Android-Canary-Channel-Google-kuendigt-neuen-Spielplatz-fuer-Entwickler-an-10483754.html
[2] https://www.reddit.com/r/android_canary/comments/1slljkt/android_canary_2604_is_now_available/
[3] https://www.heise.de/news/Gemini-fuer-Android-wird-agentisch-KI-bestellt-Essen-oder-einen-Fahrdienst-11191444.html
[4] https://www.heise.de/news/Maerz-Update-Android-Canary-Version-bringt-neue-App-Sperre-und-alte-WLAN-Kachel-11220944.html
[5] https://www.heise.de/news/Aus-fuer-Android-12-und-12L-Google-beendet-Support-fuer-Millionen-Geraete-10352204.html
[6] https://www.heise.de/newsletter/anmeldung.html?id=ki-update&wt_mc=intern.red.ho.ho_nl_ki.ho.markenbanner.markenbanner
[7] mailto:afl@heise.de
Copyright © 2026 Heise Medien
(Bild: software-architektur.tv)
Im Gespräch mit Eberhard Wolff räumt Industrial-AI-Experte Nikita Golovko mit dem Missverständnis auf, LLMs seien gleichbedeutend mit KI.
In der aktuellen englischsprachigen Folge des Videocasts software-architektur.tv [1] diskutiert Eberhard Wolff mit Nikita Golovko über ein verbreitetes Missverständnis: Viele setzen Large Language Models (LLM) mit künstlicher Intelligenz gleich – doch gerade in industriellen Anwendungen greift das zu kurz.
Nikita Golovko arbeitet als Principal Architect Industrial AI bei Siemens und erläutert im Gespräch, warum die Unterscheidung zwischen LLMs, generativer KI und anderen KI-Methoden entscheidend ist. Jede dieser Technologien entfalte ihren Wert an unterschiedlichen Stellen – die richtige Zuordnung von Werkzeug und Problem führe zu besseren Ergebnissen, und das nicht nur in der Fertigung.
Im Zentrum der Diskussion steht die Frage, wie sich probabilistische KI-Systeme in deterministische Umgebungen integrieren lassen. Industrielle Automatisierung verlangt Zuverlässigkeit, Präzision und Kontrolle – Eigenschaften, die KI-Modelle mit ihrem inhärent unscharfen Verhalten nicht ohne Weiteres bieten. Nikita Golovko [2] betont, dass eine sichere Architektur nötig sei, die diesen Spannungsbogen auflöst. Während generative KI etwa bei kreativen oder explorativen Aufgaben punkten kann, eignen sich andere KI-Verfahren besser für Vorhersage- oder Optimierungsszenarien in der Produktion.
Die Folge wird am Freitag, 17. April 2026, live ab 13 Uhr gestreamt. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite [4] einbringen.
software-architektur.tv ist ein Videocast von Eberhard Wolff, iX-Blogger [5] und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer [6] (Socreatory) und Ralf D. Müller [7] (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren berichtet heise Developer über die Episoden.
Golovko wird auch beim TechRiders Summit [8] auftreten, der am 17. und 18. Juni 2026 auf dem Euronova Campus in Hürth bei Köln stattfindet. Die Veranstaltung steht unter der Schirmherrschaft des Bundesministeriums für Digitales und Staatsmodernisierung und versammelt nach Angaben der Organisatoren über 140 Speaker, mehr als 20 Communitys und rund 2000 Teilnehmer. Themen wie Industrial AI, Edge-Systeme und Cybersecurity stehen auf dem Programm. Interessierte können sich mit einem Rabattcode ARCH-TECHRIDER-2026 [9] kostenfrei registrieren.
URL dieses Artikels:
https://www.heise.de/-11256985
Links in diesem Artikel:
[1] https://software-architektur.tv/
[2] https://www.linkedin.com/in/dr-nikita-golovko/
[3] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[4] https://software-architektur.tv/
[5] https://www.heise.de/developer/Continuous-Architecture-2687847.html
[6] https://www.socreatory.com/de/trainers/lisa-moritz
[7] https://techstories.dbsystel.de/blog/profiles/Ralf-D.-Mueller.html
[8] https://tech-riders.de/
[9] https://app.tech-riders.de/offers/1/book?v=ARCH-TECHRIDER-2026&pr=10
[10] mailto:map@ix.de
Copyright © 2026 Heise Medien
Mit außergewöhnlichen Kameras und sehr speziellem Zubehör soll das Vivo X300 Ultra vor allem Fotoliebhaber anlocken.
Dieses Smartphone [1] [1] ist nichts für Sparfüchse, dafür ist es mit knapp 2000 Euro viel zu teuer. Das X300 Ultra vom hier weniger bekannten Hersteller Vivo ist allerdings mindestens dann einen zweiten Blick wert, wenn es ein Smartphone mit einer besonderen Kamera sein soll.
Das Vivo X300 Ultra trägt den derzeit wohl höchsten Kamerahügel aller Smartphones auf dem Rücken, er ragt mehr als 8 Millimeter aus der Rückseite hervor. Als Designelement rückt er das Telefon damit weit in Richtung Kamera. Der Herstellerschriftzug ist so aufgebracht, dass er im Querformat zu lesen ist. Die Rückseite unseres Testmusters besteht aus mattem Glas in einem dezenten Grünton, das untere Viertel ist farblich leicht abgesetzt. Das gesamte Gerät ist makellos verarbeitet und wirkt hochwertig.
Schüttelt man das Smartphone, hört man dennoch deutliches Klappern. Dafür sind die großen Kameraobjektive und deren optische Stabilisatoren verantwortlich, die sich im inaktiven Zustand im Gehäuse bewegen. So ein Klappern ist bei den meisten Smartphones zu hören, vor allem bei solchen mit aufwendigen Kamerasystemen, beim Vivo X300 Ultra ist das jedoch laut. Mit 237 Gramm zählt das große Smartphone auch zu den schwereren Modellen. Nach IP68/IP69 geschützt, machen ihm Staub und Wasser nichts aus.
URL dieses Artikels:
https://www.heise.de/-11249071
Links in diesem Artikel:
[1] https://www.heise.de/thema/Smartphone
[2] https://www.heise.de/tests/Ein-teurer-Spass-Kamera-Smartphone-Vivo-X300-Ultra-im-Test-11249071.html
[3] https://www.heise.de/tests/Billiger-ist-besser-Nothing-Phone-4a-und-4a-Pro-im-Test-11257905.html
[4] https://www.heise.de/ratgeber/High-End-Smartphones-2026-Stagnation-statt-Innovation-11199992.html
[5] https://www.heise.de/tests/High-End-Smartphones-iPhone-Pixel-und-Galaxy-im-Vergleich-11173362.html
[6] https://www.heise.de/tests/Honor-Oppo-Xiaomi-im-Vergleich-High-End-Smartphones-aus-China-11173368.html
Copyright © 2026 Heise Medien
Das ukrainische Entwicklerstudio 4A Games setzt seine Shooter-Reihe mit Metro 2039 fort. Der Titel erscheint im Winter für Playstation 5, Xbox Series X/S und Windows-PC und bleibt ein reines Einzelspieler-Spiel mit Fokus auf Story, Survival und Atmosphäre.
Die Handlung spielt rund 25 Jahre nach dem Atomkrieg. Die Überlebenden sind unter einem Regime vereint, das von dem Spartaner Hunter angeführt wird. Er verspricht ein Leben auf der Oberfläche, tatsächlich bleiben die Menschen jedoch im Metro-System gefangen und werden durch Propaganda und Gewalt kontrolliert.
Im Vergleich zum Vorgänger Metro Exodus (2019) verschiebt sich der Fokus wieder stärker in Richtung enge, lineare Abschnitte im Metro-System. Während Exodus größere, offenere Gebiete bot, setzt Metro 2039 stärker auf klaustrophobische Levels, klassische Exploration sowie die Mischung aus Schleichen, Ressourcenmanagement und Gefechten.
Anders als in den Vorgängern steht außerdem nicht Artjom im Mittelpunkt. Stattdessen übernimmt mit "The Stranger" erstmals ein vollständig vertonter Held die Hauptrolle. Das soll die Inszenierung direkter machen und Dialoge stärker in den Mittelpunkt rücken. Die Figur wird von Albträumen geplagt und kehrt "an einen Ort zurück, an den sie nie zurückkehren wollte" , wie es in der Präsentation heißt.
Die Atmosphäre soll deutlich düsterer werden als in Exodus. Laut den Entwicklern geht es stärker um Konsequenzen von Krieg, Unterdrückung und individuelle Entscheidungen. Wörtlich ist von den "Kosten des Schweigens" und dem "Preis der Freiheit" die Rede.
Diese Ausrichtung hängt offenbar auch eng mit der realen Situation des Studios zusammen: 4A Games arbeitet unter Kriegsbedingungen weiterhin teilweise in der Ukraine, was die Entwicklung und die inhaltliche Ausrichtung direkt beeinflusst hat; eine Niederlassung hat ihren Sitz auf Malta.
Metro 2039 basiert erneut auf der hauseigenen 4A Engine. Die Entwickler haben laut eigener Aussage zentrale Rendering-Systeme von Grund auf überarbeitet, darunter insbesondere die Raytracing-Implementierung.
Ziel sei eine höhere Effizienz bei gleichzeitig gesteigerter Bildqualität. Bereits Metro Exodus gehörte zu den frühen Titeln mit umfangreicher Raytracing-Nutzung; darauf baut das neue Spiel auf, soll aber einen Schritt weiter gehen in Bezug auf Beleuchtung und Performance.
Ein Schwerpunkt bleibt die Gestaltung glaubwürdiger Umgebungen. Räume werden nicht modular zusammengesetzt, sondern gezielt gebaut und mit Details versehen, die konkrete Ereignisse andeuten. Die Entwickler sprechen von "eingefrorenen Momenten" , etwa einem verlassenen Tisch oder einer Szene kurz vor einem Kampf, die ohne Dialog Hinweise auf das Geschehen geben.
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Makita ist hauptsächlich für seine Akkus und das 18-Volt-Ökosystem aus Akkuschraubern, Gartengeräten und Bohrhämmern bekannt. Das Sortiment der Japaner erschöpft sich jedoch nicht darin. Handwerkzeuge gehören fest zu Makitas Portfolio.
Ein Beispiel dafür ist das 120-teilige Werkzeug-Set Makita E-08713 im Makpac der Größe 1. Dieses enthält zahlreiche Bits, eine Ratsche, Schraubenschlüssel und Stecknüsse. Das Set war schon mehrmals bei Amazon vergriffen und kostet gerade den besten Preis unter den im Preisvergleich gelisteten Shops.
Die 120 Teile des Werkzeugkoffers setzen sich hauptsächlich aus Bits und Stecknüssen zusammen. Angesprochen werden Schrauber und Bastler, die zum Beispiel in der Garage an ihren Fahrzeugen schrauben oder häufiger Schuppen und Gartenhäuser umbauen.
Natürlich muss man die Bits und Nüsse irgendwie zum Zuge bringen. Deshalb gehört eine Ratsche in 3/8 Zoll zum Lieferumfang. Verlängerungen findet man ebenfalls im Makpac. So auch einen magnetischen Ringmaulschlüssel.
Ebenfalls vorhanden sind sieben Ringmaulschlüssel, ein Innensechskantschlüssel-Set und zwei Zündkerzen-Stecknüsse in 16 und 21 Millimeter. Stecknüsse gibt es einige. Das Bit-Sortiment ist 50-teilig und deckt Profile wie Torx und PZ ab.
Gerade kostet das mit 4,7 von 5 Sternen bewertete Werkzeug-Set von Makita bei Amazon 65,89 Euro. Zusammen mit Gotools ruft Amazon
Makita E-08713 Werkzeug-Set
Zum AngebotWenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Eine Alternative ist das Werkzeug-Set E-10883. Hier gibt es zwar kein Makpac, aber 221 Teile, zum Beispiel zwei Ratschen in 1/2 und 1/4 Zoll, Steckschlüsseleinsätze, Bits, Zündkerzeneinsätze, Verlängerungen, Adapter, Steckschlüssel- und Schraubendreher-Bits, Ringmaulschlüssel und ein Innensechskantschlüssel-Set. Das Set kostet bei Amazon den aktuell besten Vergleichspreis in Höhe von 92,99 Euro
Makita E-10883 Werkzeug-Set 221-teilig
Zum AngebotWenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Nicht spannend genug? Weitere Makita-Sets findet man bei Amazon in der Übersicht.
