This is an attempt to reverse-engineer the software of a DMTECH DPF-701 (Digital Photo Frame). You can get these for about 300 SEK at Kjell&Co in Sweden, making it an affordable multi-purpose standalone mini-LCD/status-gadget if you could somehow modify the firmware to allow LCD control over USB (or IR..).
Blockdiagram of Hi2028, supposedly a platform similar to Hi1018. Hi1018 does not contain the hardware MPEG decoder datapath (crossed out in red in figure above)
Many of these features are not usable on the photoframe (such as ethernet/networking), audio playback nor the NES emulator since they are not routed on the PCB.
There are a few labeled test-points on the PCB. These often provide useful debugging information for the developers, but can also help to understand the platform for anyone else. On more generic platforms, like your typical home-consumer network equipment, 9 out of 10 contains serial port testpoints which provides shell access to the operating system.
The shippingbox states 16 Mbit of internal for photo storage, however the userguide also mentions "Not full capacity can be used for photo storage, subject to the sharing of internal software". The swedish translation is better and it clearly states that the firmware is located on the flash (in contrast to an on-chip ROM, which is kind of a showstopper for any kind of modifications).
To disassemble the firmware and gain a better understanding of how the hardware works, it needs to be extracted from the internal flash memory.
During the summer of 2010 I discovered the wonderful world of paragliding and shortly thereafter joined the local paragliding club Club Parapente Syd (CPS). To better track current weatherconditions at our most popular flying sites, CPS manages four weatherstations. These are accessible through phone and the current wind speed, direction and air temperature is read by a synthesized voice as you place a call to any of the stations.
One of the stations (DPS AWS-X, pictured to the right) support transmission of samples over GPRS/Internet, so I started experimenting with webpage publishing for easier access. I created a piece of software to receive, decode and place the samples into a database. The samples are later visualized and plotted through a webpage (swedish only).
The website quickly became popular among the CPS members and I started investigating ways of hooking up the other stations to the webpage in a similar way. Unfortunately, they are quite old and the legacy hardware does not support any kind of GPRS packet transmission.
Purchasing new stations to replace the old ones proved very costly, so instead I started designing a station on my own. WindWiz was born. WindWiz is an umbrella project for a scalable weatherstation system. It contains a piece of minimal sensor hardware with GPRS support. It also contains a generic version of the above mentioned software to collect and visualize samples. Finally, it also contains backward compatibility support for the commercial station I originally started experimenting with (DPS AWS-X).
The goal of this project is create a network of weatherstations to be deployed along the coasts of southern Sweden, and possibly at other locations. Weather samples collected by the sensor network should be transmitted back to a central server where it is stored in a database and later published to the web. It should be accessible both as webpages, from cellphones and to thirdparty applications. Everything should be open-sourced and the components required to construct the hardware must be easy to obtain (off-the-shelf).
Hashauth is a set of tools that helps you manage your passwords. Hashauth differs from traditional 'password managers' by deriving your passwords from mathematical functions (hash functions) rather than storing them on disk, and thus is completely liberated from password databases.
Users are notorious for choosing obvious and weak passwords; Passwordstrength is difficult to achieve by manually choosing a password, but in turn, generated passwords are tedious to remember.
However, a single strong password may not be enough. Using the same password for multiple resources only becomes as strong as the weakest link.
It is naive to believe that account information is stored in a secure encrypted form at all times. In fact, many websites out there still keep passwords in plaintext, which will render your strong password useless if the site is compromised. When the same password is used for multiple services, a malicious user may gain access all your accounts by attacking the weakest link.
Hashauth uses generated passwords, and so you need to replace all your existing passwords with new ones generated by Hashauth. To generate a new password, point your browser to http://auth.mag32.net/.
To obtain the unstable (latest) version of Hashauth, clone the Hashauth JS git repository:
To speed up re-generation of your passwords, profiles can be created which automatically fills in the Salt, Output length and Hash engine given a resource string. This reduces the amount of human input by sacrificing a bit of 'privacy'.
To attach a profile, enter the JSON encoded profile filename and press the "Attach profile" button. HashAuth will then load the file using an AJAX call and parse the contents. Please note that most browsers disallow AJAX requests outside the local domain, so your profile file must be located on the same domain where HashAuth is hosted. With a valid profile loaded, HashAuth will attempt to autocomplete the resource string and fill out the necessary values whenever a match is made.
Please note that the profile file is useless without the master password, which is NOT stored anywhere by HashAuth. A profile file can however reveal certain information if someone finds the file:
Python wEbpage EXchanger (PEEX) is a non-interactive FTP client for updating webpages. Peex is an utility designed to automate the task of remotely maintaining a web page or other FTP archives. It will synchronize a set of local files to a remote server by performing uploads and remote deletes as required. Peex is heavily inspired by Weex with the important difference that Peex does not try to cache remote directory structures locally. This makes it more cooperative with alien files introduces by 3rd parties. It also enables multiple developers to collaborate more efficiently.
Peex is unique in that it can protect 3rd party generated content on your server. A typical scenario is content uploaded by users on your webpage. Using a traditional synchronization tool, these files will be flagged as 'obsolete' (since they are not present in your local tree) and incorrectly removed during the synchronziation.
Example: Consider a webpage where users can upload profile images for their useraccounts. New content is added to the remote tree which should not be removed if a new version of the PHP script (uploadscript.php) is to be synchronized.
Local Tree Remote Tree ----------- ------------- . . |-- avatars |-- avatars | `-- user0.png | |-- user0.png | | |-- user1.png (incorrectly flagged as obsolete) | | `-- user2.png (incorrectly flagged as obsolete) | | `-- uploadscript.php `-- uploadscript.php
Surprisingly few synchronization tools support this use-case in a good way.
Most apps build up a local cache of the remote file tree as files are initially put into place. Files added to the remote tree by 3rd party will be ignored since they are not in the cache. In other words, they only care about content they've put into the remote tree (sane logic).
This is how Weex and several other apps work. While they do support the above case, it is not a very robust solution. If the local cache is lost, there is no way of separating obsolete local files and content added by 3rd party.
Weex and others fail when:
PEEX tries to work around this by not maintaining a local cache. Instead it refreshes the remote tree before each synchronization and relies on a set of regular expressions to detect files which should not be flagged as obsolete.
While this becomes considerably slower than a local cache, it provides a more reliable solution.
For very large single developer trees or trees where no 3rd party is involved, you should use Weex.
PEEX v1.0 is available for download here.
To obtain the unstable (latest) version of PEEX, clone the PEEX git repository:
PEEX is configured partly through commandline switches and partly through config files. The config files contain per-project settings and the command line switches are more general options.
Run PEEX without any arguments to show available commandline switches and its description.
Once the configuration file is setup, synchronization is started by issuing:
It is recommended to set restrictive file permissions on your PEEX configs as they contain sensitive account details. E.g.
For a little bit more details on progress, use:
For colored output use:
[site] host=<ftp_host> port=<ftp_port> user=<ftp_user> pass=<ftp_pass> source=<source directory on local disk e.g. /home/user/myfiles/> dest=<destination directory on FTP e.g. /www_files/> [exceptions] <regex_pattern>=[ignore|protect] The exceptions section lists files which should either be protected on the server, or ignored in the local tree. Example patterns: offline=ignore avatars/user(\d+).png=protect
The D-Link DSL-504T is an AR7-based MIPS 4KEc ADSL router designed for home and small office use. They are quite hack friendly with a pre-soldered serial connector and announced OpenWRT support (as of v8.09). This means that you can re-install a vanilla kernel on the device, and customize it to be much more than just a ADSL router.
On this page, you will find instructions on how to install and configure OpenWRT to replace the DSL 504-T stock firmware. Please note that re-flashing your device with a 3rd party firmware voids your warranty, and you also risk completely bricking your device. I take no responsibility for whatever damage the following procedure may cause on the device (or you :)
If you run into problems, a useful resource is the #openwrt channel on FreeNode where a lot of senior embedded developers hang out to discuss OpenWRT and related topics.
Until I get around writing detailed instructions for this section, you can find pre-compiled DSL504-T OpenWRT images at http://downloads.openwrt.org/ (look for openwrt-ar7-squashfs.bin in the kamikaze/*version*/ar7 directory). These images are configured to allow your DSL504-T to act as a router, much like your old stock firmware. It does however NOT include a web interface, and so you need to configure most aspects of the system manually through SSH. If you are familiar with Linux, this should not be an issue.
If you wish to build a completely customized image, you can checkout the complete OpenWRT tree from their SCM at https://dev.openwrt.org/. I recommend that you have at least basic knowledge in build-systems and some experience with embedded development (in particular, understanding the concept of cross-compiling) before doing this.
Even though console access isn't required to reflash the device, it can be an invaluable tool for developers. It can be used to inspect early kernel messages and to debug low-level subsystems. If you wish to interact with the ADAM2 bootloader prompt (Hello World-example application), a serial cable is required. If your only plan is to replace the stock firmware with an OpenWRT image, the ADAM2 FTP flashing capabilities are sufficient, but for all other purposes you should consider hooking up a serial cable to target.
USB to serial cables are usually available off-the-shelf in many electronics stores. I recommend getting a cable based on one of the FTDI USB to serial chipsets, as they are known to work well with Linux. Have a look at ftdichip.com for more details on what you need.
The console can be accessed through the pre-soldered serial port connectors found on the PCB. Pinlayout is RX, GND, +5V, GND, TX. For your convenience, I have marked the UART pins with labels in this PCB photo. To connect, use any serial terminal client: On Windows, I prefer PuTTy (recent versions support serial ports), for Linux minicom works fine (albeit a bit clumpsy). You need to set up the connection to use no flow control, a baudrate of 38400, 8 databits, no parity and one stopbit (38400 8N1).
To verify the connection, try rebooting the device and look for ADAM2 messages and/or Linux kernel output. A common mistake is to mix up the RX and TX pins. If the terminal is silent while your system boots, try swapping pin 1 with 5.
Magboot is a bootloader for the Atmega-family of Atmel processors. It provides the ability to write the onboard flash memory over the serial port. It can be used to flash an AVR device with new firmware without a dedicated ISP programmer device.
Valid question! Prior to creating Magboot I sorted through the massive amounts of bootloaders available for download. In the Arduino sourcecode repository alone, there are over 5 different bootloaders all with different features. Some are tiny, some can boot in exotic ways while others contain boardspecific stuff.
With all this configuration, and well, to be honest, messy code, it quickly becomes difficult to edit or debug for someone other than the author. I ran into some issues with the reset mechanism of the Arduino stockbootloader which forced me to debug the code. It was not pleasant!
I created Magboot to be as simple as possible. It cannot deal with anything other than raw binaries. It doesn't do EEPROM. It doesn't support any official programmer protocol or AVRdude. It is very minimal yet without any obscure code tricks nor assembly to optimize for size. It was written with readability in mind.
If you want a simple, easy-to-use serial bootloader for your Atmega-based project, Magboot might just be what you're looking for!
To obtain the unstable (latest) version of Magboot, clone the git repository: