Patching BASE.RKW on RK27xx series players.

[knob]

I've decided to start a new thread for this (rather than the Hooray Rockchip SDK)

I am working on a patching and hacking tool for base.rkw on RK27xx series players.

Basically the idea is to do advanced modding using a user friendly tool that (I hope) will work on
most rk27xx firmware and is easy for the non-technically minded to use.

I already have a tool that is usable but I am looking for a way to disable the crc32 check in the firmware.

Does anyone know where this crc check routine located?

I'm thinking it would be best to just nop this out rather than keep
updating the crc everytime a change is made to base.rkw.

btw heres a useful reference for information on base.rkw :-
http://alemaxx.al.funpic.de/rk27/rkwfwpatch.html

[makd511]

this sounds interesting knob, what simple things could a simpleton like me do with it??

well done for perusing and persisting with all this BTW

[knob]

Originally Posted by makd511

this sounds interesting knob, what simple things could a simpleton like me do with it??

Basically altering defaults and existing parameters, so no enhancements, we are still modding. But the idea is to make it as easy to use as possible.

I'm gonna start with the simple stuff and see how it goes.

[makd511]

well good luck knob and all who sail on the rockchip mod!!!
i am sure its like a nedle in a haystack for you all - hopefully it can also be used on the new 28 series as the BASE structure still seems the same although the main package is not RKW now but an IMG file

either way -will be looking in and seeing how its all going

[knob]

Here is RockBasefixv1 :-
http://www.sendspace.com/file/y4xmmy

Doesn't do very much atm but will give an idea of what can be done.

Many thanks to AleMaxx for rkwpatch, (I wouldn't be able to test this without it)

[AleMaxx]

Hi knob,
I downloaded you app but I wasnt able to test it yet. Do you plan to release the source? To answer your very 1st question: the crc checking code that also loads the BASE.RKW is either in the ROM of the chip or inside the flash. The datasheet mentions something about configuring some pins to determine where to boot from, so its kinda hard to find it or even modify it. Besides, that you can deactivate CRC checks by setting a bit flag in the header but I think keeping crc-checks would be nicer.
May I propose another feature for your tool like "make the hidden partition visible"? A general approach (that does not rely on the name of a file you put on the visible partition) would be via USB MSDC. Have a look at the code at the end of BulkOnly.c and here are the MSDC specs: http://www.usb.org/developers/devcla...assbulk_10.pdf. Also most probably Windows does offer a special API here, I think there must be a default driver for USB mass storage but Im not familiar with this.
Maybe you can also extend it to determine such things like LCD configuration etc, and maybe offer the option to patch it so a firmware can run on a player with a different screen.

Happy Coding :-)

[knob]

Do you plan to release the source?

yes, when I get a bit further.

Maybe you can also extend it to determine such things like LCD configuration etc

Yes I was already thinking about adding a feature to extract the screen information Not sure if that feature would belong in a separate tool or not.

I want this to be able to work for as many users as possible, not sure if it
works for the touch screen mp5 (I hope so).

As long as I don't get reports of users bricking their players I will go further.

[AleMaxx]

I want this to be able to work for as many users as possible, not sure if it
works for the touch screen mp5 (I hope so).

Whats the difference and why do you have concerns that it may not work for touchscreen players? Whats your approach to patching and what is getting patched? I think it would be a bad idea to assume absolute offsets since those may change even for different firmware versions of the same player. One approach to identify certain subroutines would be to calculate (crc32) signatures (independent of abs. values that may change like addresses of subroutines or variables) for these. You may need some kind of "intelligent disassembler" that identifies subroutines and can trace hardware register i/o. Here is a small article on APCS (ARM Procedure Calling Std.): APCS introduction.

Good luck

[knob]

hi AleMaxx

Whats the difference and why do you have concerns that it may not work for touchscreen players?

Should make no difference at all, only I don't have a touchscreen to test.

what is getting patched?

At the moment just a few font sizes, so I can have bigger fonts where they will fit, I don't plan to add extra code, just the settings there already.
It would be nice to be able to add a .rkp launcher but that may prove to difficult.

would be a bad idea to assume absolute offsets since those may change even for different firmware versions of the same player.

I didn't use absolute offsets, I am using byte string matching so it should work on other players, not just my own.

You may need some kind of "intelligent disassembler" that identifies subroutines

Yes you are right if am going to do some really advanced patching.

thanks for the interest
knob

[flasher86]

I also was thinking about patching original FW. To my logic, it would be the best to put extra code at the end of the base.RKW. And in the source we may just apply new address of the function to the one in the end of the file. It would be the safest way to not interupt the original offsets.

Also, in the code there are functions which load an external binary file and run it. It would be so much easier to work on small plugin-like files. We would be able to create some sort of platform, and compile stuff in ADS into ready .out file ready to run.