Dallas/Maxim's iButtons™ are integrated circuits encapsulated in metalic "Microcan" packages. They look like button cells, and the package itself can host different circuits with different functionnalities, some are a simple read-only unique serial number, others are EEPROM, others can even record temperature and humidity, with a readable battery-backed RAM.

They use One-wire technology, enabling them to run from the tiny current they get from the high state of their data line. One part of the iButton serves as ground, the other is the data/power. The only battery-powered iButtons are the ones with standalone features.

They are relatively common in identification systems, mainly to replace magnetic cards. Some iButtons have SHA1 and password protected zones, often to protect monetary data or personal information, but because they're much more expensive at a high scale, some NVRAM iButtons may be used to store monetary tokens...

[yotienpluche] was given a "Dallas Key" at work, so he could store small amounts of cash in it, and conveniently buy m&m's and other bullshit at vending machines.
I was expecting to read "DS1961" on it, as it's the part number for a SHA-1 1KBit NVRAM iButton, but we actually saw that it was only a DS1992, 1KBit NVRAM one, which meaned that anyone could read and write to it without any problem. We are still wondering if this kind of iButton is commonly used for vending machines...

We guessed before reading its contents that the cash was certainly encrypted with the iButtons serial number, and we spent quite some time trying to figure out how the vending machine was getting the job done. We had a few clues from some official guidelines on iButtons data storage, but as it's an "Universal Data Packet", anything could fit inside of it.

Finally, the idea of forging the packets from a value and a serial number was forgotten, and we went the simpler, Replay-attack way.
For example:

-The user loads up his iButton with (real) $10.
-He makes a full backup of its contents, with his encrypted $10 value.
-He buys some stuff, like usual.
-When the iButton is "out of cash", he simply writes back the memory image to it. As there is no date and time values written anywhere, the vending machine can't make the difference.
-He buys (steals) some stuff again...

Since I didn't want to buy an expensive iButton interface, I slapped together a quick One-Wire to serial adapter on a breadboard, with a ATMega8, a MAX323 and a small Visual Basic application to be able to read and write memory blocks.

The first version just dumped the serial number, part type, CRC and the 1Kbit memory contents.

The software allows to individually read and write any banks of the DS1992 iButtons.

The iButton uses a Scratchpad to temporarily store the data to be written before being effectively written in the NVRAM. This avoids interrupted writes or corrupted data to be written unintenionally.
The Scratchpad is 32 bytes big and corresponds to one data bank.

A push-button powers up the circuit, a slide switch can be used, but as the device is not intended to stay on very long, it doesn't make much sense. The Tiny45 doesn't use SLEEP modes, as to not drain the batteries after a few months. A switch allows to choose between the backup or the restore mode, because the firmware checks it on power-up, it has to be in the right position before the push-button is held down. R3 is a pull-up resistor needed to power the ibutton in between data exchanges.

Here's the bottom copper layout in 200DPI. Note that the holes for the ibutton contacts are 3mm in diameter. Also be careful to the polarity of the power supply (+), and to use alcaline batteries only (as written above, ibuttons want at least 2.8V to work).

Parts list: Batt: 2xAA ou 2xAAA battery holder with wires, the PCB can be sticked on it with double-sided tape. C1: 10nF ceramic capacitor C2: 10µF 10V (or more) electrolytic capacitor D2: 3mm red LED D3: 3mm green LED R1,R2: 100ohms 1/4W resistors R3: 5.6Kohms 1/4W resistor PWR: Micro button U1: ATTiny45 microcontroler J1: ON/ON switch (center common) GND,IBUTTON: M3 10mm screws and bolt, pointing towards the components side.

Perboard layout is coming...

Sorry, I'm not giving out the source code and bin files anymore. Some people were starting to get a bit too interested...

Constants descriptions:

MAXRETRY sets the maximum number of tries for each operation, before a blinking red LED.
RWSWITCH is the pin number for the R/W switch.
IBUTTON is the pin number fot the iButton data contact.
GREENLED is the pin conntected to the green LED's anode.
REDLED is the pin connected to the red LED's anode.

From the iButtons datasheets, should not be changed:
WRITEONE 10 // min:1µs max:15µs Duration of the low state to write a 1.
WRITEZERO 90 // min:60µs max:120µs Duration of the low state to write a 0.
TIMESLOT 120 // min:60µs max:120µs Total time for a bit write.
RESETLOW 500 // min:480µs Duration of the low state to reset an iButton.
RESETHIGH 500 // min:480µs max:960µs Duration of the high state between resets.
PRESENCE 70 // min:60µs Delay before reading a presence signal.

MINWAIT 100 // Delay in milliseconds for LED blinking and debounce stuff.

In red: bank's CRC16.
In green: contents size in bytes.