起因是这样的,我司购买了一套 Java 服务的部署版,原先我想 unzip ,并且修改一下 IP 地址(因公司换 IP 了)
结果重新打包后会出现运行错误,大约错误如下
An attempt was made to call the method javax.servlet.ServletContext.getVirtualServerName()Ljava/lang/String; but it does not exist. Its class, javax.servlet.ServletContext, is available from the following locations:
Action:
Correct the classpath of your application so that it contains a single, compatible version of javax.servlet.ServletContext
看着像是依赖包冲突了
操作流程
unzip xxx.jar -d jar
cd jar
zip -0r xxx.jar ./*
比较神奇,有人研究过这方面的问题吗?厂商原先的包是可以运行的
只要 unzip 再 zip 就会出现,即使不改任何配置
已经再安排找厂商拿新的 jar 包了,单纯好奇有技术是不是能防止别人 unzip 修改配置?
1
mineralsalt 2023-07-24 14:35:57 +08:00
当然能改, 不仅能改配置文件, class 都能反编译修改, 只是你的方法不对
|
2
zhazi 2023-07-24 14:43:55 +08:00
没必要 unzip 直接 vim 进去改就行了,打包时可能会有其他步骤,zip 时被忽略了
|
3
wetalk 2023-07-24 14:45:16 +08:00
这要从 jar 打包原理说起了
|
4
githmb 2023-07-24 14:45:53 +08:00
额,Jar 不是有签名吗,你能这样改的啊
|
5
leeseaside 2023-07-24 14:49:10 +08:00 1
可以改,,
如果是 win ,推荐使用 WinRAR,直接打开 xxx.jar 包,然后把想添加的文件压进去,压缩方式选择存储 如果是 linux, 解压出来 jar -xvf cxf-0.0.1-SNAPSHOT.jar BOOT-INF/classes/application.properties 压回去 jar -uvf cxf-0.0.1-SNAPSHOT.jar BOOT-INF/classes/application.properties |
6
mikasa1024 2023-07-24 14:51:18 +08:00 1
用 jar -cfM0 打包,例如:
jar -cvfM0 server.jar BOOT-INF/classes BOOT-INF/lib META-INF org |
7
nkidgm 2023-07-24 14:51:49 +08:00
对啊,类似安卓 APK 那种,改完还要重新签名,安卓系统才能安装那份包。
|
8
cslive 2023-07-24 15:07:59 +08:00
winrar 直接打开 jar 包该,你直接 zip 压缩,java 不认,少了参数
|
9
nekoneko 2023-07-24 15:12:26 +08:00
听 5 楼的
|
10
thevita 2023-07-24 15:23:32 +08:00
软件防串改本来就是个很复杂的问题,各种方案无非是,是用更高可信的代码来验证其他代码的可信性,收窄代码保护的范围,比如你可以这样:
你可以用一个 自己的 loader(只是一个说法不一定是 ClassLoader ) 来加载 jar 和 class ,通过签名来保证加载代码可信, 这样就能把对抗的点收窄到 这个 loader 里,如果你用 native code ,一些传统的保护方案也能用了,比如 vmp 之类的 当然这样也只是提高了成本而已,你还可以更近一步,把信任继续往前推,比如依靠 os 或者 硬件提供的功能来实现,这就是可信计算搞的那堆东西了 |
11
mankismi OP 谢谢各位大哥,确实用 java 压回去可以。先前也试过 用 jar 命令解压全部,再打包,也不行,没想到能压单个文件进去。学习了
|
12
whp1473 2023-07-25 01:49:24 +08:00
当然可以改,不光配置可以,代码也可以反编译改了再编译回去。
如果想要防止修改再运行,有几种方案: (1)掩耳盗铃版:将代码配置全部对称加密,然后将密码生成在内部的一个文件中,在类加载器加载时解密。效果:解压后,反编译或 VIM 全部乱码,不能修改,但如果知道运行步骤是可以找到密码和反编译启动的加密逻辑的。 (2)输入密码式:可以在启动时-Dpasswrod 输入密码,原理同上。效果:更安全,因为无法得到密码,光反编译加密逻辑不行。 (3)JDK 加密:第二种方式可以通过另一种方式获得,JAVA 探针,也就是对 JVM 进程 Hook ,然后直接反编译运行时字节码,然后拿到字节码后反向生成代码再编译。因此需要通过对 JDK 加壳进行防护,加密的逻辑被内嵌到 JDK 中,必须使用专用的 JDK 才可以启动。也就是将加密的攻防下沉到二进制层面,更难获得。 其他的比如网络远程服务认证、本地硬件码认证都是可以通过 Hook 形式反编译和断点绕过的,只是点越多越难绕而已。下沉到二进制层面就类似游戏外挂那种了,需要找进程号、内存地址解析、线程解析等,拼的是肝。 |
13
mikasa1024 2023-07-25 10:24:17 +08:00
@whp1473 #12
jdk 加密作用不是很大,只要能运行在标准 jvm 上的代码,都可以获取到字节码进而反编译出 java 代码 如果你指的是,修改 jvm 的读取和验证 java class 文件的逻辑,确实有更好的效果。缺点就是,现在很多依赖反射的框架会直接读取 class ,导致框架运行可能出错 再就是 aot 这两年发展好点,编译为 native code 感觉是个不错的方案 之前看知乎的这个问题与 RednaxelaFX 的回答,学到很多 https://www.zhihu.com/question/19766494 |
14
fengpan567 2023-07-25 16:29:30 +08:00
配置文件的话直接 vim 命令就能改
|
15
whp1473 2023-08-10 19:41:09 +08:00
@mikasa1024 给 C++的 JDK 加壳,然后该 JVM 的接口,限制非认证的反编译运行,但会造成比如 Hook 这种无法运行。
也可以参考新的 JVM 比如 Graalvm SpringBoot3.0 也支持,会编译成 native ,启动超快内存占用低,缺点不支持反射,有些框架不支持。 |