Ceci est le premier message. Veuillez noter que cela peut être inesthétique.
Depuis qu'il est devenu populaire de séparer chaque langue de python ...
Segfo avec python en trois lignes Segfo avec python en 2 lignes Segfo avec 16 caractères en langage C Segfo avec 33 caractères en Python Segfo avec Rust en 5 lignes Segfo avec 5 caractères en langage C
En raison de la fabrication forcée de 6 lignes
a.java
import java.lang.reflect.*;
import sun.misc.Unsafe;
class A {public static void main(String[] a) throws Exception {Constructor<Unsafe> b=Unsafe.class.getDeclaredConstructor();
b.setAccessible(true);
b.newInstance().putLong(0, 0);} }
C'est exagéré et n'a aucune lisibilité Si vous organisez le code
a.java
import java.lang.reflect.*;
import sun.misc.Unsafe;
class A {
public static void main(String[] a) throws Exception{
Constructor<Unsafe> b=Unsafe.class.getDeclaredConstructor();
b.setAccessible(true);
b.newInstance().putLong(0, 0);
}
}
Cela ne change pas grand-chose ...
Ubuntu
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f8b7c08ba84, pid=1986, tid=1987 #Segfo ici(Violation d'accès)Est passe
#
# JRE version: OpenJDK Runtime Environment (14.0.1+7) (build 14.0.1+7-Ubuntu-1ubuntu1)
# Java VM: OpenJDK 64-Bit Server VM (14.0.1+7-Ubuntu-1ubuntu1, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0xe99a84]
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/user/hs_err_pid1986.log
#
# If you would like to submit a bug report, please visit:
# Unknown
#
Aborted
(Ubuntu+OpenJDK Runtime Environment 14.0.1)
Puisqu'il a été exécuté sur WSL2, le résultat réel peut différer.
Lorsqu'il est exécuté, il produit une instruction d'erreur terrible et une instruction d'erreur de près de 750 lignes.
Faire attention à la 5ème ligne de la déclaration d'erreur ...
4ème ligne
SIGSEGV(0xb)atpc=0x00007f8b7c08ba84,pid=1986, tid=1987
Comme vous pouvez le voir, vous recevez un signal SIGSEGV (violation d'accès).
De plus, le fichier journal est une génération détaillée du fichier appelé et du vidage mémoire.
Ligne 49 du fichier journal Ubuntu:
has_err_pid{posess_id}.log
49:siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000000
Accès à l'adresse 0 et SEGV_MAPERR (erreur qui se produit lors de l'accès à la mémoire non mappée)
Vous pouvez voir que cela se passe
Windows
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd4fa119b7, pid=18520, tid=8224
#
# JRE version: Java(TM) SE Runtime Environment (14.0.1+7) (build 14.0.1+7)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (14.0.1+7, mixed mode, sharing, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# V [jvm.dll+0x7219b7]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\User\aa\hs_err_pid18520.log
#
# If you would like to submit a bug report, please visit:
# https://bugreport.java.com/bugreport/crash.jsp
#
(Windows + Java(TM) SE Runtime Environment 14.0.1)
Un fichier journal sera généré dans le même répertoire que le fichier de classe avec la même déclaration d'erreur terrible que Ubuntu.
Si vous faites attention à la 4ème ligne
4ème ligne
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd4fa119b7, pid=18520, tid=8224
Vous pouvez voir que ʻEXCEPTION_ACCESS_VIOLATION` (violation d'accès) s'est produite. Consulter le fichier journal généré dans le même répertoire que le fichier de classe
Ligne 40 du fichier journal Windows:
has_err_pid{prosess_id}.log
40:#siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), writing address 0x0000000000000000
Vous pouvez voir qu'une violation d'accès s'est produite en "écrivant" à l'adresse "0" de la mémoire.
qu'Est-ce que c'est! Ce n'est pas une erreur "Segmentation Fault"! C'est une arnaque! Je pense que certaines personnes pensent que,
"[wikipedia -Segmentation violation-](https://ja.wikipedia.org/wiki/%E3%82%BB%E3%82%B0%E3%83%A1%E3%83%B3%E3%83 % 86% E3% 83% BC% E3% 82% B7% E3% 83% A7% E3% 83% B3% E9% 81% 95% E5% 8F% 8D) "
Sur les systèmes d'exploitation de type UNIX, les processus qui accèdent à une mémoire malveillante reçoivent un signal
SIGSEGV. Sous Microsoft Windows, les processus accédant à la mémoire non autorisée reçoivent une exceptionSTATUS_ACCESS_VIOLATION
Par conséquent, je le traite comme Segfo.
Vous pouvez accéder à la mémoire même en Java avec sun.misc.Unsafe.
Alors ʻUnsafe.getUnsafe (). PutLong (0, 0) `ne peut pas être plus court? Tu pourrais penser,
Comme son nom l'indique, «unsafe» de java est une classe très dangereuse.
Vous pouvez modifier la valeur finale, allouer de la mémoire, y accéder et faire ce que vous voulez (bien qu'il semble y avoir des restrictions)
Par conséquent, le constructeur est privé et getunsafe () ne peut être instancié que sigetclassloder ()est nul.
La faille est de forcer l'instanciation avec l'API de réflexion, puis d'utiliser setAccessible (true) pour accéder à des méthodes normalement inaccessibles.
Enfin, avec putLong (address, x);, en entrant l'adresse mémoire dans ʻaddress et une valeur appropriée dans x`, nous avons pu attirer Segfo même avec java !!
Pouvoir magique de sun.misc.Unsafe Compétences puissantes qui peuvent être utilisées rapidement à tout moment - Réflexion [Violation de segmentation-wikipedia](https://ja.wikipedia.org/wiki/%E3%82%BB%E3%82%B0%E3%83%A1%E3%83%B3%E3%83%86% E3% 83% BC% E3% 82% B7% E3% 83% A7% E3% 83% B3% E9% 81% 95% E5% 8F% 8D)
N'hésitez pas à nous envoyer des demandes de modification. C'est un texte médiocre, mais merci d'avoir lu jusqu'au bout!
Recommended Posts