So it actually turns out that on Android if you opt out of ads personalisation, the app still sends the advertising ID, but also sends in the JSON "advertising_tracking_enabled: false", which is not so reassuring. See Privacy International's talk here: https://media.ccc.de/v/35c3-9941-how_facebook_tracks_you_on_...
Apart from what he points out in the article ("The PIC client is susceptible to a MitM (Man In The Middle) attack because it does not verify if the public key sent by a server is from a trusted party")
1. Weird encryption which seems to be XORing the plaintext against the same encrypted IV?
2. Using random padding instead of PKCS5 or similar?
3. Using memcmp instead of CRYPTO_memcmp or similar?
2. The padding is definitely concerning; see if you can devise an attack from it.
3. That's a real issue, but I'm not counting it (for my own count) since a memcmp timing channel against a general purpose CPU over IP is extraordinarily difficult to exploit.
Well, on closer inspection it seems like the MAC isn't actually an HMAC, but just SHA3. And since the padding isn't verified (because it can't be) that leaves it open to simple extension/truncation attacks (Crytopals challenges 29 and 30)?
Nope. It's safe to make a MAC out of a keyed SHA3 hash (one of the criteria for the SHA3 contest was that none of the hashes be vulnerable to length extension). Fun fact: that's also true of the "truncated" SHA2 variants (SHA2-384 and the like).
- Can't have the compiler side by side with the debugger, even though there's plenty of room on the screen
- When the PC jumps, the highlighted instruction doesn't follow, leaving you lost when stepping through a program
- Can't hit enter on a blank line to repeat previous command
- No 'finish' debugger command?
- Seem to end up in random functions when stepping over simple instructions
- Am I supposed to type 'flash' or 'run' to execute my compiled program? Sometimes the one I just compiled gets executed, sometimes the one I compiled previously - how can we view what's being executed?
I really enjoyed microcorruption, and thought that UI was fine, but this feels like a step backwards.
Putting the compiler in the debugger was how it used to work. Everyone hated it. Also: it's using Ace, which really grinds Chrome. I can easily add a pure textarea tab that will let you edit code, if you _really_ want it.
To run a C program, do one of two things:
* Compile it in the source editor, which will generate a blob of compiler output (which is deliberately not documented) that the browser will cache.
* Use the "flash" command to write it to SPI flash.
* Use the "vmload" command to send a SPI message to the AVR to reload the program from the SPI flash.
* Use the "vmexec" command to send a SPI message to the AVR to execute the program.
OR
* Compile it in the source editor
* Type "run", which does all the rest of those things.
I like Microcorruption's UI, too. I gave this one more to do. I agree: it's not there yet! Working on it. How elaborate do you want the web-based debugger built on this API to be? :)
(I'm serious: thanks for the feedback. This section of the thread is the stuff I was hoping to get).
Thanks for replying - I just wanted to dive in and get stuck into the levels, but found the UI so confusing that I just gave up - particularly as someone with no AVR experience, and with the tutorial dying half way through.
The biggest pain point was figuring out what was executing. As I mentioned, I would be playing around in the compiler, hit compile and save, and then attempt to run it in the debugger. The 'run' command either seemed to have no effect, or would run a previously compiled program, not the one I'd just written. Even typing 'reset' didn't help.
The memory didn't seem to be updating in real time either, which made things even more confusing!
