I am very happy with the features I have on my Kindle, as is, as I have a Note 3 as well for most of the other things I wish to do. I have however recently discovered something fun that would open up a lot of avenues, but seems to MAYBE require me to root, to accomplish. The thing is, I really don't want to if I don't have to.
What I found was that the Sony Dualshock playstation 4 controllers are able to pair, as is. They function well and it is very exciting. The main game I wish to play via this method GTA San Andras works fine with this controller, and I am told, when configured correctly, is near perfect. However, it seems the configuration of the controller is incorrect, meaning the button layout does not correspond to the correct keymap. I have found someone who corrected this problem, and was supplied with the keymap, only it needs to be placed in:system/usr/keylayout/
which is of course readonly..
It seems an awful lot of work, risk, and hassle to root to place ONE file in the proper location..
Is there any way to get around this without needing to root my device?
I thank you for any help.
ThE JafF
Well it seems no one wants to say one way or the other..
Well, maybe we can rule one of the two options out and make this multiple choice question a little easier. My device is the 8.9" and it just took the 4.5.1 update before i realized it was too late to stop it. Now that it has, are there any options out there for rooting it now?
If not then im left with finding some other sneaky way.. How about creating a legit app with the sdk that simply lets you make a keymap file? I know next to nothing about doing so, but all i am looking to do is place a text file if a particular name in a particular place.. Lol i know, it sounds so easy, but might not be.
Anyway id appreciate suggestions. Ibdont mind doing a little work, i just need someonevwith knowledge to point me in the correct direction.
Thanks
In fact to make helping me as easy as humanly possible, here is/are the results of all the work I currently was able to do for myself. I am no slouch, but i literally could get no further without assistance. I am hoping that this will mean something to someone who is willing and able to asist those eager to learn and willing to do as much as they are are currently capable of. I don't mind guidelines or vague outlines of what i will need, such as, learn what you need to get the sdk up and running, read this article xxx, hou need to understand how to handle xxx style of text and are going to want to read about lolipop, or kitkat, etc..
What won't work are suggestiobs like: learn how to program!, or, learn androiod, or buy a commercial controller.
Anyway, what I have found: it goes here:
system/usr/keylayout
It is called: Vendor_054c_Product_05c4.txt
Once in place you are supposed to change the extension to .kl
The contents of the kl file will follow this post as i am unable to post links yet. This was a bit of a suprisr, ive been reading this site for like 2 and a half years or more, just never post.. Oh well..
This info was from a user on this site called 'lilcza1' so thanks to Lilcza1 for this
So i don't think i can be accused of being lazy here, just perhaps a little behind in getting to the point of considering myself a developer, which i do hope to be able to do one day.
So a big thanks in advance for any help or guidance you might provide!
kl file
# Copyright (C) 2010 The Android Open Source Project
# Copyright (C) 2013 Amazon.com, Inc. or its affiliates. All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at the apache org site
# license 2-0
#
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
# DualShock 4 Controller
#
# Buttons
key 164 MEDIA_PLAY_PAUSE
key 168 MEDIA_REWIND
key 172 HOME
key 208 MEDIA_FAST_FORWARD
key 304 BUTTON_X
key 305 BUTTON_A
key 306 BUTTON_B
key 307 BUTTON_Y
key 308 BUTTON_L1
key 309 BUTTON_R1
key 310 BUTTON_L2
key 311 BUTTON_R2
key 312 BUTTON_SELECT
key 313 BUTTON_START
key 314 BUTTON_THUMBL
key 315 BUTTON_THUMBR
key 317 MENU
# Joystick and game controller axes.
axis 0x00 X flat 0
axis 0x01 Y flat 0
axis 0x02 Z flat 0
axis 0x05 RZ flat 0
axis 0x09 GAS
axis 0x0a BRAKE
axis 0x10 HAT_X
axis 0x11 HAT_Y
an answerable question?
Ok, since we so many have viewed this without comment, i realize now, that i'm in the raft alone and help is just not coming. But, maybe, just maybe, a single part of this can be answered for me. I have decided this is important enough for me to jump in and start swimming for it.. I just don't want it to be for nothing. I need to know there is land to swim toward.. Would it be feasible to do something like i suggested above? Develop an apk that will simply load/edit/save keymap files in the location mentioned above? It doesn't seem like a properly created / signed application would have the same restrictions a basic user would have, i just don't know enough about how android works to know if programs are able to manipulate or create their own files in the area i am suggesting, or if that kind of action would be seen as virus activity or some other kind of a security risk. I just don't want to waste my time.
Thanks in advance
Related
I read with great interest the article on XDA Memory Management. I am pretty sure I understood everything, however, there seems to be one thing missing. I understand how to get the address of the Translation Tabe Base from CP15:R1(31..14), however, it would seem to me that would be a physical address. Since I'd like to peek through the TTB, I really need to know the virtual address. In the example given, the TTB had a physical address of 0xc00b0000, and the author stated that he read the MMU tables at 0xac0b0000. When you look at the resulting tables, you can see how this works, however, this is a little bit like putting the cart before the horse, ie; *how* does one know the virtual address of the physical address that the MMU table starts at? I am trying to look at a system that is not an XDA, thus I have a different MMU map, ie; my base tabel begins at physical address 0xa0010000.
Hope someone can shed some light on this.
Cheers!
ok, now I see a way for this to work.... VirtualAlloc, VirtualCopy
Is that how the author found the mapping, or is there another way?
rcp said:
ok, now I see a way for this to work.... VirtualAlloc, VirtualCopy
Is that how the author found the mapping, or is there another way?
Click to expand...
Click to collapse
The author of that bit of information is on vacation right now, and will be back in a week or so. But maybe XDA developer entity W4XY or one of the other entities can help you as well. I'll check..
Hey guys,
I've done some dev on *NIX before, including writing ways to sign my own packages using encrypted hashes and the like. Does anyone know the method that HTC is using to sign the zip files?
The reason that I ask is because I'm interested in trying my hand at reverse-engineering the signature. I am sure some of you guys have already done some work in that area, and I'd rather not repeat someone else's effort if y'all have already taken steps to break the signature. My CSI teacher told me to never start from scratch if someone else has already done good work. It's insulting to them, and makes more work for you.
Where are you folks at with breaking the signature? Is the method known (i.e., is it based on files inside the zip, is based on the bits of the zip, is an additional hash or added metadata, etc)? I would really appreciate any feedback on this if you have the time.
EDIT: For those of you who are leakers or users et. al. DO NOT get any hopes up about this thread. I'm just getting started and this idea could fizzle within minutes of you reading this particular sentence. Anyone posting, please focus on practical suggestions or comments such as sickbox's initial comment below. Thank you!
I've wondered about this since the beginning.
I understand just how complex signing can be (to some degree, I'm not a math guy but I understand scale).
My thought though is we can utilize several tools to make this process possible - though I have no idea how to implement most of this to make this possible. Maybe I'm nuts, but here goes...?
- We now have what, three or four different HTC signed images in the wild with another on the way (OTA). Would it be possible when trying to reverse the sig to utlize the differences between the packages to narrow the cope a bit?
And next
- Using GPUs to process data like this has been shown to be exponentially more efficient and effective than CPUs. What would it take to use some of our awesome GPU power ( a la CUDA) to attempt this task?
Lastly:
- Can we break up the processing required among several of us to speed things further?
I know this has probably been thought of before and discarded for good reason, but I guess the more ideas the merrier.
I'm no CS guy, but I would love to help! I'm one of those unfortunate leakers but rather than whine I'm looking for ways to help. Reversing the HTC key would make life sooo easy. Who knows, maybe they'll use the same key on the next few phones?
Pretty much why I'm asking NOW is because I have enough packages for me to examine and compare and test against. I'm not the best or the most experienced at it, but this kind of thing is fun for me and fits into my spare time. When I have spare time.
It's not the signing we need to know how to do its the cryptographic key that they use to sign their packages that we need. The private key changed with the last bootloader so even if we cracked the key before the couple hundred years it would have taken us to crack the one used for 1.5 we would have to do it again now for 2.1 stuff.
Just look around for test signing and such and you can find the test key that people use to sign stuff as well as the method used to sign the package.
As far as getting the key... you will have to know someone from HTC who would risk their job to get you a copy of their private key.
Greetings Sickbox,
I guess my intention isn't clear. I want to be able to sign packages regardless of what key HTC uses. We have a signature, and we have keyhole. I've noted that the behavior on my Eris is that the signed packages check out just fine each time no matter what version I'm trying to flash (obviously, cannot downgrade, I know, but trying to downgrade still passes the signature and it is the version that fails). So what I would like to do is reverse engineer the signature not necessarily to find the key, but to discover how to create keys. I have 4 different packages, and two test keys that I can examine.
I'm only wanting to know if someone knows how the packages are signed so that I can eliminate looking at all the signing methods. In my research so far, I haven't been able to google, bing, or yahoo anyone who knows what method is used to sign the HTC official packages.
That help, Sickbox? Thanks for your input, I really appreciate it.
So the intent is to reverse engineer the key correct? Then we can sign whatever we want...
Or are you trying something else?
Just want to see if we're on the same page.
1234567ten
I don't necessarily want to reverse engineer the specific key that HTC used to sign any one package, but rather the template for the keys. A prime example of this kind of key decryption would be DeCSS written by DVDJon. He quit trying to reverse engineer the keys used to encrypt DVDs and reverse engineered the decryption of DVD signatures.
I'm not using technical terms for the following, but basically when you sign or encrypt something, the key used is not found within the package or signature, nor is it in the program used to verify the signature or decrypt the package.
If I can do nothing with the signatures of the Eris roms, it's no waste to me. I have fun with this because I want to design an open source DRM system someday. *Sigh* dreams.
Try these. I'm still not sure if I fully understand your question but this as much as I could come up with.
Found by searching "android signing" & "android sign rom" on google if you wanna see what else might come up.
http://developer.android.com/guide/publishing/app-signing.html
http://androidforums.com/developer-101/8665-how-signing-roms.html
sickbox said:
Try these. I'm still not sure if I fully understand your question but this as much as I could come up with.
Found by searching "android signing" & "android sign rom" on google if you wanna see what else might come up.
developer.android.com/guide/publishing/app-signing.html
androidforums.com/developer-101/8665-how-signing-roms.html
Click to expand...
Click to collapse
Hmm... maybe I was being too specific when looking for "htc sign rom" and "eris htc sign rom," etc. I'll see what I can cull from those broader searches. Thanks for the tip, sickbox.
np
34567ten
You might have noticed that there is a little bit of confusion in the posts here when "signing" is brought up; there are two completely different signing methods in use.
The first applies to applications (.apk bundles), "update.zip" files (which could be used with Amon_RA's recovery), and OTA-delivered update files. The distinguishing feature of these .zip files are: 1. They have a META-INF folder in them with two Manifest files and a RSA public key file, and 2. there is nothing "unusual" about the zip file itself. (The contents of the zip file are signed, but the whole zip file is not.)
The second type is the "rom.zip" files buried inside the MR1/MR2 " RUU" updates. These files, when renamed to PB00IMG.ZIP, can be used with the bootloader to update the phone. The distinguishing feature of this type of file is that: it has a mystery blob of binary data at the front of the zip file - 256 bytes. The rest of the file is an ordinary .zip file, and if you unpack it you will find that there are no manifests, no META-INF file, and no public key certs. (In this case, the entire zip is signed, but none of the individual content files are.) I think it is this second type of signing you were referring to in your posts, but honestly I am not certain.
The first form of signing is perfomed with a java tool called "jarsigner", and its behavior is well understood: it creates the first manifest file by computing SHA-1 hashes for every file to be included in the .zip archive. Then, it creates a second manifest file which shadows the first one, and for each SHA-1 hash value, it "signs" them using the signer's private key. In this 2nd file, it also computes the hash for the complete (1st) manifest file, and signs that hash. In any event, what I mean by " well understood" is that this is just a standard use of RSA public key cryptography, using widely deployed Sun Java tools. Break it and you will have made quite a name for yourself.
Now, as for the 2nd type of file - rom.zip/PB00IMG.ZIP, I have not seen anyone (yet) describe the format of that MIC (Message Integrity Check) 256-byte blob. I poked at it a little, but certainly not exhaustively.
If you want to add to the knowledge here, try and discover what the "format" of that MIC is. I suspect that even if you do that, you will find that the sig uses exactly the same PK tools that are already built in to the bootloader - from the standpoint of practicality, it really doesn't make any sense why HTC would " roll their own" when they already went to the effort of coding RSA tools into their botloader(s).
bftb0
Hey bftb0,
You answered my question PERFECTLY. Nobody I've spoken with elsewhere has yet brought up the RSA encryption that's already built into it. You're probably only second guy to mention it, beyond some dude in an IRC somewhere (and I think he was drunk at the time).
Knowing that it is just additional bits on the zip, has anyone thought off hacking it off and paring it to another zip in an attempt to "sign" the zip (I've done this successfully with various signed ISOs)? Also, the public key could be arrived at, given two factors, 1. The same key was used for all Eris 2.1 packages; and 2. The "blobs" of data can be sufficiently compared and I have enough computing power.
Thank God I may be getting an intel I7.
Or I'll just borrow my friend's PC.
I hope I'm not just blowing steam, because it would suck to get working on this and then find it's impossible. But they say that about a lot of key encryption schemes. LIKE RSA on Blu-Ray.
Thank you so much bftb0
Don't read too much "encouragement" into my post; I responded in order to shed some light on the way that HTC is doing things, and that's about all.
If you think about it carefully, you will understand that the manifest-signing operation gives you hundreds, if not thousands, of individual plaintext/crypt-text pairs that are all signed with the same private key. That doesn't mean that a known-plaintext attack is easy, though.
The EFF commissioned a project a couple of years back where they built custom hardware that would brute-force key searches for short keys- 256 bit keys IIRC. The machine they built was a parallel processor built from fpgas/DSPs, and it could recover keys in a few days. Their budget for that was in the low 100,000s. Offhand, I don't know what key length HTC is using, but I doubt it is 256 bits.
I don't recommend you spend any cycles trying to brute force a key recovery.
bftb0
bftb0 said:
Don't read too much "encouragement" into my post; I responded in order to shed some light on the way that HTC is doing things, and that's about all.
I don't recommend you spend any cycles trying to brute force a key recovery.
Click to expand...
Click to collapse
Dude, I was so encouraged that I want to rip open my PS3 and put it to work RIGHT NOW.
Not really. I'm too lazy-assed to spend much time brute forcing it. I'd rather pick it apart and see if there's anyway to mimic the signature. Your advice that it may be RSA based is more exciting in that it helps me know what I may be dealing with. I hope to pick at the binary data appended to the signed roms either tomorrow or next weekend.
And thats what I appreciate.
I'm not sure what you're trying to do. You either brute force the private key, using various bits of super-math (e.g. elliptic curve cryptography?), or you give up and move on -- perhaps looking at patching the subsystem responsible for validating signatures (dangerous for production use).
There are no "mimicing" possibilities and swapping blobs/zips around is just silly. You should spend your time elsewhere, like reading up on how public-key cryptography works.
Thanks WithinRafael,
I think some of what I've written above shows I'm researching public-key cryptography. I really appreciate your thoughts, and it became clear by the end of sunday that the signature is specific to the package. Without me doing much work, mostly research. RSA is a load of work and I do not want to mess with trying to crack that.
I recently became interested in trying to turn S-off. Someone recently gained RW access to NVRAM, and I'm hoping this weekend to move on as you mentioned. Thanks for the good discussion, guys!
with a pen....duh j/k
Anyone have a supercomputer? ...lets brute force it.
Is there a way to check if a rom passes the signature test without trying to load into the phone? Can we check if the signature passes on a computer?
If so we could sign it with all possible keys and see which one passes.
Is this frowned upon and shouldn't even be discussed? or would it just take too long to do? ... or is it just not possible to check the signature on a computer?
... or all of the above?
DarthMowzy said:
Anyone have a supercomputer? ...lets brute force it.
Is there a way to check if a rom passes the signature test without trying to load into the phone? Can we check if the signature passes on a computer?
If so we could sign it with all possible keys and see which one passes.
Is this frowned upon and shouldn't even be discussed? or would it just take too long to do? ... or is it just not possible to check the signature on a computer?
... or all of the above?
Click to expand...
Click to collapse
We can check the signatures based on what is stored in the Manifest file inside the PB00IMG.zip file.
It is possible to brute-force it but it would take years to do so it isn't really worth the effort.
UPDATE:
So it seems as though i have solved that problem, and now i just away the kernel modules. Thanks for all your help guys.
Code:
adb shell /data/local/kexec /data/local/uImage
MSTART= 12668952828585181184 MEND=18014435486466048 MEMTYPE=0 NR_SEGMENTS=0 ULONG_MAX= 4294967295
MSTART= 12668952829122052096 MEND=18014435822010368 MEMTYPE=0 NR_SEGMENTS=0 ULONG_MAX= 4294967295
MSTART= 12668952829390487552 MEND=18014436090445824 MEMTYPE=0 NR_SEGMENTS=0 ULONG_MAX= 4294967295
start= AFD1297980000000 mem_min= 0 hole_min=0 end=4000089C000000 mem_max =FFFFFFFF hole_max=FFFFFFFF
Cannot open /proc/atags: No such file or directory (Doesnt really matter from what ive read)
kexec_load failed: Function not implemented (The module)
entry = 0x80008000 flags = 280000
nr_segments = 2
segment[0].buf = 0x2e4e8
segment[0].bufsz = 10
segment[0].mem = 0x80001000
segment[0].memsz = 1000
segment[1].buf = 0x403ff048
segment[1].bufsz = 2c4214
segment[1].mem = 0x80008000
segment[1].memsz = 2c5000
So hears the deal myself and gameman73 have been working our a**es off trying to get this KEXEC to compile and work. The problem is the current memory will not allow for certain calls to the iomem.
We need to find a way to have this line of code compile and be true on our devices. If someone could sift through the code alittle that be well appreciated:
Code:
kexec/kexec.c 230: while ((j < info->nr_segments) && (([B](unsigned long)info->segment[j].mem) <= mend[/B]))
Apparently it thinks info->segment[j].mem is a const * void
Here's the source http://horms.net/projects/kexec/kexec-tools/kexec-tools-2.0.2.tar.bz2
When I work on something, I often find that having a complete understanding of the problem makes the solution clear. Perhaps this will help you understand the problem better:
SEE ATTACHED FILE, FIRST LINK*
Related. Looks like you aren't the first person to have a problem with the way memory is called in kexec. You might be able to work something out from this discussion, however old it may be.
SEE ATTACHED FILE, SECOND LINK*
This is something else about disabling kexec from executing. A workaround is discussed, but I am by no means a developer and I can't make any sense of it. Just giving you what I find.
I don't mean to spam, and I don't want to be the typical noob getting in the way, but I do want to help. Research, it seems, is about all I can do until my unit arrives (hopefully tomorrow).
*edit: since this is my first post, please excuse the attached file. It is only because with less than 8 posts I cannot put the links in the body of my message.
twodollaz: research is awesome. digging that crap up is a giant pita.
loglud: did you guys get kexec-mod compiling and loading? i haven't had time to look at it much, but all the sources i've found require a huge amount of work to compile, let alone load and run. do y'all have more information on that? i'd look at why the line you mentioned isn't working but i have no frame of reference if i can't reproduce it myself :-/
Actually you really don't need the module to reproduce the error that I am talking about. But gameman73 does have a fully compiled module loading into insmod. And it is showing as installed. You can ask him.
As for you links twodollaz there actually very useful, however not for our problem. The problem that they are incurring is that of the memory not being malloced, or assigned to the process. Our problem is that according to the program there is no memory existing, (the page is there but the lines are not). I think i might have found a solution last night while sleeping ironically, however i am in work and cant test till I get home.
You've gotta love it when your subconscious does the work for you.
If you guys need more help with this I would be glad to join in. I have literally no experience with kernels, hardware, etc though so I will need some hand holding to get kexec loaded and testing. Once I have the build/run setup I might be able to help. I am a programmer by trade, mostly java based, but can write c/c++ when pressed. Alot of what I do on a day to day basis is pull apart other people's code and fix it, optimize it, etc - mostly in a JVM but I have done this some for system cores.
zambien said:
You've gotta love it when your subconscious does the work for you.
If you guys need more help with this I would be glad to join in. I have literally no experience with kernels, hardware, etc though so I will need some hand holding to get kexec loaded and testing. Once I have the build/run setup I might be able to help. I am a programmer by trade, mostly java based, but can write c/c++ when pressed. Alot of what I do on a day to day basis is pull apart other people's code and fix it, optimize it, etc - mostly in a JVM but I have done this some for system cores.
Click to expand...
Click to collapse
zambien you are my new best friend. If you could take a look at what are valid memory locations in the locate_holes function that would be amazing. So far when i do an
Code:
fprintf(stderr, "mem= %li...",(unsigned long)info->segment[j].mem))
i always get nothing. I think this might be because j needs to start at 1 but idk. if you could find a way to iterate through
Code:
info->segment[j].mem
and find where it is valid, we might be on our way.
Forgive me if I'm way off, but how does this sound? I don't know if this device is EFI compliant, but if it is - and apparently some ARMv7 devices are - then it could allow kexec to reference a more complete memory map provided by EFI. The patch behind the link is for x86, but perhaps there are some ideas it might provide.
Just trying to help.
See attached for link..
twodollaz said:
Forgive me if I'm way off, but how does this sound? I don't know if this device is EFI compliant, but if it is - and apparently some ARMv7 devices are - then it could allow kexec to reference a more complete memory map provided by EFI. The patch behind the link is for x86, but perhaps there are some ideas it might provide.
Just trying to help.
See attached for link..
Click to expand...
Click to collapse
Hmm thats very interesing... Ill try this when i get home. Im looking though it more and im starting to think that this could be our problem. Im going to pull one of the patched files down tonight and try seeing what happens.
I have written code using tcl/tk for quite some time and I would not have much problem writing this code (actually, I have written a very similar code before) but since Android is Java I will have to educate myself before I try to build this app. What I am trying to find out is how much will I have to educate myself before I can pull this thru. Learning to write code in tcl/tc did not took me long and I actually did a lot of learning while writing code so again, not having experience in java I am seeking the feed back of those that are currently way ahead of me to give me a better feel of what I am getting into... :victory:
This app will be based in a program built for windows. I have thru the years ask the vendor if they are going to port it to android and I always get the same response, "in a few months"...
Here is what I am looking forward to build...
Overview
Need to create an Android app that will consist of an UI and data processing terminal to communicate with a serial device. The terminal will be capable of sending commands to the serial device to gather information, process the information and then display it in human understandable terms.
Goals
Basic program:
* Create communication with a FTDI chip at 1200 Baud Rate, 8 data bits, No Parity, 1 stop bits and xon/xoff flow control, I have prove it to work with no control since the amount and rate of data is so small.
* Capable to send hex ascci commands, receive a dump in hex ascci then translate that hex ascci dump into decimal format for processing. The serial device communication and hardware cannot be changed. Most all commands are set but there is one command that the value will change depending on previous data found.
Example of communication:
send :000000037D (status command)
Response:
Hex/ascii -> decimal
:0401010C2A0094 -> 4 1 1 12 42 0 148
:0401010C9A0489 -> 4 1 1 12 154 4 137
In this example column 2, 3, 5 and 6 has the data I need and will have to process to display the final values.
* Status command should have option to be controlled with a timer with options for 1, 5, 20, 40 sec and Timer off. There should be a button on the UI to send that status command, also, the ability in the future for the command to be microphone driven (x amplitude loud noise will trigger command).
UI:
* Dark colors to keep the display from eating up the battery.
* Should turn off the display every 10 seconds and should come up on new data, mic driven or phone shake.
* Should have a display where the last data numbers will be displayed. Also to have the ability to create a second larger display with the same last data numbers.
* Need 8 buttons for commands, drop down menu for settings (timer settings) and exit button.
* There should be a space (table) to display data, up to 99 records. It should look more like a excel spread sheet with just 2 column. These columns will bet the data location and the data itself. The table should be able to hold about XX amount of records, if it gets larger then a scroll bar should be used to navigate up and down the table.
Enhanced program
Display altitude/barometric pressure on request(capable phones).
Future:
Right now the device talks to the computer via a serial/usb dongle but I am planning to build the hardware to make it Bluetooth capable but in very few odd instances I might have to run it with the dongle due to the distance between the device and the phone might exceed the most common 30 feet Bluetooth maximum distance.
Im tired of taking my pc to a dusty and pc unfriendly environment so I have decided to take the plunge and build the app myself. Learning Java and android will be beneficial as I can see me in the future building more apps for personal use .
As it is now I can control this device using a hyper-terminal in my Samsung Note. Problem is having to type the commands manually, getting the responses back, translating those hex responses to decimal then building the response... too much work by hand...
Currently im using Slick USB Serial Terminal. Although they have a paid version that could help with the commands it will still leave me with processing the response by hand. It is useful when all I want is to advance the display on the device as it is the most used command but still at times it is imperative to get the status from the system and I am back to square one. And if I wanted a full status report It would take me nearly an hour to process by hand...
I have bought these books:
Java All-In-One for Dummies 3rd edition.
Programing Android, O'Reilly, 2nd edition.
Beginning Android 4, Application Development, Wei-Meng Lee, seems to be 1st edition.
Android application development for java programers, James C Sheusi, also seems to be 1st edition.
Anyone care to comment or recommend a book or a website?
Thanks everyone! You will be seeing much more of me as soon as I start having questions!!! lol!
Is my English really that bad? lol!!!
kinda hard to believe no one can answer this question here. moving on.
Probably this that you may be looking for.
Save time on re-inventing the wheels, or you can decompile theirs.
one of the hyperterminals I been using provides their source so Im not too worried about that. I did not knew you could decompile and app. Anyways, thanks for your reply.
Has anyone had any luck find the source code for the MTCB MCU? I'd like to mod the shutdown timer such that it leaves the device fully operational for the timer duration. Or if anyone has info on the instruction set used, I could perhaps made the mod using assembly or bitbanging.
This may help. It uses an 8051 instruction set
KLD2-v277 "source"
I have been studying and commenting the MCU code for a few months now -- specifically the KLD2-2.77 version. I used darksimpson's mcu decryption tool on the mcu.img file to get the 8051 binary file, then used the D52 disassembler to create "source" code from that.
Studying this code is an ongoing, very slow process but still I have made significant progress.
A few observations (any of which may contain errors!):
1) The original source appears to be written in a higher level language, probably C (not sure which compiler).
2) It appears to communicate with the Android CPU using Serial Port 2 and also an SPI port. There are two I2C buses that the MCU uses to control the various peripheral chips such as the radio, sound processor, and video matrix.
3) Serial data is in the form of packets consisting of a 3 byte preamble followed by one or more bytes of data and ending with a checksum. The specific form of the packet and checksum can vary and is determined by the preamble.
4) Serial packets mostly go from MCU to Android. The MCU can receive packets too, but that capability doesn't seem to be used much, if at all.
5) The primary method of control from Android to MCU seems to be through the SPI port. This consists of 16 bit command words that are handled by a very large CASE statement. Each command word can be followed by additional data (depends on the command) and may also cause the MCU to send data back, either through SPI or more commonly by serial port packets.
6) It appears to me that the designers have nearly maxed out the code space. In other words there is very little room left for additional code, and also evidence that they did things to try to squeeze more code into the available space.
7) Finally -- and not to bash the Chinese designers in any way (tremendous effort contained in this code) -- there are some obvious bugs and also significant room for improvement.
If anyone wants more specific details on what I've learned please PM me. If anyone wants to dive in and study as well, please share what you learn!
One thing that would help me tremendously would be more information on the actual hardware environment. My HU is an 8133 with 480x800 display (specifically a Pumpkin C0235) but it is already installed in my car and I really like it there instead of on a workbench. . So if anyone is in a position to provide hardware details (such as clear photos and schematic diagrams -- either partial or complete, handmade is ok!), sharing them here will help a lot! The code does a lot with MCU I/O pins and without knowing what is connected to those pins it is difficult to really understand their true purpose.
Zipped text file is attached
dhmsjs said:
I have been studying and commenting the MCU code for a few months now -- specifically the KLD2-2.77 version. I used darksimpson's mcu decryption tool on the mcu.img file to get the 8051 binary file, then used the D52 disassembler to create "source" code from that.
Studying this code is an ongoing, very slow process but still I have made significant progress.
A few observations (any of which may contain errors!):
1) The original source appears to be written in a higher level language, probably C (not sure which compiler).
2) It appears to communicate with the Android CPU using Serial Port 2 and also an SPI port. There are two I2C buses that the MCU uses to control the various peripheral chips such as the radio, sound processor, and video matrix.
3) Serial data is in the form of packets consisting of a 3 byte preamble followed by one or more bytes of data and ending with a checksum. The specific form of the packet and checksum can vary and is determined by the preamble.
4) Serial packets mostly go from MCU to Android. The MCU can receive packets too, but that capability doesn't seem to be used much, if at all.
5) The primary method of control from Android to MCU seems to be through the SPI port. This consists of 16 bit command words that are handled by a very large CASE statement. Each command word can be followed by additional data (depends on the command) and may also cause the MCU to send data back, either through SPI or more commonly by serial port packets.
6) It appears to me that the designers have nearly maxed out the code space. In other words there is very little room left for additional code, and also evidence that they did things to try to squeeze more code into the available space.
7) Finally -- and not to bash the Chinese designers in any way (tremendous effort contained in this code) -- there are some obvious bugs and also significant room for improvement.
If anyone wants more specific details on what I've learned please PM me. If anyone wants to dive in and study as well, please share what you learn!
One thing that would help me tremendously would be more information on the actual hardware environment. My HU is an 8133 with 480x800 display (specifically a Pumpkin C0235) but it is already installed in my car and I really like it there instead of on a workbench. . So if anyone is in a position to provide hardware details (such as clear photos and schematic diagrams -- either partial or complete, handmade is ok!), sharing them here will help a lot! The code does a lot with MCU I/O pins and without knowing what is connected to those pins it is difficult to really understand their true purpose.
Zipped text file is attached
Click to expand...
Click to collapse
Great work! Thank you! I'm not profound in this MCU programming but I really believe that it is of great importance to hack that code and mod it in order to squeeze more from these units. A applause you and hope other will join your effort.
Open source implementation could be interesting down the road
Wonder if we could steal any of the tricks from old days of DSS cards and double up code by using lookup tables for some references to make more room for improvement code.
webdude12 said:
Wonder if we could steal any of the tricks from old days of DSS cards and double up code by using lookup tables for some references to make more room for improvement code.
Click to expand...
Click to collapse
There is a lot of "wasted" space (duplicate initialization data for instance) so there's plenty of room available if the software is written efficiently. However modifying what is there, other than small tweeks, is probably not likely to succeed. It looks to me like there is a lot of "band aid" fixes in there and (in my experience anyway) modifying that kind of code often ends up creating more subtle, unforeseen problems than it fixes.
Yes an open-source rewrite will be the best long term solution but that will require a thorough understanding of both the MCU and the Android side of the interface. On the other hand we have potentially a large group of international talent to apply to the task, and no hard deadlines either. It is certainly possible to do.
The MCU processor itself is well known. The peripheral devices are well known (or knowable). So reimplementing those interfaces can be largely independent of the Android-MCU interface. But knowing what the Android CPU expects, and accommodating that for all variants is currently the big unknown for me.
dhmsjs said:
There is a lot of "wasted" space (duplicate initialization data for instance) so there's plenty of room available if the software is written efficiently. However modifying what is there, other than small tweeks, is probably not likely to succeed. It looks to me like there is a lot of "band aid" fixes in there and (in my experience anyway) modifying that kind of code often ends up creating more subtle, unforeseen problems than it fixes.
Yes an open-source rewrite will be the best long term solution but that will require a thorough understanding of both the MCU and the Android side of the interface. On the other hand we have potentially a large group of international talent to apply to the task, and no hard deadlines either. It is certainly possible to do.
The MCU processor itself is well known. The peripheral devices are well known (or knowable). So reimplementing those interfaces can be largely independent of the Android-MCU interface. But knowing what the Android CPU expects, and accommodating that for all variants is currently the big unknown for me.
Click to expand...
Click to collapse
Well that is great to hear. So what I would think that needs to be done first is a complete comment dis-assembly. This has been completely useful in other "hacking" attempts as it allows you to fully understand step by step what the original coders were doing. It also allows for debuggers / emulators to written.
From there it can be determined if it makes sense to re-write sections, re-route code, or completely re-write from scratch providing the same functions.
webdude12 said:
Well that is great to hear. So what I would think that needs to be done first is a complete comment dis-assembly. This has been completely useful in other "hacking" attempts as it allows you to fully understand step by step what the original coders were doing. It also allows for debuggers / emulators to written.
From there it can be determined if it makes sense to re-write sections, re-route code, or completely re-write from scratch providing the same functions.
Click to expand...
Click to collapse
While it is by no means complete, I've worked through enough of this MCU code that I think I have a pretty good high-level understanding of how and what the MCU does. As I said above, what I'm missing now is much of the hardware context (for example which MCU pins connect to what, some of the peripheral chip #s, etc), and also the Android software context -- specifically the code that sends commands through SPI to the MCU. I have looked briefly at some of the Android code (for example MTCManager.apk) but didn't find anything useful there. It seems like the SPI interface is lower level -- perhaps as in a device driver??
This is just a dumb question because you guys would be so far away from modifying mcu code, yet I'm going to ask it.
Could some of the hardware hacks (Using different sound processor for radio, mic mods) be accomplished through software, if you got a good handle on things?
DRidilla said:
This is just a dumb question because you guys would be so far away from modifying mcu code, yet I'm going to ask it.
Could some of the hardware hacks (Using different sound processor for radio, mic mods) be accomplished through software, if you got a good handle on things?
Click to expand...
Click to collapse
Sound processor yes since that is just sending different commands to the sound processor. Mic mod no since that is a hardware mod only (as far as I can see it anyway).
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal? Hypothetically of course.
Would be amazing if down the road those sort of mods could be done on the software side.
Also add "Control radio before android boots" to my dream list.
DRidilla said:
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal? Hypothetically of course.
Would be amazing if down the road those sort of mods could be done on the software side.
Also add "Control radio before android boots" to my dream list.
Click to expand...
Click to collapse
My understanding of the mic hardware interconnection is not good enough to say one way or the other. Probably varies from model to model as well (I don't seem to have a big problem with my external mic).
Control radio before Android boots might be tough since most all of the radio user interface comes through Android anyway. Might be possible to restore previous radio config before Android is up, but that might also not be such a great thing for many users. Not sure I'd want my radio to come up blasting away if I don't also have a way to silence it.
Then again with an open source solution, all you would really need is the will to make it so. I guess we all have our own dream lists, no?
DRidilla said:
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal?
Click to expand...
Click to collapse
Both microphones are hardwired together. It is not possible to "shut off" one with software. There's also a modification to improve the radio's frequency response by replacing some capacitors. Again, not possible with software.
dhmsjs said:
...
Click to expand...
Click to collapse
Wow, nice work!! I typically have a few KGL units on the bench. Attached are a few images to get you started. These are of the 1024x600px resolution units.
Next time I'm at the office, I'll check out which I/O expansion chip(s) are being used and see if I can identify some of the lines.
Aaaron16 said:
Wow, nice work!! I typically have a few KGL units on the bench. Attached are a few images to get you started. These are of the 1024x600px resolution units.
Next time I'm at the office, I'll check out which I/O expansion chip(s) are being used and see if I can identify some of the lines.
Click to expand...
Click to collapse
Thanks! Really appreciate the photos. Difficult to read the chip #s though.
I know the radio device is similar to a TEF6624 - maybe a TEF6686?
Pretty sure the sound processor is a BD37531 or BD37534.
Not sure what the video matrix switch is -- FMS6502 maybe?
These all connect to the MCU via I2C. Interested in identifying the other devices that connect via I2C too. I can see the I2C addresses they use to communicate with the chips, but I can't generally look up a chip # by its I2C address. The goal is to find the data sheets for each device so that I can understand exactly what the I2C comm is doing. I have data sheets for the devices listed above.
Also as an update: I stated above that the MCU is controlled by Android through an SPI channel. I've been studying this more closely and it is clear that it is not actually SPI. Looks more like a custom 3 wire interface. Uses pins 1, 2 and 3 of the MCU (the IAP15F2K61S2 device).
Pin 1 (P0.5) is data (or ACK) to Android from MCU, driven by MCU
Pin 2 (P0.6) is the clock, which can be driven by either side (open collector with pullup?)
Pin 3 (P0.7) is data (or ACK) to MCU from Android, driven by the Android CPU
It would be helpful to know which pins these connect to on the Android CPU.
Each bit sent must be acknowledged by the receiver before the next bit is clocked out. There is debouncing and timeouts applied to the signals and the transfer is aborted if either fails. Maximum bit rate is around 1MHz I think, and probably slower in actual use. If anyone recognizes this as a particular comm standard, let me know! Otherwise it must be custom for these HUs.
Component Listing (KGL Mainboard)
I noticed the KGL devices use different radio modules even across the same model. I have some units with TEF6624 modules and others with TDA7786 modules. The following are the IC part numbers for the newer 1024x600px KGL main board (date code 2014-07-20):
1. AU6258J61-JES-GR (USB 2.0 Controller)
2. 15L2K61S2 (MCU)
3. FMS6502MTC (Video Sw Matrix)
4. BD37033FV (Sound Processor)
5. GM8283C (? - 10+ traces going to 50-something pin IDC display connector)
6. T132BT (TFT Video Controller)
7. WM8751L (Stereo DAC) - markings rubbed off. See attached photo.
I couldn't find an I/O expander chip on the main board, so I'm guessing the MCU drives most of the I/O lines directly (aside from those handled by their respective audio/video controllers).
Possibly related, I found this document which seems to include many of the same components:
http://p.globalsources.com/IMAGES/PDT/SPEC/216/K1127159216.pdf
MCU Memory Map/Resource Use
So attached below is a document containing a partial memory map, resources used, and I/O pin assignments as I currently understand it from studying the MCU code. The document changes every day as I learn more.
Again this is a KLD2 unit and the V2.77 version of MCU code I'm studying. For Aaaron16 or anyone else who has the ability to explore the hardware of a KLD2 head unit, what will help me a lot in this effort is understanding what the I/O pins connect to. They are listed at the top of the document.
If you explore your hardware, post what you find in this thread and I'll add it to the doc. TIA!
Could Malaysk make modified MCU with redisigned sound processor and sleep mod fo MTCB-MD-V2.67:angel:. I cant post download link
drive.google.com/file/d/0B9-2UI8L0wScel92bUFlaExkWnc/view?usp=sharing
dhmsjs said:
So attached below is a document containing a partial memory map, resources used, and I/O pin assignments as I currently understand it from studying the MCU code. The document changes every day as I learn more.
Again this is a KLD2 unit and the V2.77 version of MCU code I'm studying. For Aaaron16 or anyone else who has the ability to explore the hardware of a KLD2 head unit, what will help me a lot in this effort is understanding what the I/O pins connect to. They are listed at the top of the document.
If you explore your hardware, post what you find in this thread and I'll add it to the doc. TIA!
Click to expand...
Click to collapse
How is this progressing @dhmsjs ?