Java without JVM

[BiggBoss]

Hello there!
I always feel like i had to learn any language like C++ in order to create applications that people could run without have jdk in their computer. However, and googling for other purpose, a caught this:

http://www.javaworld.com/javaqa/2001-06 ... 5-exe.html

There (after a little explanation), drives you to some pages where you can download a native code compiler. I didnt know about that and was so surprised to download one (excelsior JET) and try it: After build my own gui application, compile it and then compile to native code, i take to a machine w/o java, run it and...voila! My program was fully working without the need of Java in the computer

Of course everything has his advantages and disadvantages, in this case, the native code compilation make your application platform-dependient, which means, only will work in the platform where it was build, something that wouldnt happen with the non-native code java application

[Vapulabe]

Well, it may pose some problems with L2J as L2J uses the "reflexion" mechanism to do some "runtime" compiling and linking...

Which means that all the .java from L2DP would not work...

[BiggBoss]

i wasnt talking about l2j
I made a launcher for a future server ( i hope ) to restrict them to join with X active programs but they would need Java on their computers...till now
Heres the advantage small-medium (mostly GUI) applications for client users

[Vapulabe]

it'd be way to easy to bypass... They would only need to check the hosts file while the client is running... Or doing a netstat to see the IP address... and then, start L2 by themself...

If you want to put such a restriction, it's be better to use a server-based approach based on the IP... and allows exceptions for people on the same NAT (they'd have to declare their IP and the people playing... Any other account using the IP would be blocked and you may put restrictions on the interractions between the account (using logs and such to check).

[BiggBoss]

you dont know how my launcher works . Its alredy tested

[Vapulabe]

Well, if it's a launcher for L2, it has to start L2 at the end... and in order to have L2 be able to connect to another server, it has to resolve L2Authd.lineage.com to your server address... And once connected, a simple "netstat" will show the current established connections...

Which means that players who are at least a little bit technical aware will be able to bypass it, giving them an unfair advantage on the other players...

[BiggBoss]

really, you have 0 idea about how its work, how come you say

Well, if it's a launcher for L2, it has to start L2 at the end... and in order to have L2 be able to connect to another server, it has to resolve L2Authd.lineage.com to your server address... And once connected, a simple "netstat" will show the current established connections...

stop that stupid thing about netstat if you dont have idea about it. Now we know who will not be able to bypass it

[Vapulabe]

Well, I'd be able to bypass it anyway as all my network trafic goes trhough a linux box responsible for NAT... it'd be a trivial task to monitor the whole network trafic...

The only part that could be tricky is if the whole connexion is done through a VPN... But even then, host/port of the VPN would be easy to find and I don't think that JAVA has the needed support to set up a VPN tunnel...

Which makes me think that VPN could be a (legal) solution against GameGuard and hosts checks... More specifically, if the remote end of the VPN appears to be the L2authd destination address no need to edit hosts file). But i'tll be a little pore tricky to configure server-side (need to install a VPN server which could prove to be challenge to some L2J admins)

[BiggBoss]

thanks, im now 120% sure you have 0 idea
You would not be able to bypass it, not cause its impossible, but your brainless words make me sure about that

[denser]

only way to encrypt it)) it self by self key encryption) like bank-systems) i have already couple of kind.

have many ways to make unbypassable systems so BB is right) if you domt know how it works - you couldt say that you can broke it)

[Vapulabe]

thanks, im now 120% sure you have 0 idea
You would not be able to bypass it, not cause its impossible, but your brainless words make me sure about that

1) no need to behave like that... I'm certainly NOT stupid and I may know more about cryptography, networks and similar than you...
2) there are not many possible way to control what server L2 connects to... Either you change the name resolution (DNS/hosts/...), you modify packet routing (given the internet system, the only way to do it is by encapsulating the data by technologies like VPN or IPv6 over IPv4,...), you do packet rewritting (on the fly destination IP change) or you MOD the L2 client to change it's server address...
3) There is no such thing as security by obscurity... And a packet sniffer can do wonders to see the destination of the network packets !!!

Well, it's true that you could use port-knocking in front of the (login) server, with your program doing the knocks... but again, a simple trafic logger would detect the pattern...

But well, let's wait until your server is up and I'll be happy to try your "wrapper" and to bypass it

Edit :
-------
By the way, I won't be silly enough to run your "closed source wrapper"' on my computer... A VMWare or VirtualBox virtual machine will be enough for my tests... I'm not stupid enough to try potentially destructive code on my computer !!!

[BiggBoss]

thanks
Due your 1) point:
now we know all you are is a wannabe-anyone in the world, potentially society problems of inferiority cause you may be shy or a social marginalization.

Due your 2) point:
you have 0 idea about what im talking about and it makes me to fully reject your 1) point

Due your 3) point:
same as 2)

You cannot differnce whats a launcher and whats a wrapper ?
Seriously, you may like any other kind of hobby than computer technology

