I wish I didn't need money, so I could just play this game. Unfortunately I'm starting a new venture right now, so it's terrible timing :( And in real life, at least in telecom, far less people seem to care about security and exploits.
Starfighter sounds incredibly ambitious and fun. Patrick's part sounds like it'll be making fun of Bitcoin exchanges. And there's probably going to be a rush to build higher and higher level compilers for this emulator.
Knowing just a teensy bit of 68K and x86 assembly, I still am shocked to hear that there are "something like 16 load and 13 store instructions". Super... cool.
This post has given Starfighter a lot more flavour in my mind. Thanks, Erin!
We're definitely not stopping with AVR. The original plan was, AVR, then compiler, then (architecture X), then launch. But compiler took so long that we're just going to do AVR and surface the compiler's IR as another architecture.
We'll have (architecture X) done in a month or so. And a pretty hilarious "architecture" after that.
I'm excited that all the AVR I learned reverse engineering mouse firmware isn't going to go to waste. I honestly thought it was knowledge I would never use again.
I'm super excited for this. Micro Corruption [1] literally changed my life [2], and I can't wait to see what the team at Starfighter have put together.
If you haven't yet, give Micro Corruption a try. It's the first thing I recommend when people ask me how to get started in application security, and everyone I've recommended it to loves it.
You don't need to know anything about security to finish the first level, but by the time you finish the last level you'll be a force to be reckoned with.
Best of luck to tptacek and co., the Samurai CTF team can't wait to play your next game.
[2] I've since dropped out of school to work full time in security, and now compete on a top-tier CTF team. I couldn't even spell buffer overflow before Micro Corruption.
It wasn't clear to me, but it sounded like the community might be able to contribute back to the core of the game, by improving tools/finding (unintentional) bugs etc.
Is that an intended aspect of the game, and how do you see it fitting in with the game's ecosystem?
Perhaps by corollary, will there be a significant open-source community built around the game; will there be open-source assets, but also the ability to contribute to those assets?
> We'd like that to happen. We have ideas on ways to provide "hooks" for people to publish and collaborate on projects. We'd be thrilled if, even before that happened, people just threw random code they wrote for us on Github.
From previous coding games, it does seem common for people to publish solutions to github, but this is often tempered by a reluctance to allow 'script-kiddies' to solve the same problems without doing the work.
Hopefully the design of the games will make this kind of 'cheating' pointless, so sharing and collaborating on solutions is desirable.
If there is an on-line code editor involved at any point, I'm much more likely to publish to somewhere like github if that feature is baked in :) (also easy offline IDE integration is a bit simpler if git is baked in...)
I guess I my question was more targeted at this line:
"We’re giving players the dev kit for the handheld trading device. You can program it in AVR assembly. But the vendor also offers support for a very limited dialect of C, compiled to bytecode IR or to AVR. Emphasis on “limited”. You know, because we did less of the fun stuff for you."
This seems very much like a situation where the community can work together to improve their ability to play the game.
> At this point though we're just running (or in Erin's case skating) as fast as we can to launch the damn thing.
It is absolutely intended that people will build things on top of Starfighter. People built things on top of Microcorruption, too -- there are actual professional-grade reversing tools which have a command-line "microcorruption quirks mode" to better emulate the behavior of the game's emulator. We will also, naturally, take bug reports -- and sometimes even fix them.
I don't see us shipping much OSS at launch, but that's something I'd be willing to try in the future.
One recommendation which may be really obvious: don't release any source unless you want to simulate that the source has been released in the "game" world.
If you want to release any source code for any segment of the challenge, while the challenge is ongoing, it will be torn apart by the competitors for bugs.
Because, as Erin said: "...pretending all our bugs were intentional, to make things more like the real world!"
From the post it sounds like prop trading firms / hedge funds and other finance companies are a big target demographic for Starfighter to make placements at...
From Thomas's background in Chicago I predict the following firms as early customers:
Why would a developer work in such a place? I imagine you would be forced to be all professional yet always play second fiddle to the traders, no matter great your skills were.
But then again I am probably the only one who is disappointed over this announcement - the game sounds really boring to me.
> Why would a developer work in such a place? I imagine you would be forced to be all professional yet always play second fiddle to the traders, no matter great your skills were.
This is generally the case at most places where software development is done, even when the software is the product.
For example, as any developer working at an "enterprise software" shop -- despite being the "producers", you're still beholden to (and less important than) the sales folks.
Not saying that's right or wrong, just that that is how it is.
But also in general, in places like that there is also a huge priority placed on having absolutely the best infrastructure & systems reasonably affordable in order to empower the traders. For example, of Fidelity's ~45,000 employees, about 14,000 work in technology roles (both internal IT and product stuff). To me that's an insane ratio for a non-tech company ...
... but, if you talk to any big-finance leaders these days, they'll probably admit to you that their tech is their competitive advantage (and not just in HFT, either).
Imagine is the keyword in your statement. Different firms are going to have different cultures. There are places where the developer is essentially the trader and as far as professionalism goes, I could easily be mistaken for a startup employee with my jeans, t-shirt, and Nikes.
> Why would a developer work in such a place? I imagine you would be forced to be all professional yet always play second fiddle to the traders, no matter great your skills were.
Even if your imagination were correct, I'd expect "money" would be a factor. Not all developers are primarily concerned about maximizing workplace status.
s/fine/crappy. Alas, all I can say is maybe. Because this emulator doesn't have some of the components that, say, an Arduino UNO might have, it doesn't support the entire AVR instruction set. For example, there is no UART support. I did write a bit that listens on a port where I could send the emulator keystrokes to mock up a UART (mostly just because I was stuck on something else and needed a distraction), but I didn't need IO, so there really is none, currently.
Uploading machine code -might- break something. But in a fun way, I think.
When this showed up in my inbox, I was so excited. I've got a few weeks of holiday starting tomorrow, perfect timing for once! For example with Microcorruption my problem was exactly that I did a few hours of it right when it launched, and then had forgotten everything a few months later when I next had time to look at it.
But then I got to the end of the email, and it turns out that it's the opposite :-) Guess it'll be playable just when it's back to the grind for me. But it does look incredibly interesting. And maybe having multiple separate things to do will make it easier to pick up after a bit of an absence; can just start on one of the other "tech trees" instead of having to redo old work to get up to speed.
Golang makes total sense for the kind of programmer who wants everything to be there on the screen in front of them. It’s like C in that regard - write code, the computer does what the code says, programmer is happy: No constructors, no destructors, no exceptions, no weirdness
But C has weird bits & odd corner cases. C isn’t type safe. C requires you to do all your own memory management. C is in fact full of landmines for the ordinary programmer (which is all of us, even the very best on a bad day) to step on inadvertently. What if you could have a language that acted like C, but was type safe, did do memory management for you, and had a decent standard library so you didn’t have to spend time writing yet another linked list implementation? Oh, and the one true concurrency scheme (Hoare’s communicating sequential processes) is built right in to the language, so you can write type-safe asynchronous systems without tedious boilerplate.
That language is Golang. Like C, it’s a wysiwyg language, unlike C it’s much harder to shoot your own foot off with it.
If you've ever programmed assembly on the TI-99/4A, the TI MSP430 instruction set is an obvious evolution of the TMS9900 microprocessor. Looking forward to that being relevant to me again when playing Microcorruption, which I have not had a chance to get into.
Stuff like when Tom called me and asked if he could have a truckload of pork bellies (CME ticker:GBP. And: I told him no.) delivered to our house.
Sadly frozen pork belly futures don't trade anymore and haven't for about 4 years (almost to the day), and the Globex contract was GPB not GBP. But whatever, that sounds like a cool story and you should tell the rest of it :)
It's been almost 3 years since we sold Matasano, 4 since Erin left, and a few years more to get to that story. Matasano started in 2005. Also: we're old.
Sorry, silly question, we're pork bellies in particular chosen due to the movie Trading Places? If I were to pick a stock for a laugh I would have chosen pork bellies... It's a shame to see that they aren't traded anymore :-(
I've heard many stories about traders letting their futures expire and having to take delivery of whatever commodity it was. I'm pretty sure they're all urban myths though. They probably just had to unload them quickly at a big loss.
I would love to be proved wrong if anyone has a story with evidence. Preferably with pictures of shipping containers arriving at a city office!
Delivery was always at an established market point. Also, brokers would never let retail customers take delivery and would close out the trade because they would be at risk too.
"Ideally, the broker will make sure everything goes according to plan," the Prince of Peanut Oil told me. "But I once knew a guy who was trading for himself. He bought six egg contracts, with each contract worth 18,000 cartons of one dozen eggs. That's 1,296,000 total. The guy somehow made the mistake of taking delivery."
> I don’t really like games.
> Yeah, so… I was planning on telling you more about our game.
> Just two months ago, Tom and I were driving to the grocery store
The announcement read like a mentally disturbed love letter about the typical idea guy stream of consciousness. Good luck, but I had to unsubscribe to prevent the arrival of any more...whatever that was.
Interesting - I think this is probably the first piece of Erin's that I've read, and I found it really engaging. Definitely a love letter type of tone, and I guess I'm used to that a little having a lot of conversations work-wise with people discussing their 'my business is my baby' passion.
It was a great read for sure. But since it was called an announcement, I was expecting a "when we launch" in the first paragraph. Not a "this is not the announcement you were looking for" in the very last sentence of a 5 page post.
Well IMHO the whole "I had no idea what I was doing and it was really difficult to figure out that in the emulator memory-mapped registers must be (gasp!) mapped to memory, and Tom's mansplanation didn't help" doesn't exactly inspire a lot of confidence.
What are you talking about? That's not what she said. She pointed out that the stack pointer is a I/O register, which was in fact so weird that we did in fact argue about it (she was right, I was wrong). Why did she write about that? I don't know, perhaps because people who participate in Microcorruption are going to program AVR stack pointers?
"Mansplanation"? Really?
It feels like no matter what someone writes --- an emulator, a TCP/IP stack, a Montgomery curve implementation, the world's fastest SMT solver, whatever --- there is always somebody, who always writes like they sound like "that creepy booger-nosed kid" from King of the Hill, to tell us how unimpressive the accomplishment is. Thanks, Clark Peters! You've struck again!
> What are you talking about? That's not what she said. She pointed out that the stack pointer is a I/O register, which was in fact so weird that we did in fact argue about it (she was right, I was wrong).
Yes, that's what I'm talking about, and that is what she said: You argued about something that is a fact (and well-documented) and thus simply not up for argument.
Previously I thought you were a group of experienced professionals with a proven track record of delivering great stuff. That made me pretty confident that Starfighter would be awesome. With this announcement that explains how you all did new stuff without building on that experience and it came out kinda crappy and buggy, haha, my confidence is diminished. I don't expect you to agree, but that is my impression from what I can gather from this announcement.
The world has way too much bland corporate/HR sanitized writing as it is. Besides when you are married to someone who is your equal and then some that is how some conversations go :)
Atmega chips are great. It's not really because of AVR architecture, but the options they provide are amazing - from standard built-in UART to a proper RF TX/RX. All on one chip.
I really liked working with Atmega (and AtTiny) hardware. So if you get a compiler chain that works for AVR because of the competition, you may as well continue and get a starter kit ;)
I initially thought that the subject of the email (Stockfighter Announcement) was some sort of auto-correct fail. This makes much more sense after reading it in full!
Pretty excited about this as I was on a team that built a trading system (won't say which one but it was a big one) and my education is in electronics. It will be refreshing to deal with a (fake) trading system that uses "JSON/REST" as most of the real ones use proprietary binary protocols or something even worse like FIX!
Oh don't worry, we'll get people's hands dirty with FIX, too, but making things accessible to web developers in their usual toolchains seemed like a good call for Chapter 1. Especially since I had never personally worked with FIX before and we had a slightly aggressive timeline.
I feel sorry for you having to use it. Especially the XML version. Stay strong!
Fun fact, the SOH delimiter character renders as a smiley face in some terminals. Some of the proprietary protocols are fixed width which makes them so much simpler to parse than FIX.
Great news! I played with matasano crypto challenges and Microcorruption. And as I understand this one is more greater and more enveloping. I was so excited when read "compiler theory" in the letter because I realized the LR(1) compiler engine in JavaScript, and these skills will help me in Starfigher I think.
111 comments
[ 2.8 ms ] story [ 169 ms ] threadStarfighter sounds incredibly ambitious and fun. Patrick's part sounds like it'll be making fun of Bitcoin exchanges. And there's probably going to be a rush to build higher and higher level compilers for this emulator.
This is gonna be awesome.
Oh believe me, when we do Bitcoin, we won't be nearly that subtle.
This post has given Starfighter a lot more flavour in my mind. Thanks, Erin!
edit: For anyone interested, here's a link to that ATmega8515 data sheet: (caution, pdf) http://www.atmel.com/images/2512s.pdf
We'll have (architecture X) done in a month or so. And a pretty hilarious "architecture" after that.
If you haven't yet, give Micro Corruption a try. It's the first thing I recommend when people ask me how to get started in application security, and everyone I've recommended it to loves it.
You don't need to know anything about security to finish the first level, but by the time you finish the last level you'll be a force to be reckoned with.
Best of luck to tptacek and co., the Samurai CTF team can't wait to play your next game.
[1] https://microcorruption.com
[2] I've since dropped out of school to work full time in security, and now compete on a top-tier CTF team. I couldn't even spell buffer overflow before Micro Corruption.
Is that an intended aspect of the game, and how do you see it fitting in with the game's ecosystem?
Perhaps by corollary, will there be a significant open-source community built around the game; will there be open-source assets, but also the ability to contribute to those assets?
From previous coding games, it does seem common for people to publish solutions to github, but this is often tempered by a reluctance to allow 'script-kiddies' to solve the same problems without doing the work.
Hopefully the design of the games will make this kind of 'cheating' pointless, so sharing and collaborating on solutions is desirable.
If there is an on-line code editor involved at any point, I'm much more likely to publish to somewhere like github if that feature is baked in :) (also easy offline IDE integration is a bit simpler if git is baked in...)
I guess I my question was more targeted at this line:
"We’re giving players the dev kit for the handheld trading device. You can program it in AVR assembly. But the vendor also offers support for a very limited dialect of C, compiled to bytecode IR or to AVR. Emphasis on “limited”. You know, because we did less of the fun stuff for you."
This seems very much like a situation where the community can work together to improve their ability to play the game.
> At this point though we're just running (or in Erin's case skating) as fast as we can to launch the damn thing.
Please do :)
I don't see us shipping much OSS at launch, but that's something I'd be willing to try in the future.
If you want to release any source code for any segment of the challenge, while the challenge is ongoing, it will be torn apart by the competitors for bugs.
Because, as Erin said: "...pretending all our bugs were intentional, to make things more like the real world!"
From Thomas's background in Chicago I predict the following firms as early customers:
http://www.spottradingllc.com/
http://www.belvederetrading.com/
http://www.towerhilltrading.com/
But then again I am probably the only one who is disappointed over this announcement - the game sounds really boring to me.
This is generally the case at most places where software development is done, even when the software is the product.
For example, as any developer working at an "enterprise software" shop -- despite being the "producers", you're still beholden to (and less important than) the sales folks.
Not saying that's right or wrong, just that that is how it is.
... but, if you talk to any big-finance leaders these days, they'll probably admit to you that their tech is their competitive advantage (and not just in HFT, either).
Second fiddle, depends where you're working. Like everything else, there are crappy shops and there are amazing ones.
Even if your imagination were correct, I'd expect "money" would be a factor. Not all developers are primarily concerned about maximizing workplace status.
All of my test code was compiled with Crosspack AVR libc. The bundle has its own test code which was very useful.
Uploading machine code -might- break something. But in a fun way, I think.
But then I got to the end of the email, and it turns out that it's the opposite :-) Guess it'll be playable just when it's back to the grind for me. But it does look incredibly interesting. And maybe having multiple separate things to do will make it easier to pick up after a bit of an absence; can just start on one of the other "tech trees" instead of having to redo old work to get up to speed.
I kill me.
But C has weird bits & odd corner cases. C isn’t type safe. C requires you to do all your own memory management. C is in fact full of landmines for the ordinary programmer (which is all of us, even the very best on a bad day) to step on inadvertently. What if you could have a language that acted like C, but was type safe, did do memory management for you, and had a decent standard library so you didn’t have to spend time writing yet another linked list implementation? Oh, and the one true concurrency scheme (Hoare’s communicating sequential processes) is built right in to the language, so you can write type-safe asynchronous systems without tedious boilerplate.
That language is Golang. Like C, it’s a wysiwyg language, unlike C it’s much harder to shoot your own foot off with it.
Sadly frozen pork belly futures don't trade anymore and haven't for about 4 years (almost to the day), and the Globex contract was GPB not GBP. But whatever, that sounds like a cool story and you should tell the rest of it :)
(The ticker is my fault).
I would love to be proved wrong if anyone has a story with evidence. Preferably with pictures of shipping containers arriving at a city office!
"Ideally, the broker will make sure everything goes according to plan," the Prince of Peanut Oil told me. "But I once knew a guy who was trading for himself. He bought six egg contracts, with each contract worth 18,000 cartons of one dozen eggs. That's 1,296,000 total. The guy somehow made the mistake of taking delivery."
"aptwebapps made his profile public."
"Ah, he must be on the hunt for a new role somewhere..."
The announcement read like a mentally disturbed love letter about the typical idea guy stream of consciousness. Good luck, but I had to unsubscribe to prevent the arrival of any more...whatever that was.
"Mansplanation"? Really?
It feels like no matter what someone writes --- an emulator, a TCP/IP stack, a Montgomery curve implementation, the world's fastest SMT solver, whatever --- there is always somebody, who always writes like they sound like "that creepy booger-nosed kid" from King of the Hill, to tell us how unimpressive the accomplishment is. Thanks, Clark Peters! You've struck again!
Yes, that's what I'm talking about, and that is what she said: You argued about something that is a fact (and well-documented) and thus simply not up for argument.
Previously I thought you were a group of experienced professionals with a proven track record of delivering great stuff. That made me pretty confident that Starfighter would be awesome. With this announcement that explains how you all did new stuff without building on that experience and it came out kinda crappy and buggy, haha, my confidence is diminished. I don't expect you to agree, but that is my impression from what I can gather from this announcement.
1. Meat-loaf.
2. Beat-loaf.
3. I hate meat-loaf.
If that's mentally disturbed, I'm in the club :-)
I really liked working with Atmega (and AtTiny) hardware. So if you get a compiler chain that works for AVR because of the competition, you may as well continue and get a starter kit ;)
Pretty excited about this as I was on a team that built a trading system (won't say which one but it was a big one) and my education is in electronics. It will be refreshing to deal with a (fake) trading system that uses "JSON/REST" as most of the real ones use proprietary binary protocols or something even worse like FIX!
Fun fact, the SOH delimiter character renders as a smiley face in some terminals. Some of the proprietary protocols are fixed width which makes them so much simpler to parse than FIX.
Hm, maybe shouldn't have given that one away. Oh well, people will forget before we launch.