[00:01:07] user890104: Does the decryption chip/part of the chip also contain the encryption btis? [00:01:59] yes, but we're unable to extract the keys [00:02:43] we're able to make the chip sign our code, and that's how our installers work [00:03:56] user890104: How feasible would it be to separate the SOC from the rest of the device so it's never necessary to find a vuln in the first place? [00:04:05] Or is it not exposed sufficiently [00:05:27] well, if you like soldering BGA... [00:05:38] and i don't see how separating will help [00:06:26] nano2g's bootrom was initially dumped by taking the chip out of the board, and wiring it to a dev board [00:06:49] user890104: Like, rather than looking for a vulnerability in the OS itself, why can't we take a ripped apart device to be used solely for code signing an OS which will run normally just by flashing an arbitrary device through the normal iTunes interface? [00:06:58] so in theory, if we can dump the bootrom of a device, we can disassemble it and look for vulns [00:07:32] because there are two types of keys - device keys and global keys [00:07:42] you can only encrypt/sign with the device key [00:07:52] and the code runs on the very same device [00:08:07] Why did Apple use device keys in the first place then? [00:08:12] they are used for different operations [00:08:55] for example, when an update comes, it's signed with the global key. then when the ipod updated its bootloader on the utility flash, it signs it using the device key [00:09:12] s/updated/updates/ [00:09:45] our installer uses a DFU exploit, then signs the bootloader using the device key [00:10:01] and makes the bootrom happy [00:10:10] Hmm [00:10:30] Would the image in NAND be signed with the global key or the device key? [00:11:03] i guess it's the global one, but TheSeven might be able to explain this better [00:11:19] it's actually encrypted, not signed [00:11:21] if it uses any of those HW key crypto, it will be the global key [00:11:39] AES-128 CBC, zero IV IIRC [00:11:41] however they tend to sign things with RSA certificates these days [00:11:59] and don't rely on encrypted hashes for that anymore [00:12:27] so it's quite likely that everything that you need to verify the signature is in fact in that image [00:12:45] however you need the private key for that certificate to sign something [00:12:59] encryption will likely be group HW key AES128 CBC [00:13:47] we've never seen things outside the boot flash (or nand boot area on newer ipods) be encrypted with the device key [00:23:09] *** Joins: prof_wolfff (~prof_wolf@82.158.1.206.dyn.user.ono.com) [00:23:15] hello, prof_wolfff [00:23:29] hello [00:24:33] *** Quits: nialv7 (~nialv7@adm-129-49-227-93.wi-fi.stonybrook.edu) (Ping timeout: 244 seconds) [00:34:21] *** Joins: nialv7 (~nialv7@adm-129-49-227-93.wi-fi.stonybrook.edu) [01:42:34] *** Quits: nialv7 (~nialv7@adm-129-49-227-93.wi-fi.stonybrook.edu) (Ping timeout: 244 seconds) [02:23:13] *** Joins: nialv7 (~nialv7@130.245.213.24) [03:53:17] Doing something a little bit crazy [03:53:24] And by a little, I mean a lot [03:53:51] When I modified the rsrc section, it booted into recovery mode which is sharing with disk mode, [03:54:06] Seeing what will happen if I switch osos and disk sections [03:54:12] please don't break everything ^_^ [03:55:12] ..the fuck [03:55:14] it worked [03:56:12] It showed the iTunes restore screen, but it booted anyway ^_^ [03:56:22] Guess I just discovered my first vuln ^_^ [03:58:41] TheSeven user890104 [Saint]: My mind is booting into DFU mode right now [03:59:46] shadowcoder: "booted anyway"? [03:59:58] despite OSOS containing (signed) nonsense (i.e. fat16 fs)? [04:00:08] No no, [04:00:11] I switched OSOS and disk [04:00:16] "disk"? [04:00:28] So when rsrc was wrong and it wanted to boot into recovery mode (which is the same as disk mode apparently), [04:00:39] It was tricked into booting into the main kernel anyway [04:00:43] ouch [04:00:47] these modes are exposed there now? [04:01:02] what do you mean? [04:01:18] on older generations the disk/diagmode images weren't in the firmware.mse file [04:01:25] Oh [04:01:28] but in a separate section of flash [04:01:30] Yeah, there are nine sections now [04:01:35] but I guess it makes sense to unify that [04:01:44] 1. because it's now on the same flash chip anyway [04:01:54] 2. because it's unbrickable (thanks to DFU) anyway [04:01:58] so yeah, it shows apple logo, then it shows "Use iTunes to Restore" for a while, then it just goes to "Connected eject first" [04:02:42] that's a rather funny way to bypass a RSRC sigcheck ;) [04:02:55] kinda funny that the bootloader checks RSRC signature at all [04:02:57] Thought of it while in a painfully long car ride today [04:03:03] I'd have expected OSOS to take care of that [04:03:17] OMG [04:03:19] it worked [04:03:23] i.e. instruct the bootloader to boot to disk mode on the next boot [04:03:32] so it actually loads the hacked filesystem? [04:03:47] yeah [04:03:48] and doesn't just reject it at a later point? [04:03:50] wtf [04:03:58] now that was seriously dumb, apple ;) [04:04:15] have fun with your freetype vuln then ;) [04:04:33] does this mean that we can patch OF graphics etc. without actually hacking the firmware now? :P [04:04:41] oh, btw, hi prof_wolfff ;) [04:04:42] There's a little bit to go for that [04:04:48] But yes, [04:05:00] prof_wolfff: you're castor munoz IIUC? [04:05:06] I turned on VoiceOver, and was going through home screen items (my mom didn't realize how magical this was): [04:05:11] Clock [04:05:11] Fitness [04:05:15] Feist (Radio) [04:05:19] Music [04:05:27] Now Playing [04:06:03] (VoiceOver dictionary overrides are the only part of the entire firmware that are A) text B) really trivial format C) unencrypted in the rsrc portion [04:07:03] TheSeven: While I haven't tried yet, I'd have to guess that since I switched the section names, if I shut it down it will boot into disk mode ^_^ [04:07:29] *** Joins: alexbobp (~alex@capitalthree.pwnz.org) [04:07:55] Hello, alexbobp! [04:08:02] *** Joins: [Franklin] (~quassel@cpe-071-071-039-006.triad.res.rr.com) [04:08:12] hi! [04:08:20] so newer nanos as in the iOS ones? [04:08:57] yes [04:09:07] iOS-looking ones ;) [04:09:14] <[Franklin]> where's the logs? [04:09:21] <[Franklin]> logs.freemyipod.org only goes to 2013-11 [04:10:59] <[Franklin]> TheSeven: what's the attack vector? [04:11:16] http://pastie.org/9731274 [04:11:19] *** shadowcoder is now known as shadowcoder|zzz [04:11:58] Night night! [04:12:09] I'll figure out how to get this to do something useful tomorrow [04:12:17] <[Franklin]> shadowcoder|zzz: no! we will! :) [04:12:31] this is my project [04:12:44] <[Franklin]> lol [04:13:04] but seriously, I'd like to work on this by myself [04:13:20] <[Franklin]> shadowcoder|zzz: really? [04:13:40] Hi TheSeven, i am Cástor [04:13:58] <[Franklin]> prof_wolfff: nice patches [04:14:02] [Franklin] I'm here to play around with my device, not port [random OS here] to it [04:14:08] <[Franklin]> I especially like the timer patch :) [04:14:16] [Franklin]: thanks [04:14:23] anyways, cya tomorrow [04:14:25] <[Franklin]> shadowcoder|zzz: aww... :( [04:14:30] <[Franklin]> nite [04:14:52] <[Franklin]> TheSeven: anyway, would a rockbox port be possible? [04:15:04] <[Franklin]> I can't seem to find hardware specs anyware [04:16:11] shadowcoder|zzz: your work might pave the way for people like [Franklin] to port rockbox to these devices though :) [04:16:23] <[Franklin]> shadowcoder|zzz: thanks! [04:16:38] [Franklin]: it might be possible, but if it is, it will be quite a lot of work of course [04:16:52] mostly reverse engineering work, as very little is know about that SoC [04:17:08] <[Franklin]> what SoC is it? [04:17:15] but having a way to bypass these sigchecks will likely open up some code execution vector in the main firmware [04:17:24] <[Franklin]> again, I can't find any specs [04:17:25] s5l8723 or something like that [04:17:33] <[Franklin]> ram? [04:19:50] <[Franklin]> I'm assuming its got a video decoding chip or similar, apparently it gets 30fps with h264 [04:20:30] my guess would be 32-64MB of ram [04:20:47] <[Franklin]> ok so a port is feasible at least hardware-wise [04:21:18] yes [04:21:27] apple's crap uses way more resources than we do [04:21:35] remember that this is a NAND-flash based target though [04:21:40] <[Franklin]> yeah, so? [04:21:46] TheSeven: I see. a fake ios. [04:21:47] i.e. we'll have to either reverse engineer or replace an FTL [04:21:57] if it were a real ios device I'd be really surprised that it got hacked, but neat [04:22:08] and reverse engineering FTLs is some serious fun... [04:22:40] IOs might actually be easier to attack than this, just because it has much more surface area ;) [04:23:54] <[Franklin]> TheSeven: well, it'd be awesome to see a rockbox-able device on shelves again :) [04:24:15] <[Franklin]> you can't find sansas in stores, at least not here [04:26:24] aw I see [04:26:57] I'm probably going to get a lot of flack in a channel for apple hardware, but I really prefer sansas... the biggest annoyance with using my phone for media is that I have touch controls instead of buttons I can press without looking [04:27:16] sansas clip on my pants and keep a low profile, and are harmless if they fall and dangle at the end of the headphone cable [04:30:03] *** Quits: [Franklin] (~quassel@cpe-071-071-039-006.triad.res.rr.com) (Ping timeout: 255 seconds) [04:34:13] *** Joins: franklin (~quassel@cpe-071-071-039-006.triad.res.rr.com) [04:36:59] *** franklin is now known as [Franklin] [04:42:28] *** Quits: [Franklin] (~quassel@cpe-071-071-039-006.triad.res.rr.com) (Ping timeout: 272 seconds) [04:57:18] <[Saint]> That was ducking dumb...omg. [04:57:28] <[Saint]> That...wow. [06:47:36] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 265 seconds) [06:48:56] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [08:38:37] *** Quits: alexbobp (~alex@capitalthree.pwnz.org) (Ping timeout: 245 seconds) [08:39:35] *** Joins: alexbobp (~alex@capitalthree.pwnz.org) [08:39:57] *** alexbobp is now known as Guest15006 [09:10:40] *** Quits: nialv7 (~nialv7@130.245.213.24) (Remote host closed the connection) [09:52:03] *** Joins: STeeF (~STeeF@office.hostnetbv.nl) [12:47:31] *** Guest15006 is now known as alexbobp [13:42:34] *** shadowcoder|zzz is now known as shadowcoder [13:48:54] [Saint]: The "vuln" I found? [13:49:15] Also, @everyone: I'd appreciate if you kept a low profile about my project [13:49:23] At least until I have code execution [13:51:22] TheSeven: Should have clarified: My plan is mostly to do my vuln searching, get root access, run ShadowOS or whatever on there (i.e.: <1 KLOC worth of OS), and dump the code on GitHub for people like [Franklin] to port their stuff to [13:51:46] Personally, I'm more interested in running an OS X-themed Linux distro on there [13:56:20] Also, user890104 TheSeven: it appears my vuln renders the device unbootable once powered off [13:56:32] Guess we'll need to reflash it every time until we get code execution, haha :P [13:57:06] anyways, i'm off to school, but I have CS today... so we'll see what happens [13:57:20] (btw, I leave IRC open, feel free to leave me a message) [17:53:12] *** Joins: CATBRUSH (~shinji@50-88-120-232.res.bhn.net) [18:06:28] *** Quits: CATBRUSH (~shinji@50-88-120-232.res.bhn.net) (Quit: Changing server) [18:46:18] *** Quits: STeeF (~STeeF@office.hostnetbv.nl) (Remote host closed the connection) [22:21:20] TheSeven user890104 [Saint]: (not Apple-specific) If I replace a file in a FAT16-file system with a smaller file, and instead of modify the FAT16-file header size, I simply lower the in-header file size and pad it with zeroes, would that work in general? (it would simplify replacing fonts soo much) [22:22:46] it should be possible to just pad the extra space with zeroes, without modifying the FAT [22:31:15] shadowcoder: emCORE might be a useful tool for you as well ;) [22:32:42] shadowcoder: overwrite the file contents (assuming those are sequential in the image) and fix up the size in the directory entry [22:32:54] most systems won't care if the clusterchain extends beyond the end of the file [22:33:21] but if you want to be safe, locate the last still used cluster in the FAT and set its entry to the "end of clusterchain" mark [22:33:47] then you have a stray clusterchain containing the remaining clusters of the old file. you can mark those as free by just zeroing their FAT entries [22:34:09] for fat16 that's all that is required to cleanly shrink a file [22:34:29] for fat32 you theoretically need to update some FSINFO data, but nobody really cares if you don't for this purpose [22:46:46] *** Joins: Kebianizao (~kvirc@250.9.219.87.dynamic.jazztel.es)