This could be ended at first, whith your stupid answer to my first post. Someone with the knowledges you say that you owns would know how to distingish between the point of my post and your please-see-how-skilled-i-am question, why? 1)I said the purpose in the post, you did just ignore it and try to become someone by asking a non-sense question, 2) YOU DO NOT KNOW HOW MY LAUNCHER WORKS, MR FORTUNE-TELLER

I may be wrong and i dunno whats are your programming/computer related skills (couldnt find any proof on this forum about those skills you have) and sorry if you get angry, but thats the truth. And of course with this post im not saying im a god or something like that as you may are interpreting, just come to post something which could be useful for others

[Vapulabe]

Let's make things clear :

1) about my programming skills
High enough to have the whole social service of province-teaching rely on a program I made... It's not about an hobby but my day work... and the program has to take account for more money on one single year than you'll ever have on your bank account...
I don't spend that much time on L2J... because I've other project on my own... Both on computer (mix between electronics and microcontrollers) and outside computer (raising a small boy takes much time)

2) Please note that a Launcher IS a wrapper... specialized in the launching of another program but nevertheless a wrapper...Everything that wraps around another program is a wrapper, even if it don't does anything before running that program or after it had ended...

3) Indeed, I don't know how you wrapper works... But as you programmed it in Java, I seriously doubt that you read the L2 executable in memory, manyally link it and relocate it and then do a direct jump into the code... so a good guess is that you end calling the OS syscall responsible to execute a file... Well, as you programmed it in Java, it'll more likely be calling the Java API responsible for executing some host-native executable.

4) If you check back in the beginning of the thread, you'll see that I only told you that it'd be very difficult to protect client-side because most client-side restrictions are likely to be bypassed. And I added that i'd probably be better to do a server side protection... On that, you took that "you're silly, you don't know how I did it" attitude... I don't think that trying to point you to probable plausible attacks against your wrapper was insulting... But your answers were clearly insulting...

5) If you want a good control on the connections, given the L2-client very closed and locked nature, the approach that has the most chance to lead to some result is using some encapsulating done (VPN, IPv4 over IPv4, ...) with decent crypto to authenticate the connection... But I don't think that Java allows to control the windows' VPN subsystem...

6) If you don't see any contributed code from me here, it's for several reason : I only sent a few bugfixes, some time ago... I don't spend much time on L2J (I'm more busy with VHDL and FPGA's at the moment)... And I like less and less the behaviour of some people on this forum... L2J is a huge piece of code with about not documentation (javadoc is not so difficult to use...)

So, Mr Snake Oil, go ahead with your program...

-----------------

note to Denser

I agree that strong crypto (like Diffie Helman key generation and AES for example) is quite secure... But we are here talking about a (pure ?) JAVA wrapper and JAVA is very restrictive when it comes about interactions between the program and the OS...
As the socket creation is done by the L2 client, the only way to apply some extra crypto on the communication would be to use some C/C++ program which would interact with the Windows network system... And you know that GameGuard is very restrictive about the network subsystem... This leaves the "normal" windows network capabilities, including the VPN one...
Also, when crypto and such is involved, the security must rely in the keys and not on the algorithms... A good reference is "applied cryptography" by Bruce schneier... this book don't limit itself on the cryptographic algorithms but also to the protocol problems and such...
Unpassable systems are possible when at least one part is unavailable: the key and the algorithm... Authentication (key is the value being tested), signing (key is not fully known) can be done securely. Hardware based system can also be secure if well designed (keys and/or algorithms may be protected). Fully software based systems are not... an example is the DVD/BluRay software players which allowed to crack the DVD/Bluray encryption.

[BiggBoss]

ye, whatever
now lets stop and leave it for the original content

[Vapulabe]

OK... so let's go back about that program to compile Java to native code...

AFAIK, there is a Java frontend in GCC... But I never tried it... I don't know if it allows Java -> Native or only Java -> Bytecode...

They speak about Cygnus port of GCC... but another one (which may be easier to use) is MinGW (sourceforge project if I remind well). I know that their port of the C/C++ part of GCC is good (it's also the recomended port by Qt Free under windows).

As I said in my first post, the biggest problem about these is that such a native code will lack some of the core functionnalities of Java like the Reflexibility which allows to examine class in runtime (like get the list of methods available or call a specific method) and may affect the use of dynamic class loading (like it's done for DB access). Basically, only a subset of Java can be used as a (bad ?) trend in java is to rely more and more on these API...

If what you want is to make a small native code program, maybe looking to QT/GPL + MinGW could be a good move... but it's true that you lose thing like Swing and the Garbage collector... Qt had lots of example code and is much cleaner than Microsoft's library (and extra bonus, it also exists under linux). There is also GTK for windows (used for example for The Gimp). GTK approach may be easier to learn (no OO needed and you build your GUI using an approach similar to Java (Frames with pack manager)). Here again, you may use MinGW.

Just my 2 cent on Java bytecode to native... it may sound great for small applications but may soon become useless when you add DB and other...