Intel Management Engine JTAG Proof of Concept

https://github.com/ptresearch/IntelTXE-PoC

by adulau • 8 years ago

301 75 8 years ago

is there any specific reason for using python 2 instead of 3 or it is just how you guys do it

Freak_NL• 8 years ago

Python 3 is ten (!) years old and perfectly usable, but it suffers from a well-known, but curious problem where people who occasionally use Python for some light scripting tend to go for Python 2.7. Rarely it's a choice made because of library availability, more often it is because of the perceived ubiquity of Python 2.7 installs on the target user's computer or simply because of a mindset where Python 2.7 is good enough and getting the hang of Python 3 seems like a huge obstacle (it isn't).

I'd love to know why this project specifically chose Python 2.7 too. Python 2 reaches its end of life in 2020, any new Python code should really be written in Python 3.

By the way, if you want to prevent getting a bunch of downvotes like your comment did, be polite! Not including any capitalization or punctuation is considered downright rude by many. Your text reads like a robot's printout.

josefx2• 8 years ago

You forgot one reason not to switch from 2 to 3: Zero benefit. Nothing python 3 does would benefit my scripts to any extend over just using python 2 as I always did. Is learning 3 a huge hurdle? No, it is however in some cases completely unnecessary.

gaius2• 8 years ago

more often it is because of the perceived ubiquity of Python 2.7 installs on the target user's computer

It’s not just “perceived”, it is actual reality e.g. on CentOS. If you need compatibility still the best option is 2, regardless.

_0w8t3• 8 years ago

On Redhat and compatible systems python 2 will be supported for at least 10 years.

avian• 8 years ago

I'd love to know why this project specifically chose Python 2.7 too.

My guess is they just went with whatever was most convenient and worked. I doubt if this kind of questions were even on the radar. It's security research, not a production website. In research you tend to go with whatever tool does the job.

Look at the overall complexity of this work. Maybe the author simply felt more confident with Python 2. You take whatever shortcuts that make things simpler, even if it means using 20 year old software.

j1elo• 8 years ago

It's not a huge obstacle, but it _is_ an obstacle.

I'm not a Python programmer, but I can find my way around without much issue. Still, from where I'm sitting all that stuff about envs and the 2, 3 or 4 redundant, overriden, or deprecated mix of solutions sounds strange to me, I don't really want to buy into that just yet (I need Python like once per month, no more). For the casual programmer ("just want to change this line and run, please") it's just a block in the road that virtually all instructions you might see on any random README in Github might tell you to use "pip install..." but then you have to second guess if they mean "pip2" or "pip3", and whether they assume you'll be running with v2 or v3, maybe they tell you to run "pip install something" (which runs pip2), then in the script there is a Python 3 shebang... the installed dependency won't be found and now you have to understand all this mess if you want to continue.

This is in Ubuntu, where the system's "python" is Python 2, and you need to explicitly add a "3" to all your commands if you want to run v3. I'm sure there are clever ways to solve the issue, but I bet they'll break some use case. I'd just rather none of this nonsense existed at all, then no funny workarounds would be needed.

I wonder, how come other languages are able to slowly introduce some breaking changes over time (I'd swear Ruby was mentioned in some other HN thread about doing this) but not cause this kind of mess (as perceived from my humble external point of view)?

CamperBob2• 8 years ago

Why is this downvoted to goatse.cx territory? It's a perfectly reasonable question with no self-evident answer.

kencausey• 8 years ago

I didn't downvote it but it seems well off-topic to me.

exikyut• 8 years ago

Nobody else answering this question seems to have read the article.

Like DAL, the OpenIPC library includes a command-line interface (CLI), written in Python and provided as a library for Python as part of Intel System Studio, which can be installed on the system with the help of pip.

Intel System Studio doesn't ship its own python, it depends on the OS' python version. So here we have an industry-infra dependency on python, and these typically seem to still be stuck in 2.7 land.

Python is being used here to actually wrap/coordinate the components that do the JTAG handshake. A neat approach, just using a whole programming language as the REPL. I like it. But this is one situation where I'm going to be very conservative with the tooling, as I don't want to break my system! :)

So, that's the real reason why.

Also; the repo actually has, right in view, a recent commit message of "fix for Python 3 compatibiliy". The authors are clearly just using 2.7 because ISS requires it and considering the bigger picture of tinkering with PoCs, mucking about with multiple Python versions seems like a waste of cycles and unnecessary management+verification of moving parts (I don't savor the idea of figuring out "ok how do I tell ISS where 2.7 is and how do I absolutely make sure it's avoiding 3.0?").

HN, please endeavor to pursue higher quality discussion. Devolving into meta is an excellent way to encourage stagnation. (I know this sounds a bit of a self-righteous thing to say but it's tricky to objectively articulate.)

someguydave• 8 years ago

Agreed. Nothing repels an actual hardware hacker harder than finding that the reaction to a significant finding consists mainly of bikesheding the python version of his concept script

rasz2• 8 years ago

3 forces you to screw around with Unicode encoding/decoding everything, painful when dealing with raw bytes.

marssaxman2• 8 years ago

That's called "dealing with the reality of international text instead of burying your head in the sand," isn't it? Bytes are not text any more than bytes are a picture or bytes are a sound recording; it is only in the context of an encoding that bytes can be interpreted as something more.

For that matter, given the inexplicable popularity of emojis, it isn't even a matter of international text anymore.

therein• 8 years ago

That was a fun read. Interesting trick with the debug USB cable with some of the pins isolated.

rzzzt• 8 years ago

I don't quite get how it works. A quick search tells me that USB 3.0 indeed allows A-A crossover cables to connect two hosts: https://superuser.com/a/945523

...but this leaves only a single conductor to do the entire thing?

AnssiH• 8 years ago

A USB3 A connector has 9 pins, not 4 like USB2, so there are still 6 left.

tyingq• 8 years ago

The picture is somewhat misleading, as you can only see the 4 connectors in the front. The other 5 are out of view. https://www.stemmer-imaging.com/media/cache/gallery_preview_...

superkuh• 8 years ago

There's the other side plus the shield itself is a pin. It's the ground.

tempodox• 8 years ago

So do we finally have reliable backdoors into any and all chips?

pingec• 8 years ago

Does this help with reversing the intel ME and/or figurring out how to disable to potential spyware parts of it?

19962• 8 years ago

Tremendously. It is a huge first step. I worked on BIOS stuff before. I decided to wait until AMT was more exploitable to come back to the scene.

This is big news. It should be #1 on HN, instead of the failed pentest story.

Right now I am ordering a GB-BPCE-3350C to replicate their work and see how to extend it to other platforms. Intel will limit the vulnerability. No time to wait.

A modern AMT free laptop would be of great value.

Sephr• 8 years ago

This isn't as highly upvoted because it's old news from two months ago.

I remember this being very well received when it was first published on Twitter.

codedokode3• 8 years ago

Why does Intel encrypt the code? It is unlikely that anyone would steal it because it is useable only with Intel CPUs and is protected with copyright. So the reasons are either Intel wants to hide something (a code that changes CPU behaviour when a benchmark is detected?) or wants to have some features that cannot be disabled or modified by the user.

It is difficult to believe that there is no backdoor.

int0x80• 8 years ago

That an also to avoid posibly revealing internals and details of the designs/architecture/etc to non-intel people.

monocasa4• 8 years ago

Security by obscurity obviously shouldn't be your only method, but it can absolutely be a valid component of a broad defense in depth.

fromthestart• 8 years ago

I don't know if I agree. While obscurity can be a deterrent, I imagine most groups are unlikely to come up with sufficient, convoluted complexity to prevent identification of exploits. Primarily because you're effectively pitting yourself against a collective of $hat hackers, instead of doing things "right" and attempting to use encryption.

This doesn't mean it isn't a deterrent, but doing things in an obfuscated and unusual way also means you're potentially treading on unexplored ground, and so there will potentially be other exploits, bugs, innefficiencies which can come with the territory.

codedokode3• 8 years ago

Defence from whom? From system administrator?

fermienrico• 8 years ago

I am not defending Intel, but firmware encryption is a very common thing in embedded software. The new ARM Cortex M33 architecture adds a ton of security & encryption features. This is becoming increasingly important in IOT devices.

marssaxman2• 8 years ago

Wow, that's awful! All the more reason to continue avoiding having anything to do with the IOT. Who would want to own household devices that keep secrets against you?

nickpsecurity3• 8 years ago

There's two reasons I've seen companies obfuscate as much of their hardware and firmware as possible:

1. Protecting their trade secrets. Even if it's eventually leaked or copied, the time between introducing the product and a clone happening might represent billions in sales.

2. Reducing patent damages. Hardware is a patent minefield with suits and licensing deals pretty common. The companies that want to troll need to see clearly that their patents were infringed. Making the product as opaque as possible reduces the number that will notice in the first place and/or how certain their claim will look. Patent suits are the single, greatest threat to open-source, hardware companies that operate in an existing ecosystem.

ratmice• 8 years ago

IANAL, but I find 2. weird, my first thought was that it obfuscation would give the opposing litigant an argument for willfulness potentially increasing patent damages.

i.e. it may reduce the total sum of patent damages across all potential cases by reducing the number that result in litigation, while increasing likelihood of increased damages for an unsuccessful defense.

Can't help but think 2. really seems to me a double edged sword.

codedokode3• 8 years ago

Why copy the code that can run only on Intel CPUs? It doesn't make sense.

bubblethink2• 8 years ago

Why does Intel encrypt the code?

In general, to protect the hardware IP. ME and FSP both do a lot of low level stuff that is instrumental to the silicon working in the first place.

extrapickles• 8 years ago

Physics is another reason. Since things are so small these days, you don't want a large amount of 1s or 0s because the charge will "leak" into neighboring cells. In the case of buses, anything other than a nominal 50/50 distribution requires too much power or will confuse the automatic gain control on the RX end of the link.

DDR3&4 is a good example of this where the CPU scrambles[0] what is written to physical memory to get the data closer to 50/50 1s and 0s.

In this case I doubt this is the primary reason though.

[0] https://web.eecs.umich.edu/~taustin/papers/HPCA17-coldboot.p...

slededit• 8 years ago

DDR3 doesn't scramble the data bits, and I don't think DDR4 does either.

Here's an open source controller - you can see yourself: https://github.com/enjoy-digital/litedram

zzo38computer• 8 years ago

Can we disable Management Engine entirely in order to don't waste energy, in addition to not having stuff that you don't know so that it will not run all of the stuff you do not need.

FlyMoreRockets• 8 years ago

Last I checked, there was no way to disable ME.

bubblethink2• 8 years ago

Only partially for new machines. For pre-Nehalem ones, you can disable it fully. You may be interested in this: https://github.com/corna/me_cleaner

Intel Management Engine JTAG Proof of Concept

Related Stories