Nano 2G

[tnt23]

Sorry if it may sound silly, but do all those games for iPod out there run on Nano 2G?
If yes, then probably it is possible to develop a piece of code that'd dump the unencryped firmware (assuming it is stored somewhere in RAM), and download it just as any other game?

[rlowens]

The Nanos (1G and 2G) don't support the iTunes downloadable games.

[Tim H.]

I'm stupid, I have read the posts of this forum to quickly and read over the small link in scorche's post.

I removed the top and the bottom of my ipod. Then I pulled out the headphone-jack, but I have not seen that there is a connector between the flexible printed Circuit and the main PCB. Next I removed the screws and pushed the main PCB out. With this action I have distroyed the flexible PCB. Now my Ipod is only a huge Flash USB-Disk  

For everybody who wants to open his Ipod nano 2.gen
Read this disassembly procedure, otherwise you would destroy your IPod
It is important to disconnect the flexible PCB from the main PCB before pushing out the main PCB!!

You will get high resolution scans/photos of the ipod in the near future.

Tim

P.S. I'm sorry for the huge font-size but I don't want anybody to kill another ipod.

[GodEater]

Well done - that enormous fonted link doesn't work.

[bascule]

But this will...

http://www.ifixit.com/Guide/iPod/iPod-Nano-Remastered/Complete-Disassembly-Page-1-Complete-Disassembly

[tnt23]

Has anyone suceeded in dumping the bootloader ROM?  

Not yet..  If any one of you guys have experience in reading Flash-ROMs and the equipment to snoop off a very high density BGA chip, let us know.

Looking at the specs, its got 16 address and 16 data pins, plus power, RE, etc crammed into a half cm^2.  I think thats going to take someone with access to a dead nano and a BGA capable programmer (or a DIP flash programmer and a really impressive adapter),

Could it be that the boot flash and storage flash share the same data and address lines? It then could be much easier to tap these at storage flash pins which luckily isn't BGA.

[Tim H.]

I'm not sure whether anybody still needs them but here are the high resolution scans:

top view
bottom view
list of chips

here ist the list of chips I could read:

Code: [Select]

--------top-------------

1: 337S32918701
N042DQS
0636 ARM

2: SEC 637 GG75
K4M56163PG
AQH373P1

3: SST39WF800A
90-4C-C2QE
0631287-A

4: National Semiconductor
JM66RJ
L34910B

5: APPLE
338S0310
68BTST8

6: Linear Technology  
6H
4066
B8966

7: 1.8432
638

8: KAET8

9: VE

10: 24.000
639

11: TXU

12: KAET8

13: VE

14: VE

15: BG

16: TVP

17: TXU

--------bottom----------
B1: TOSHIBA P11023
JAPAN 0636 KAE
TP0560
TH58NVG5D4CTG20

B2: APPLE
338S0261
P29T6  04
cPG0637Y
01/N2

-----back of display

LS015A7UC01 B
6XG002309

Tim

P.S. There seems to be a bug in the forum-software. If I leave away the "http://" in the link the preview is ok. But in the final post the link goes to "http://forums.rockbox.org/www....."

[scox]

We start with some friends to work to port linux on the iPod Nano 2nd Generation.
For more information you can see our website http://www.linux4nano.org

[Llorean]

Just to reiterate: THIS IS A DEVELOPMENT THREAD.

Posts here must be directly related to the attempt to get Rockbox working on the 2G Nano.

[keenanpepper]

Hi, I just won one of these at a TopCoder programming contest, but it's no use to me because my music library is mostly Ogg Vorbis. I'm thinking of selling it, but I could also donate it if there are developers willing to hack it but lacking hardware. Email me if you think you can convince me to donate it.

[Der Papst]

I don't have a nano but with a bit of googleling i found something interesting (<-- link):

Edit: BlaBlox is the guy who found out how to decrypt the aupd image in the Apple Firmware (Flash_Decryption) and he has successfully decrypted 2 iPodGames (Tetris and Vortex) with the help of a memdumper (self-)implemented in the Apple Firmware.

From: Franco Zavatti
Date: 19-Mar-2007 04:17
Subject: Firmware protection, a way to decrypt!
To: JD

Ok let's do it "Telegraph" style

1-I don't own a Nano! I own a 5G, and all my work is based on the 5G
2-I'm a crypto expert and I like to test real world systems, the Nano
could be interesting for me.
3-I just realized 3 days ago, the Nano firmware was protected, So I
decided to help!
4-I think I can help, because I have reversed the protection of
previous Firmware version.
5-Previous Firmware version work with a 32 bits key and a RC4 cihper.
The key is in the security block
 which prepend every file. I already send the details on the iPodLinux forum.
6-I have a dump of the firmware from the firmware partition of the
Nano 2G. It won't be enough for me to decrypt.
We need the actual decripted version from the flashrom!
7-I need the help of someone who own a Nano to extract the flashrom,
with a technique I'm about to explain.


But first...

The Security block:

The security block, is the random looking data that prepend every file
on firmware version 3.
There is 2 version of it. I know all the details of the version 1. The
version 2 is the Nano 2G version, which is different.

The security block V1 is 512 bytes long. The Security block V2 is 2048
byte long (but with the first 512 with actual data)

The security block tells the bootloader if the following file is
encrypted or not, and if it is, it will gives you the key!

In the case of V1, the cipher is standard RC4, and the key is only 32
bits long. Short enough for a brute force attack.

I don't know much about the V2 version. That's why we need to work
together to get this thing done.

