Je veux désactiver la trace de la pile à être générée lorsqu'une exception est lancée.
J'ai utilisé, mais je pouvais toujours voir la trace à être générée. Comment peux-tu faire ça? De plus, je dois détecter si quelqu'un débogage de ma classe. Je veux désactiver toutes les traces d'exception. Je ne peux pas utiliser Obfuscation car mon produit est un SDK qui sera utilisé dans le développement. Je propose une exécution également utilisée lorsque les gens veulent déployer leurs applications construites à l'aide de mon SDK. Mes exigences, c'est que toute personne utilisant mes pots d'exécution ne devrait pas être en mesure de déboguer le code écrit ... ou au moins je vais le rendre difficile de déboguer en évitant la génération de la trace de la pile à partir de mes bocaux d'exécution. Une façon dont j'ai trouvé, c'est que toutes les exceptions provenant de mes bocaux d'exécution, je voudrais simplement les attraper et définir un réseau de cheminée vide à l'objet d'exception et le rejeter ... < / p> pourquoi une telle exigence?
Supposons que vous développiez une application à l'aide de mon SDK. (SDK Bors ne peut pas grouper avec votre application..Je les ai limitées et la finale finale :) !!) Pour exécuter votre application sur votre ordinateur, vous devez installer la machine. Runtime sur la machine du client et exécutez votre application. Maintenant, que si votre client commence à développer ses propres applications à l'aide de mes pots d'exécution !! C'est une menace pour mon entreprise ... c'est pourquoi l'horrible exigence. Pourquoi désactiver la trace de la pile?
En désactivant la génération de la génération ou la méthode de la méthode de la pile, je voulais faire du développement de code avec mes pots d'exécution difficiles et c'est pourquoi j'ai commencé ma question de cette façon ... suggérez une autre solution pour atteindre une telle exigence ...
6 Réponses :
Voulez-vous désactiver pour toutes les exceptions?
Sans savoir ce que vous essayez d'atteindre, je dirais que c'est le mauvais chemin de descendre. Si vous vous attendez à ce qu'une exception soit lancée que vous soyez heureux de vous ignorer, vous devez l'attraper explicitement et le gérer (où la manipulation peut simplement signifier l'ignorer ou enregistrer un message court sans la trace de la pile complète).
Il y a quelques parties complexes de la JVM (au moins, la mise en œuvre du Sun de Sun) qui ne fonctionnent pas si la génération de trace de pile est désactivée (j'ai vu cela dans la mise en œuvre de certaines méthodes de support de réflexion). Donc, je ne pense pas que la génération de trace de pile puisse être désactivée du tout. Les méthodes En toutes généralités, tout code Java peut être analysé de manière transparente, si seulement via l'instrumentation ByTecode (Bytecode modifiée avec des instructions supplémentaires lorsqu'elle est chargée). La seule défense connue contre une telle analyse (je suppose que vous essayez de garder votre code interne confidentiel) est l'obfuscation. Voir par exemple Proguard . Obfuscation fera des traces de pile inutiles à tout utilisateur trop curieux (et, malheureusement, il fait de déboguer très difficile, pour les mêmes raisons). runtime.trace * () sont à propos de quelque chose d'autre (un outil de débogage beaucoup plus complet que les traces de pile).
Je veux désactiver toutes les traces d'exception. Je ne peux pas utiliser Obfuscation car mon produit est un SDK qui sera utilisé dans le développement. Je propose une exécution également utilisée lorsque les gens veulent déployer leurs applications construites à l'aide de mon SDK. Mes exigences, c'est que toute personne utilisant mes pots d'exécution ne devrait pas être en mesure de déboguer le code écrit ... ou au moins je vais le rendre difficile de déboguer en évitant la génération de la trace de la pile à partir de mes bocaux d'exécution.
Une façon dont j'ai trouvé, c'est que toutes les exceptions originaires de mes bocaux d'exécution, je voudrais simplement les attraper et définir un tableau de cheminée vide à l'exception et le rejeter ...
Alors, pourquoi ne pas distribuer des pots d'exécution et de développement distincts, où les pots d'exécution sont obscurcissés?
Je ne pense pas qu'il est possible que le code sache qu'il est débogué, sauf indirectement (et peu fiable) signifie que la mesure de la mesure de la durée nécessaire pour exécuter des séquences de code.
Il n'est pas possible de désactiver toutes les structures de pile. Vous peut désactiver les chaînes de strack pour des classes d'exception que vous définissez vous-même, en remplacement Mais si vous envisagez de faire ces choses pour prévenir l'ingénierie inverse, vous perdriez votre temps même si vous pouviez le faire. Il serait simple d'identifier le code d'ingénierie anti-inverse de votre application et d'éditer les fichiers ByTecode pertinents pour le désactiver.
Si j'étais client, je préférerais probablement que vous achèteriez un code obscope que cela. Mais probablement, j'essayais très fort de trouver un fournisseur de logiciels alternatifs que n'a pas traité ses clients payants comme vols . lancable.illinstacktrace () pour ne rien faire.
Mais cela ne fonctionnera pas pour les cours que vous ne pouvez pas changer.
Si je peux partager mon expérience: j'ai écrit une fois une très bonne solution Java pour une opération simple mais coûteuse. Ma licence avec le client était qu'ils me paient tous les mois pour tant qu'ils utilisent le produit. Un jour, ils ont cessé de payer. À travers des canaux non officiels, j'ai découvert qu'ils ont analysé mon code et ont embauché une personne moins chère pour capitaliser sur toute la logique d'entreprise que j'ai apprise (que vous pouvez voir soigneusement dans le code, mais nous a pris des âges à l'agrégat). Depuis lors, j'ai développé mon propre langage de programmation et compilateur natif, qui sont secrets. Bonne chance d'analyser ça!
L'hypothèse est que "si votre code est facile à lire, il est donc facile de programmer et, donc ne vaut donc rien". C'est comme la vieille blague: "500 dollars? Il ne vous fallu que 15 minutes pour réparer la fuite!" - "Mais cela m'a fallu 25 ans pour savoir comment le trouver!".
Votre erreur était que vous avez essayé d'activer votre demande en un flux de revenus. Vous devriez juste vous y vendre pour un paiement à une fois off. Si vous souhaitiez un flux de revenus, vous avez dû faire appel à la demande, un service exécuté sur le matériel que vous contrôlez. Je suppose que la deuxième erreur ne poursuivait pas leur pantalon. Mais voici la chose. Les étapes que l'OP propose de faire ne voudrait pas avoir arrêté d'un ingénieur inversé déterminé de toute façon.
Là dehors? Vous êtes au Royaume-Uni? Ils ont un système juridique sonore, non? Si vous avez pris soin de l'élaboration du contrat / du contrat de licence, l'ingénierie inverse devrait être une violation claire du contrat. Trouvez un cabinet d'avocats qui travaillera pour des frais de contingence ...
Je voulais éviter d'expliquer l'histoire de ma vie :) Je vis au Royaume-Uni mais j'ai également vécu dans plusieurs autres pays, où l'idée de la propriété intellectuelle est considérée comme risible. Même les entreprises britanniques sont (parfois) de manière stratégique ne s'appuient pas sur le concept de propriété intellectuelle. J'ai travaillé pour une immense entreprise où ils n'ont pas intentionnellement déposé pour les brevets. La technologie en question est brillante et simple à copier. Un brevet impliquerait de révéler des détails sur cette technologie au public, qui pourrait être au Royaume-Uni ou non. En supposant que "vous pourriez poursuivre leur pantalon" n'est pas une stratégie hermétique.
Je suis aussi curieux de savoir pourquoi vous voulez faire cela, mais si vous avez vraiment vos raisons, vous avez au moins deux options:
Si vous souhaitez désactiver la génération de trace de pile pour vos propres implémentations d'exception, vous pouvez remplacez simplement la méthode FillInstackTrace: Si vous souhaitez le désactiver pour toutes les exceptions , vous pouvez utiliser un agent d'instrumentation de code d'octet pour remplacer la remplissage de remplissage. méthode dans la classe lancée. Cela ne fonctionnera toutefois que pour Java 6, puisque vous, en Java 5, ne sont pas autorisés à remplacer une méthode natale (FillinstackTrace) avec une méthode Java à l'aide d'une instrumentation.
Remplacer FillInstackTrace pour toutes les exceptions est susceptible de casser des choses; par exemple. Sécurité Java.
@Stephen: Vous voulez-vous expliquer pourquoi, ou si cela devrait-il être évident?
IIRC, certains contrôles de sécurité impliquent l'examen de la CallStack pour voir si l'appelant est un code «privilégié». IIRC cela s'appuie sur FillinstackTrace.
De plus, vous voulez 'retourner cela', pas "retour null", sinon vous violez le Javadoc de FillinstackTrace ()
Voir com.sun.org.apache.xerces.internal.Parsers.AbstractDomparser .Abort
lanceur.setStackTrace (StackTraceElement [] StackTrace) bloquera les ajouts à StackTrace après son appel:
Throwable t = new Throwable();
StackTraceElement[] myStackTrace = new StackTraceElement[] {
new StackTraceElement("MySDKClass","MySDKMethod","MySDKFile",0)
};
t.setStackTrace(trace);
Vous pouvez rediriger toutes les exceptions à un emplacement différent, par exemple: ou simplement: note: N'utilisez jamais le code ci-dessus en production, à moins que vous souhaitiez donner à vos collègues un temps difficile
Je pense qu'il y a deux questions distinctes ici. Vous devriez les résoudre séparément.
S'il vous plaît ajouter plus de détails, par exemple pourquoi voulez-vous désactiver la trace de la pile? Que voulez-vous dire exactement par "Désactiver StackTrace" (comme c'est juste la chaîne d'exceptions)
Je pense que vous donnez à vos utilisateurs un mauvais service ici. Un SDK ne donne pas d'exceptions utiles?
«Mes exigences, c'est que toute personne utilisant mes pots d'exécution ne devrait pas être en mesure de déboguer le code écrit» - c'est une exigence horrible et une approche horrible pour essayer de répondre à cette "exigence".
@ user279436: Est-ce pour le développement d'applications mobiles? Quoi qu'il en soit, vous vous trompez si vous pensez que parce que vous avez une API publique, vous ne pouvez pas utiliser PROGUARD. Vous pouvez utiliser PROGUARD pour obscurcir toutes les parties de votre SDK qui ne sont pas accessibles au public. C'est une caractéristique très pratique et très puissante de PROGUARD.
Supposons que vous développiez une application à l'aide de mon SDK. (SDK Bors ne peut pas grouper avec votre application..Je les ai limitées et la finale finale :) !!) Pour exécuter votre application sur votre ordinateur, vous devez installer la machine. Runtime sur la machine du client et exécutez votre application. Maintenant, que si votre client commence à développer ses propres applications à l'aide de mes pots d'exécution !! C'est une menace pour mon entreprise ... c'est pourquoi l'horrible exigence.
En désactivant la génération de la génération ou la méthode de la méthode de la pile, je souhaitais faire du développement de code avec mes pots d'exécution difficiles et c'est pourquoi j'ai commencé ma question de cette façon ... suggérez une autre solution pour atteindre une telle exigence ...