Brief comparison of ipodedit and iPodWizard:

• iPodWizard changes the updater instead of changing the firmware on the device itself. There should not be an issue of figuring out the right firmware to change with ipodedit as you can change the iPod directly. Also, to avoid a complete restore and wipe of the iPod when using the updater, it is required to edit the Sysinfo file to fake the installer to think it is at an older version. This gets tiring to do.
• ipodedit dumps many more resources and allows for much easier string editing than iPodWizard. However, ipodedit doesn't deal with fonts in an easy manner yet.
• Resources sizes (e.g. graphics and text) can be changed drastically in ipodedit and not in iPodWizard.
• iPodWizard is a GUI, ipodedit is a command line program. There are GUIs on top of ipodedit available.
• iPodWizard is Windows only. Even with the recent release of its source code, its use of Windows API makes it difficult to port to other systems. ipodedit should compile and run on a variety of systems (including Linux, OS X, the iPod itself, and Windows).

Warning: use this at your own risk. I take no responsibility for anything whatsoever. This program is not for those who shudder at using the command line. If you cannot compile this program yourself, then you probably should not be using this!

For most people, I would recommend trying one of the following programs instead. These other options include GUIs, precompiled binaries, and much more support: iPodIcons (Mac OS X, Linux, *BSD, Windows?, anything else with Qt), alterPod (Mac OS X) (google for alterpod, podite.com site is no longer available), or iPodEditor (Mac OS X).

