--- Log opened Thu Jul 29 17:05:31 2010
17:35 *** AriX_ has quit IRC (Quit: Leaving...)
17:37 *** AriX_ has joined #linux4nano
17:42 *** benedikt93 has quit IRC (Ping timeout: 276 seconds)
17:57 *** benedikt93 has joined #linux4nano
17:58 *** cmwslw has joined #linux4nano
17:58 *** mode/#linux4nano [+o cmwslw] by chanserv
18:28 *** Kyle6513 has quit IRC (Quit:  HydraIRC -> http://www.hydrairc.com <- Like it?  Visit #hydrairc on EFNet)
18:48 *** kyle6513_ has joined #linux4nano
18:49 < kyle6513_> cmwslw: so, the main concern right now is that in order to write to the firmware partition we need to understand the EFI's jumps (which are completely random)
18:49 < kyle6513_> and in order to work them out an emulator is in order?
18:50 *** kyle6513_ is now known as kyle6513
18:50 *** kyle6513 has quit IRC (Client Quit)
18:50 *** kyle6513_ has joined #linux4nano
18:50 *** kyle6513_ is now known as kyle6513
18:53 < cmwslw> well i havent even looked into it that much
18:53 < kyle6513> ah right
18:54 < cmwslw> but it mainly has to do with hardware initialization I think
18:54 < kyle6513> sigh, apple you bastards -shakes fist-
18:59 < kyle6513> thats why we're here though, any sort of testing, graphics or such to be done? I really want to help but it seems arm is a requirement here =/
18:59 *** watto has left #linux4nano
19:18 < cmwslw> well you could help out with the wiki transition when that happens
19:20 < kyle6513> sounds good (:
19:25 < cmwslw> so what sort of programming experience do you have?
19:25 < kyle6513> a little amount of C
19:26 < kyle6513> i've been learning python
19:26 < kyle6513> which isnt that large of a jump
19:26 < kyle6513> i used to do a bit of flash
19:26 < kyle6513> nothing really major though
19:26 < kyle6513> i need to get a solid paper book before i can learn, thats the trouble
19:27 < cmwslw> you shouldn't need a paper book for python, the docs are amazing
19:27 < cmwslw> but i guess a paper book for c would be nice
19:27 < GaveUp> arguably paper books are needed for many things anymore
19:27 < kyle6513> haha i like how it has references to monty python
19:27 < kyle6513> but reading off a computer screen is very different from reading a book
19:27 < GaveUp> although that one paper book on RE is nice
19:28 < kyle6513> reading a book the information soaks in more i find
19:28 < GaveUp> kyle6513: depends on what it is for me ... language wise unless I write it it isn't soaking in
19:28 < GaveUp> the theory stuff ... yeah a book can be nice
19:28 < kyle6513> yeah
19:29 < GaveUp> aside from bjorne's book...that thing is a dense headache inducing....
19:29 < kyle6513> bjorne?
19:29 < GaveUp> c++ creator
19:30 < kyle6513> ah
19:30 < kyle6513> i suppose he would have never had to learn it
19:30 < kyle6513> so i dont think he would be the easiest to learn from
19:30 < GaveUp> i've had that book for probably a decade and it's still headache inducing
19:30 < kyle6513> haha
19:30 < GaveUp> it's not really a "learn c++" book
19:30 < kyle6513> more the creation of c++?
19:31 < cmwslw> it has a lot of intricate details of c++ that humans don't really need to know
19:31 < kyle6513> haha
19:31 < GaveUp> exactly
19:31 < GaveUp> all the libraries and templating and stuff
19:31 < cmwslw> but if you think thats bad, learning arm from the "ARM ARM" is 100x worse
19:32 * GaveUp grumbles about running in to a wall learning arm
19:32 < kyle6513> I understand C++ like structs and such and I understand their uses but theres always the problem of not knowing what to make
19:33 < GaveUp> structs aren't c++ necc. ... more inherited from c
19:33 < kyle6513> well, c/c++
19:33 < kyle6513> thats what i was learning
19:33 < cmwslw> once you know what to make you start worrying about the best and most standard way to make it
19:33 < kyle6513> haha yeah
19:34 < kyle6513> then theres cross platform ect
19:34 < GaveUp> cmwslw: i dunno...with the whole embedded thing it's not the what I want more the how the hell do you and where do you start that results in head meeting wall
19:35 < kyle6513> you start small and build onto it (:
19:35 < kyle6513> like a wall
19:35 < kyle6513> you always start with one brick
19:35 < kyle6513> you dont make chunks of wall and put them together
19:36 < cmwslw> GaveUp: are you talking about learning the syntax in general or compiling or what?
19:36 < kyle6513> although you can code that way
19:36 * kyle6513 is rambling on ><
19:37 < cmwslw> and if you want to feel encouraged i suggest changing your irc name
19:37 < kyle6513> hahaha
19:38 < GaveUp> cmwslw: more in that RE in general is a beast from hell to try to pick up by oneself/without an expert to consult
19:38 < kyle6513> do we not have people here? or some random IRC channel to grab help from?
19:39 < cmwslw> GaveUp: by RE you mean regex? that has nothing to do with arm
19:39 < GaveUp> cmwslw: reverse engineering
19:39 < cmwslw> oh i definitely agree
19:40 < cmwslw> ive been tagging along for a year now and i just have a basic grasp
19:40 < kyle6513> well, im screwed
19:40 < kyle6513> haha
19:40 < GaveUp> i mean like lately I've been reading on the iphone but without someone to really bounce back and forth with or someone experienced in toying around with embedded getting further than the general understanding is near impossible unless you're one of those that can pick up ARM and all that fast
19:41 < cmwslw> but mostly it involves getting a dump, by injecting code somehow
19:41 < GaveUp> well i've done RE of x86 software before but that's a whole dfferent beast by a long shot ... you have a lot more knowns in that scenario
19:41 < cmwslw> this has to be an unencrypted dump btw
19:42 < kyle6513> and the somehow is an exploit
19:42 < kyle6513> if i understand correctly
19:42 < cmwslw> then you can disassemble it and pour through tons of arm assembly trying to understand
19:42 < cmwslw> well finding a vulnerability is the very first step
19:43 < GaveUp> well exploits in general are a whole other topic ... just understanding how buffer overflows and such work keeps escaping me at anything more than a high level generic understanding
19:43 < kyle6513> well the vulerability is required to inject code isnt it?
19:43 < kyle6513> the vulerability lets you execute arbitrary code, aka injecting code
19:44 < cmwslw> kyle6513: if its in some sort of protected system, yes
19:44 < kyle6513> ah right
19:45 < cmwslw> and to understand buffer overflows you have to understand that sometimes more data can be written to a buffer than the buffer is supposed to hold
19:45 < kyle6513> which causes an overflow
19:46 < kyle6513> buffers are in ram arent they?
19:46 < kyle6513> sorry, ill google haha
19:46 < cmwslw> yep, and so is normal code
19:46 < kyle6513> haha
19:47 < cmwslw> some things in the ram are meant to be executed, and some things are meant to be data
19:47 < cmwslw> the processor has no distinction between the two however
19:47 < kyle6513> can a buffer overflow happen in each scenario?
19:48 < cmwslw> well, a buffer is meant to hold data, but if it overflows, the processor might execute the overflow part
19:48 < cmwslw> thats how you can inject code
19:48 < kyle6513> ohh
19:48 < kyle6513> wow thats really complex
19:49 < kyle6513> and finding a place to be able to exploit it from is mind boggling
19:49 < benedikt93> it's AFAIK just trial and error, which can take a very long time though I never did duch thing
19:49 < cmwslw> generally people look for crashes when they put in messed up input
19:49 < benedikt93> *such
19:50 < kyle6513> like the notes exploit
19:50 < cmwslw> buffer overflows usually don't occur with normal input
19:50 < kyle6513> yeah i was thinking as such
19:51 < cmwslw> but if something crashes, it can be a possible buffer overflow capable of being exploited
19:51 < kyle6513> which they managed to find
19:51 < kyle6513> through the use of the nanotrons
19:52 < benedikt93> the nanotrons were used to find how to use an previously found buffer overflow exactly
19:53 < cmwslw> they were searching for an intact copy of our payload in memory
19:54 < kyle6513> but from what i understand is they just looked for the screen to sit white, i assume that is mainly due to the way the ipod works
19:54 < kyle6513> ?
19:54 < cmwslw> the overflow in the notes bug allowed us to jump to places in memory
19:54 < Farthen> our code was somewhere in the big memory
19:54 < cmwslw> what the nanotrons were doing were looking for signs that our code was executed
19:55 < kyle6513> oh right
19:55 < Farthen> our code was nothing than an endless loop (freeze)
19:55 < kyle6513> and each html file had a different place
19:55 < kyle6513> and when it was finally executed the nanotron logged it and continued on
19:56 < cmwslw> if the ipod froze when we sent it code that was supposed to freeze the ipod, its a good sign
19:56 < kyle6513> haha yeah
19:56 < kyle6513> but from what
19:56 < kyle6513> I've read there were a few false cases?
19:57 < Farthen> sure. that's when you hit some data/code that produces an endless loop also
19:57 < cmwslw> it might just be that it was not our code that caused it to freeze, but some random code in memory
19:57 < cmwslw> to test for these false positives, we would upload code to crash the ipod and see if it crashed
19:57 < kyle6513> haha thanks for helping me understand
19:58 < kyle6513> massive side track thanks to me ><
19:58 < Farthen> what was the topic? :-P
19:58 < cmwslw> its fine. teaching people is helping me get back into the groove
19:58 < kyle6513> hahaha
19:58 < kyle6513> well in that case....
19:58 < kyle6513> haha just kidding :P
19:59 < cmwslw> got any more questions?
19:59 < kyle6513> hmm
20:01 < Farthen> don't suck them out of your fingers. they will come by themselves, trust me :-P
20:01 < kyle6513> haha
20:02 < cmwslw> thats why i like this project - i have so many questions about it
20:02 < kyle6513> i was going to ask about the EFI but then realised you probably know about as much as me
20:03 < Farthen> what do you want to ask about the efi
20:03 < cmwslw> yea, but Farthen may know more
20:03 < kyle6513> so its basically a buffer for writing or talking to the firmware partition?
20:03 < kyle6513> (see what i did there? :P)
20:03 < Farthen> not, it's a bootloader
20:03 < kyle6513> oh so a bios
20:03 < kyle6513> of sorts
20:04 < Farthen> somehow, yes
20:04 < kyle6513> does it decrypt the firmware like in the 2g sort of thing
20:04 < Farthen> it initializes the hardware and boots the apple firmware
20:04 < kyle6513> or is that handled by the crypto
20:04 < Farthen> it uses the crypto engine to decypt the apple firmware
20:05 < kyle6513> now its starting to sound more like a computer :P
20:05 < kyle6513> thats the stuff i like haha
20:05 < Farthen> well, it would be easier if it would not be that complicated
20:05 < kyle6513> thats true
20:05 < kyle6513> so we need to find out how to talk to the EFI and tell it we want the firmware in a dumbed down version?
20:06 < Farthen> we don't know much about what the efi does because all jumps are indirect
20:06 < kyle6513> indirect or random?
20:06 < kyle6513> oh, as in all jumps go to a pointer sort of thing?
20:06 < Farthen> they are calculated somehow so you need to trace each function calls' address
20:07 < kyle6513> and how is an emulator going to help with that?
20:07 < Farthen> tracing the addresses so that this has not to be done manually
20:08 < cmwslw> an emulator lets us see every step of the process
20:08 < cmwslw> we can't do that on an ipod
20:08 < kyle6513> hmm how are you going to make an emulator without knowing the jumps ect
20:08 < kyle6513> oh, so you know whats on and inside the EFI
20:09 < kyle6513> but the ipod limits you to being able to see the process it goes through?
20:09 * kyle6513 's head explodes
20:09 < cmwslw> we have a memory dump that we can use, we just need a way to understand it
20:09 < kyle6513> ahh
20:10 < kyle6513> which is where the emulator comes in?
20:10 < cmwslw> like we have all the code we need, but trying to go through all the jumps by hand would make anyone's brain explode
20:10 < kyle6513> haha yeah
20:10 < kyle6513> well, thats what machines were made for i suppose
20:10 < benedikt93> a question from my side there: why do they use such a complictaed jumpin, whats the use of this?
20:11 < cmwslw> so an emulator can run through the code for us
20:11 < cmwslw> i dont know anything about how it jumps, maybe farthen knows more
20:11 < kyle6513> because the original EFI was made by ibm and they like their complicated stuff haha just kidding
20:11 < Farthen> the code is very modular
20:12 < Farthen> and all jumps between modules are calculated from an address in a lookup table and the function offset
20:12 < cmwslw> oh ok
20:13 < Farthen> IIRC the code first looks in the moule lookup table and fetches the address from the module. then it looks in the module and fetches the function offset from there
20:13 < Farthen> but i don't know exactly
20:14 < benedikt93> but your explanation seems to make sens to me, thx
20:15 < kyle6513> so the EFI would be just an arm chip programmed to be an EFI?
20:15 < cmwslw> efi is software that runs on the arm chip
20:15 < benedikt93> it's one of the first things to be executed on startup
20:15 < kyle6513> oh, here i was thinking it was another chip entirely
20:16 < GaveUp> cmwslw: RE: buffer overflows ... yeah that high levels stuff is the easy part to grasp...actually say coming up with a working example or such to really solidify said knowledge not so much
20:16 < benedikt93> it might be in an external memory, don't know this
20:16 < benedikt93> bios also is only some memory chip
20:16 < kyle6513> yeah thats what i was thinking
20:17 < cmwslw> yea idk what memory its stored on
20:17 < GaveUp> cmwslw: but anyway...if you find someone willing to be bombarded with questions from a noob point him in my direction :P
20:17 < kyle6513> so we're going to need a piece of this EFI software in order to be able to run through that list you were talking about right?
20:17 < cmwslw> GaveUp: im always happy to answer noob questions
20:18 < GaveUp> cmwslw: where's your areas of expertise?
20:18 < benedikt93> the efi software is already dumped in case of nano 4g
20:18 < kyle6513> oh
20:18 < kyle6513> well
20:18 < kyle6513> NOW i understand haha
20:19 < TheSeven> benedikt93: how is the 3g work going?
20:19 < cmwslw> GaveUp: i dont have anything special, but i like to learn about every part
20:19 < benedikt93> nothing, actually
20:19 < TheSeven> serpillere says he found the SPI flash reading code
20:19 < kyle6513> the efi software has been dumped and now we need an arm emulator to play host to the EFI software in order to allow us to probe it's inner workings, right>
20:19 < benedikt93> i've been to france for two weeks and just came back at 5 am
20:20 < GaveUp> cmwslw: i meant more ipod, iphone, etc ... like i said before lately i've been investigating the iphone (because my ipod is about as near non-functioning as it can get)
20:20 < benedikt93> TheSeven: for nano 3G?
20:21 < TheSeven> yes, for the 8702 (nano3g and classic 1/2/3g)
20:21 < TheSeven> it seems to be similar to openiboot once again
20:22 < benedikt93> only useful thing I saw was some code that looked to me like checking for a double reset (still held down menu and middle button)
20:22 < benedikt93> what's openiboot?
20:22 < cmwslw> GaveUp: ipod for sure, i dont have an iphone but i have an ipod touch and i have played with iphonelinux
20:22 < kyle6513> iphone linux sounds fun haha
20:23 < GaveUp> cmwslw: mind if i msg?
20:24 < cmwslw> benedikt93: openiboot is a bootloader for the iphone
20:25 < cmwslw> GaveUp: no
20:25 < TheSeven> benedikt93:
20:25 < TheSeven> 0x20004AF4 = int8_t SPI_get_byte(uint32_t spi_n, uint8_t *b)
20:25 < TheSeven> 0x20004B4C = int8_t SPI_send_byte(uint32_t spi_n, uint8_t b)
20:25 < TheSeven> 0x20004BC4 = uint8_t SPI_read_status_register(uint32_t spi_n)
20:25 < TheSeven> 0x20004C7C = uint8_t SPI_wait_busy(uint32_t spi_n)
20:25 < TheSeven> 0x20004D60 = SPI_Jedec_ID_Read(uint32_t spi_n)
20:25 < TheSeven> 0x2000906C = SPI_read_cont_wait_busy(uint32_t spi_n, uint32_t len, uint8_t *buf, uint32_t addr)
20:25 < TheSeven> typedef struct _spi_t {
20:25 < TheSeven>   uint32_t reg_control;
20:25 < TheSeven>   uint32_t reg_setup;
20:25 < TheSeven>   uint32_t reg_status;
20:25 < TheSeven>   uint32_t reg_unk1;
20:25 < TheSeven>   uint32_t reg_txdata;
20:25 < TheSeven>   uint32_t dum1[0xC];
20:25 < TheSeven>   uint32_t reg_rxdata;
20:25 < TheSeven>   uint32_t dum2[0xC];
20:25 < TheSeven>   uint32_t reg_clkdiv;
20:25 < TheSeven>   uint32_t reg_unk2;
20:25 < TheSeven>   uint32_t reg_unk3;
20:25 < TheSeven>   
20:25 < GaveUp> woah!
20:25 < TheSeven> } __attribute__((packed, aligned(1))) spi_t;
20:25 < kyle6513> yeah....
20:26 < cmwslw> benedikt93: were you able to tell what a double reset did?
20:35 < benedikt93> at which point it is triggered, though I'm not sure
20:38 < benedikt93> TheSeven: at 200032F0 it could be reading the two buttons, then check some USNPHY thing, then check the button's states
20:38 < benedikt93> dfu would than be possible to be triggered through USB
20:39 < benedikt93> which would then start at loc_20003328
20:40 < kyle6513> annnnd im lost :P
20:44 < benedikt93> this would make more sens to you, if you had the disassembled bootrom code of those ipods
20:44 < benedikt93> bootrom is a rom inside the processor
20:45 < benedikt93> it's content is immidiatly executed at startup
20:45 < benedikt93> it initialises some stuff and then loads some code from the external norflash, which is connected by SPI
20:46 < benedikt93> the code in norflassh is likely to decrypt the frimware, so we would need to get a dump of it
20:47 < benedikt93> if we now know how to access norflash, we could read it and send it over USB to a pc
20:47 < cmwslw> does the 3g have EFI? me and Farthen were wondering about this the other day
20:48 < benedikt93> not sure, how would I recognize this?
20:48 < kyle6513> which means we would have the dissassembled bootrom code
20:48 < kyle6513> ...right?
20:48 < cmwslw> benedikt93: no clue, i doubt EFI would be on the bootrom though
20:49 < cmwslw> so you probably cant tell yet
20:50 < benedikt93> in the bootrom I don't see relative jumps a lot, but there are 'headers' of blocks of the code which contain some data (and adresses)?
20:50 < benedikt93> I didn't see any code accessing that yet
20:51 < kyle6513> oh i just realized what you're close to is finding the code to decrypting the firmware
20:52 < kyle6513> but due to the fact that you dont have access to the crypto...it wont be of much use would it?
20:52 < benedikt93> to use custom software on iPods, we need to examine their hardware
20:52 < cmwslw> the code to decrypting the firmware == access to the crypto
20:52 < kyle6513> oh
20:52 < kyle6513> lol
20:53 < benedikt93> which can only be done by analysing all available code, as theier is no datasheet
20:53 < kyle6513> damned social reflex >.>
20:53 < cmwslw> we just need to find out how to talk to everything
20:53 < kyle6513> haha
20:53 < kyle6513> the next step is getting it talking back right? :P
20:54 < cmwslw> yep
20:55 < kyle6513> and once you have that you can grab all the information off that which will give you information on the hardware due to reverse engineering and then you'll have all the information to bypass the EFI and write drivers for rockbox/bootloaders ect
20:55 < kyle6513> that was an estimated guess haha
20:56 < kyle6513> well not bypass the efi as such, tell it to do other stuff
20:56 < benedikt93> replace the efi, more likely
20:56 < benedikt93> with a custom bootloader
20:56 < cmwslw> dont think of the efi as a blocking thing
20:57 < kyle6513> well it is essentially in the way since you need to find a way to talk to it :P
20:57 < cmwslw> its just an interface for communicating with hardware (but a complicated modular one at that)
20:57 < kyle6513> which makes it all that much more fun :P
20:57 < kyle6513> did i say fun? i meant frustrating haha
20:58 < benedikt93> I don't think we could tell it to start up another software that easily
20:58 < cmwslw> yea well AFAIK, we dont even know if the 3g has EFI
20:58 < kyle6513> atleast you know how you're going to go about finding how to talk to it
21:02 < kyle6513> to me thats an accomplishment, to you...not so much haha
21:06 < kyle6513> since the EFI is there to communicate with the hardware, wont that make writing drivers a bit easier?
21:06 < kyle6513> considering all of the code is already there
21:10 < cmwslw> well the driver code will always be there, thats the main thing we want to find
21:11 < kyle6513> ah right
21:11 < cmwslw> normally its in easier to find places, but with the new EFI, it makes finding and identifying the driver code more difficult
21:11 < kyle6513> damnned thing is the root of all troubles haha
21:12 < kyle6513> and then you have to do it again for the 5g
21:12 < kyle6513> although the upside is you'll already have your emulator cooked up
21:16 < cmwslw> 5g had a more important problem: we don't have execution since both the notes bug and pwnage 2.0  have been fixed
21:16 < cmwslw> and those are the only two ways of execution on the ipod so far
21:17 < kyle6513> hmm
21:18 < kyle6513> square one again
21:27 < benedikt93> were there already ideas for new exploits?
21:30 < TheSeven> nope
21:30 < cmwslw> there's been at least one but it turned out to be a flop
21:31 < cmwslw> for the 5g we might be able to piggyback off the iphone hacking community and wait till they find an exploit that works for it
21:31 < kyle6513> we could try torturing the device?
21:33 < benedikt93> TheSeven: what do you think about the stuff Iw rote on the dfu thing above?
21:38 < benedikt93> kyle6513: you would need really good torturing skills, I think :P
21:39 < kyle6513> haha
21:39 < kyle6513> i've managed to kill two ipod nanos so far
21:45 < kyle6513> attempting to swap the batteries
21:45 < kyle6513> thats one stunt i wish to never repeat haha
22:13 *** kyle6513 has quit IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6.7/20100713130626])
22:32 *** benedikt93 has quit IRC (Quit: Bye ;))
23:31 < teuf> cmwslw: fwiw, I've got a spare nano5g here on which I can try to run whatever exploit is worth trying
23:31 < teuf> I don't care about the data that is on it nor if it gets broken
23:31 < teuf> (I'd rather keep it functional, but I won't get too upset if it dies ;)
23:33 < cmwslw> teuf: i'll keep that in mind, but right now theres nothing to try
--- Log closed Fri Jul 30 00:26:24 2010