Thank You for your continued support and contributions!
The problem is that in the firmware there is a few room left, but yesterday we discussed with atomik_punk about that:Some firmwares (like the clip) present padding blocks in this way:The first DWORD is 0xdeadbeef and the following 0x1FC bytes are junk so we could probably insert code in there rather at the end of the firmware block.
I think I will test that tonight: put a magic string in a padding block and browse memory to find this string: if found, return immediately to the original firmware code, else sleep for 10 seconds or so.
Did you check utils/AMS/hacking in the rockbox subversion repo ?
Quote from: funman on July 31, 2008, 07:43:04 AMThe problem is that in the firmware there is a few room left, but yesterday we discussed with atomik_punk about that:Some firmwares (like the clip) present padding blocks in this way:The first DWORD is 0xdeadbeef and the following 0x1FC bytes are junk so we could probably insert code in there rather at the end of the firmware block.OK, but will this work on other players but the clip? Well, let's see if it even works for the clip
As for chatting: Where do you come from? You could update your profile with your local time (if it's not correct now) so it's easier to communicate But I don't have much time to spend on the sansas until saturday ~4pm (UTC+2h) ^^
So far we can address all the firmware file, not only the firmware block !!
Maybe I could check that the code is the one I wanted before jumping (or branching if you prefer) with cmp ..
Don't forget to swap the bytes when you read them from xxd !
Aah I didn't see your edit till now ^^ I've been watching here all the time for you to post some news Quote from: funman on July 31, 2008, 07:43:04 AMSo far we can address all the firmware file, not only the firmware block !!That's great news!
Quote from: funman on July 31, 2008, 07:43:04 AMMaybe I could check that the code is the one I wanted before jumping (or branching if you prefer) with cmp ..Well, if it is possible, why not... you don't want to brick your player, do you? So being careful is never wrong.
ldr r3, =0x30400ldr r2, [r3] /* load the word we are checking */ldr r1, =0x38100000 /* verify that it's a pointer to the OF (0x138) */cmp r1,r2beq boot1### missing r1 assignement ### damn !!b bootboot1:mov r1,#0x500000 /* ~ 5 seconds */b bootboot: /* sleep loop */subs r1, r1, #1bne bootldr pc, original_entry #jump to OF
Edit firmware file at address 0xEFFFF8 to say 74 6F 62 69 (the value i've chosen)Now here comes the problem: what should I write into MAGICVAL? According to what you told me in jabber, it should be 0xf6479626. But that doesn't work, I have to wait 5 sec...
I've been experimenting quite a lot now... My result is that it's NOT possible to access anything outside the firmware block using this method. The very last thing I can access is the 00 00 00 00 at 0x1DE18, which is right at the beginning of the first library. I think the library starts exactly at 0x1de1c, and not at 0x1de00 as calculated by 0x400 + 0x200 * firmware_size_multiplier.
I don't understand well what you mean : from 0x1de00 to 0x1de18 (well - 0x400) you can see:0x38220100 0x00000d30 0x70220e30 .. etc ?
Also I took the conversion code to translate instructions in utils/disassembler/arm/disasm_arm.c
As discussed with the hackers, it would be wise to execute our code after some stuff has been initialized.
Page created in 0.118 seconds with 21 queries.