Patching BASE.RKW on RK27xx series players.
 

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

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

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.

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

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)

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 :-)

yes, when I get a bit further.

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.:rolleyes:

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

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

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.

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

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

thanks for the interest
knob ;)

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.

hello,

i have an ramos t8.
i can mod all the images and text with image searcher and string editor.
but what can I do with this peace of software when it whill be released knob?
And how user friendly whill this be? because i got no experience with coding or anything :P.
Can I for example let my ramos t8 start in the music screen in stead of the home screen? and can i chance the location of where the buttons are?

many thank you,
i really hope this whill be something usefull :P

Actually, I am working on theme tool which will enable to rearrange all the buttons, text areas and graphics to the position you like. Also the interface will be very user-friendly. As soon as I will release beta version you may test it on your own Firmware, but you must know that I am working only on 3 different types of FW at the moment, so I don't guarantee that beta version will work with other than standard source layouts. But after that step I am planning to gather as much different firmwares as possible to make it more compatible. I must note that it doesn't have to be exactly the same firmware I am using to create this tool. It rather should be similar in terms of the structure of the source, which for most graphical objects seems to be in fact similar.

That's my contribution to the topic, I don't know how knob is doing with his own stuff.

that sounds SOOO great , thats what I always wanted when it comes to modding my media player

I will be Waiting for the beta..

When you gonna release the beta? or you dont know?

thanks! :cool:

I started doing this tool quite long time ago, but I didn't tell anything until there was a chance that it will work properly. And also because I wanted to avoid others expectations. I work on it when I have some free time. Luckily or not, I've been ill for a whole week so I had a lot of time. I'm back in college by Wednesday, and I don't know how busy I will be. Therefore please be patient if someone is interested.

But one thing is sure: I wont abandon this project as I tend to do sometimes. So cross fingers for me, because sometimes I encounter very tiresome problems to solve.

Also, I have a question for other developers. On what it depends whether 32bpp bitmap can be displayed (with alpha transparency values).
I found some enum type of data and I am not sure whether one of these values will enable to display fully 32bpp Picture.
I just wonder if it depends on one of these?

just to say flasher - this is very good news, i assume this is for 27 series firmwares or 26 series?? -- looking forward to see the development on both of these projects, at the moment when modding we can only FAKE moving of images on some player that support transparency by making images larger, the firmware accespts this) but we can only expand from original XY postion --> out - so this, if you get it working will be excellent and hopefully all these tools can transfer to the new 28 series as the firmware appears similar but images in new 28 series are all offsett for some reason, i think rockchip may be making things a little more difficult in their latest 27 series and 28 series firmwares to stop our simple image modding

anyway good luck

Yes it is for RK27XX players. I don't know if it will work with rk28. I mean, doesnt it use different assembler codes? (ARM7 vs ARM9) If the asm instructions are the same, and crucial source code layout is similar, then there is hope, otherwise I have no help in RK28XX players. The only reason why my tool can be done is the source code of the SDK for 27 players which I've been studying and comparing C-input code with ASM-output code. I am beginner in ASM, though this project helped me a lot with understanding such wild language as Assembler is.

I whill test the software when beta releases , i got touchscreen 4.3 inch ramos t8

Ok, guys, I know it will be very useful tool, but that's what I wanted to avoid - expectations. I need to take my time, to make it as universal as possible. I want to create a new theme format which will include all the new bitmaps and parameters so it can be exported or imported and applied for any firmware.

About Ramos I really don't know how it will work. I know it has very different graphical layout from the standard SDK 1.08. The worst case will be that some of the desired elements will not accessible, and some of them will be.

But I want to ask again, how to enable displaying 32bpp bitmaps with alpha transparency. I know its done in several firmwares, and I know it's possible to do it via SDK. If I knew where to find, It will be also possible to apply it for most of the elements (if not all) handled by my tool, so we would be able to replace 24bpp graphics with 32bpp. At the moment, my original firmware ignores alpha transparency byte (rrggbbXX) in every single graphic.

I understand what you mean , i whill shut up till the beta whill be released :rolleyes:

No, I didn't mean to shut anybody up. I'm just saying - dont get too excited too soon

I understand , but I still whill shut up so you can do your work :cool:

hi knob.
is your project making some progress?
any updates on your project?

thanks!