Sometime, when doing reverse in some binaries I get this kind of ASCII strings:

00000000: 4665 5446 6554 4665 5446 6554 4665 5446  FeTFeTFeTFeTFeTF
00000010: 6554 4665 5446 6554 4665 5446 6554 4665  eTFeTFeTFeTFeTFe
00000020: 5446 6554 4665 5446 6554 4665 5446 6554  TFeTFeTFeTFeTFeT
00000030: 4665 5446 6554 4665 5446 6554 4665 5446  FeTFeTFeTFeTFeTF
00000040: 6554 4665 5446 6554 4665 5446 6554 4665  eTFeTFeTFeTFeTFe
00000050: 5446 6554 4665 5446 6554 4665 5446 6554  TFeTFeTFeTFeTFeT

What does it correspond to ?

Edit: following editor request, clarification: When you have a reverse engineering, static analysis style, sometime you end up with binaries you can't run, can't even load in debugger / IDA due to strange arch or lack of known entry point. Therefore, understanding the content of the files, sections, strings is very useful. Hence the question.

  • 1
    Why don't you pass the string to a disassembler to find out? Anyway, it's impossible to say what it corresponds to, as you don't mention the processor type and there are thousands of different processors around.
    – nrz
    Jun 6, 2014 at 11:09
  • This happens here in ARM (Cortex v9) but I've seen it also on other arch (x86 and MIPS i believe).
    – Phil L.
    Jun 6, 2014 at 11:10
  • Looks possibly like some kind of encoding or compression of (originally) repeating string...
    – Phil L.
    Jun 6, 2014 at 12:14
  • 1
    In ye olde MS-DOS .COM programs it was not uncommon to see stackstackstackstack...
    – Jongware
    Jun 6, 2014 at 17:15
  • 1
    Can't be ARM instructions, they're always 4 bytes long (unless thumb instructions, but they're 2 bytes long), and that string is 3 bytes, repeating. Probably a space filler to reserve room for something. Weird though, as that implies static storage. For FeT, nothing comes to mind as an acronym or whatnot. Probably a form of 'stackstackstack' as mentioned previously. Keep working on it, Another clue would be relative position in file. Disassembly / Analysis is a long process, experience and intuition help too.
    – lornix
    Jun 6, 2014 at 18:43

1 Answer 1


In IDA, you'll get the above if you have code that has an data reference to that memory address. It happens to me all the time, if the data "could be a string" IDA's auto magic type guesser does just that.

So, the true data could be words, or dwords, but because it's all in the ASCII range, bang one big epic string. I tend to jump to that location, hit undefine (u), and the data (d) once to turn to byte, and wait until later when I understand the data layout/structure better.

  • Yes, but here IDA doesn't help since entry point not known and when you choose valid start of opcode but arbitrary entry point (typing (c) on such offset), very few strings get referenced.
    – Phil L.
    Jun 6, 2014 at 17:27
  • Well, IDA is interactive, so start anywhere within the disassembly, find something that looks like a return statement (or something that looks like a frame start), and tell IDA that it is code. Repeat until you have the whole thing analysed. Jun 7, 2014 at 6:26
  • Maybe I misunderstood your question, when/why this might happen. verse I have a file that is only. Jun 11, 2014 at 4:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.