5 ms·
While I respect the author's choice, I have to disagree over the point about people contributing to the codebase. I've spent the past two years reverse enginee
by iuguy 14y ago
While I respect the author's choice, I have to disagree over the point about people contributing to the codebase.
I've spent the past two years reverse engineering products built on Linux with no source code or build chain available. Last week I spent two days breaking into an embedded Linux device that runs alongside entire families of motherboards using an almost completely open stack with no attribution, no contribution and no source code release. The authors (both the OEM and the motherboard manufacturer) as far as I can tell do not contribute to any of the projects I've identified on the board from their official email addresses or in a professional capacity.
When you start looking at MiFi hotspots it's even worse. I did a talk last year at BlackHat EU on one example[1] where I finally managed to get the developers to fess up the source.
[1] - http://media.blackhat.com/bh-eu-12/Lord/bh-eu-12-Lord-Hotspot-Slides.pdf http://media.blackhat.com/bh-eu-12/Lord/bh-eu-12-Lord-Hotspo...
- jcr 14y agoFor those interested in seeing the BlackHat video presentation by Steve Lord (hn:iuguy): https://www.blackhat.com/html/bh-eu-12/bh-eu-12-archives.html#lord https://www.blackhat.com/html/bh-eu-12/bh-eu-12-archives.htm... At the time the idea of "required sharing" was put forward by RMS (1985 or so), it was a serious improvement over the status quo of proprietary software protected by confusing licensing terms. Trying to redefine the terms "free," "freedom," and "liberty" to mean "restricted," "required," and "threat of legal harm" is dishonest rhetoric. The GNU/FSF should be more honest and direct by clearly describing their license as "sharing required." The existence of a commonly used "sharing required" licenses like the GPL, and LGPL, and LLGPL, and ... has been beneficial in a lot of different ways. The primary way it has been beneficial over the years has been in how it very successfully nudges reluctant industry players towards releasing source code. The _requirement_ of sharing has shown industry the advantages of sharing code when they were previously fixated on the competitive advantages of not releasing code. In the early days, the older BSD/MIT/ISC/PublicDomain licenses (well, public domain is not formally a license but you get the point), were insufficient to convince industry players to give up the competitive advantages of proprietary licenses and closed source software for the competitive advantages of collaboration through open source. Times have changed, but not much. Licenses on open source code are still violated constantly by closed source vendors. It's not just a GPL problem; there's tons of proprietary closed source programs out there that fail to live up to either the "attribution" clause or the old "advertising" clause of the BSD-ish licenses. It really doesn't matter if your license of choice has an inherited "sharing required" clause, since it will still get lifted and incorporated into closed source, proprietary programs. Unless you have tons of time and money to waste in chasing the violators, your preferred license terms really don't matter. The most interesting thing about violations of open source licenses is the reverse engineering perspective. When you're able to identify the misused open source code within an executable binary, you can then use fingerprinting of the open source to better understand the closed source binaries. If you're curious about this kind of identification and program understanding in reverse engineering, you should look into the FLIRT and FLARE features of the IDA Pro disassembler.
- iuguy 14y ago> The most interesting thing about violations of open source licenses is the reverse engineering perspective. When you're able to identify the misused open source code within an executable binary, you can then use fingerprinting of the open source to better understand the closed source binaries. If you're curious about this kind of identification and program understanding in reverse engineering, you should look into the FLIRT and FLARE features of the IDA Pro disassembler. For Linux-based devices more often than not they use a uImage loader with one of 3 filesystems (JFFS2, Squashfs, CramFS), so once you've got around whatever encryption or encapsulation's in the image (I typically generate a picture graphing bytes to spot entropy, a technique I shamelessly stole from Don A. Bailey) you can normally run something like binwalk[1] to identify the filesystems and dd them out using a small shell script. I typically mount each resulting image and extract the contents then unmount. You can usually spot the open source bits by looking at binary names, strings and the way they're linked. Most Linux-based devices use common distros based on SBCs with uClibc and are either ARM or MIPS based. I'm slightly biased towards ARM because of the hotspot work but there's a lot of broadcom SBCs out there running *wrt variants. If anyone's interested, I'll be at #44Café[2] this tuesday talking about breaking into onboard BMCs used for IPMI-based management. Again, GPL violations ahoy. [1] - https://code.google.com/p/binwalk/ https://code.google.com/p/binwalk/ [2] - http://44con.com/44cafe http://44con.com/44cafe
- jcr 14y agoThanks for the 44con invite. It looks like fun, but I'm nowhere near there. Also, your BlackHat presentation was excellent, and surprisingly, I'm actually planing on watching it again to lift the details. I'm curious if you've touched any of the Verizon "MiFi" devices? I've started mildly poking at a MiFi4620LE (4G LTE "jetpack") recently, but not very seriously --It's not mine personally and its on a corporate account so I've been promised (read: threatened) to not mess with it too much. ;-) It's extremely fast but the double (p)NAT'ing is annoying i.e. it provides access to client devices via NAT to priv address space, but it's upstream interface is also NAT'ed by the carrier and in priv address space. So far I've figured out how to talk to it over USB, but I want to get it into "stupid" mode and talk directly to its internal modem. I want it to just be a dumb modem with a public address(es). I'm fairly sure there's a way to do it, but I just need to figure out how to do it. If I can get at the serial port, then it's game over.