But if you're feeling brave today, here's the program source released under the GPL) almost certainly with many untested "features" (that's what you're for):
Download: ipodedit.c (Last update: Feb. 3, 2008) (update for 5g/5.5g ipods). It should easily compile (it shouldn't have any dependencies). Note program is not being actively managed as I no longer use an ipod. If you have a good patch, I'll incorporate it. Otherwise, don't expect much more from this program.
This version may or may not support newer iPods. I've only personally tested on one 4g ipod. Let me know if it doesn't work on newer models, or better yet, send me a new iPod and I'll be sure to make this program work for that version :).

Notes about use

• You do not need to use dd to extract and write your iPod firmware, but if you wish to, you can still do it with that relatively dangerous method. You can substitute ipodedit for dd by running the program directly on the iPod device file. Using the program to access the device file directly may be safer as the program does check that the file being read/written at least looks like an iPod firmware before making any changes. So for example, ipodedit extract /dev/sda1 extracts out resources as expected if the user has read permissions on /dev/sda1. You can also extract out the firmware to a local file by running the extract command and treating the disk device file as if it were the updater file: ipodedit extract /dev/sda 1 will extract the first firmware it can find from the disk. In this case, specifying the 1 is important unless you wish it to scan your entire very large disk. However, you extract the firmware, be sure to save a copy of your original firmware, in case of problems! For example, to change the firmware from a FAT formatted iPod under iPodLinux, use /dev/hda1 as the target firmware device.
• To understand how to use the program, it is helpful to understand how the iPod firmware is laid out. There are blocks of resources. Resources are of some type (e.g. bitmap or text) and some data. There are first many resource blocks that each contain text for the various languages that the iPod supports. After these language resources, there's a resource block that I call the primary resource block. This block contains the English text and also the general resources used for all languages like bitmaps.
• The program is invoked with a general form like ipodedit command args. For help with commands the program recognizes, just type ipodedit with no arguments. All commands have a descriptive name like "extract" and a shorter, easier to type name like "x" (see the program help for these forms). Here are brief descriptions of each of the commands.
• ipodedit extract firmware [num]: This is probably the first thing you want to do. This will extract resources from a firmware file. If num is a positive number, then only that language resource block number will be extracted (see list of languages below). The first language resource block is block 1 so ipodedit extract firmware 1 extracts that block. If num is 0, only the primary resource block is extracted. If num is -1, all resource blocks including every language and the primary resource block is dumped.

  If num is omitted, it defaults to 0, meaning only the primary resource block is dumped (probably what most people want). Most people probably don't want to play with a bunch of languages. Each file is prepended with a number that indicates which resource block it is from as resource IDs are not unique across all resource blocks. Most of the resources are quite small and there are many of them. Even though the total bytes for all combined is quite small, depending on your disk's block size and the minimum size for a file, the disk space needed to dump everything can be around 40 MB.

  The raw data is dumped into directories named raw. The filenames are of the form [type][id].rsrc. For example, the file bmap17800.rsrc contains the resource of type 'bmap' (bitmap) with ID 17800. All resources are referred to with their internal IDs. Note that IDs can be negative so text-104.rsrc refers to a resource of type 'text' with ID -104. With that said, most people should probably completely ignore the raw directories. The more friendly usable "decoded" data is dumped separately into the directory ipod/[block num]/[rsrc type]/name. So for example, ipod/0/raw/bmap/bmap17800.rsrc is converted into an image file at ipod/0/bmap/bmap17800.pgm.

  There is an ipod-resources.txt file that is written. It contains some information about each resource dumped, one per line.

• ipodedit prepare file: This converts a file in the human-friendly form back to the raw form. For example, suppose you wish to edit the text-104 resource. You first dump all resources and then open up the file ipod/text-104.txt in a text editor. You edit the text in there to what you want. Writing your changes back to the firmware is a two step process. The first step is to run ipodedit prepare ipod/text-104.txt. It'll write the file ipod/text-104.rsrc which is the raw form for the data which is needed by the write command to update the firmware.

  The program automatically reduces grayscale depth by simply chopping off all but the most significant bits. I've found that this sometimes makes not so nice looking pictures from high depth pictures. You might get better looking pictures by reducing the grayscale depth using your favorite image program with its fancy (i.e. not hacky) algorithms.

• ipodedit decode file.rsrc ...: This converts resources into an editable form. It is the opposite of the prepare command. Normally, you don't need to run this command, as all resources are decoded automatically upon extraction. However, if you get files from some other source as .rsrc (for example from a theme), then you can use this command manually.
• ipodedit map directory [mapfile]: This maps resource numbers specific to one firmware to potentially generic and more descriptive names. mapfile if not specified defaults to resource.map in the current directory. The format of mapfile is three items per line containing the resource type, the firmware resource ID, and a generic name (no spaces in the name) of the following form:

  bmap 12345 do-not-disconnect
  text 54321 ipod
  

  If the file resource.map exists in the current directory when extracting resources, the mapping is performed automatically upon extraction. Mapped resources are written into the ./ipod.map/ directory.
• ipodedit unmap directory [mapfile]: This is essentially the reverse of the map command taking generic names to firmware specific names. Unmmaped files are written into the ./ipod/ directory.
• ipodedit write firmware directory [num]: This command is the heart of the program. It'll look in the given directory tree for files with the extension .rsrc and will try to update those resources in the firmware. Only resources that have a corresponding .rsrc file will be updated. If a .rsrc file is missing, then that resource will remain whatever it currently is. Note that the file name must be correct (what was dumped by the program) for the correct resource to be updated. Directory names don't ever matter so you don't have to use the default ipod directory. The checksum is updated if necessary.

  The num argument has the same meaning as the extract command except that the default value if omitted is -1, that is, all blocks are updated if an appropriate .rsrc file is found.

  Individual resource sizes can be changed! Because the entire resource table is written out, you are no longer limited by the size of an individual resource, but you are limited by the size of the entire resource table. So for example, if you would like to increase the string length in one resource, you need to reduce the string length or picture size in another resource (within the same block). This means that you can change image sizes or depths if you want. If you do this, your firmware will likely not blow up, but I'm not guaranteeing that the pictures will show up as you intend them to. Increasing picture sizes will likely have the picture crop on the iPod. I have been able to increase the displayed size of pictures but that required also changing the bounding box size located in a 'view' resource (currently not easily editable except with hex editor.) Changing the sizes of resources seems to always work for me, but please let me know about your success or failure stories.

• ipodedit checksum firmware: This command will update the checksum in the firmware. Most people will never use this command as the program automatically updates the checksum when writing. But if you make other changes manually, such as with a hex editor, this command will update the checksum.
• ipodedit info firmware: This command prints out some information about the firmware. It does the same thing as the checksum command but doesn't ever write anything.
• ipodedit extractfw updater [num]: This will extract firmwares that it can find from the updater (or any file, really) into many firmware files. It doesn't tell you which file it dumps is the firmware for which iPod, so you have to figure that out yourself. If num is specified, it extracts at most num files. For example, you can use this to extract the firmware from a raw disk partition of a connected iPod by specifying num as 1.
• ipodedit write updater directory [num]: This will re-write an updater file with new firmwares. The directory should contain the firmware(s) that you wish to update. The new firmware must have the same name and be exactly the same size as that which was dumped by the extract command originally. Num has the same meaning as for extract with the default being to update all firmwares that are found.
• Languages: The order for the language blocks is:
  1. Danish
  2. German (Dates & Time)
  3. German
  4. Spanish
  5. Finnish
  6. French (Dates & Times)
  7. French (Dates & Times)
  8. French
  9. Italian
  10. Japanese
  11. Korean
  12. Dutch (Dates & Times)
  13. Dutch
  14. Norwegian
  15. Spanish (Dates & Times)
  16. Swedish
  17. Simplified Chinese
  18. Traditional Chinese

  It is possible to make your own language translation package. You can take an existing language you don't need and replace all the text files with a particular language (assuming a font with all the characters needed exists for that language). If you'd like to publish your translation for others to use, you can make a bundle of the .rsrc files as a theme.

• Resource types: There are many different resources types. Not everything is yet handled by the dump and prepare commands. The known types are:
  • bmap: graphics output as grayscale PGM raw 'P5' files or color PPM raw 'P6' files. In addition, an extra .prop file is dumped with extra image information that is probably best left alone. When running the prepare command on a bitmap, the prop file must be present for it to correctly regenerate the rsrc file.
  • text: strings output as .txt text files
  • boot: graphics located in the bootloader only for pre-4th generation firmwares and are dumped just like bmap resources. boot resources cannot be decoded with the decode command.
  • menu: includes menu data such as what shows up in what order.
  • type: font mappings
  • view: layout of elements in the iPod display
  • tcmd: a command table
  • ldtm: unknown, perhaps some sort of language definition (pretty much the same in all language blocks)
  • none: empty space placeholder

  Some resources are dumped to .prop property files. This is basically a hex editor in disguise. Files can be edited with a normal text editor with values entered either in decimal or hex. Value names should not be changed and comments are specified with '#'.

  Unlike editing the text or picture files, it is extremely easy to make your iPod unbootable (and require entering disk mode) by editing and writing back the .prop files. Therefore, only advanced/brave/stupid users should be editing the .prop files. In the .prop files, you'll see that many of the fields have non-descriptive names. This is because I don't know what the fields do, so if you figure out what they do, please let me know!

• String editing: you do not need to use a hex editor so this program makes it safer to edit strings that are meant to be edited. To find the appropriate resource to edit, you can use grep to find the appropriate text file to edit and then use any text editor to do the editing. It is possible to either increase or decrease the size of text substantially if you wish. Some text are quite obvious candidates for shrinking to give you more space for other resources.
• Themes: The program has support for themes. Any directory of .rsrc files (graphics and text and maybe other resources once they are reverse engineered) is a theme that can be updated with one write command. A theme only updates the specified resources and leaves all others untouched so a theme package doesn't take much space. For highest compatibility, themes should be distributed using standard canonical generic names along with the necessary mapping files to convert to various firmware versions if necessary.
• Scripting: This command-line program makes it easy for simple scripting tasks. Imagine a cron job that automatically changes your iPod text to a fortune message or something crazy like that. You can automatically change pictures or text whenever you connect your iPod so you never know what you'll see next. You can even let people over the web change the text that shows up on your iPod. I can't imagine why you would want to do this, but it seems people are putting their entire lives on to the web these days.

Bugs/Improvements

• Fonts are parsed but they currently aren't dumped in an easily editable form. It's purely an interface issue. The bitmap could easily be dumped and edited, but it isn't clear the best way to dump the other font info to allow editing. I'm thinking the easiest way would be to read and write a simple font file format like BDF (then you could use a program like fontforge to convert to and from truetype, postscript, etc. fonts). But I don't have too much motivation right now for changing the fonts on my iPod so I may not get around to doing this anytime soon. If someone else would like to write such a thing, let me know. (Here's the BDF specs).
• Complaints about speed, lack of GUI, the ability to screw up your iPod, etc., will be cheerfully ignored. But if there's some extra feature that you think can/should be added, do let me know or better yet, send me a patch.

Have fun and don't get into trouble.

Austin Che