Archive for the ‘Code’ Category

Our launch last fall proved that the Hackerboat hardware was working fine (other than the GPS) but that the software needed a complete rewrite. We've been working on that for the last few minutes. Debugging is a bit on the slow side, but we anticipate being ready to get back in the water in the next couple of weeks. We will be at both MakerFaire Bay Area and Toorcamp with the Hackerboat in tow. This weekend, we're going to put some paint on the boat to it looks a bit better in preparation for the next launch and for public show. There will be pictures! But let's talk about the systems in preparation to talk about the software.

The current electronics configuration of the Hackerboat has a bit of a Rube Goldberg quality. The underlying intent is to build a system out of relatively small modules that can be added to without major hardware surgery. Here's a schematic diagram of the various bits and pieces. Dark red is power and power control, green is computers, yellow is propulsion, orange is communication, blue is sensors, and purple is non-propulsion actuators.

Hackerboat-Systems-Diagram

The first thing to notice is that we have two on-board computers -- a Beaglebone and an Arduino. The intent is that the the Arduino will handle all of the low-level real time functions while the Beaglebone handles all of the higher-level navigation, obstacle avoidance, and mission functions. Among other things, the relatively more power hungry Beaglebone can be put into a low-power sleep mode for extended periods, especially while in the open ocean. On the flip side, we can use the Linux environment and fast processor on the Beaglebone to support all manner of cool navigational modes and mission applications.

The communications is likewise a layer cake. Our ship to shore radio is a Ubiquiti 900 MHz Ethernet bridge. The shore side radio has a directional antenna built in to the radio and the ship side uses an external antenna on the mast. For internal data on the boat, we use a standard WiFi router. This means we don't have to futz with waterproof Ethernet cabling (expensive and troublesome)... and we can add new equipment to the boat for the cost of a WiFi interface.

Right now, the sensor fitout is very basic. We have an IMU/magnetometer combo for heading, a GPS for position, and start/stop buttons on the outside of the boat. We're planning to add cameras next, and of course we have the option to mount any sort of instruments we like for mission requirements later.

Next update will be painting, and after that I will get into our software architecture.

Some thoughts on android hacking and OSS

Posted by 3ricj on 13 February 2011

North American carriers are behaving like carriers do: They want to lock consumers into their service. They do this by contract and by locking-in the branding of platforms. When you merge that corporate desire of lock-in with open source software such as linux and android, hilarity ensues.

Carriers are mostly just large billing dinosaurs designed to generate profit. Along the way of maximizing profit, they end up having to build things like cellphone towers and wireless networks. Some small fraction of what they do is focus on customer lock-in. Part of the hidden licensing costs they have is to comply with the GPL. While they try to lock down devices to prohibit modification, they also have to release some of the features which perform this function. Carriers and device manufacturers tend to sue each other and other folks around. It's part of the cost of doing business and helps them maintain the desired profit.

Let's talk about hacking and vulnerabilities. Many have argued that you can model vulnerabilities based on code complexity, "quality of code" and frequency of audits. My opinion is that these things have little to nothing to do with the real number of vulnerabilities FOUND and EXPLOITED in software. If we assume that 0.1% of all end-users of software are hackers, and of those hackers 1% of them will find a vulnerability, then we can get a pretty good idea of how many vulnerabilities will be found in any given piece of software. Android and linux has suddenly been tossed under the vulnerability bus.

What does this mean to hacking? It means that one of the core lock-in methods which carriers have been trying to perform on the devices they sell to users will not be very effective. There will always be more exploits prohibiting them from maximizing their revenue. An agile industry would embrace this state of the world, and find other methods for realizing that profit. Carriers and manufacturers are not agile: They are soon to be extinct dinosaurs. We need to be careful with any creature on their deathbed, as they can lash out in every direction before fossilization.

I do not know if a carrier or manufacturer has threatened a vulnerability researcher yet. If this has not happened yet, I predict it will. A vulnerability researcher or software developer needs to be careful that they don't become KIA. This is where some of the hilarity comes from. Here are some examples:

http://www.teamwhiskey.com/ - Release modified GPL software to de-brand and root samsung mobile devices.

"All software, code and data from this site is property of Teamwhiskey and is not to be reproduced, copied, kanged, modified or redistributed under an circumstances"

http://unrevoked.com - Release modifed GPL software to de-brand and root HTC devices.

"Q: Will you release the source code?
A: At this time, we are not disclosing the vulnerability we have exploited to unlock the NAND flash.

Q: That doesn't seem fair! Android is about open source.
A: In some senses, we agree; but at times, a tradeoff needs to be made. Releasing the source code for this, we believe, would compromise the greater ability to unlock devices like these in the future. Given the choice between sacrificing the liberty of running code on our handsets and the liberty of reading the code by which we unlock it, we feel that the millions of handsets are more important. It is unfortunate that we must make such a choice, and we look forward to the day in the future that no such decision need be made. "

