On Tue, 26 Aug 2025, Marcin Cieslak wrote:
On Tue, 26 Aug 2025, Mark Felder wrote:If someone could figure out a way to dynamically patch the class in the jar file -- either manually with a script the porter needs to run or as part of the port itself -- I'll pay out a $200 bounty. It would remove a lot of tedious pain when doing updates. I don't think it's possible though.What about something like the below. Requires xxd and jar. JARFILE=../Omada_SDN_Controller_v5.15.24.19_linux_x64/lib/omada-common-5.15.24.19.jar ISLINUXOS_CLASS="com/tplink/smb/omada/common/util/S.class"
[...]
Can't test if this really works at the moment, should update the omada-common-5.15.24.19.jar file in place. If "check" fails, we need to figure out whether the Linux-checking function has been moved, renamed or discarded.
This seems to let me go past the following message:
08-26-2025 22:28:52.159 ERROR [main] [] c.t.s.o.s.OmadaLinuxMain(): Error:
system is not linux, should not call this founction
By the way, to find out what the blackbox Java application is doing,
I find Java Security Manager to be a very useful tool, sadly deprecated and
removed
in Java 24:
with the following all.policy file:
grant {
permission java.security.AllPermission "", "";
}
java -Djava.security.manager -Djava.security.policy=all.policy
-Djava.security.debug=access ...
will spit out lots of messages about every file, socket, property or some other
resource
the code is trying to access.
Can be useful to figure out if some jar is really used and when, which files
are read/written, etc.
smime.p7s
Description: S/MIME Cryptographic Signature
