Hiding Variables in Debug
TurnipTruck
Posts: 1,485
Greetings,
Can someone explain how to hide variables from the list in debug?
I ask for the purpose of writing premium modules to be released as tko only.
Thank you.
Can someone explain how to hide variables from the list in debug?
I ask for the purpose of writing premium modules to be released as tko only.
Thank you.
0
Comments
in the main or include file: DEFINE_VARIABLE VOLATILE INTEGER nAP_DeBug = 0 ; //debug variable, allows debug msg's to be sent to master DEFINE_MODULE 'VAV_AP_PrecisLT_Rev1' UNIT_1 (vdvAP,dvAP_Arry,dvAPTP_Arry,ccZONE_OUT_GRP_NAMES, (**) ccZONE_OUT_NAMES,ccINPUT_NAMES,cVOL_DEFAULT_LVL, (**) nDefaultAudioSource,nAP_DeBug,dvDMS_AP_Arry,nDMS_APBtnArry,nDMSZONEIndexArry, (**) dvKP_AP_Arry,nKP_APBtnArry,nKPZONEIndexArry,nAPzoneLocalGrpArry_1, (**) nAPzoneLocalGrpArry_2) in the module: MODULE_NAME='VAV_AP_PrecisLT_Rev1' (DEV vdvAP,DEV dvAP_Arry[],DEV dvTP_Arry[],CHAR ZONE_OUT_GRP_NAMES[][], CHAR ZONE_OUT_NAMES[][],CHAR INPUT_NAMES[][],CHAR cVolDefaultLVL[], INTEGER nDefaultAudioIn,INTEGER nAP_DeBug,DEV dvDMS_AP_Arry[],INTEGER nDMS_APBtnArry[], INTEGER nDMSZONEIndexArry[],DEV dvKP_AP_Arry[],INTEGER nKP_APBtnArry[],INTEGER nKPZONEIndexArry[], INTEGER nAPzoneLocalGrpArry_1[],INTEGER nAPzoneLocalGrpArry_2[]) DEFINE_FUNCTION CHAR fnDebug(CHAR iMSG[]) { if(nAP_DeBug) { SEND_STRING 0,"'AutoPatch Module-',iMSG,CRLF" ; RETURN TRUE ; } RETURN FALSE ; } where ever you want debug info sent to the master you call the function fnDeBug with whatever mssage or variables you wnat for your string. fnDebug("'Device:',fnDEV_TO_STRING(DATA.DEVICE),' Parsed Number not valid "',itoa(nOutPuts + iOutPutOffset),'", line-<',ITOA(__LINE__),'>'") ;I don't know if this is what you're asking for but I declare a debug variable specifically for each device and pass it to the module in the modules paremeter list. When I need to debug I sent the debug variable to one in NS2's debug window. I put these types of debug lines through out the code when creating a module but once the modules about set I remove all but the essential ones.
I think Trunip means how to prevent vairables he decleared in a module from being watched in a module like passwords of MACs ...etc.
In this case , variables in modules are not accessible at all.
as far as i know, i can 'see' variables in modules using the 'add variable from list' option in my debug window.
Also, the debugger itself is so buggy, that the opposite also works. Make your variable names very generic, and use them in every single module the same way. They won't be able to watch them because the multiple instances feature never did work right and they will more than likely get the wrong one (OK, so I'm being a bit sarcastic here, the debugger flaws drive me crazy).
oh really???
Only STACK_VARs or LOCAL_VARs (or both) can't be watched, that might be a way of doing it, but it's a bit difficult to bug check...
I downloaded one of my programs into the NI and then went and got a totally unrelated workspace out and then right clicked in the debug window. It only showed me vars from the code in the edit window, not what was in the processor.
Even though it must connect to the master to run debug, the info is still only from the edit window....
...so if you have vars used for security, for instance, unless the code is in the window, I don't think they can be discovered.
Oh, and it appears to get things a bit muddled also - see pic (BUT...the names are real....)
You know, I somehow never noticed that feature! Not very useful really, now that I have seen it, I doubt I'll use it much.
Jeff
Nope, I tried it (now that I know that list exists!); they still show even with debug off. Makes you wonder exactly what it does.
An exact knowledge of the situation might lead to a better idea how to deal with it.
I also use an encode/decode to scramble my unlock keys, which are generated by the NI's master serial number that the mod is running on.
DHawthorne wrote: I second the question.
Paul
Just compile your module without debug information. Your variables from that module will not show up in any list, plus if you know the names, you wont be able to watch them in debug even if you wanted to...
oops ---- I see Spire_Jeff already said this... But this is the only way to not get the variables on the list...
Will this work even if the distributed tko is included in a project with debug information turned on? Or is it even necessary? I can't recall whether I can see variable names within a tko during a debug session, but my guess would be no.
Thanks,
Paul
Mine was already not checked and every variable is visible, no matter what I do.
Maybe I misunderstood your post...
I tested it too, and I still got a list. It wasn't complete, but somehow was able to pull some of the variables up anyway. The difference (which is one of the reasons I asked why this exercise in the first place) is if you have the source open in NS, it still can create a variable list, debug info or no, and it was able to debug variables that existed in this list. Of course, if you have the source anyway, it hardly matters.
I have to amend that statement - turns out, on second look, it's the persistent variables that it can still find. If they aren't persistent, they don't show.
If so, anyone know if compiling without debug info has any speed advantages or lowers the processor overhead?
Jeff
No, like my "amended" statement says, it can only see persistent variables. Earlier in the thread, I posted something about being able to see the entire list; I did that at home real fast, and I probably goofed something, making that statement invalid. But you can't put break points and step through the code if there is no debug information.
Anyone have any ideas as to how much overhead the debug info creates for the processor?
Jeff
Dave, you might have the source, but perhaps not for an included module, yet these vars become visible in the list.
Well, on my system anyhow.
;-)
That's what I first saw when I tried it on my home system, but when I couldn't duplicate it at work, I figured I went too fast and made a mistake. Apparently, there is more to this than what is obvious.
- Studio will crack the TKN file to get a list of variables, regardless if the "compile with debug info" is checked in the NetLinx Compiler preference tab. Studio does not poll the master for variables. We do verify that the TKN that is on the user's PC matches the one on the master. Studio will yell at the user if they are not the same.
- The "debug info" that is added to the TKN is basically line numbers of executable code that allows the user to set breakpoints within their source code.
- Basically, if someone is trying to "debug" a master to gain proprietary knowledge, they will need the TKN on their PC since that is where the list of variables are retrieved from. Studio nor the FileTransfer program have a mechanism of pulling the TKN off the master, but there are ways of grabbing the TKN file.
Hope this helps. I definitely understand your pain and confusion on this matter.
Two men, Mike and Bob, are getting ready to go hiking in bear country. The get out of their SUV and start to get their gear ready for the hike. Mike is in the middle of tying his hiking boots when he looks over at Bob at notices Bob putting on Tennis Shoes. Mike is confused and asks Bob why he isn't putting on his hiking boots? Bob tells him that this is bear country and he has a fear of being eaten by a bear. Mike starts to laugh and tells him that there is no way a human can outrun a bear. Bob looks at Mike very seriously and says "I'm not trying to outrun the bear, I just have to run faster than you!"
The moral of the story is that you just have to make the code difficult enough to reverse engineer that it becomes easier to write it yourself. Anyone that has the skill and access to grab a TKN and reverse engineer it, could likely write their own code much easier. If they are trying to circumvent some security, my guess is that there are easier methods than reverse engineering a TKN (such as putting in a sniffer to grab the actual commands being sent to the device being controlled).
If you are really concerned about your code being stolen, you could always strip all comments from the distribution code and then go in and search replace all of the variable names to be very nondescript names such as a, b, c, d, .... This would render the code very difficult to read and understand.
Just my humble opinion,
Jeff