tag:blogger.com,1999:blog-2188843482388834721.post2563638538907164015..comments2023-05-14T00:49:23.489-07:00Comments on Routards Team Blog: Defcon 22 CTF - Badgerroutardzhttp://www.blogger.com/profile/16885996044315754891noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-2188843482388834721.post-74542855321480424832014-08-16T04:59:02.669-07:002014-08-16T04:59:02.669-07:00Hi guys,
@psifertex
I did indeed try your shellco...Hi guys,<br /><br />@psifertex<br />I did indeed try your shellcode in the emulator and it seems to work, at least for queuing the message containing the token.<br />However there are 3 possible issues with the ones I sniffed during the game:<br />1/ The stack is smashed well after 0x4200. Not sure if these addresses are used though,<br />2/ The Src and Dest ID are the same, I don't know if this is supposed to work,<br />3/ The RF state machine is not updated as you jump back on the eint/cpuoff instructions, so the RF might not be in a correct state and may stay like that.<br />The point 3 is the more likely and is difficult to check without debugging during the live game...<br /><br />@bigred<br />For the exact same reason as @psifertex said, we chose not to investigate the response message path because we just never received them in our logs (but we could see us sending them back during SLA checks).<br />Thanks for mentioning the second bug, I was actually curious to know if there was indeed something to do with this type of messages. So now we know.<br />This would have make a much better attack since the response is sent directly and not queued for later. As well as more reliable than smashing the stack !routardzhttps://www.blogger.com/profile/16885996044315754891noreply@blogger.comtag:blogger.com,1999:blog-2188843482388834721.post-70718015568077639502014-08-15T18:43:47.857-07:002014-08-15T18:43:47.857-07:00We tried to take advantage of a different bug in t...We tried to take advantage of a different bug in the decode_unk function. That function built the data used for the RM message, and could return various pieces of information such as radio state, team id and CRC16 checksums of the picture or text. The DM message included the start and end offsets for the bytes to checksum in the picture, but the check was signed. A negative enough offset would point to the token in memory, since the token was at an address before the stack. You could also request multiple pieces of information in one message, so we were creating a message to return 8 checksums, each of the individual bytes of the token. <br /><br />We had it working locally, but as psifertex said, RM messages never seemed to be passed back. sirgoon said afterwards that this was indeed a second intentional bug and that it was possible to get the RM messages, but it was unclear as to how exactly. Oh well, great job!<br /><br />(bigred - reckless abandon)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2188843482388834721.post-22522570175394171472014-08-15T17:54:41.430-07:002014-08-15T17:54:41.430-07:00Dang. Nice turn around! We didn't test our she...Dang. Nice turn around! We didn't test our shellcode well enough apparently. :-( Still not sure why it didn't work since it worked fine the night before when testing the shellcode in the room. Well, I know part of the problem was our header was off, but even with that fixed the shellcode wasn't working right on the game network when injecting it into the badge and debugging it directly (using the debug mode available) worked great. <br /><br />I was told by sirgoon there are cache coherency problems and you have to pad your shellcode with nops, but clearly you guys didn't have a problem with that so I was very curious to see which payload you ended up using. PPP's was ROP based which avoided the problem altogether, but they tried leaking the data back via the broken reply message (which were rarely getting passed back by the base station as far as we could tell -- which was why we used a similar technique to queue it up in response). <br /><br />(psifertex - men in black hats)Jordanhttps://www.blogger.com/profile/08341608982649448622noreply@blogger.com