Hiding Variables in Debug

TurnipTruckTurnipTruck Junior MemberPosts: 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.

Comments

  • viningvining X Member Posts: 4,353
    TurnipTruck wrote:
    Can someone explain how to hide variables from the list in debug?
    What do you mean by "hide variables from the list"?
    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.
  • SensivaSensiva Junior Member Posts: 211
    I think...

    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.
  • yuriyuri Junior Member Posts: 861
    Sensiva wrote: »
    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.
  • TurnipTruckTurnipTruck Junior Member Posts: 1,485
    Yes, I don't want my declared variables to be able to be watched. Under normal circumstances, you can watch them in debug.
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    Give them funky names that no one could possibly guess to type in. It's not like you can call up a list of all the variables used ...

    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).
  • yuriyuri Junior Member Posts: 861
    DHawthorne wrote: »
    It's not like you can call up a list of all the variables used ...

    oh really??? :p you CAN call up a list of all variables used.
    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...
  • Stephen BoltonStephen Bolton Junior Member Posts: 345
    yuri wrote: »
    oh really??? :p you CAN call up a list of all variables used.
    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...
    But NSX will only list vars from the code currently in the edit window, not the processor. It appears to get the list upon opening of a workspace, and compiling only.

    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....)
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    yuri wrote: »
    oh really??? :p you CAN call up a list of all variables used.
    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...

    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.
  • Spire_JeffSpire_Jeff Formerly Caffeinated Programmer Posts: 1,917
    I'm not sure if this will help, but you could also turn off the Compile with Debug Info option in the preferences>Netlinx Compiler. Intuitively, I would think this would accomplish what you want, but this is an assumption on my part :)

    Jeff
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    Spire_Jeff wrote: »
    I'm not sure if this will help, but you could also turn off the Compile with Debug Info option in the preferences>Netlinx Compiler. Intuitively, I would think this would accomplish what you want, but this is an assumption on my part :)

    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.
  • mpullinmpullin Obvious Troll Account, Marked for Deletion Posts: 949
    Maybe just write a coder/decoder function that uses some kind of hash and only store the variable in hashed form. When you need access to the variable, you make a STACK_VAR and unhash the contents of the variable, putting the unhashed version in the STACK_VAR, and then just work with that.
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    I suspect we are attacking this problem from the wrong angle. Exactly why do you need to hide a variable? Only someone with access to NS and the debugger, and the system itself, can call the list up; I have to presume you are trying to hide something sensitive like login information from installers. If it's something like that, you need to encrypt that value, and only unencrypt it on the fly as it is sent to whatever it is sent to, so it never resides in a variable unencrypted.

    An exact knowledge of the situation might lead to a better idea how to deal with it.
  • TurnipTruckTurnipTruck Junior Member Posts: 1,485
    I am trying to hide the variables in a module that I will be selling. A lot of work went into the module and being able to view variables may help reveal my secret herbs and spices. I've since found that making variables volatile in the module prevents them from being visible in debug entirely.
  • GSLogicGSLogic Original Member Posts: 562
    I've since found that making variables volatile in the module prevents them from being visible in debug entirely.
    I was to late to respond but you figured it out - volatile vars.
    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.
  • viningvining X Member Posts: 4,353
    GSLogic wrote:
    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.
    For something like this I just put a constant string for the key in the compiled code. Once a key is entered and compared to the constant key I write it as a XML file to the master so that on every reboot or reload it will look for the XML file and again compare the key so it doesn't have to be manually re-entered every time. Otherwise what could you possibly want to hide that's a variable in the compiled module?

    DHawthorne wrote:
    Exactly why do you need to hide a variable?
    I second the question.
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    I am late to this party, but if variable name hiding is what you are trying to do, wouldn't it be easier to write your module with the names you are using, but then just put it through a script that obfuscates each variable name to something uninterpretable like var_1, var_2 etc? You could write your own obfuscator or there is likely one already available. Or you could do it manually but that would be a pain.
    Paul
  • AMXJeffAMXJeff Senior Member Posts: 450
    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.


    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...
    Spire_Jeff wrote: »
    I'm not sure if this will help, but you could also turn off the Compile with Debug Info option in the preferences>Netlinx Compiler. Intuitively, I would think this would accomplish what you want, but this is an assumption on my part
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    AMXJeff wrote: »
    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
  • Stephen BoltonStephen Bolton Junior Member Posts: 345
    AMXJeff wrote: »
    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...
    If I've read you right, you suggest ensuring the option under >>Settings>>Preferences>>Netlinx compiler for 'compile with debug info' is NOT checked.

    Mine was already not checked and every variable is visible, no matter what I do.

    Maybe I misunderstood your post...
  • AMXJeffAMXJeff Senior Member Posts: 450
    No you did not misunderstand, I actually tested it before I posted. You uncheck compile with debug information, then actually compile your module. You now can check it again and compile other modules/source code that you want to debug. Any variable that was in that module that you compiled without debug information will not show up in the variable pick list, plus you wont be able to debug it even if you know the name.
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    AMXJeff wrote: »
    No you did not misunderstand, I actually tested it before I posted. You uncheck compile with debug information, then actually compile your module. You now can check it again and compile other modules/source code that you want to debug. Any variable that was in that module that you compiled without debug information will not show up in the variable pick list, plus you wont be able to debug it even if you know the name.

    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.
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    DHawthorne wrote: »
    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.
  • Spire_JeffSpire_Jeff Formerly Caffeinated Programmer Posts: 1,917
    Dave, without debug info being compiled, are you still able to step through the program in debug mode as well as view the variables?

    If so, anyone know if compiling without debug info has any speed advantages or lowers the processor overhead?

    Jeff
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    Spire_Jeff wrote: »
    Dave, without debug info being compiled, are you still able to step through the program in debug mode as well as view the variables?

    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.
  • Spire_JeffSpire_Jeff Formerly Caffeinated Programmer Posts: 1,917
    Thanks, I missed the amended statement. Sometimes I take a while from the time I click on reply until I click on send. This is mainly dependent on phone calls I receive and disasters I have to deal with in between the beginning and end of my post :)

    Anyone have any ideas as to how much overhead the debug info creates for the processor?

    Jeff
  • Stephen BoltonStephen Bolton Junior Member Posts: 345
    DHawthorne wrote: »
    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 don't use compile with debug and the box is not checked, and I definitely get a list of vars.

    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.

    ;-)
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    I don't use compile with debug and the box is not checked, and I definitely get a list of vars.

    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.
  • To add more mud to the murky waters of a debug session in NS2...

    - 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.
  • Stephen BoltonStephen Bolton Junior Member Posts: 345
    dvalosek wrote: »
    Studio nor the FileTransfer program have a mechanism of pulling the TKN off the master, but there are ways of grabbing the TKN file.
    Could you expand/explain what you mean here a bit please David?
  • Spire_JeffSpire_Jeff Formerly Caffeinated Programmer Posts: 1,917
    My guess is that it involves pulling the flash card and.... well, you can figure out the rest. Or, maybe there is a way to accomplish it via telnet/ftp. I think my philosophy can best ne summed up by this little story:

    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
Sign In or Register to comment.