Log in

View Full Version : Together v6.0 -- FlexLM protection


bad2
April 18th, 2002, 06:30
just like the together V5.0, I decompile the zaq.class and find:

public static int ag = 0x17deeaab;
public static int ah = 0xb4c8d384;
public static int ai = 0xa2a1a978;
public static int aj = 0x1080480;
public static int ak = 0x5d5e5687;
public static int al = 0xfc9841d8;
public static int am = 0xc07286a2;
public static int an = 0xa0424122;
public static String ao = "uphfuifs";

ak = ~ak;
al++;
am ^= ai;
an |= aj;

then i get the keys.

but when i use the keys that i got to gen a license, it does not work.

Can anyone help.

Actlon
April 19th, 2002, 20:48
If Together 6.0 is anything like 5.0, the easiest solution is to take the licence class (zah.class in 5.0) & make all the functions return 0 (the 'good' value)...it has several advantages...together starts faster for one. If you're lucky there's a Jar or Zip called misclib that contains the original FlexLM files...which have meaningful names in them.

bad2
April 23rd, 2002, 09:07
Thanks, but after i patched the checkout funtion it still does not work.
It seems that the program ever not run to the flexlm checkout point before it fails check license.

Actlon
April 23rd, 2002, 18:21
Having checked the code I wrote, I've found there are some 'cavets':

btw. did you find the original FlexLM classes in the together package somewhere ? you'll probably need these to figure out the functions in the obsfuticated classes.

In license.class (=zah.class for v5) there is a function named 'ok' returning a boolean...evidentally thats got to return 'true'...in my copy the fn 'ok' got obsfuticated to 'b' returning boolean & had no parameters.

There are also some methods returning Strings...you can probably figure out appropritate strings from the disassemblies

Good Luck

PS Could you ZIP & attach a copy of the original FlexLM files for Together 6.0 ? cheers !

PPS I think probably what happens when the class is inited is something like this:

licence lic = new license(1,2,...,n);
if( ! lic.ok() ) {
// license didn't init properly, so do some kind of error exit here
}

bad2
April 24th, 2002, 05:31
I also patched the ok function, but it still not work. does anything I do wrong?

The original class file and the one I patched is here.

Actlon
April 24th, 2002, 20:00
Okay, I probably wasn't very clear in what I said

The stuff in misclib does nothing as far as I know (I'm not even sure why they supply it).

I didn't mean that you need to patch the license.class file in misclib. What you need to do is locate the equivelent class file in the main package (still 'together.jar' I assume). The easiest way to do this is to unpack the jar file & then search for various strings.

The FlexLM files are actual in the main package but renamed & their members are also renamed. Fortunatelly the literal strings in the files don't change from the FlexLM files supplied in misclib. Looking through the license.class file you attached I can find the strings "JavaDisplay", "JavaUser" and "JavaHost".

With the unpacked files search through them for the strings...with any luck they will be present in only one file. If they are more than 1 files, you will need to decompile them. The correct class will be the one that has exactly the same numbers of variables with the same types AND the same numbers of methods with the same prototypes.

The correct FlexLM files shouldn't reference any of the com.togethersoft.* packages.

You should be able to figure out which methods in the class you find correspond to the mehods in the license.class file by the prototypes and because with most decompilers they will decompile into the same positions in the decompiled source files.

Basically all you need to do is gut the code of the class & fix the return values to suitable okay values (in terms of FlexLM, 0 usually indicates success, anything else is an error value. As I noted before 'ok' should return true & some of the functions should return a String [eg getUserName, getHostName] + some of the String returning fuctions should return null [eg warning].

Recompile the relevent files & replace the class files, then jar everything back up into a new version of together.jar and [with luck] bob's your uncle!

Hope that clears things up a bit & helps

bad2
April 25th, 2002, 16:20
I searched the upacked together.jar files, and can't find the file that you mentioned. but I saw the zad.class that contain's the error message. so i decompiled it and find something like

filename endsWith(".tg"
and exists:
license.edition
license.id
license.expiration
license.hostid
license.numofinstances

so it may not direct use flexlm licensing system.

Actlon
April 26th, 2002, 00:53
Looks like they've changed the system slightly...I've eventually d'l ed the installation...only I'm having trouble b/c it won't install properly b/c it can't find jvm.dll - presumably the MS Java VM ? don't really want to download the version with VM b/c I've only got a 56k modem & it's slow...

However back to the story, I've been able to extract the archives & so I've had a quick look:

About five classes import flexlm.license, of which 2 are sub-classes of another one.

zaq.class contains references to flexlm.class and in places it checks stuff out and checks it back in at other places. It's interesting that they are now referencing the FlexLM classes directly rather than copies. The next thing we need to do is establish if it's using the FlexLM files in MiscLib

Oh yeah - another thing - I just remembered that Together 5.0 does it's own check to establish if a license file is on the system in the correct place before letting FlexLM have a look - the file can be blank, it doesn't matter. It may be that the file is called *.tg ? usually FlexLM schemes have files with names like license.dat or *.lic. I think that perhaps the license file name is specified in a config file somewhere ?

I'll have a better look tomorrow when I'm less tired

Actlon
April 26th, 2002, 19:05
Okay - I figured how to hack the installer so that it found Java & installed.

Hunted arround a bit in the code & eventually figured out a solution...which is suprisingly easy.

Here's how I found it - edited some what to remove many of the false steps I took !

Had a look at zad.class b/c of many licensing error messages being there. I found a method that examined a property called "license.edition" - sounded interesting. Discovered that the class that set it (zaf.class) set it to a default value of "whiteboard"...& the querying method checked the string several times for "whiteboard" and at times was making bad decisions based on this. So I hex hacked the zaf.class so that it returned "blackboard" instead. This - when put into together.jar - allowed Together to run past the splash screen - but there were a lot of errors - things didn't turn up, several exceptions (that were handled) projects didn't load properly and there were 'feature not present' errors. So I cast arround a bit & then noticed an array of strings in zaq.class that had a seemingly random string then a comprehendable string in a repeated patern - of which "whiteboard" was one. I then tried changing "whiteboard" in zaf.class to "enterprise" because they were the same length - same results as "blackboard" - strange. Cast around a bit more and I found that there was a class referenced in zad.class called zdg6.class that contained strings including the various levels of installation - but not including "enterprise" - and it seemed to identify the privalages of each installation level. Out of these levels I selected "controlcenter" and put it into the zaf.class file. When I ran Together it ran perfectly - and suprisingly it doesn't seem to do any other licensing checks - which I can't explaing, but it does seem a bit lame. Oh, and everything seems to work.

To hex patch java strings in zaf.class you need to find the string in the file (it's very short ~500bytes). The byte before it gives the length of the string (for whiteboard, length = 0xA) followed by the ascii chars in the string. To patch it to "controlcenter" (length 0xD), you need to change this byte to 0xD and _insert_ an extra 3 bytes into the file at the point of the string, set the whole string to read "controlcenter", put it back into the together.jar file. Together should run perfectly now as a "ControlCenter" version which seems to be the most powerful version avalible commersially. As you will see if you look, there are several versions avalible - including a version that is not sold.

Hope that helps a bit.