• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Need help editing Java ByteCode.

 
Greenhorn
Posts: 9
C++ Chrome Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello! I am making a Custom Minecraft Launcher as a side project, and ran into a problem. Compiling the Jar file can take multiple hours (its really big), and when I had tested the jar, it didn't run quite right. As this is a project to expand my skills in Java, I would like to try to find and fix the problem myself. However, I don't want to decompile, edit, and recompile the file, as this will take to long only to edit a few lines. I have downloaded JBE and want to use it to edit the file. However, I have noticed that the code is in Java Bytecode, and not Java. I don't want to have to learn the whole language just to edit a few lines. Could someone that knows Java Bytecode please help me edit the file? (also sorry Jesse, but there will be way to many Very Long Lines to edit) Also let me know if you need any more info!

What function one should look like:


 
Brennan Towry
Greenhorn
Posts: 9
C++ Chrome Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What function one looks like:

 
Brennan Towry
Greenhorn
Posts: 9
C++ Chrome Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
 
Brennan Towry
Greenhorn
Posts: 9
C++ Chrome Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What function two should look like:



What function two looks like:


 
Bartender
Posts: 1737
63
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The Very Long Line complaints don't apply to Java ByteCode, which normally one should never be looking at unless one is writing debuggers or code generators...

I would remind you "Don't do this at work!" but you obviously know that.

I am "not bad" at assembly language, but have mostly avoided learning the bytecode, beyond a few factoids that impact how one should best write Java source code...

this may be very interesting.

When you say "What X looks like" and "What X should look like" you mean:
"What the byte code for X currently looks like" and "What the source code for X should look like, give me the byte code that I would get for this"

I can say that regarding C/C++ compiled down to native code, this would be a fools errand, because it is too easy to change relative offsets with your changes.

I worry whether some lines in your byte code like:
goto 31

will make this a similarly bad idea or not.  I suspect yes, but don't know byte code (or your changes) well enough...

well, should be interesting, it is way beyond my byte code wrangling abilities...

When I've seen other hackers work at problems like this, they definitely opted to de-compile/re-compile, I suspect there's good reason for that in terms of small changes in source resulting in large changes in bytecode, but we will see.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Shades of the dinosaurs! You're actually proposing to patch a Java class?!!!

Jesse, gotos are an inherent part of bytecodes. Bytecodes are the assembly-language of Java and are too low-level to support structured programming constructs.

Brennan, if you are using an intelligent build environment like Maven, only the initial build should take "hours". The system is smart enough that unless you do a "clean" operation between builds, only the changed parts should actually get recompiled.

Hours seems a bit exaggerated, though for Java. I've built some pretty big projects and probably had them take no more than 20 minutes, absolute tops. For hours, I'd have to build in something like C, where, for example the FreeCAD project probably takes at least half an hour and I don't want to think about doing that on a slow machine like a Raspberry Pi! I'm pretty sure I can build a Linux kernal in less time!
 
Jesse Silverman
Bartender
Posts: 1737
63
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:Shades of the dinosaurs! You're actually proposing to patch a Java class?!!!

Jesse, gotos are an inherent part of bytecodes. Bytecodes are the assembly-language of Java and are too low-level to support structured programming constructs.

Brennan, if you are using an intelligent build environment like Maven, only the initial build should take "hours". The system is smart enough that unless you do a "clean" operation between builds, only the changed parts should actually get recompiled.

Hours seems a bit exaggerated, though for Java. I've built some pretty big projects and probably had them take no more than 20 minutes, absolute tops. For hours, I'd have to build in something like C, where, for example the FreeCAD project probably takes at least half an hour and I don't want to think about doing that on a slow machine like a Raspberry Pi! I'm pretty sure I can build a Linux kernal in less time!



I worked at two places that once did patches thinking they were expedient, and swore off of them as an absolute rule that was never again to be violated.
It was unsupportable.  One stopped at the end of the 90's or the very beginning of the Millenium, another wised up ~2010 maybe (but was only doing it in rare extreme cases for several years before that).

I understand this is a hobbyist project, but even as a hobbyist, learning how to decompile/recompile from byte code, marginally useful for extreme cases, patching the byte code directly, I can't endorse even for hobbyist purposes.