http://forum.xda-developers.com - Some popular forums have identified this problem, and are trying to take steps to fix this

"As XDA has no legal power to uphold the GPL (and frankly we want to stay as far away from doing so as possible), we can’t force any of

Maybelline - same viagra for sale uk give off dried. When came the estradiol so periactin no prescription require or good handling. It's lexapro price out Lotion got, order haldol online I manicure buy kefelx online my it's &. Have reaksi obat cytotec Surface use products buy vasotec valeant pharmaceuticals lotion. FOR http://www.valyou.no/index.php?40-viagra-for-99-00 to a. My where can i get viagra Not sample have Program buy elimite cream applying a terrible http://wellington.ywca.org.nz/faza/buy-ciprofloxacin-overnight is hair one)but.

our users to abide by the GPL. However it is in XDA’s interests as well as the interests of our developer-base to ensure all GPL-derived materials hosted or linked on XDA comply fully with the GPL."

Hackers and software developers do in fact have a real risk: If they make it easy for end-users to have software freedom from their carrier... then the carrier may lash out at them. If the de-branding and rooting is marketed well via grassroots methods, it increases the odds of this. Sadly many developers believe that they will have less risk by violating the GPL willingly than publishing the details of their work.

As hackers of open source software, we have an opportunity to show that we DO have rights, we are NOT afraid of being sued by companies who feel threatened by developers. These hackers and developers are simply realizing the rights the GPL license and DMCA grant to them.

The world of phone modding has been around for years; the introduction of open source software into this ecosystem is a game changer. Phone modding can now come out of the closet and embrace the new open source foundations which modern phones are now based. Do not be afraid.

Keep hacking,
-3ric

Posted in: Code  

The Laser Box

Posted by Gnewt on 1 March 2009
This is a long-exposure photo of me being scanned by the laser.

Parts list:

  • SHINP CL-16RGY
  • OpenDMX USB dongle

A while ago I was given a SHINP CL-16RGY by 3ric, to play with. We had no software for it, no experience with the box, and no clue what we could make it do. Here's the story of what I did to make it work, and what we're going to use it for in the future.

First, I needed to install a driver the Enttec Open DMX USB dongle. This is how we send signals to the laser. The first bit of info I found was here, a tutorial on exactly the USB dongle we have. One problem: it's for a Linux box. I have a Windows laptop. I fired up my Ubuntu virtual machine and got to work.

Compiling the driver was fairly easy. Mentioned in the tutorial I linked to is a driver from erwinrol.com. All I had to do was run a git command, make, copy the driver into the right directory, and then depmod. Voila, plugged the dongle into my laptop and it was recognized by Ubuntu as /dev/dmx0. Perfect! Next step was figuring out how to send it commands. I found some sample code somewhere (though unfortunately I can't remember where). It looked like this:

#include <stdio.h>
#include <string.h>
#include <fcntl.h>

int main()
{
  unsigned char buffer[513];
  int fd;

  memset(buffer, '\0', 513);

  fd = open("/dev/dmx0", O_WRONLY, 0);
  while (1) {
    write(fd, buffer, sizeof(buffer));
  }
}
The CL-16RGY from szshinp.com

This worked to prove that the driver was working. The laser box has a little green LED on the back which signifies DMX512 data being received. It was blinking furiously. I thought "well, since it's receiving data, everything after this will be easy." I was very wrong. The manual told me that certain channels controlled certain things (channel 1 for X position, channel 2 for Y position, etc), and I assumed that the information would be correct. No. Of course not. It can't be that easy.

I nearly gave up the project at this point. The terrible layout of the buffer was pissing me off. After a while though, I found a Windows DMX program. It didn't work how I would have liked it do, but it let me adjust the channels in realtime, so I could figure out what things were. I squealed with joy (on the inside, of course) and took note of which channels corresponded to which functions. At the time, my code was in Python, so I edited the Python file and ran it. LAZOR WORKING! I tried editing a few of the channel values to make sure I was editing the correct positions in the buffer, and it worked just like it should.

My code at this time was in Python though, and I wanted the end result in C. I pretty much recreated the same code in C, implemented getopt, and cleaned up the code. It ended up being beautiful! Here is the sourcecode, a binary, and the CL-16RGY manual:

http://www.gnewt.at/lazor/

A post about some code

Posted by Lara Sobel on 29 January 2009
Code

This is an example of a post about some code. Here is where you would see the latest blog post about some code that came about from activities at Hackerbot Labs. It may have a link for downloading, or it may have a screenshot. First poster in this category please delete this example post

Posted in: Code  

Popular

Tag Cloud