How did I reversed the Security block V1: with an emulator!

I wrote an emulator based on the MESS system (based itself on MAME)

So I have trace the code and it took me less than a day to get the
decryption working but to do that, I need the firmware from the
flashrom.

How can we get the firmware from the flash?

If we can run native code in the iPod, we will be able to dump the flashrom.
I have already wrote a memDumper for the 5G, but in that case, I wrote
the data to the HDD. I don't know flash based player.

To write the memdumper we need to know:

Processor type (ARM)
Rom address (probably 0x00000000)
A way to write to the main storage flash (?)


How can we run native code in the iPod Nano?

We need to modify a boot file (AUPD or OSOS) and it will be executed
by the bootloader.

We cannot write code that override AUPD or OSOS because the files are
encrypted!

False, I have notice the file RSCS is not protected, and the Security
block V2 (2048 bytes) is all filled with F!

So we replace the security block of OSOS by an all "F" one, telling
the bootloader the file is not protected.

Then we overwrite OSOS with the memDumper code. We recalculate the
checksum in the directory and Voila!

I assume a lot of things, and I know this is a new hardware, but how
different it is?

Who can write ARM code and know enough already existing iPod hardware
to write the memDumper and store the dump to the flash storage?

So, what do you think? Comments?

[Mutmatt]

Ok so this is my nano 2ng gen.... i've been up all night searching just about every forum i could find and the ... the sgold_bootrom bootneuter thing seem quite interesting and should be looked into... at least in my mind after a sleepless night it should be haha


i included the save file and a picture

http://www.msprotege.com/members/Mutmatt/nanobackup

[HJRodrigo]

Rockbox may get a port yet, a major break through has occured tof managed to extract the contents of the SST39WF800A chip and disassembling started. Just contact THEM if you want to get the dump and help with the reverse engineering.

[Bagder]

We're already in touch with them and we cooperate on bringing facts and efforts to this. This thing shares the same/similar CPU with the Meizu M6 effort.

The 1MB flash dump is still mostly encrypted and nobody has yet figured it out.

[Der Papst]

This is a email Emmanuel sent me.
Hi,

Der Papst wrote:
> Thanks for sending me the dump :-)

You're welcome!

> We had a first look at it and i have to admit i don't know anything
> about arm asm. However 0x0 seems to jump to 0x8000. There i'm able to
> disassemble 15 more instructions.
>
> ROM:00008000                 STRMI   R7, [R9],#0x3DD
> ROM:00008004                 ANDLS   R6, PC, R3,LSL#8
> ROM:00008008                 BLLE    0xFFFFFFFFFE3BE444
> ROM:0000800C                 STCMI   p5, c0, [R7],#0x3A0!
> ROM:00008010                 LDRVCHT R7, [R9],#-0x68
> ROM:00008014                 LDMLTIB R11!, {R1,R5-R9,R11-PC}
> ROM:00008018                 SBCNE   R10, R4, #0xED00000
> ROM:0000801C                 STMCSIB R3!, {R0,R1,R6,R7,R9,SP,PC}
> ROM:00008020                 STRVCB  R7, [PC],#0xAD1
> ROM:00008024                 STRLTT  R5, [SP],#-0x4D8
> ROM:00008028                 STCPLL  p5, c0, [R10],#0x3C0
> ROM:0000802C                 TST     R3, R12,ROR#6
> ROM:00008030                 RSBLTS  R1, R8, #0xD9000000
> ROM:00008034                 SWIEQ   0x2E0C30
> ROM:00008038                 EOR     R0, R7, R10,LSL R12
>
> Then disassembling stops because the next instructions seem invalid.

Yes. We do have the same.

> Now i do some quoting...
>
> What does this first code do? It jumps to encrypted stuff.

In a matter of fact, we do think approximately the same. We are now
hitting the last level of protection, which is probably hidden inside
the processor. Hopefully here, encryption is just performed through a
last XOR applied by the processor (hopefully).

What make us guess that it was the right representation of the binaries
was the preamble and the end of the binary file which were both
perfectly meaningful in ARM asm.

Nevertheless, it seems that large area of the binary have been encrypted
(see: http://www.labri.fr/~fleury/download/ipodnano/bootloader_swap16_swap32.png).

Actually, understanding what is going on in this file is our main
concern now.

> It's probably some sort of failsafe or god knows what. Whatever it jumps
> to looks like one of the classic examples of 'invalid code'. Sure, it
> converts to instructions but they don't make sense. How to see that
> it's invalid? Well, lots of conditional code without any code
> actually checking for a condition. And there is more. About 6 or 7
> to-self jumps right after the first one. The disassembler doesn't
> find them because no code references them. That's about it.

Yes, we had the exact same reasoning. Which make us think to an
encryption (or a compression) algorithm.

> So we think (more guess) that this code is decrypted by the CPU since
> it has about 50kb embedded boot rom.

By any chance, did you ever break or analyze such a scheme where the
processor itself was involved in decrypting the BIOS or similar data ?
This kind of things are highly related to embedded systems and I have to
admit I quite unexperimented on this side.

> I hope you find out some more (and of course more encouraging) stuff.

At least, you had the exact same conclusion as we did. This is more or
less strengthening our hypothesis.

Regards
--
Emmanuel

That being said please don't contact them for the dump. It's not of use for you anyway unless you're a god at cryptography. Emmanuel told be he's harassed by people now and I don't want him to get mad at us.

Additional information can be found here: http://ipodlinux.org/Nano2G (iPL Server currently down. We're working on recovering it.)