Time and time it comes up: Why do you want to shut off the data plan on the phone? You've paid for the features, why not use them?
Simple: Platinumtel charges for the data. I wanted the features for when I was home and could surf / watch on the internet, and not have it automatically connect to 3G every time I went somewhere. And I can't use airplane mode or else I lose ability to receive calls and SMS messages. Programs on the market don't work to shut off the data, mainly because they are written for non CDMA phones or gingerbread, and...platinumtel uses CDMA and Froyo.
There's a "safe" way -- dial *#*#INFO#*#* (that's *#*#4636#*#* for phone newbies)
when you type the last * it should automatically take you to a special screen (you don't have to hit the phone button to call -- if it didn't go to the screen, you typed it wrong).
Select "Phone Information"
select the menu button. There will be an option on the bottom right side "Disable data connection". it will only have that option if you are currently connected to 3g. If you are connected to wifi it will say Enable data connection.
Basically every time it disconnects from wifi it automatically connects to 3g so you have to go in and disable the data connection. Well that sucks.
But there is another way.
Root it, then load DroidWall and then whitelist only wifi. Sounds simple enough, but quite a lot involved.
Quick note on rooting platinumtel sanyo or kyocera zio PLS-8600. If you root it, you violate the warranty. A rooted phone can give access to apps that they shouldn't have. And you can also end up bricking the phone. So if that scares you, use the other method for a while. When you get tired of that, come back and read how to root it. Just make sure that any apps that request root access only be given root access if you expected them to request it and you know why they need it.
Rooting this took a while to get it figured out, and nobody really had an answer anywhere else so I figured I'd post the necessary steps.
See, the PLS-8600 has no drivers. There's drivers for the SCP-8600, but none for the PLS-8600, at least none I could find with a good amount of searching. You can access the phone via USB and see the directories, but in order to root it with a PC you need to be able to run the ADB program (or have a program that uses ADB) and without the drivers, ADB can't see the phone. So you can't use the methods that use a PC, such as superoneclick.
But, gingerbreak.apk file will do it. http://forum.xda-developers.com/showthread.php?t=1044765
You have to install that onto your phone. In order to do that, you have to enable "unknown sources". So go into the menu / settings and select applications. Check the unknown sources to allow installation of non-Market applications. Now go fetch the APK. Or, if you'd prefer, you can do it from the SD card. Copy the gingerbreak.apk onto the SD card, then put it back in the phone and go to the market and install and run appinstaller (funtrigger version). There are probably others that worked, but some crashed on me and that is the one I ended up using that worked. Run it and install gingerbreak.
Now enable debugging mode. Go into the settings menu, select applications, select development and checkmark the USB debugging. Now go run the gingerbreak. Select root, and wait.
It'll reboot the phone. And the phone will seemingly get stuck on the "ZIO" screen. Be patient, it takes a while. I started thinking I had just bricked the phone. Anyway, once it finally goes on, you'll have a new program called "superuser". Now pull droidwall from the market. Once you get it up and running, you'll see a screen with lots of apps and nothing checked. From here, you can manually check the left column (the wifi column) for any apps you want to grant access to wifi. There is one that will give access to any app if you want all apps to have wifi access. Click menu button and select apply. It'll ask for superuser access. Grant and allow it to remember that it has access. Otherwise it will need to request it every time you make a change. Next go to the menu and select the firewall button. I think it initially says "disabled" or something like that. When you enable it, it will turn green.
There ya go. Now whenever you leave the wifi, it will still connect to 3G but very, very little will be used on the data plan. You can bring up the browser to confirm. It'll still retrieve any cached pages (such as the initial google search page) but anything else will be denied. If you want access to 3g, just bring up the droidwall and turn off the firewall. That'll give you full access to 3g, or you can enable specific programs to have access all of the time. Just remember to apply the changes.
One more thing. Once you've rooted the phone, don't update. Usually you have to unroot and restore everything on the phone before you apply updates. On my Atrix, I had frozen some programs and altered some others. I couldn't get the updates on until I restored everything back the way it was before I rooted it, including the programs I had altered and unfreezing others and then unrooting the phone. The update, in that case, just kept crashing about 1/3 of the way through.
Unrooting the Sanyo will be manual, since you can't use something like Peter's Motorola root tools to put things back. So track everything you do that required root access and make sure you undo it. Then you can manually uninstall it using a terminal emulator on the phone. There are several on the market. Once you run them you'll need to:
mount -o rw,remount /system
rm /system/app/Superuser.apk
rm /system/{,x}bin/su
reboot
The unrooting instructions above are theoretical. I haven't had a need to do it, but should I ever need to, I now won't have to look it up and I'll make sure these instructions are correct. Basically it remounts the system directory as read/write, then removes the Superuser program and the su program. There may be others that need to be removed. At this point, I haven't really looked. busybox might be one. But all that research will come later, if and when I need to do it.
Tuesday, March 13, 2012
Monday, October 25, 2010
Canon SX10IS fix
My powershot SX10IS was doing something very weird. With the flip out screen in normal position facing the photographer, the LCD was off. If I moved it out just slightly, the LCD would come on, but the picture was upside down.
It actually worked ok if I flipped out the LCD, but it was annoying. So I tore it apart to fix it and decided to document it since I found nobody else having run into this issue.
Step 1, remove the two visible screws that show up when you flip out the screen. Once you've removed those, the black shield can be removed.
It snaps in and out so a little force was needed to slide it out. It slides away from the LCD.
Flip the LCD back to normal position. This is where you'll see the microswitch. In my case, there was a broken wire.
Resoldered the two broken wire pieces together and that took care of it. To test it, I had to make sure the microswitch was firmly in the correct position.
yeah, I know, bad solder job. The wires were super small, very thin. I had to strip back some of the insulation. Anyway, my point here isn't to demonstrate my superior soldering and electrical engineering capabilities, but to show others how to get to that part of the camera and fix it yourself if it is malfunctioning the same way.
The more exciting stuff comes from the safe software hacking. Since the canon can "boot up" from a properly formatted SD card, you don't have to do any kind of bios flashing, which makes the chdk hack one of the safest I've seen.
Tried out the "fast MD 080914" script to see if I could get some lightning from a storm. Now, I'm familiar with the long exposure time technique to capture lightning. I don't like it. Not only is the picture noisy, but any other lights in the area get over exposed and quite often the picture, taken at night, looks like a daytime picture.
But not with this script.
I could actually hold the camera, with ISO set at 80, late at night and catch some very crisp, clean lightning strikes.
That was a 1 second exposure. All I had to do was hold the camera while it watched for the lightning and snapped the picture on its own. Very nice hack. There's others stuff, like being able to see the exact battery % and watch as it drops while the flash is being powered up, and then goes back up. It reveals why the camera thinks it is low on battery and yet seems to go fine for a long time after. And the temperature sensors - I didn't even know there that many sensors for detecting temperature in the different parts of the camera.
Anyway, if you have a canon, consider looking into that hack. I'm glad I did.
It actually worked ok if I flipped out the LCD, but it was annoying. So I tore it apart to fix it and decided to document it since I found nobody else having run into this issue.
Step 1, remove the two visible screws that show up when you flip out the screen. Once you've removed those, the black shield can be removed.
It snaps in and out so a little force was needed to slide it out. It slides away from the LCD.
Flip the LCD back to normal position. This is where you'll see the microswitch. In my case, there was a broken wire.
Resoldered the two broken wire pieces together and that took care of it. To test it, I had to make sure the microswitch was firmly in the correct position.
yeah, I know, bad solder job. The wires were super small, very thin. I had to strip back some of the insulation. Anyway, my point here isn't to demonstrate my superior soldering and electrical engineering capabilities, but to show others how to get to that part of the camera and fix it yourself if it is malfunctioning the same way.
The more exciting stuff comes from the safe software hacking. Since the canon can "boot up" from a properly formatted SD card, you don't have to do any kind of bios flashing, which makes the chdk hack one of the safest I've seen.
Tried out the "fast MD 080914" script to see if I could get some lightning from a storm. Now, I'm familiar with the long exposure time technique to capture lightning. I don't like it. Not only is the picture noisy, but any other lights in the area get over exposed and quite often the picture, taken at night, looks like a daytime picture.
But not with this script.
I could actually hold the camera, with ISO set at 80, late at night and catch some very crisp, clean lightning strikes.
That was a 1 second exposure. All I had to do was hold the camera while it watched for the lightning and snapped the picture on its own. Very nice hack. There's others stuff, like being able to see the exact battery % and watch as it drops while the flash is being powered up, and then goes back up. It reveals why the camera thinks it is low on battery and yet seems to go fine for a long time after. And the temperature sensors - I didn't even know there that many sensors for detecting temperature in the different parts of the camera.
Anyway, if you have a canon, consider looking into that hack. I'm glad I did.
Sunday, September 5, 2010
Canon SX10 IS initial hacking
This camera was actually very easy to hack. Indeed, most Canon cameras are. And the greatest thing about it is that it is almost perfectly safe. You don't flash anything into the firmware. Instead, you program an SD card to be bootable and to have the specific boot files you need on it.
All of that is available at CHDK. It is a site set up to specifically hack Canon cameras. The firmwares are adapted for new cameras all of the time, and the wiki page is pretty clear on how to do it.
I am no photo expert, but the hacks have helped add some fun to the camera. Ok, it's somewhat fun to play games on the camera while you're waiting for your kid's school play to start. But there are a few things that I have really enjoyed.
First, my SD card lost it's little plastic tab that determines whether it is read only or writable. So now the card is read only to every device, except my canon. In the read only mode, the canon hack is enabled and can write to the card. So i haven't lost the card's usefulness.
Second, the motion detection scripts. I set up the camera when a recent electrical storm passed through and caught pictures of lightning, all without having to do a 30 second exposure. in fact, the pictures are crisp, clean with no ISO noise and all taken while I was holding the camera. I had taken pictures of lightning before by doing long term exposures, but these pictures were so much better and I didn't have to use a tripod.
Time lapse, being able to see the temperature of the lens, and the exact battery power % available at all times, those are really great functions.
I did run into one hardware problem with this camera. The LCD screen had a little switch in it that allows it to detect when you've flipped the screen over. As a result, when I close flip LCD with it facing me, it thinks it is facing the camera and shuts off the LCD. In order to use the LCD, I have to swing it open and, since it can't detect which direction, I end up not being able to flip the screen so the person I'm taking a picture of can see themselves. It's annoying, but something I can actually live with.
Nonetheless, I took apart part of the camera and found that the cause was this really, really small wire that had broken. So I reattached it and the camera was working again.
Note the use the of the word "was". It's happened again, so I'm going to need to take it apart again. This time I'll take pictures with my other digital camera so I can document how to fix it.
All of that is available at CHDK. It is a site set up to specifically hack Canon cameras. The firmwares are adapted for new cameras all of the time, and the wiki page is pretty clear on how to do it.
I am no photo expert, but the hacks have helped add some fun to the camera. Ok, it's somewhat fun to play games on the camera while you're waiting for your kid's school play to start. But there are a few things that I have really enjoyed.
First, my SD card lost it's little plastic tab that determines whether it is read only or writable. So now the card is read only to every device, except my canon. In the read only mode, the canon hack is enabled and can write to the card. So i haven't lost the card's usefulness.
Second, the motion detection scripts. I set up the camera when a recent electrical storm passed through and caught pictures of lightning, all without having to do a 30 second exposure. in fact, the pictures are crisp, clean with no ISO noise and all taken while I was holding the camera. I had taken pictures of lightning before by doing long term exposures, but these pictures were so much better and I didn't have to use a tripod.
Time lapse, being able to see the temperature of the lens, and the exact battery power % available at all times, those are really great functions.
I did run into one hardware problem with this camera. The LCD screen had a little switch in it that allows it to detect when you've flipped the screen over. As a result, when I close flip LCD with it facing me, it thinks it is facing the camera and shuts off the LCD. In order to use the LCD, I have to swing it open and, since it can't detect which direction, I end up not being able to flip the screen so the person I'm taking a picture of can see themselves. It's annoying, but something I can actually live with.
Nonetheless, I took apart part of the camera and found that the cause was this really, really small wire that had broken. So I reattached it and the camera was working again.
Note the use the of the word "was". It's happened again, so I'm going to need to take it apart again. This time I'll take pictures with my other digital camera so I can document how to fix it.
Thursday, August 19, 2010
Why no progress?
Yes, I'm still alive but of little or no use at this point.
The sourceforge project was been taken down due to a DMCA order from two parties. After scrubbing the project of all files considered copyrighted, there isn't enough there to continue investigation. I could get the opensphd part hosted again (although one of the parties has not reviewed the code and accepted that it is open source) but it requires taking upon myself the liability and costs for any challenge issued after reinstating that code. I don't have bottomless pockets and can't take that liability upon myself.
There is another project called ketlaer that has taken a different approach and is adaptable to 1283/1073 devices. They tap into the Asus library, which is publicly available from Asus to work with those devices. MyMediaSystem has been ported and known to work on several compatible devices. Unfortunately, does not work with the 1262/1282 nor could I see any way to adapt it such that it would without adding code that would be considered in violation of the DMCA.
It is not the end of my blog, but looks like the end of my screenplay hacking for now.
The sourceforge project was been taken down due to a DMCA order from two parties. After scrubbing the project of all files considered copyrighted, there isn't enough there to continue investigation. I could get the opensphd part hosted again (although one of the parties has not reviewed the code and accepted that it is open source) but it requires taking upon myself the liability and costs for any challenge issued after reinstating that code. I don't have bottomless pockets and can't take that liability upon myself.
There is another project called ketlaer that has taken a different approach and is adaptable to 1283/1073 devices. They tap into the Asus library, which is publicly available from Asus to work with those devices. MyMediaSystem has been ported and known to work on several compatible devices. Unfortunately, does not work with the 1262/1282 nor could I see any way to adapt it such that it would without adding code that would be considered in violation of the DMCA.
It is not the end of my blog, but looks like the end of my screenplay hacking for now.
Wednesday, April 14, 2010
MIPS disassembler / reverse engineering tool
I know I haven't posted for a long time, but I have been busy hacking.
I needed a decompiler with source code that I could modify to try to build something similar to what an acquaintance of mine once built, the MIPSX Sourcer. When I was into hacking a certain DVD player, I learned MIPSX which isn't too far different than MIPS but different enough to make the tools incompatible. Doing a disassembler is easy. In fact, objdump comes on the ScreenPlay Pro itself, so just objdump the DvdPlayer and presto, a gazillion lines of MIPS code with no chance of understanding it and not knowing where to start. I needed something that would take any new information I gave it and apply it across the whole file to give me more information back, and I had to start from scratch.
First, I needed an understanding of the binary format of the executable file.
http://www.skyfree.org/linux/references/ELF_Format.pdf
I put together a basic program to open and do a raw dump of each section defined in that ELF_Format.
Once I had that, it was a small matter to make the disassembler, made even easier by the Reverse Engineering Compiler:
http://www.backerstreet.com/rec/rec.htm
In fact REC looked very similar to what I wanted...but it was not able to handle the Iomega firmware and testing with other MIPS code I found it was difficult to get the information together that I wanted. However, the author published a small piece of his code:
http://www.backerstreet.com/rec/dismips.c
This was a nice jewel. It had some stuff wrong but it was a nice start anyway. So I plugged in the functions into the code I wrote and send each instruction from the ELF segments that were listed as executable and poof, instant MIPS code. It didn't match exactly with what I was getting out of objdump, so I did some investigating.
http://www.mips.com/products/architectures/mips32/index.cfm#specifications
You have to register (free) to get the documents, but this is the most accurate documentation on the language, of course. Not always the easiest to digest for a beginner, so here was a good primer I came across:
http://www.eecs.harvard.edu/~ellard/Courses/cs50-asm.pdf
I didn't like the way dismips.c was representing a lot of the information, and some of it was just wrong. So I modified it to resemble the objdump disassembly a little closer. Then I have it analyze the code from top down. It assumes that any 0x3c1cXXXX followed by a 0x279cXXXX (where XXXX is any hexadecimal digit) is the beginning of a new function...and so far I haven't found any exceptions to the rule. Those two values equate to: LUI $gp,0xXXXX and ADDIU $gp,$gp,0xXXXX. These almost always followed a JR $RA instruction (with one instruction after that).
Those familiar with assembly but not familiar with MIPS need to understand that MIPS processors use a pipeline for processing the instructions and depending upon the pipeline, you can have multiple instructions in the pipe being processed at different stages. JR $RA (Jump to address specified by Register RA) changes the current execution address. But JR doesn't get the address loaded into the current instruction pointer (IP) before the next instruction is loaded into the pipeline. So the next instruction will also be executed even though it occurs AFTER the JR.
so you may see something like:
jr $ra
addiu $sp,$sp,0x20
lui $gp,0xfcc
addiu $gp,$gp,0xffffb9a4
addu $gp,$gp,$t9
the actual start of the function is on the LUI and the end of the other function will include adding 32 (hex value 0x20) into the $SP (stack pointer) register.
Ok, I'm getting sidetracked. The links up above contain better information about how MIPS works, but I wanted to explain that part so I could explain how the analysis engine works.
Now, I figured out that register $t9 always contains the address of the function being started. Whenever the code was calling a function it would do a JALR $ra,$t9 (objdump leaves off $ra since it is assumed, but I like having it there). What that does is jumps to register $t9 and stores the current IP in $ra (so that JA can then return to the next line after the JALR + one more line due to pipelining). So I make the assumption that $t9 will always contain the address of the beginning of the function at the beginning.
$a0 - $a3 are registers that are typically used for passing parameters. More can be passed by placing them onto the stack, but most times I only need to know what the first 4 parameters to any given function are anyway. Knowing this means a block of code like this:
lw $a0,0xffff802c($gp)
nop
addiu $a0,$a0,0xffff9460
lw $t9,0x2cd8($gp)
nop
jalr $ra,$t9
nop
is a call to a function with one parameter. But objdump shows this and trying to make sense of it isn't all that helpful.
So I have the program analyze the registers as it decompiles them. If it knows the value, it prints it next to the instruction. LW $a0,0xffff802c($gp) means to take the value of the register $gp and add 0xffff802c and go to that address and fetch the word (LoadWord) at that address. Well, these addresses are all in the .GOT segment in the ELF file (Global Offsets Table) so I have it peek in there to get the address. I also added the opcode and address.
004002e0: 3c1c0fcc lui $gp,0xfcc; gp=0x0fcc0000
004002e4: 279cb920 addiu $gp,$gp,0xffffb920; gp=0xfcbb920
004002e8: 0399e021 addu $gp,$gp,$t9; gp=0x100bbc00
...
0040034c: 8f84802c lw $a0,0xffff802c($gp); a0=0x00af0000
00400350: 00000000 nop
00400354: 24849460 addiu $a0,$a0,0xffff9460; a0=00ae9460
00400358: 8f992cd8 lw $t9,0x2cd8($gp); t9=0x00ad2310
0040035c: 00000000 nop
00400360: 0320f809 jalr $ra,$t9
00400364: 00000000 nop
(the first hex number is the address where the instruction will be loaded, the second hex number is the instruction that is decoded) So now we know it's calling a function with one parameter, 0x00ae9460. That happens to be an address in the .rodata segment (Read Only data segment). So I looked there, found a string terminated with a zero and included this information in. This is what I get:
004002e0: 3c1c0fcc lui $gp,0xfcc; gp=0x0fcc0000
004002e4: 279cb920 addiu $gp,$gp,0xffffb920; gp=0xfcbb920
004002e8: 0399e021 addu $gp,$gp,$t9; gp=0x100bbc00
...
0040034c: 8f84802c lw $a0,0xffff802c($gp); a0=0x00af0000
00400350: 00000000 nop
00400354: 24849460 addiu $a0,$a0,0xffff9460; a0=00ae9460
00400358: 8f992cd8 lw $t9,0x2cd8($gp); t9=0x00ad2310
0040035c: 00000000 nop
00400360: 0320f809 jalr $ra,$t9; unknown("malloc failure\n")
00400364: 00000000 nop
and that unknown function at that address is scattered throughout the code with other strings that I commonly see when I execute DvdPlayer. So I know now that the function at address 0x00ad2310 is probably printf.
So I built a separate file to document the addresses and functions at those addresses. The disassembler can then use those to pull the function names when parsing apart functions, rather than saying "unknown".
From there, I used objdump on the Ellion firmware, compiled with symbols and objdumped it with symbols. Looked at the printf function and sure enough it matched the opcodes for the function I figured was printf in the Iomega firmware. The only exceptions were the addresses and offset values. Went forward and backward from those function and found the matching functions and was able to label those.
With many of the library functions identified, it makes it that much easier to read the source and find functions that match in the Iomega vs. Ellion firmware. Especially helpful was to find the assert command, because it lists what function name it was in as one of the parameters.
I'm using this utility to try to track down what is turning off the flashing light when the DvdPlayer boots. I've identified all of the calls in the main.cpp function, which is similar but not exactly the same as the Ellion's main.cpp. What I'm going to do from this point is knock out the function calls one at a time, searching the binary file and replacing the JALR calls with NOPs. I can more easily find the ones I'm looking for due to the disassembly and using HexEdit I can replace the opcode with 0s to turn it into a NOP.
I've added some other analysis to the utility, which I will blog about when I publish the utility.
I needed a decompiler with source code that I could modify to try to build something similar to what an acquaintance of mine once built, the MIPSX Sourcer. When I was into hacking a certain DVD player, I learned MIPSX which isn't too far different than MIPS but different enough to make the tools incompatible. Doing a disassembler is easy. In fact, objdump comes on the ScreenPlay Pro itself, so just objdump the DvdPlayer and presto, a gazillion lines of MIPS code with no chance of understanding it and not knowing where to start. I needed something that would take any new information I gave it and apply it across the whole file to give me more information back, and I had to start from scratch.
First, I needed an understanding of the binary format of the executable file.
http://www.skyfree.org/linux/references/ELF_Format.pdf
I put together a basic program to open and do a raw dump of each section defined in that ELF_Format.
Once I had that, it was a small matter to make the disassembler, made even easier by the Reverse Engineering Compiler:
http://www.backerstreet.com/rec/rec.htm
In fact REC looked very similar to what I wanted...but it was not able to handle the Iomega firmware and testing with other MIPS code I found it was difficult to get the information together that I wanted. However, the author published a small piece of his code:
http://www.backerstreet.com/rec/dismips.c
This was a nice jewel. It had some stuff wrong but it was a nice start anyway. So I plugged in the functions into the code I wrote and send each instruction from the ELF segments that were listed as executable and poof, instant MIPS code. It didn't match exactly with what I was getting out of objdump, so I did some investigating.
http://www.mips.com/products/architectures/mips32/index.cfm#specifications
You have to register (free) to get the documents, but this is the most accurate documentation on the language, of course. Not always the easiest to digest for a beginner, so here was a good primer I came across:
http://www.eecs.harvard.edu/~ellard/Courses/cs50-asm.pdf
I didn't like the way dismips.c was representing a lot of the information, and some of it was just wrong. So I modified it to resemble the objdump disassembly a little closer. Then I have it analyze the code from top down. It assumes that any 0x3c1cXXXX followed by a 0x279cXXXX (where XXXX is any hexadecimal digit) is the beginning of a new function...and so far I haven't found any exceptions to the rule. Those two values equate to: LUI $gp,0xXXXX and ADDIU $gp,$gp,0xXXXX. These almost always followed a JR $RA instruction (with one instruction after that).
Those familiar with assembly but not familiar with MIPS need to understand that MIPS processors use a pipeline for processing the instructions and depending upon the pipeline, you can have multiple instructions in the pipe being processed at different stages. JR $RA (Jump to address specified by Register RA) changes the current execution address. But JR doesn't get the address loaded into the current instruction pointer (IP) before the next instruction is loaded into the pipeline. So the next instruction will also be executed even though it occurs AFTER the JR.
so you may see something like:
jr $ra
addiu $sp,$sp,0x20
lui $gp,0xfcc
addiu $gp,$gp,0xffffb9a4
addu $gp,$gp,$t9
the actual start of the function is on the LUI and the end of the other function will include adding 32 (hex value 0x20) into the $SP (stack pointer) register.
Ok, I'm getting sidetracked. The links up above contain better information about how MIPS works, but I wanted to explain that part so I could explain how the analysis engine works.
Now, I figured out that register $t9 always contains the address of the function being started. Whenever the code was calling a function it would do a JALR $ra,$t9 (objdump leaves off $ra since it is assumed, but I like having it there). What that does is jumps to register $t9 and stores the current IP in $ra (so that JA can then return to the next line after the JALR + one more line due to pipelining). So I make the assumption that $t9 will always contain the address of the beginning of the function at the beginning.
$a0 - $a3 are registers that are typically used for passing parameters. More can be passed by placing them onto the stack, but most times I only need to know what the first 4 parameters to any given function are anyway. Knowing this means a block of code like this:
lw $a0,0xffff802c($gp)
nop
addiu $a0,$a0,0xffff9460
lw $t9,0x2cd8($gp)
nop
jalr $ra,$t9
nop
is a call to a function with one parameter. But objdump shows this and trying to make sense of it isn't all that helpful.
So I have the program analyze the registers as it decompiles them. If it knows the value, it prints it next to the instruction. LW $a0,0xffff802c($gp) means to take the value of the register $gp and add 0xffff802c and go to that address and fetch the word (LoadWord) at that address. Well, these addresses are all in the .GOT segment in the ELF file (Global Offsets Table) so I have it peek in there to get the address. I also added the opcode and address.
004002e0: 3c1c0fcc lui $gp,0xfcc; gp=0x0fcc0000
004002e4: 279cb920 addiu $gp,$gp,0xffffb920; gp=0xfcbb920
004002e8: 0399e021 addu $gp,$gp,$t9; gp=0x100bbc00
...
0040034c: 8f84802c lw $a0,0xffff802c($gp); a0=0x00af0000
00400350: 00000000 nop
00400354: 24849460 addiu $a0,$a0,0xffff9460; a0=00ae9460
00400358: 8f992cd8 lw $t9,0x2cd8($gp); t9=0x00ad2310
0040035c: 00000000 nop
00400360: 0320f809 jalr $ra,$t9
00400364: 00000000 nop
(the first hex number is the address where the instruction will be loaded, the second hex number is the instruction that is decoded) So now we know it's calling a function with one parameter, 0x00ae9460. That happens to be an address in the .rodata segment (Read Only data segment). So I looked there, found a string terminated with a zero and included this information in. This is what I get:
004002e0: 3c1c0fcc lui $gp,0xfcc; gp=0x0fcc0000
004002e4: 279cb920 addiu $gp,$gp,0xffffb920; gp=0xfcbb920
004002e8: 0399e021 addu $gp,$gp,$t9; gp=0x100bbc00
...
0040034c: 8f84802c lw $a0,0xffff802c($gp); a0=0x00af0000
00400350: 00000000 nop
00400354: 24849460 addiu $a0,$a0,0xffff9460; a0=00ae9460
00400358: 8f992cd8 lw $t9,0x2cd8($gp); t9=0x00ad2310
0040035c: 00000000 nop
00400360: 0320f809 jalr $ra,$t9; unknown("malloc failure\n")
00400364: 00000000 nop
and that unknown function at that address is scattered throughout the code with other strings that I commonly see when I execute DvdPlayer. So I know now that the function at address 0x00ad2310 is probably printf.
So I built a separate file to document the addresses and functions at those addresses. The disassembler can then use those to pull the function names when parsing apart functions, rather than saying "unknown".
From there, I used objdump on the Ellion firmware, compiled with symbols and objdumped it with symbols. Looked at the printf function and sure enough it matched the opcodes for the function I figured was printf in the Iomega firmware. The only exceptions were the addresses and offset values. Went forward and backward from those function and found the matching functions and was able to label those.
With many of the library functions identified, it makes it that much easier to read the source and find functions that match in the Iomega vs. Ellion firmware. Especially helpful was to find the assert command, because it lists what function name it was in as one of the parameters.
I'm using this utility to try to track down what is turning off the flashing light when the DvdPlayer boots. I've identified all of the calls in the main.cpp function, which is similar but not exactly the same as the Ellion's main.cpp. What I'm going to do from this point is knock out the function calls one at a time, searching the binary file and replacing the JALR calls with NOPs. I can more easily find the ones I'm looking for due to the disassembly and using HexEdit I can replace the opcode with 0s to turn it into a NOP.
I've added some other analysis to the utility, which I will blog about when I publish the utility.
Tuesday, March 9, 2010
Wifi mostly solved
For my purposes, it's solved. But if you use WEP or no wifi security, there would need to be changes.
I posted this at mini-modding, but I'm replicating it here as well:
In the /tmp/hddmedia/wpa.conf file I have the following (replaced 'thessid' with the SSID used, and 'thepassphrase' with the passphrase used:
wpa.conf
ctrl_interface=/tmp/net/wpa_supplicant
ctrl_interface_group=root
network={
ssid="myssid"
proto=WPA RSN
key_mgmt=WPA-PSK
pairwise=TKIP CCMP
group=TKIP CCMP
psk="thepassphrase"
}
since the interface is at /tmp/net I have to create the directory. And since the file is stored on the 4th partition, I also needed to mount that. Also, I wanted to make sure the wired LAN was also recognized if present. So here's what is at the beginning of my /usr/local/etc/rcS file:
/usr/local/etc/rcS
mount /dev/ide/host0/bus0/target0/lun0/part4 /usr/local/etc/dvdplayer/hdd/volumes/HDD1
ln -s /usr/local/etc/dvdplayer/hdd/volumes/HDD1 /tmp/hddmedia
mkdir /tmp/net
echo 'nameserver 127.0.0.1' > /etc/resolv.conf
udhcpc -p /var/lock/udhcpc_eth0.pid -t 15 -b -s /etc/udhcpc.script -i eth0
modprobe ehci-hcd
modprobe ohci-hcd
sleep 2
ifconfig wlan0 up
iwconfig wlan0 essid "myssid"
wpa_supplicant -P/var/lock/wpa_supplicant.pid -D ipw -c /tmp/hddmedia/wpa.conf -i wlan0 -B
udhcpc -p /var/lock/udhcpc_wlan0.pid -t 15 -b -s /etc/udhcpc.script -i wlan0
The second udhcpc takes about 30 seconds to run, and then it still doesn't start responding to pings until after another minute has passed.
Now I'm sure there's going to be a better way to do what I've listed above. Like do we really need to have udhcpc staying as a running process after it has assigned the IP address? I don't know. But this is a starting point that works at least.
There is a script already on the ScreenPlay in the /etc directory called udhcpc.script. It's already there, but for reference here is the listing:
/etc/udhcpc.script
#!/bin/sh
# udhcpc script edited by Jason Lee
[ -z "$1" ] && echo "Error: should be called from udhcpc" && exit 1
RESOLV_CONF="/etc/resolv.conf"
DHCP_OK="/var/lock/dhcp.ok"
DHCP_OK2="/var/lock/dhcp."
[ -n "$broadcast" ] && BROADCAST="broadcast $broadcast"
[ -n "$subnet" ] && NETMASK="netmask $subnet"
case "$1" in
deconfig)
/sbin/ifconfig $interface 0.0.0.0
;;
renew|bound)
/sbin/ifconfig $interface $ip $BROADCAST $NETMASK
if [ -n "$router" ] ; then
echo "deleting routers"
while route del default gw 0.0.0.0 dev $interface ; do
:
done
for i in $router ; do
route add default gw $i dev $interface
done
fi
echo -n > $RESOLV_CONF
# [ -n "$domain" ] && echo search $domain >> $RESOLV_CONF
[ -n "$domain" ] && echo domain $domain >> $RESOLV_CONF
for i in $dns ; do
echo adding dns $i
echo nameserver $i >> $RESOLV_CONF
done
echo ok > $DHCP_OK
echo ok > $DHCP_OK2$interface
;;
esac
exit 0
I posted this at mini-modding, but I'm replicating it here as well:
In the /tmp/hddmedia/wpa.conf file I have the following (replaced 'thessid' with the SSID used, and 'thepassphrase' with the passphrase used:
wpa.conf
ctrl_interface=/tmp/net/wpa_supplicant
ctrl_interface_group=root
network={
ssid="myssid"
proto=WPA RSN
key_mgmt=WPA-PSK
pairwise=TKIP CCMP
group=TKIP CCMP
psk="thepassphrase"
}
since the interface is at /tmp/net I have to create the directory. And since the file is stored on the 4th partition, I also needed to mount that. Also, I wanted to make sure the wired LAN was also recognized if present. So here's what is at the beginning of my /usr/local/etc/rcS file:
/usr/local/etc/rcS
mount /dev/ide/host0/bus0/target0/lun0/part4 /usr/local/etc/dvdplayer/hdd/volumes/HDD1
ln -s /usr/local/etc/dvdplayer/hdd/volumes/HDD1 /tmp/hddmedia
mkdir /tmp/net
echo 'nameserver 127.0.0.1' > /etc/resolv.conf
udhcpc -p /var/lock/udhcpc_eth0.pid -t 15 -b -s /etc/udhcpc.script -i eth0
modprobe ehci-hcd
modprobe ohci-hcd
sleep 2
ifconfig wlan0 up
iwconfig wlan0 essid "myssid"
wpa_supplicant -P/var/lock/wpa_supplicant.pid -D ipw -c /tmp/hddmedia/wpa.conf -i wlan0 -B
udhcpc -p /var/lock/udhcpc_wlan0.pid -t 15 -b -s /etc/udhcpc.script -i wlan0
The second udhcpc takes about 30 seconds to run, and then it still doesn't start responding to pings until after another minute has passed.
Now I'm sure there's going to be a better way to do what I've listed above. Like do we really need to have udhcpc staying as a running process after it has assigned the IP address? I don't know. But this is a starting point that works at least.
There is a script already on the ScreenPlay in the /etc directory called udhcpc.script. It's already there, but for reference here is the listing:
/etc/udhcpc.script
#!/bin/sh
# udhcpc script edited by Jason Lee
[ -z "$1" ] && echo "Error: should be called from udhcpc" && exit 1
RESOLV_CONF="/etc/resolv.conf"
DHCP_OK="/var/lock/dhcp.ok"
DHCP_OK2="/var/lock/dhcp."
[ -n "$broadcast" ] && BROADCAST="broadcast $broadcast"
[ -n "$subnet" ] && NETMASK="netmask $subnet"
case "$1" in
deconfig)
/sbin/ifconfig $interface 0.0.0.0
;;
renew|bound)
/sbin/ifconfig $interface $ip $BROADCAST $NETMASK
if [ -n "$router" ] ; then
echo "deleting routers"
while route del default gw 0.0.0.0 dev $interface ; do
:
done
for i in $router ; do
route add default gw $i dev $interface
done
fi
echo -n > $RESOLV_CONF
# [ -n "$domain" ] && echo search $domain >> $RESOLV_CONF
[ -n "$domain" ] && echo domain $domain >> $RESOLV_CONF
for i in $dns ; do
echo adding dns $i
echo nameserver $i >> $RESOLV_CONF
done
echo ok > $DHCP_OK
echo ok > $DHCP_OK2$interface
;;
esac
exit 0
Friday, March 5, 2010
RootApp and Wifi
Played around with the RootApp. Noticed that if you run RootApp with a -1 DvdPlayer then it will execute the specified program once, go to sleep after the program exits, then when you turn it back on it will resume and exit the RootApp watchdog program. Also, if you do RootApp -s then it won't execute any program, but will immediately put the player to sleep. When you power on, it wakes up and...reboots. But if you combine them doing -s -1 then when you power back on, it will resume and exit from RootApp.
I've also worked on trying to understand the wifi. When you disable the DvdPlayer from starting up, it doesn't mount the media partition or link the media drive to /tmp/hddmedia. It also doesn't configure the network/netmask and gateway for the wired or wireless connection.
At the beginning of the rcS file in the /usr/local/etc is the instructions for doing the network config, so I just adapted it for mine and added drive mounting and linking.
ifconfig eth0 192.168.0.2 netmask 255.255.0.0
route add default gw 192.168.0.1
mount /dev/ide/host0/bus0/target0/lun0/part4 /usr/local/etc/dvdplayer/hdd/volumes/HDD1
ln -s /usr/local/etc/dvdplayer/hdd/volumes/HDD1 /tmp/hddmedia
And of course I took out the RootApp DvdPlayer command so that it wouldn't activate the DvdPlayer. This has left two things for me to solve. #1) How to control the blue light. It continues to flash after booting, and the bootscreen stays up. Well, the HelloWorld can take care of the bootscreen, but figuring out what controls that power light has been more difficult. #2) Wifi does not get set up.
First run
/usr/local/etc/dvdplayer/script/run_tail
which installs the ehci-hcd and ohci-hcd modules using modprobe.
I think it also needs:
/sbin/modprobe ieee80211-rtl
/sbin/modprobe ieee80211_crypt
I found this info in the Main DvdPlayer as well:
/bin/echo nameserver 127.0.0.1 >> /etc/resolv.conf
ifconfig wlan0 up
wpa_supplicant -P/var/lock/wpa_supplicant.pid -D ipw -c /tmp/net/wpa.conf -i wlan0 -B
wpa_cli -p /tmp/net/wpa_supplicant status > /tmp/net/WPA.STATUS;touch /tmp/net/WPA.OK
The /tmp/net/wpa.conf file is added when DvdPlayer runs, but it looks something like this:
ctrl_interface=/tmp/net/wpa_supplicant
ctrl_interface_group=root
network={
ssid="MySSId"
proto=WPA RSN
key_mgmt=WPA-PSK
pairwise=TKIP CCMP
group=TKIP CCMP
psk="your wifi passphrase"
}
I've extracted information and found a webpage about setting up which has helped.
http://wiki.archlinux.org/index.php/WPA_supplicant
But I'm actually stuck at ifconfig wlan0 up. wlan0 isn't there. The light doesn't come on in the wifi adapter so I think the port needs to activate power or recognize the device or something similar. NetworkSet.cpp (can be found in Conceptronic sources) gives some hints but I haven't understood it yet. Anyway, that's what I'm working on now.
I've also worked on trying to understand the wifi. When you disable the DvdPlayer from starting up, it doesn't mount the media partition or link the media drive to /tmp/hddmedia. It also doesn't configure the network/netmask and gateway for the wired or wireless connection.
At the beginning of the rcS file in the /usr/local/etc is the instructions for doing the network config, so I just adapted it for mine and added drive mounting and linking.
ifconfig eth0 192.168.0.2 netmask 255.255.0.0
route add default gw 192.168.0.1
mount /dev/ide/host0/bus0/target0/lun0/part4 /usr/local/etc/dvdplayer/hdd/volumes/HDD1
ln -s /usr/local/etc/dvdplayer/hdd/volumes/HDD1 /tmp/hddmedia
And of course I took out the RootApp DvdPlayer command so that it wouldn't activate the DvdPlayer. This has left two things for me to solve. #1) How to control the blue light. It continues to flash after booting, and the bootscreen stays up. Well, the HelloWorld can take care of the bootscreen, but figuring out what controls that power light has been more difficult. #2) Wifi does not get set up.
First run
/usr/local/etc/dvdplayer/script/run_tail
which installs the ehci-hcd and ohci-hcd modules using modprobe.
I think it also needs:
/sbin/modprobe ieee80211-rtl
/sbin/modprobe ieee80211_crypt
I found this info in the Main DvdPlayer as well:
/bin/echo nameserver 127.0.0.1 >> /etc/resolv.conf
ifconfig wlan0 up
wpa_supplicant -P/var/lock/wpa_supplicant.pid -D ipw -c /tmp/net/wpa.conf -i wlan0 -B
wpa_cli -p /tmp/net/wpa_supplicant status > /tmp/net/WPA.STATUS;touch /tmp/net/WPA.OK
The /tmp/net/wpa.conf file is added when DvdPlayer runs, but it looks something like this:
ctrl_interface=/tmp/net/wpa_supplicant
ctrl_interface_group=root
network={
ssid="MySSId"
proto=WPA RSN
key_mgmt=WPA-PSK
pairwise=TKIP CCMP
group=TKIP CCMP
psk="your wifi passphrase"
}
I've extracted information and found a webpage about setting up which has helped.
http://wiki.archlinux.org/index.php/WPA_supplicant
But I'm actually stuck at ifconfig wlan0 up. wlan0 isn't there. The light doesn't come on in the wifi adapter so I think the port needs to activate power or recognize the device or something similar. NetworkSet.cpp (can be found in Conceptronic sources) gives some hints but I haven't understood it yet. Anyway, that's what I'm working on now.
Subscribe to:
Posts (Atom)