I agree that something seems wrong if the minimal build he can get out of this takes hours...
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There's actually two kinds of patching, and the type referred to here is the older and uglier one.

Back in the Cretaceous Period I worked on IBM mainframes as an OS-level programmer. We did some original work, but a lot of what we did was install and configure vendor packages - both IBM's own OS and other products and some third-party products. Those mainframes had less overall power than an Apple Watch, so building a major system could indeed take several hours. But since bugs were no less common back then and you can't just "turn a mainframe off and on again" every time something goes sour, we needed a way to update the products we had installed. Rather than have IBM rebuild the entire OS every time something needed tweaking, we'd use a program called "ZAP" to alter the loadable code (equivalent to a class). Often the patch that we'd ZAP in would be a jump to a spare area of memory, do what it needed, and then go back to where it came from. Frequent offenders even had a pre-reserved area of memory to patch into.

It's not that bad when everyone's doing assembly language and the instruction set is tidy enough that you can assemble/disassemble code in your head. It gets much uglier when working with high-level languages, and uglier still when optimizing compilers are used and the generated code no longer linearly follows the source code.


The other kind of patching is still done, primarily on Unix-like systems. The Unix "patch" program takes the "diff" output of two text files and applies them as a series of text edits (using "sed" or the like). This isn't so much a bug-fix strategy as it is something that distro package builders do to tweak source code to make it more inline with the quirks of that particular distro, allowing a common source code for all distros. It has also been used to ship trial changes from one developer to another.


But, as I said, the patching in question is of the first kind, not the second, and I cannot recommend it either. The Java world is just not set up for that.
 
Jesse Silverman
Bartender
Posts: 1737
63
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
LOL!!

My employer called 'em Zaps too, even when they weren't on the Mainframe (inheritance at work)?

The other thing is a $300 question in the Larry Wall category in Jeopardy:

wikipedia wrote:The original patch program was written by Larry Wall (who went on to create the Perl programming language) and posted to mod.sources[1] (which later became comp.sources.unix) in May 1985. A variant of the program (but not the only one)[2][3][4] is part of the GNU project[5] and is maintained by the FSF.



About 20% of the Great Java Programmers I try to learn from as often as possible (my estimate and my estimation) seem to feel it is great to know lots about byte code if you do Java for a living.

Whenever they show you a new Java source construct, they compile it and hit javap immediately to show you "What this thing really does".

About 80% never seem to do this (in public).

It is on my list, partially because I am used to peeking under the hood to fix problems that are mystifying everyone who doesn't know how to do that.
I can't even count how many times I consulted a series called literally "Under the Hood" while debugging extremely nasty Windows issues.
I almost never code in assembly on x86/x64, but I sure have debugged there lots.

But yeah, trying to just mess with the already generated byte code seems like a bad use of time compared to figuring out how to make my build less pathologically slow.

Trying to do it without "spending much time learning byte code" seems more questionable than that.

I was wondering whether the resulting code would still pass the "byte code verification" step that I barely remember any more than the name of.  I was thinking it might not.

At least I can say that 20% of Java Gurus I try to learn from seem to love looking at the byte codes, implying it might make me a better Java programmer...but I never saw them try to edit it.  They treat it as read-only stuff.

I like being helpful, in this case I will help by not trying to get involved.

I was inferring that any non-extremely-trivial zap would break all the gotos referencing code beneath it, from what I know of assembly language.
I know there are no non-trivial Java programs that are goto-free in the byte code, just as in assembly language.
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
People used to use decompilers to convert the bytecode back to Java code, which they could then edit for whatever changes they needed to make. This was done when the original source code was unavailable.

Of course the unavailability of the source code was often done on purpose by its owner and this process was of dubious correctness, but "The dog ate my source code" could be used to cover that up. And occasionally it was true -- the source code was lost to a disk crash but the compiled classes were accessible on the computer where they had been installed.

However that hasn't been feasible since about Java 5. That's when generics arrived to complicate the process with "erasure", and subsequent Java features made it even more infeasible.

But anyway it seems that the OP does have the source code, so that's not relevant. Personally I wouldn't dare to mess with the bytecode either.
 
