8 Replies
      Latest reply on Apr 13, 2020 2:04 AM by Aravind41
      quasimodo Level 1 Level 1 (0 points)

        I have been converting the entered password into NSString.


        NSString * tempStr = [[NSString alloc] initWithData: [[DummyEnc sharedInstance] decDummy] encoding: NSUTF8StringEncoding];


        NSString is required because tempStr handles other logic.

        But there is a problem that tempStr remains in memory, how do I fix it?


        Is there a way I would like to use it as an NSString?

        • Re: NSString remains in Memory
          eskimo Apple Staff Apple Staff (13,885 points)

          What do you mean by “remains in memory”?  That someone is holding a reference to it, and thus the object is never deallocated?  Or that once the object is deallocated the bytes representing the string are left in memory? [1]  Or something else?

          Share and Enjoy

          Quinn “The Eskimo!”
          Apple Developer Relations, Developer Technical Support, Core OS/Hardware
          let myEmail = "eskimo" + "1" + "@apple.com"

          [1] Folks complain about this from time to time because they have security-critical data in the string.

            • Re: NSString remains in Memory
              quasimodo Level 1 Level 1 (0 points)

              I have removed variables from memory by assigning nil to tempStr.

              But, The value of tempStr is exposed when memory dump is done on the jailbroken iPhone.

              It is assumed that a memory problem occurs when converting the NSData returned by the decDummy() method to NSString.

              When initializing a variable in NSString,I wonder if tempStr can not be freed  due to some characteristics (literal string, nstaggedpointer,?)

                • Re: NSString remains in Memory
                  PBK Level 7 Level 7 (3,765 points)

                  Try using NSMutableString and setting it to some other value when you are done with it.  Perhaps that will overwrite the memory space that was originally used for the pasword.


                  You can (and should) never use the original password but rather immediately create and store a salted hash with the contents of the .text property of some UITextField.  Perhaps that approach is the better one.

                    • Re: NSString remains in Memory
                      quasimodo Level 1 Level 1 (0 points)

                      As you say, I think that important data such as passwords should be well managed.

                      I want to test it right now, but I jailbreaked to test my old, unused phone (4s), but unfortunately the phone became a brick.


                      The existing code is tempStr = @ "000000" and tempStr = nil.

                      I wonder how tempStr (NSString) is different if it is an NSMutableString.


                      I want to know why. Thank you.

                        • Re: NSString remains in Memory
                          PBK Level 7 Level 7 (3,765 points)

                          tempStr=nil and tempStr=@“something else” will not affect the memory location originally pointed to by the variable tempStr. I am wondering whether [tempStr setString:@“something else”] will leave the pointer tempStr pointing to the same memory location and change the content of that location.  I do not know how the mutable property is implemented.

                          • Re: NSString remains in Memory
                            QuinceyMorris Level 8 Level 8 (6,060 points)

                            >> but unfortunately the phone became a brick


                            So it protected the password pretty well without any code, yes?


                            You can't actually solve your problem deterministically. The password is in (at least) two places: (1) the NSData object returned by [[DummyEnc sharedInstance] decDummy], where it's a UTF-8 string, and (2) the NSString object referred to by tempStr, where it's a UTF-16 code unit array.


                            Both of these use some kind of underlying storage (in general) for the actual data they contain, and you can't (in general) force that data to be overwritten.


                            For the NSData object, the best you can hope for is that its underlying buffer is overwritten by something after it's returned to the malloc pool and later reused. (Returning it to the pool will overwrite part of it, probably, but not all.) If it's really a NSMutableData object, you might be able to overwrite the underlying data yourself, before releasing it.


                            For the NSString object, the situation is similar, in that if it's really a NSMutableString you might be able to cause the underlying data to be overwritten. However, unlike NSData, there's no direct API for this, and you can't be certain that changing the value of a NSMutableString overwrites its internal buffer, instead of freeing it and allocating a new one.


                            Furthermore, you don't know for certain whether your code is causing any temporary copies of the data to be created. Perhaps not, but it's implementation dependent.


                            The only absolutely safe way is brick the phone. You seem to have discovered that solution empirically.

                    • Re: NSString remains in Memory
                      Aravind41 Level 1 Level 1 (0 points)

                      UndoManager of text field saves the text entered for undo purpose.


                      So incase if textfield is used.To completely remove the strings from the heap memory, along with replacing the text in the text field, undo manager should be disabled or removeAllActions of undoManager(after setting the text) should be executed on the TextField.


                      [textField.undoManager removeAllActions];