Ok, so I wanted to cover packing binary files with my students in Systems Programming. Why you ask? It's good for them for starters. Until you read a packed binary specification and write a packer/unpacker, I don't think you truly understand what the low level systems calls like open(), read(), and write() are capable of. Plus, I wanted to foreshadow what we will be covering when we get to networking and we cover binary network protocols.
So I knew I wanted the students to either pack or unpack some binary format, but I struggled with what to have them do. Most of the students have had very little practical programming experience, even though they're all basically either seniors in computer science or masters degree students in computer science. I know, that seems ridiculous, and it is, but that's a topic for another post. So I started looking around. I thought it'd be cool to extract exif data from a jpeg. So I started reading up on it, and saw that it wasn't trivial. It's probably something seniors and grad students SHOULD be able to handle, but I didn't want to push it. They need to walk before they can run. Then I thought, tar...tar is pretty simple and it's been around forever and it's well documented. So I looked at tar. While it isn't THAT bad, it still seemed a bit steep for their first time out.
So, I ended up developing an extremely simple file format. It's in the same vein as tar, but much much much (did I say much) simpler. Basically it starts with a 4 byte header to declare that it's the format I came up with for the class, followed by variable length records for each file. The "variable length records" start with a 2 byte short declaring the length of the filename, followed by that many bytes which is the filename. That is followed by 8 bytes representing a 64bit int, which specified the number of bytes that file is, immediately followed by the bytes for the file. The next record follows immediately after. So yeah, super simple. No support for directory structures or anything...just file names and file data. Hopefully, this won't be too difficult.
Ok, so I know I mentioned a financial motivation. Among the miscellaneous files packed into the sample I plan to give the students, is a wallet.dat file. For those of you familiar with cryptocurrency, you know what that means. For those of you who are not familiar, it is basically where the encryption keys are stored for a "wallet". Basically, if you have the wallet.dat file and it's not encrypted, then you can spend any of the coins associated with any of the account numbers in the wallet. And yes, I put some in there. Now mind you, this isn't a bitcoin wallet, this is a dogecoin wallet. So the coins in there are not quite as valuable currently, but that's not really the point. The main point is, only one person can control a wallet. The first student who finds the wallet.dat, and realizes what it is, can transfer all the coins out of it to another wallet. Any subsequent student who looks at the wallet, it'll be useless. So it's sort of an arms race. More importantly, I hope for it to show me which of my students are the most committed and determined.
Oh, and due to the awesomeness of crypto currency, if anyone reads this who has a few dogecoin to spare, you can send them to:
DHHCc6kfpMCLE4FEaSaPGCTMpbNUWRmJi8
It'll be interesting to see if one of my students actually gets the wallet out and takes the coins. I'm also debating just not telling them and see if one of them figures it out on their own. Of course, the file is just named wallet.dat and so without knowing that it is a dogecoin specific wallet, it may be complicated. But I did include a picture of a shibe...so that should be a clue right?
I'll hopefully follow up after the assignment has been submitted by everyone.
No comments:
Post a Comment