Return to Question

##Updates

Updates

Final Remarks

For posterity, I never really solved the issue, however I can confirm the underlying binary file was responsible for raising an exception in get_ascii_contents2. I've reloaded the same file, however as a raw binary file in one large segment and the function worked flawlessly.

##Updates

The code above appears valid after adding the missing parenthesis as mentioned in the comments. However this was only a typo in the post and not the source of the issue. The find_strings worked fine in other typical binaries. Further proof is that by using the idc.GetString(self.ea, self.length, self.type) also returned NoneType.

Diff mentioned that the get_ascii_contents2 is failing and thus returning null, which is very likely the cause. What is unclear is why the function is failing, while the GUI succeeds in locating most of the strings.

The first string at 0x208E is a trash Unicode string. The string at 0x21B0 is an actual ASCII string composed of 37 chars. I cannot post the complete string due to disclosure/legal issues. Notice that when displayed in the hex editor, the byte order of the ASCII view is inverted for an unknown reason. The bitness of the overall firmware is 16bit.

434F 5059 5249 4748 5420 A920 ... 4544 2000 0000 : OCYPIRHG T ¬ ... DE.

Finally, note that the function MakeStr works without any issue. I have the following code, when used at 0x21B0, will successfully create a string within a data segment:

def create_string(self, _startea, _endea, _segname=".const", _unicode=False):
        
        if (SegStart(_startea) == idc.BADADDR):
            self.create_data_segment(_startea, _endea, ".const")
        else:
            segtype = GetSegmentAttr(_startea, SEGATTR_TYPE)
            if (segtype != IDAEngine.SEG_TYPE_DATA):
                DelSeg(_startea, 0)
                self.create_data_segment(_startea, _endea, _segname)
        
        result = MakeStr(_startea, _endea)
        if (result == IDAEngine.FAIL):
            print "[-] Failed to create a string at 0x{:x} to 0x{:x}.".format(_startea, _endea)

At this point, I believe the structure of the firmware is to blame (combination of bitness, lack of symbols and an obsolete but supported microprocessor), however I couldn't pinpoint the exact issue. For now, since I can use find_strings() to retrieve the offsets and then use MakeStr on strings with a certain length and the manually vetting the "real" strings.