包含java无帐号数据保护的词条
今天给各位分享java无帐号数据保护的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
java加密
可以的，但是对jar包直接加密，目前只支持J2SE，还不支持J2EE。更多的还是用混编器（java obfuscator）。下面是关于HASP的介绍。
-----------------------------------------------------
针对java加密防止反编译的解决方案
众所周知，java开发语言提供了很方便的开发平台，开发出来的程序很容易在不同的平台上被移植，现在越来越多的人使用它来开发软件，与.net语言并驾齐驱。
Java有它方便的一面，同时也给开发者带来了一个不小的烦恼，就是保护程序代码变得困难，因为java语言编译和代码执行的特殊性，目前，除了HASP外，还没有一个更好的解决办法或保护方案，但如果不采取有力的措施，则自己辛辛苦苦开发出来的程序很容易被人复制而据为己有，一般情况下，大多数的人都是用混编器（java obfuscator）来把开发出来的程序进行打乱，以想达到防止反编译的目的，但是，这种方法在网上很容易找到相关的软件来重新整理，那么这个混编器工具也只能控制一些本来就没有办法的人，而对于稍懂工具的人几乎是透明的，没有任何意义。再说硬件加密锁，大多数厂商提供的加密锁只能进行dll的连接或简单的api调用，只要简单地反编译，就很容易把api去掉，这样加密锁根本起不了作用，那到底是否还有更好的解决办法呢？
现提供2种解决办法：
1、以色列阿拉丁公司的HASP HL加密锁提供的外壳加密工具中，有一个叫做数据加密的功能，这个功能可以很好的防止反编译而去掉api的调用，大家知道：硬件加密锁的保护原理就是让加密过的软件和硬件紧密地连接在一起，调用不会轻易地被剔除，这样才能持久地保护您的软件不被盗版，同时，这种方式使用起来非常简单，很容易被程序员掌握，要对一个软件实现保护，大约只需几分钟的时间就可以了，下面简单介绍一下它的原理：
运用HASP HL的外壳工具先把java解释器进行加密，那么，如果要启动这个解释器就需要有特定的加密锁存在，然后，再运用外壳工具中的数据加密功能把java程序(CLASS或JAR包)当作一个数据文件来进行加密处理，生成新的java程序(CLASS或JAR包)，因为这个加密过程是在锁内完成的，并采用了128位的AES算法，这样，加密后的java程序，无论你采用什么样的反编译工具，都是无法反编译出来的。您的软件也只有被加密过的java解释器并有加密锁的情况下才能正常运行，如果没有加密锁，程序不能运行，从而达到真正保护您的软件的目的。
2、HASP HL提供专门针对java外壳加密工具，直接加密jar包，防止外编译，目前只支持J2SE，将来会进一步支持J2EE，如果情况适合则是最简单的方法。
java开发人事系统，需要对敏感数据进行加密存储，为了不影响统计分析和查询功能，大家有好的实现方案吗？
没错，数据库中存的ID项加密。查询匹配时使用js或后台将用户输入的内容加密后去数据库匹配。查询到加密的数据库数据后在后台解密在发送到前台。如果对于安全要求较高就不要在js中解密。最后，类似于ID的数据加密模式和敏感信息的加密模式要不一致，这样可以保护你需要保护的敏感信息，即使有人通过js破解了你的ID等数据的加密，也无法获取真正的敏感信息。
【转】如何保护Java代码
以下从技术角度就常见的保护措施 和常用工具来看看如何有效保护java代码：1. 将java包装成exe 特点：将jar包装成可执行文件，便于使用，但对java程序没有任何保护。不要以为生成了exe就和普通可执行文件效果一样了。这些包装成exe的程序运行时都会将jar文件释放到临时目录，很容易获取。常用的工具有exe4j、jsmooth、NativeJ等等。jsmooth生成的exe运行时临时目录在exe所在目录中或是用户临时目录 中；exe4j生成的exe运行时临时目录在用户临时目录中；NativeJ生成的exe直接用winrar打开，然后用zip格式修复成一个jar文件，就得到了原文件。如果只是为了使用和发布方便，不需要保护java代码，使用这些工具是很好的选择。2. java混淆器特点：使用一种或多种处理方式将class文件、java源代码进行混淆处理后生成新的class，使混淆后的代码不易被反编译，而反编译后的代码难以阅 读和理解。这类混淆器工具很多，而且也很有成效。缺点：虽然混淆的代码反编译后不易读懂，但对于有经验的人或是多花些时间，还是能找到或计算出你代码中隐藏的敏感内容，而且在很多应用中不是全部代码都能混淆的，往往一些关键的库、类名、方法名、变量名等因使用要求的限制反而还不能混淆。3. 隔离java程序到服务端特点：把java程序放到服务端，让用户不能访问到class文件和相关配套文件，客户端只通过接口访问。这种方式在客户/服务模式的应用中能较好地保护java代码。缺点是：必须是客户/服务模式，这种特点限制了此种方式的使用范围；客户端因为逻辑的暴露始终是较为薄弱的环节，所以访问接口时一般都需要安全性认证。4. java加密保护特点：自定义ClassLoader，将class文件和相关文件加密，运行时由此ClassLoader解密相关文件并装载类，要起到保护作用必须自定 义本地代码执行器将自定义ClassLoader和加密解密的相关类和配套文件也保护起来。此种方式能很有效地保护java代码。缺点：可以通过替换JRE包中与类装载相关的java类或虚拟机动态库截获java字节码。 jar2exe属于这类工具。5. 提前编译技术(AOT) 特点：将java代码静态编译成本地机器码，脱离通用JRE。此种方式能够非常有效地保护java代码，且程序启动比通用JVM快一点。具有代表性的是GNU的gcj，可以做到对java代码完全提前编译，但gcj存在诸多局限性，如：对JRE 5不能完整支持、不支持JRE 6及以后的版本。由于java平台的复杂性，做到能及时支持最新java版本和JRE的完全提前编译是非常困难的，所以这类工具往往采取灵活方式，该用即时编译的地方还是 要用，成为提前编译和即时编译的混合体。缺点：由于与通用JRE的差异和java运用中的复杂性，并非java程序中的所有jar都能得到完全的保护；只能使用此种工具提供的一个运行环境，如果工具更新滞后或你需要特定版本的JRE，有可能得不到此种工具的支持。 Excelsior JET属于这类工具。6. 使用jni方式保护特点：将敏感的方法和数据通过jni方式处理。此种方式和“隔离java程序到服务端”有些类似，可以看作把需要保护的代码和数据“隔离”到动态库中，不同的是可以在单机程序中运用。缺点和上述“隔离java程序到服务端”类似。7. 不脱离JRE的综合方式保护特点：非提前编译，不脱离JRE，采用多种软保护方式，从多方面防止java程序被窃取。此种方式由于采取了多种保护措施，比如自定义执行器和装载器、加密、JNI、安全性检测、生成可执行文件等等，使保护力度大大增强，同样能够非常有效地保护java代码。缺点：由于jar文件存在方式的改变和java运用中的复杂性，并非java程序中的所有jar都能得到完全的保护；很有可能并不支持所有的JRE版本。 JXMaker属于此类工具。8. 用加密锁硬件保护特点：使用与硬件相关的专用程序将java虚拟机启动程序加壳，将虚拟机配套文件和java程序加密，启动的是加壳程序，由加壳程序建立一个与硬件相关的 受保护的运行环境，为了加强安全性可以和加密锁内植入的程序互动。此种方式与以上“不脱离JRE的综合方式保护”相似，只是使用了专用硬件设备，也能很好地保护java代码。缺点：有人认为加密锁用户使用上不太方便，且每个安装需要附带一个。从以上描述中我们可以看出：1. 各种保护方式都有其优缺点，应根据实际选用2. 要更好地保护java代码应该使用综合的保护措施3. 单机环境中要真正有效保护java代码，必须要有本地代码程序配合当然，安全都是相对的，一方面看你的保护措施和使用的工具能达到的程度，一方面看黑客的意愿和能力，不能只从技术上保护知识产权。总之，在java 代码保护方面可以采取各种可能的方式，不可拘泥于那些条条框框。
关于java无帐号数据保护和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
发布于：2022-12-10，除非注明，否则均为原创文章，转载请注明出处。