[00:40:42] *** Quits: n1s (~n1s@rockbox/developer/n1s) (Quit: Ex-Chat) [01:26:55] *** Joins: user890104 (Venci@unaffiliated/user890104) [01:26:55] *** Server sets mode: +nt [06:36:55] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 252 seconds) [06:38:25] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [06:49:39] *** Joins: steffengy (~quassel@p57B49A5B.dip0.t-ipconnect.de) [06:52:56] *** Quits: steffengy1 (~quassel@p5088F2AE.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) [13:57:46] *** Joins: n1s (~n1s@c-26d572d5.010-215-7570701.cust.bredbandsbolaget.se) [13:57:46] *** Quits: n1s (~n1s@c-26d572d5.010-215-7570701.cust.bredbandsbolaget.se) (Changing host) [13:57:46] *** Joins: n1s (~n1s@rockbox/developer/n1s) [15:01:38] *** Quits: n1s (~n1s@rockbox/developer/n1s) (Quit: Ex-Chat) [15:28:19] *** Joins: bcobco (~bcobco@77.225.204.119) [15:35:24] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [15:35:48] *** Joins: bcobco (~bcobco@77.225.204.119) [15:59:16] *** el3ctrik-away is now known as el3ctrik [16:51:03] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [16:51:25] *** Joins: bcobco (~bcobco@77.225.204.119) [17:18:18] * TheSeven is confused [17:19:14] user890104: once emcore has touched that tarkan CF adapter, it will refuse to work with the OF/diskmode as well until it gets power cycled [17:34:55] holy crap. now it started to just work with emcore. [17:35:10] <[Saint]> Maaaaaaaaaaaaaaaaaaaagiiiiiiiiiiiiiic. [17:35:14] <[Saint]> [17:36:32] this is just crazy. [17:36:52] now I tried out the OF boot thing, which previously failed on my classic3g [17:36:56] on the classic1g it just works [17:37:49] <[Saint]> shitty traces and poor manufacturing tolerances? [17:37:57] <[Saint]> ie. bad contacts? [17:38:40] <[Saint]> Seems like a logical answer to a seemingly illogical solution. [17:38:50] <[Saint]> Slight flex or torsion, bam, no worky. [17:38:59] not really logical either if it previously reproducibly worked with the OF but not our code [17:38:59] <[Saint]> Or, perhaps, worky. [17:39:10] <[Saint]> Ah. Hmmm. [17:39:26] <[Saint]> I wasn't aware it worked reliably anywhere at all. [17:40:01] well according to copper it worked reliably with the OF [17:40:17] * TheSeven plays around some more with the OF [17:44:03] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [17:44:29] *** Joins: bcobco (~bcobco@77.225.204.119) [19:16:53] *** Quits: Basstard` (~sturgeon@host-95-195-153-67.mobileonline.telia.com) (Ping timeout: 248 seconds) [19:23:35] *** Joins: Basstard` (~sturgeon@host-95-195-153-67.mobileonline.telia.com) [19:29:27] TheSeven: did you manage to boot OF using emcore (and without crashes)? [19:30:03] on 1g yes, on 3g no [19:30:12] still trying to figure out why [19:30:47] from what it looks like the 1g and 3g firmwares are incomatible with each other [19:31:06] itunes installes 1.0.2 on a 1g, 2.x.x on a 3g [19:37:02] what about 2g? what do i need to do in order to test it? [19:48:23] user890104: test what exactly? usb? [19:48:31] just my patches on gerrit... [19:48:42] the first one (reverting that really old commit) should be optional [19:48:45] test OF on classic 2g [19:48:55] ah, I was implying nano when hearing 2g :P [19:49:00] :) [19:49:09] I suspect that the 2g is basically a 1g with a different drive [19:49:31] do you have an installer that has an OF option [19:49:31] grab an appleos binary (decrypted osos) matching your device [19:49:45] or i need to "runfirmware" it? [19:50:08] runfirmware should work on the emcore version in that huge archive that I sent you [19:50:50] so i don't need a patched emcore version? [19:50:58] the patch is in that tree [19:52:44] *** Quits: el3ctrik (~el3ctrik@2a00:1c10:5:202:216:3eff:fe98:c8f1) (Ping timeout: 240 seconds) [19:56:08] crap [19:56:37] hm, do we know which generation we're running on? seems like the different bootloader versions handle some sysinfo fields differently [19:56:54] we found that field in the flash sysinfo, right? [19:57:35] seems like 1g sets vrsn=0x1308004, 3g sets vrsn=0x1708004 [19:59:39] which field is that? [19:59:51] i have a 2g sysinfo somewhere [20:00:20] hm, do you have a SystemConfig.efi from a 2g somewhere? [20:02:14] what's that? isn't efi used only in n3g+? [20:02:30] classic == n3g for that matter, both are s5l8702 [20:02:45] on n3g the also implemented diagmode that way, on classic that's still monolithic [20:03:59] which image contains this module? [20:04:15] norboot [20:05:35] 3g HwVr seems to be 0x130200 [20:07:13] 1g HwVr seems to be 0x130000 [20:07:35] so 2g is probably 0x130100 [20:07:43] 0x130100 (as you might have expected) :) [20:07:54] hm... [20:08:07] do you have a sram snapshot after norboot was running somewhere? [20:08:47] no, but i can make one [20:09:03] I need that vrsn value from the runtime syscfg of a 2g [20:09:31] I'm wondering if this might be related to the software version rather than hardware generation [20:09:45] however is there even any overlap between software versions of the various generations? [20:13:08] can we make norboot run that memory upload/download stub? [20:15:11] hm, if we manage to chainload it without confusing it too badly... [20:15:46] and if you know an address where you can set a breakpoint after it has set up the syscfg [20:16:04] that part is a bit tricky due to all those modules being loaded and decompressed at runtime, so you can't easily inject the breakpoint [20:29:47] hm, fixing the vrsn field didn't help, still data aborting... [20:29:48] Hit abort (05) at 08034838 (accessing 00ffc3ea)! [20:29:48] r00: 08b30820, r04: 00ffc3ea, r08: 0000000f, r12: ea00ffc3 [20:29:48] r01: 200000d3, r05: 00000001, r09: 39a00094, r13: 08b30820 [20:29:49] r02: 000000c0, r06: 089aed2c, r10: 00008000, r14: 08034838 [20:29:51] r03: 02000000, r07: 0812cc38, r11: 00000020, r15: 0803483c [20:29:53] spsr: 200000d3, cpsr: 200000d7, fsr: 00000005, far: 00ffc3ea [20:29:55] Enabled IRQs: 0 1 2 3 8 16 17 18 21 23 24 29 33 (IRQs globally disabled!) [20:54:40] let me backtrace that: [20:55:16] 08034838 crashes because R4 is nonsense, which was passed to 08034824 as r0 [20:55:21] er, r1 [20:56:04] that gets called from 08034cdc, the bad pointer is passed to 08034ccc as r0 [20:56:43] that in turn gets jumped to from 080a50b8, with r0 being dereferenced [20:56:59] (that's 080a50b4) [20:57:18] that in turn gets jumped to from a veneer at 22003598 [20:57:45] which gets called from 22002f40 [20:58:28] which is only called if r8 (which ends up in r0) is nonzero [20:58:38] so whatever we're dereferencing there is nonsense, but not null [21:00:45] * TheSeven jumps back to that location to capture the pointer [21:01:06] seems like it's 09829b08, which is likely a heap allocation :/ [21:02:08] hm, or not... [21:02:18] it's likely not the first loop iteration that's crashing here [21:02:30] * TheSeven wonders what kind of data that function is processing [21:13:45] user890104: can you try a coldboot attack on your 2g? [21:14:31] i.e. flash OF and then boot into DFU, upload the dumper, and capture the SRAM contents [21:14:51] then search for "vrsm" or that in reverse, and tell me the 4 bytes after that [21:14:57] er, "vrsn" of course [21:15:33] what's the address and size of the sram area? [21:18:33] 0x22000000 0x00040000 [21:21:10] hm, this seems to be some resource lookup code that's crashing here [21:51:59] "the dumper" == usbstub, right? [21:53:01] do you happen to have a build? [21:55:48] should be in that huge 7z [22:02:48] in /tmp? [22:03:09] yes [22:03:44] classic1g_dbgldr.bin [22:04:07] yes [22:14:23] TheSeven: is only restoing the bootflash enough? [22:14:30] should be [22:14:41] possibly even chainloading norboot through emcore [22:14:57] ok, let's see... [22:15:09] i need to wrap your binary in pwnage, right? [22:16:18] hm yes, should work [22:16:25] I don't think it will need a boot stub [22:16:52] ok [22:17:09] i just made a build using: make TYPE=release usbstub/ipodclassic [22:24:50] TheSeven: looks like it locked up [22:25:13] what exactly? [22:26:10] i used embed.exe and the 128kB container to wrap my build of usbstub [22:26:22] then loaded it using ipoddfu.py [22:26:32] and no usb reaction? [22:26:37] and the dfu device didn't disappear [22:26:54] and nothing appears after a reconnect? [22:27:06] ("broken device" after 10 seconds or so) [22:27:25] exactly [22:27:33] hm [22:27:39] try wrapping it into a bootstub then [22:27:44] ok [22:36:25] that's better :) [22:38:48] interesting... [22:38:58] not quite sure what it's relying on, probably page tables [22:40:11] the boot stub will trash quite some hw state, but I hope it leaves the ram in question intact [22:45:08] usb.core.USBError: [Errno None] b'libusb0-dll:err [control_msg] sending control message failed, win error: A device attached to the system is not functioning.\r\n\n' [22:48:48] TheSeven: http://paste.pm/raw/i3a [22:49:38] hm [22:49:43] probably bulk endpoints broken [22:49:52] try commenting the relevant parts of libemcore as a workaround [22:53:15] it's a ctrl_transfer [22:53:38] it probably fails at getting a descriptor [22:55:01] i've commented out self.bulk[in,out] = ep, but it still fails [22:56:10] if it would fail at getting a descriptor, it wouldn't get anywhere near that far [22:56:22] it failed after attempting the first bulk transaction [22:56:27] again at ctrl_transfer (triggered by getversioninfo) [22:56:32] so I guess it will work if you limit it to control only [22:56:50] http://paste.pm/raw/i3b [22:57:06] that was with the ipod already hung, right? [22:58:00] ah :) [22:58:54] sending it to you on skype [23:05:44] damn [23:05:52] no traces of sysinfo in there [23:11:09] i can try again [23:11:32] I need the string "nsrv" to be in there [23:19:26] can we patch norboot to jump to our usb stub after running the code you're interested in? [23:22:35] not easily [23:23:06] to do that we'd have to unpack and repack it, which is more effort than extracting the code in question in the first place [23:23:25] ah [23:23:30] any idea what "Mikey" might stand for? ("MikeyTask") [23:23:55] name of a developer :P [23:24:08] I've seen that turn up in multiple spots in apple firmwares, but never figured out what it means [23:26:42] full list of tasks that I've found: http://paste.pm/i3c.m (and MikeyTask is the one that data aborts) [23:28:24] task_USBAudioTask sounds interesting [23:36:01] could "Mikey" be the headphone remote? [23:36:05] that name would actually make sense... [23:36:11] and it would differentiate it from the 1g [23:37:01] http://bluemic.com/mikey_digital/ [23:37:05] looks like you're right [23:38:08] not sure if that's related... [23:38:10] actually, http://bluemic.com/mikey_for_ipod/ [23:38:48] MikeyTask == RecordingTask? [23:39:41] possibly [23:41:03] It works with the first three generations of the iPod touch, the second-through-fifth generations of the iPod nano, all iPod classics, the fifth generation iPod, and the iPhone 3GS and earlier. [23:44:44] hm, so it's *not* 3g specific [23:51:22] * TheSeven spots some code that deals with postscript fonts [23:57:01] TheSeven: what are you disassembling at the moment? [23:57:08] 3g of [23:57:22] specifically the area that data aborts