Travis Goodspeed

The point is it's important to define a new spec if you are being "liberal" in what you accept. For example, while RFC 4180 defines line endings as CRLF, it might be reasonable to "be liberal" and accept files with just LF if and only if you add a rule similar to

<line-ending> ::= "\r\n" | "\n"

to your input grammar, and properly recognize that the input matches that grammar before using any parsed values. It's an extension ("being liberal") to the official spec, but still strictly defined in the implemented parser.

> This lets you exploit things by sneaking in headers

In the talk at my previous [2][3], Serge specifically mentions Travis Goodspeed's packet-in-packet[4] exploit as an example of why you have to define what "liberal" means if you want to implement Postel's principle. (You should also limit input grammar's complexity to deterministic context-free, or the recognizer will be undecidable)

> in practice has made things a nightmare

That's what [2][3] is trying to fix. Stop using Turing Complete input languages, explicitly define your input grammar no matter what you're choosing to parse, and formally recognize all input against that grammar. The data either matches the defined grammar or it should be failed as invalid. Any allowances for sloppy input must be baked into that process.

[4] http://travisgoodspeed.blogspot.com/2011/09/remotely-exploiting-phy-layer.html

>some people noted that some 'hardware' attacks can't be seen because they use original parts.

You can have original looking part. Imagine a 8Mbit SOIC SPI NOR flash chip. Looks the part, belongs in its spot, you decap it and it sure does look like a flash Die with its normal Flash controller. Now consider this: http://travisgoodspeed.blogspot.com/2012/07/emulating-usb-devices-with-python.html
I cant find it right now, but Afair Travis (or maybe it was hak5 RubberDucky folks) noticed early on that its pretty trivial to detect what is happening on the Host side of the interface - what operating system am I plugged into and at what phase of the operation are we on (bios query, OS loading drivers).

Imagine a Flash chip that is able to tell (power sequencing, timing and order of commands) if its booting a particular controller on the board, or if its being read in a flash programmer. Flash chips have processors running their own firmware nowadays, turtles all the way own.

Even open source hardware isn't sufficient against an attacker as seriously resource rich (both cash and technical ability-wise) as the NSA.

You can't trust the supply chain any more, you can't even trust the silicon unless you made it (and all the machines you used to make it) yourself.

Are you _sure_ that network chip, usb controller, or flash ram you built your open source hardware out of isn't exploited?

If you're on the fence about whether you're "too paranoid" or "not paranoid enough", make sure you've read what some people do for free, just for fun/curiosity/geek-cred/reputation:

http://travisgoodspeed.blogspot.com.au/2012/07/emulating-usb-devices-with-python.html

http://www.bunniestudios.com/blog/?p=3554

Then imagine what their grey-suited counterparts on 200K salaries at the NSA with (for all intents and purposes) unlimited research budgets might be up to.

You'll probably see this on the Sparkfun saga, but the way to remove it at the Atmega lab (with a hotplate and acetone) is quite dangerous. Don't try that at home.

Instead, drop the whole chip in a test tube of fuming nitric acid at room temp, and let it work slowly overnight. Anything with fuming nitric acid is dangerous, but this is much safer than the hot plate method. See this tutorial by Travis Goodspeed:

http://travisgoodspeed.blogspot.com/2009/06/cold-labless-hno3-decapping-procedure.html

I found these articles helpful/educational:

* https://urish.medium.com/reverse-engineering-a-bluetooth-lightbulb-56580fcb7546

* http://travisgoodspeed.blogspot.com/2011/12/introduction-to-bluetooth-rfcomm.html

* https://github.com/dlenski/ttblue/blob/master/tt_bluetooth.md#reverse-engineered-ble-protocol

Start here:

http://youtu.be/D8Im0_KUEf8

See also:

http://travisgoodspeed.blogspot.com/2012/07/emulating-usb-devices-with-python.html

http://travisgoodspeed.blogspot.com/2012/10/emulating-usb-dfu-to-capture-firmware.html

http://goodfet.sourceforge.net/hardware/facedancer21/