cancel
Showing results for 
Search instead for 
Did you mean: 
jmoleary
Pilgrim

Upgrade to 2017.08.0: TRA strings work fine but number values return 0

I'm having a problem using TRA with FlexNet embedded in my C++ application. At startup, after loading the TRA environment, I can successfully retrieve all the string values from TRA aliases but any attempt to retrieve a *number* from a TRA alias returns a value of 0. The tra_get_value() function does not report any error, it just sets the output parameter to zero. It doesn't matter whether I try to go through the TDT type or if I make a raw call to tra_get_value().

This is for a TRA file and project that has worked perfectly until now.

I'm using FlexNet Embedded 2017.08.0.
I have just upgraded from version 2016.08.0.
Even once I upgraded, I used the same identity header files that I generated back in version 2016.08.0. I'm running with a license file that I generated under that identity as well.

Any idea what I'm doing wrong here or how to determine what the problem is? Am I supposed to generate new identity files every time I upgrade the FlexNet embedded SDK version? I hope not. Otherwise I would have to issue new licenses to all my clients just to give them a new binary.

Edit: I've recently discovered that this only happens if I am debugging the application. If I run the application outside of the debugger, everything works fine. Again, I don't understand this as until now, I was able to debug just fine. My TRA file debugging options are set to allow debugging and they have not changed: Here is the relevant section



options.debug = {
["trace"] = false,
["allow_debugger"] = true,
["allow_failure"] = false,
["visual_studio"] = true,
}
options.header = "MyCompanyName"
options.TDT = { ["typename"] = "TFT" }
options.verify_modules = {
[ "windows" ] = {
["kernel32"] = { ["checksigned"] = true },
["User32"] = { ["checksigned"] = true },
["wintrust"] = { ["checksigned"] = true },
["crypt32"] = { ["checksigned"] = true },
["psapi"] = { ["checksigned"] = true, ["lazy"] = true },
["FlxCore"] = { ["checksum"] = true, ["lazy"] = true, ["target"] = "FlxCore64" },
},
}

options.multithreaded = true
Labels (1)
0 Kudos
3 Replies
jmoleary
Pilgrim

An Answer (in case anyone actually reads this forum)

Managed to solve my own problem. Doesn't look like too anybody answers things here so maybe this will help the next guy.

Apparently the options settings I had still allow you to debug on Visual Studio 15 but never allow you to debug on Visual Studio 17

options.debug = {
["trace"] = false,
["allow_debugger"] = true,
["allow_failure"] = false,
["visual_studio"] = true,
}


That "allow_failure" needs to be set to true if you want the TFT integer variables to work when debugging. But the worst part is that in the sort of failure I was having they simply fail silently. They just return 0. I would have hoped for an exception or something.
0 Kudos

Re: An Answer (in case anyone actually reads this forum)

That "allow_failure" needs to be set to true if you want the TFT integer variables to work when debugging. But the worst part is that in the sort of failure I was having they simply fail silently. They just return 0. I would have hoped for an exception or something. been there , done that . Not working for me anymore.
0 Kudos
Highlighted
Flexera mjolnir
Flexera

Re: An Answer (in case anyone actually reads this forum)

This is the sort of behaviour (integers returning zero) you would see if tampering is detected. It was a design decision not to raise exceptions in the event of tampering as it could yield clues to someone attempting static analysis of the code.

To diagnose your particular issue you should enable TRA trace which will hopefully give you an explanation of what is failing. I would speculate that the reason why tampering appears to be detected in your scenario is that there is a software breakpoint set in the protected executable/dll, which effectively modifies the code section (even though it appears not to have). TRA correctly identifies these changes as tampering. Clearing all breakpoints would hopefully solve the problem (albeit making debugging more challenging!).

Some debuggers use a different approach to debugging involving hardware breakpoints and you might have more success there (see http://www.nynaeve.net/?p=80 for an overview of the differences).

Hope that helps!