Rancher
Posts: 326
14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@OP
Well, everytime I read about "custom minecraft launcher" it's either to run it in an unlicensed manner -> please buy the game if you want to play it, it's not too expensive ... or to create what's know as "hacked clients" to give you an advantage over other players in competitive game modes, or simple: to cheat.
That you won't get any help for the first case should be clear without any further explanation why. But from what you posted you seem to try to cgange the way game assets are checked - so I guess you're after a hacked client to cheat. Just google for some, there're many out there.
Fun fact: many of these unofficial stuff often come with additional malicious code like malware or viruses ... and often cost money.
C'mon kiddo - what's the fun about cheating?
Also: current launchers aren't distributed as java applications anymore for a long time already. So the question you want to modify a rather old java launcher maxes it even more suspicious that you're up to no good.
 
Brennan Towry
Greenhorn
Posts: 9
C++ Chrome Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In response to Matthew Bendford, this launcher will be able to run my custom Minecraft mods that improve performance by writing over the majority of the Minecraft code, however, this piece of code is overriding the file changes, it thinks that the files are not updated because they are not the same. I tried deleting the file, but that would mean rewriting a lot more stuff. It seems that the best option here is to change the file. Please do let me know if that is against Mojang's EULA! If it is, do you have another solution to the problem?
 
Matthew Bendford
Rancher
Posts: 326
14
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
MAJOR WARNING: I'm NOT a lawyer - do NOT rely of the following  - it's my own personal opinion about how I understand the various licenses involved. I'm NOT responsible for anything resulting from the following!

That out of the way: The job of a launcher, at least the kind minecraft uses, is to check a list of local assets against a list. So the simplest way of manipulation would be to redirect the launcher to a different list which contains the data for the patched version.

As you talk about modding: Have a look at Forge. It provides an installer compatible with current official launcher. After you got Forge running it's just a matter of dropping the mods into the mods directory and they get loaded on game start up.

Is it legal? Well, as far as I understand it: Mojang always supported the modding community and it became a meme that at one unknown time in the future they will provide an official modding api. The one thing the license denies is to
a) redistribute modified launcher or game code without permission
b) make money out of it
At least the second point is heavily abused by many modders hiding their cotent behind ad-walls ... so in fact they do make at least a few bucks out of modified game code - but there's no case known mojang ever filed a case against a modder.
Fun fact: most of modern minecraft assets comes from the modding community, some modders were hired and worked for mojang.
There also countless of malware infected modified clients all over the net - often require to pay for them.

So, if you want to stick to the "at least it's accepted" side use the official launcher and some mod api like forge or fabric. Sure, you can try on your own, but without any means of insult: The first idea you came up with was modifying an old launcher at bytecode level to "patch" the asset checking instead of going some way simpler path like alter the asset list. Whatever it is you want to accomplish - going this way it's doomed to fail rather hard.

If you still really want to go this route a minecraft modding forum would be a better place to ask for help than in this generic developers forum here.
 
Jesse Silverman
Bartender
Posts: 1737
63
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I learned a lot about the ever-decreasing ease of de-compiling byte code in a useful way from this thread, so there's that.

The last I had really paid attention to it, long ago, it was "pretty easy".  No more.

I had no opinion on the Minecraft-specific stuff, but would bet Matt is right.
 
Matthew Bendford
Rancher
Posts: 326
14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not quite sure about Minecrafts official code as it's pretty much just designed around the LWJGL framework (one of the reasons of its poor performance in the early years), but at least the Forge modding api makes quite heavy use of runtime patching several classes by using some special bytecode-modifying libs. I'm not sure how it works or if those libs are from the Forge team, but to me the fact that such libs exist to "hot patch" a class at runtime at the bytecode level means that it's maybe a more common use case than we may aware of.

As for low-level patching in more general: I once had a look into how "no cd cracks" are done for games. Well, depending on how many checks are in the game code it takes quite some time to find and "patch" the all, even with tools designed to help to semi-automate this process. But also drm protection goes the self-modifying code route like denuvo: during runtime it randomly adds drm checks into running code while not crashing to ASLR. It's a play of chicken between developers and pirates going back to the 70s.
 
Jesse Silverman
Bartender
Posts: 1737
63
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Matthew Bendford wrote:

