[03:09:24] *** Quits: Dgby714 (~dgby714@nala.villavu.com) (Read error: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac) [03:09:32] *** Joins: Dgby714 (~dgby714@nala.villavu.com) [03:09:32] *** Joins: Dgby714_ (~dgby714@nala.villavu.com) [03:09:32] *** Joins: Dgby714__ (~dgby714@nala.villavu.com) [03:09:43] *** Joins: Dgby714_1 (~dgby714@nala.villavu.com) [03:09:56] *** Quits: Dgby714__ (~dgby714@nala.villavu.com) (Read error: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac) [03:10:22] *** Quits: Dgby714_ (~dgby714@nala.villavu.com) (Read error: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac) [03:11:09] *** Quits: Dgby714_1 (~dgby714@nala.villavu.com) (Read error: Connection reset by peer) [03:11:15] *** Quits: Dgby714 (~dgby714@nala.villavu.com) (Client Quit) [03:13:13] *** Joins: Dgby714 (~dgby714@nala.villavu.com) [04:08:24] *** Joins: user890104_ (Venci@unaffiliated/user890104) [04:08:24] *** Server sets mode: +nt [04:10:51] *** Joins: fmibot1 (~ircbot@freemyipod.org) [04:10:51] *** ChanServ sets mode: +o fmibot1 [04:16:19] *** Quits: fmibot (~ircbot@freemyipod.org) (*.net *.split) [04:16:19] *** Quits: user890104 (Venci@unaffiliated/user890104) (*.net *.split) [04:16:22] *** user890104_ is now known as user890104 [04:22:10] *** Quits: gevaerts (~fg@rockbox/developer/gevaerts) (Disconnected by services) [04:22:18] *** Joins: gevaerts_ (~fg@rockbox/developer/gevaerts) [04:45:07] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Disconnected by services) [04:45:14] *** Joins: [7] (~quassel@rockbox/developer/TheSeven) [04:55:22] *** Quits: [Franklin] (~franklin@unaffiliated/franklin) (Remote host closed the connection) [06:38:52] *** Joins: luyikei (~quassel@i255020.dynamic.ppp.asahi-net.or.jp) [06:53:27] *** Quits: [7] (~quassel@rockbox/developer/TheSeven) (Ping timeout: 272 seconds) [06:54:22] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [08:59:39] *** Quits: luyikei (~quassel@i255020.dynamic.ppp.asahi-net.or.jp) (Remote host closed the connection) [09:35:06] *** Joins: luyikei (~quassel@i255020.dynamic.ppp.asahi-net.or.jp) [13:59:53] *** gevaerts_ is now known as gevaerts [14:28:36] *** Joins: benedikt93 (~benedikt9@frbg-5d84e63b.pool.mediaWays.net) [14:28:52] *** Quits: benedikt93 (~benedikt9@frbg-5d84e63b.pool.mediaWays.net) (Changing host) [14:28:52] *** Joins: benedikt93 (~benedikt9@unaffiliated/benedikt93) [15:20:23] *** Quits: benedikt93 (~benedikt9@unaffiliated/benedikt93) (Ping timeout: 240 seconds) [15:43:51] *** Joins: benedikt93 (~benedikt9@frbg-5d84ec43.pool.mediaWays.net) [15:43:51] *** Quits: benedikt93 (~benedikt9@frbg-5d84ec43.pool.mediaWays.net) (Changing host) [15:43:51] *** Joins: benedikt93 (~benedikt9@unaffiliated/benedikt93) [16:15:37] *** Quits: benedikt93 (~benedikt9@unaffiliated/benedikt93) (Ping timeout: 252 seconds) [16:46:14] *** Joins: x56 (~0x56@sillytitties.com) [17:00:00] are there any sources out there for info on reversing classic iPods other than the core of this wiki? [17:00:31] lots of links have dried up and I'm not seeing much [17:01:17] speicifcally I'm interested in things pertaining to Apple's RTXC (I'd settle for anything on RTXC 3.2 in general) [17:02:34] x56: well, RTXC isn't really from apple, they just licensed that [17:02:39] understood [17:02:51] I assume the customized it heavily as they are wont to do [17:02:54] *they [17:03:20] I don't have the money or other requirements to licensce more info [17:03:28] (from Quadros that is) [17:03:33] we haven't really looked into the RTXC core much at all [17:04:02] I identified some important syscalls such as starting/terminating of tasks, mutex/semaphore stuff, etc. [17:04:18] mostly the stuff that you need to understand driver code [17:04:52] but apart from that nobody really cared about the kernel, as all that we're after is figuring out how to access the ipod hardware [17:05:10] yeah, different goals [17:05:25] it seems RTXC may have made a comeback as part of the platfrom firmwares on new iDevices [17:05:30] *platform [17:05:40] that's rather interesting [17:05:56] where are they using that? coprocessors? [17:06:04] I have a dump of something and I'm trying to figure out if it's actually RTXC, or just possibly interacting with an RTXC component [17:06:15] I think it's the NAND controller [17:06:54] (and yes, on the SoC) [17:07:22] they're still interfacing with raw nand instead of emmc or whatever chips these days? [17:07:47] that's a huge PITA for reverse engineering ;) [17:07:49] it seems so...the controller is integrated, flash is external [17:08:05] yeah, the SoC is an absolute mess of things [17:09:39] afaict this particular component appeared with the A7 [17:11:00] and the TLC NAND they started using [17:11:25] anyway, thanks for the reply, I guess I'll keep digging :) [17:11:34] so they're running the FTL on some secondary processor core? not integrated into the main OS kernel anymore? [17:11:39] http://i.imgur.com/3JMkVa9.png [17:11:45] yeah, that's what I'm seeing [17:11:48] this is what the RTXC syscall entry point typically looks like [17:11:55] you might find a similar pattern [17:13:15] the first LDR, PC =blah, that's the vector right? [17:13:20] then jumps right into the handler [17:13:30] and this huge beast is the demultiplexer that jumps to the individual syscall handlers: http://i.imgur.com/wkpHyYm.png [17:13:43] AAAAAAA [17:13:45] lol [17:13:45] ok [17:14:36] try looking for that msr cpsr_c, #0x93 instruction [17:14:41] that won't turn up in many places [17:17:27] a good place to look at for analyzing the kernel data structures is the RTXCbug task, which is some kind of serial port command shell for manipulating kernel objects [17:17:38] it contains lots of helpful strings [17:18:14] I'm not seeing that [17:18:16] *** Joins: benedikt93 (~benedikt9@unaffiliated/benedikt93) [17:18:23] I'm thinking this isn't actually RTXC at all [17:18:32] it's sort of like iBoot in a few places [17:18:39] but it references RTXC [17:19:05] http://i.imgur.com/qBDgNdN.png [17:19:25] yeah, I don't have anything like that [17:19:37] in which context does RTXC appear then? [17:20:13] src/drivers/apple/aspcore/system-rtxc/main.c [17:20:19] src/drivers/apple/aspcore/host-rtxc/cmd_mmap.c [17:20:21] etc. [17:20:24] just strings [17:20:34] ok, so just source file paths? [17:20:34] for the panic routine [17:20:38] yeah [17:20:46] hm, assertions [17:21:14] ASP == AppleStorageProcessor [17:21:53] those two particular paths sure look like kernel stuff though... [17:22:02] I agree [17:22:35] there are other coprocessors which I've recovered firmware for [17:22:39] where are those referenced? does the code in that area look kernel-ish? [17:22:47] not specific mention of RTXC in them either though [17:23:01] btw, just curious, did EFI turn up on any iDevices in the meantime? ;) [17:23:23] I was kinda baffled when that first appeared on ipod nanos... [17:23:35] sort of, they use edk2 for internal diagnostics and such at the factory [17:23:47] not on prod devices [17:24:09] (though I did find it as a bootloader on one of the AirPort routers for some reason) [17:24:24] on nano3g/4g (later ones haven't been analyzed) they implemented their on-device diagnostic mode using UEFI/TianoCore [17:24:37] yeah, that must be the same thing [17:24:53] there were also some remnants from factory burn-in testing code in the flash, implemented on top of that [17:25:19] hahahaha I found that still on my iPad Air 2 [17:25:20] on the nano4g they implemented the full boot process using UEFI, in contrast to the 3g where it was just the diag stuff [17:25:25] how long has that been leaking [17:25:26] ? [17:25:40] and it's DOG SLOW ;) [17:25:45] *** Quits: luyikei (~quassel@i255020.dynamic.ppp.asahi-net.or.jp) (Remote host closed the connection) [17:26:25] that phoenix thing first turned up on nano3g around 2007 I think [17:26:54] or maybe it was the 4g (2008, the 3g hasn't been analyzed thoroughly) [17:27:04] that's funny [17:29:15] do they still use code from whimory for FTL stuff? or do they have their own by now? [17:30:15] I think they moved away from Whimory with the A7 [17:30:28] maybe A6, I haven't really looked at that generation though [17:30:33] probably when switching to TLC? [17:30:44] would make sense [17:31:05] they went super custom starting with the A7 [17:31:13] memory controller [17:31:21] some weird TZesque thing [17:31:33] but not like anything described in ARM TZASC docs [17:31:58] NAND controller [17:32:06] something they call SuperIO [17:32:19] hm, this is still manufactured by samsung, but not engineered by them (like the early ones) anymore? [17:32:53] I think so [17:33:04] they're moving towards TSMC for everything it looks like [17:33:24] would make sense to move away from samsung as a direct competitor ;) [17:33:37] A8 was the first big step away [17:33:46] and I read the A9 is being handled completely by TSMC [17:34:29] I don't know too much about the development lifecycle or fabrication end of things though, so don't quote me on any of that [18:58:36] *** Quits: benedikt93 (~benedikt9@unaffiliated/benedikt93) (Ping timeout: 272 seconds) [19:43:14] *** Joins: [Franklin] (~franklin@unaffiliated/franklin) [20:57:24] *** Joins: benedikt93 (~benedikt9@unaffiliated/benedikt93) [23:46:45] *** Quits: benedikt93 (~benedikt9@unaffiliated/benedikt93) (Ping timeout: 276 seconds) [23:52:50] *** Joins: benedikt93 (~benedikt9@unaffiliated/benedikt93)