So, it looks like just a few tweaks were required to get my jffs2 filesystem working. So, with this phase of the project wrapped up, I'm now onto a really tricked out set of things to do.
1) Build a "from-scratch" version of the system which only contains qte/qtopia and konqueror (plus the associated required stuff)
2) build a version of ruby for the board which strips down to roughly 9 or so mb
3) strip down metasploit to 15mb
4) get a working cheops-esque software on the board
5) general debugging / testing.
I'll post on each one as I do it. Expect that this project will take months upon months.
Friday, July 31, 2009
Wednesday, July 29, 2009
Git 'er done
I'm really really digging git. I've been able to pull tons of projects with little more than a single command line, and it just feels cleaner than cvs/svn. I'm certainly no Linus Torvalds fanboy, but when he has a need he writes a damn elegant solution.
As far as the mini2440 board is concerned, I'm in the process of writing some embedded apps for it. The first of which is a cheops-like tool. It'll be written using the GTK toolkit, but will be closed source. My plan for the device is to develop a suite of software for different models of device, and the first model will be for security testing / network analysis. My thought is that if I can put out a quality product, and charge 1/2 of what the competition would charge, I will be able to clean up. Even if I only sell a few hundred units, it'll be some spare cash for my daughter's college fund (yeah, never thought I'd write those words this young).
Anyway, I'm getting ahead of myself. There are a lot of features I really need to have before the device will go anywhere. Plus, there are a lot of features that the features need. For instance, because the keypad display will end up being so small, the better approach to a 'keyboard' interface would be handwriting recognition. However, that's a pretty tough nut to crack on its own, and I'm not sure I have the gusto to get it done in such a small amount of time. Still, if I can get a prototype done by December, and still meet my deadlines at work (meaning there ain't no rest for the weary... not that a screaming 1 month old would let me sleep anyway). We'll see how that goes.
As far as the mini2440 board is concerned, I'm in the process of writing some embedded apps for it. The first of which is a cheops-like tool. It'll be written using the GTK toolkit, but will be closed source. My plan for the device is to develop a suite of software for different models of device, and the first model will be for security testing / network analysis. My thought is that if I can put out a quality product, and charge 1/2 of what the competition would charge, I will be able to clean up. Even if I only sell a few hundred units, it'll be some spare cash for my daughter's college fund (yeah, never thought I'd write those words this young).
Anyway, I'm getting ahead of myself. There are a lot of features I really need to have before the device will go anywhere. Plus, there are a lot of features that the features need. For instance, because the keypad display will end up being so small, the better approach to a 'keyboard' interface would be handwriting recognition. However, that's a pretty tough nut to crack on its own, and I'm not sure I have the gusto to get it done in such a small amount of time. Still, if I can get a prototype done by December, and still meet my deadlines at work (meaning there ain't no rest for the weary... not that a screaming 1 month old would let me sleep anyway). We'll see how that goes.
Tuesday, July 28, 2009
u-Boot on a FriendlyARM
So, I recently ordered a FriendlyARM development kit, with jtag & cmos camera. It's a small handheld unit with touch-screen, usb, rj-45, and SD card reader. The goal is to build a portable diagnostics device for anything I could imagine.
It came pre-loaded with a 2.6.13 series kernel, Qtopia, and a few odds and ends worth of tools. As for the bootloader, it comes with vivi, which is a fairly lightweight flash loader. It used a different version of gcc to build each component, from vivi to qtopia to the kernel. Plus, it doesn't feel like I can "get under the hood" as easily with their versions of things.
So, first order of business was to get u-boot running in place of vivi.
The vivi image is located in both the nor and the nand flash on the board. I used the nor flash as a bootstrap to put uboot on the nand flash. To do this, I first did a git pull from a public repository for the mini2440, as well as getting a publicly compiled mini2440 unified toolchain (not from sourcery, or whatever it's called). I built the u-boot image, and ended up with a nand512 image, which I then copied to the nand memory area via xmodem (minicom is great). Set execution to that point, and then bam, flashed the nand with the uboot image (I got it again via tftp, but that was so that I could use uboot to update the bbt which is a bad-block table).
Now, I'm building a 2.6.31 series kernel (the latest) and will be building a custom system which includes the latest qtopia as well as metasploit, nmap(with a frontend), and a few other neat security tools. We'll see if I have enough space (64MB of flashable space is not much).
More updates later.
It came pre-loaded with a 2.6.13 series kernel, Qtopia, and a few odds and ends worth of tools. As for the bootloader, it comes with vivi, which is a fairly lightweight flash loader. It used a different version of gcc to build each component, from vivi to qtopia to the kernel. Plus, it doesn't feel like I can "get under the hood" as easily with their versions of things.
So, first order of business was to get u-boot running in place of vivi.
The vivi image is located in both the nor and the nand flash on the board. I used the nor flash as a bootstrap to put uboot on the nand flash. To do this, I first did a git pull from a public repository for the mini2440, as well as getting a publicly compiled mini2440 unified toolchain (not from sourcery, or whatever it's called). I built the u-boot image, and ended up with a nand512 image, which I then copied to the nand memory area via xmodem (minicom is great). Set execution to that point, and then bam, flashed the nand with the uboot image (I got it again via tftp, but that was so that I could use uboot to update the bbt which is a bad-block table).
Now, I'm building a 2.6.31 series kernel (the latest) and will be building a custom system which includes the latest qtopia as well as metasploit, nmap(with a frontend), and a few other neat security tools. We'll see if I have enough space (64MB of flashable space is not much).
More updates later.
Tuesday, July 7, 2009
Another Brick in the wall
I've been playing with dynamic symbol loading. It's actually pretty cool! The gist is, you don't know what another developer will be doing, so you try and provide enough hooks so that they can get done what they need. However, if you give that person too much power, there's always the chance they will abuse it and then your users are left blaming you for some nefarious code someone else wrote.
The approach I'm taking is to have a bunch of places where the developer can hook, and give them copies of the actual data that I use internally. That way, I can run sanity checks before I decide to use that data myself. This gives me a bit of extra control, at the cost of some performance.
But, no system is bulletproof, and this approach still doesn't prevent someone from breaking things. Only makes it so that they probably have to be intentionally trying to break things instead of being able to claim that their buffer overflow which manages to get a remote shell up is a lucky accident.
The approach I'm taking is to have a bunch of places where the developer can hook, and give them copies of the actual data that I use internally. That way, I can run sanity checks before I decide to use that data myself. This gives me a bit of extra control, at the cost of some performance.
But, no system is bulletproof, and this approach still doesn't prevent someone from breaking things. Only makes it so that they probably have to be intentionally trying to break things instead of being able to claim that their buffer overflow which manages to get a remote shell up is a lucky accident.
Subscribe to:
Posts (Atom)