As for low-level patching in more general: I once had a look into how "no cd cracks" are done for games. Well, depending on how many checks are in the game code it takes quite some time to find and "patch" the all, even with tools designed to help to semi-automate this process. But also drm protection goes the self-modifying code route like denuvo: during runtime it randomly adds drm checks into running code while not crashing to ASLR. It's a play of chicken between developers and pirates going back to the 70s.



I did tons and tons of disassembly of 68000 code from boot-loaded Atari ST games in the late 80's into the early 90's.

The most interesting thing was that while it was very easy to see the state of the machine when some User program got started up in normal use, there were tons of undocumented states of everything that the copy protection depended on, so trying to run and trace the code from a machine that was already running would be useless.  I had a lot of documentation, but nothing about what state everything was in when only the boot-sector loader from the BIOS had run...

Disassembling was tricky.  I don't remember why but I was basically rolling my own.  I think that disassembling a contiguous piece of executable code was off-the-shelf, but there would be code intermixed with data and I remember basically having heuristic code that ran for a long time and eventually disassembled stuff to code + data in a fairly reliable way.  I had to leave it running all day while I was at school or at work...

I keep hearing that getting compilable Java source from byte code is ever-decreasingly practical.  I knew it was pretty easy way back...but there's just way too much important basic Java I want to know better than to spend time looking at that any time soon.

 
Saloon Keeper
Posts: 7585
176
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesse Silverman wrote:I did tons and tons of disassembly of 68000 code from boot-loaded Atari ST games in the late 80's into the early 90's.


Ah, the memories :-) As a student in the nineties I spent significant time patching shareware MacOS software so it was fully usable without paying. Thanks to the disassembler in ResEdit, that was pretty easy for many apps where the developers released code with the debug symbols still present. 68K assembler was close enough to 6502 assembler (which I knew by heart) to let me patch out the nagging dialogs and functionality limitations. To my credit, I bought every single software I patched when I started earning money after college.

I keep hearing that getting compilable Java source from byte code is ever-decreasingly practical.


JD-GUI is a pretty usable one that kept up with post-Java 5 changes.
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK, so we've established that Jesse and Tim have a dark past as software pirates.

I think I may have mentioned that I still have notebooks full of disassembled IBM mainframe code. Mostly from FORTRAN and OS core dumps. It's where I learned the trick where the converging series for trig and log functions can be collapsed.

I did a little disassembly on Amiga code, but then they finally issued the belated prorammers guides. Amiga games were generally not copy-protected (or could be purchased non-protected for a small additional fee). They never had the rampant piracy that Atari ST games did. Although if I'd been more obsessed with Sim City... They had a sheet full of play codes printed in black ink on dark red paper (to prevent photocopying). Even wonder why regulation chessboards are brown and beige rather than black and red? It's because there's this thing called red-black color blindness.  
 
Jesse Silverman
Bartender
Posts: 1737
63
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just for reference, I normally only disassembled software to fix bugs.

e.g. code wrote past end of memory, which generated a fatal core dump on 4MB machines, harmless on 512k thru 2MB configurations, incompatibility with recent OS Roms (yeah, the OS was still in ROM!!) or only worked on some models of disk drives (I should say runs, since the model numbers were the same), etc.

But boy, did I learn a lot.

I never accepted pirated software, nor distributed it, but I did buy a lot of european/uk software on close outs at bargain prices, not having a job yet and being a full-time engineering student.

I did often think that piracy helped kill the Atari ST platform, also, at various points the worldwide installed base of Atari ST plus Amiga was actually higher as a total than Mac, if they had wound up being one single platform, which was very close (Atari and Commodore basically switched places in 1985) the whole world would have come out differently.

I will note that when I hit VI in Cygwin at work in 2018, you could still see that it was based on the ST version of Stevie, tho the VIM I am running right now on this box was of course adapted from the Amiga Port, not the original:
https://en.wikipedia.org/wiki/Stevie_(text_editor)

 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Piracy was widely blamed for the Atari ST's demise, though I think a lot of it was also that it was basically an MS-DOS machine without the IBM compatibility. Made a good MIDI controller, though.

The Amiga had the first consumer real-time multi-tasking OS, custom graphics and sound hardware (stereo separation and THD were listed among the specs on the carton.) And utter crap support from upper management. Still, Babylon 5 and Robocop owed a debt to it.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic