Related
I have seen other methods of removing the gesture or pattern lock but with this method you can remove the lock temporaley and apply it again without knowing the key.
Check it out here http://sud0x3.net/?p=5
What... you mean this: http://forum.xda-developers.com/showthread.php?t=536352
???
Nice find, just a little late.
lbcoder said:
What... you mean this: http://forum.xda-developers.com/showthread.php?t=536352
???
Nice find, just a little late.
Click to expand...
Click to collapse
I did do a few searches, but only found the method that changes settings in the sqlite3 database.
Suppose the method of recovering the pattern from gesture.key file is on here somewhere too then.
sud0x3 said:
I did do a few searches, but only found the method that changes settings in the sqlite3 database.
Suppose the method of recovering the pattern from gesture.key file is on here somewhere too then.
Click to expand...
Click to collapse
As far as I know, it is encrypted.
However, should be fairly easy to brute force given the low number of possible combinations.
lbcoder said:
As far as I know, it is encrypted.
However, should be fairly easy to brute force given the low number of possible combinations.
Click to expand...
Click to collapse
There are a lot of combinations and im not sure how you would go about brute-forcing it, unless you mean by making a comparison list of common gestures then referencing it.
sud0x3 said:
There are a lot of combinations and im not sure how you would go about brute-forcing it, unless you mean by making a comparison list of common gestures then referencing it.
Click to expand...
Click to collapse
This research could be of use but i cant get it to work yet http://moshe.nl/android/
My idea was to hex a load of key files, store them in a db and then compare. But this guy may have really cracked it.
sud0x3 said:
There are a lot of combinations and im not sure how you would go about brute-forcing it, unless you mean by making a comparison list of common gestures then referencing it.
Click to expand...
Click to collapse
Think about it;
There are precisely 9 points. You can't cross a point more than once, and each point you connect to has to be adjacent to the previous one. Each gesture can therefore be mapped to a tree, which you can traverse recursively until the proper pattern has been identified. You identify the proper pattern by encrypting the current pattern using the same encryption used by the phone (which we have source for and therefore KNOW), and comparing that against the contents of gesture.key.
Implementation:
We number each point 1 through 9.
From each point, you can go on to specific "next" points, which include all the adjacent points to that point except for any point that has already been traversed. You recursively test each of the possible next points until all possibilities are exhausted.
Lets say that point 1 is the upper left, counting across (3 is upper right), and then down (4 is below 1), etc.
Your function will basically do this (pseudocode):
Code:
boolean test(gesture_list){
if (encrypt(gesture_list)==gesture.key){
print(gesture_list);
return true;
} else {
for (nextmove in potential_next_moves){
if (test(gesture_list+nextmove)) return true;
}
return false;
}
Do you see how that works?
This is a simple brute force algo for this problem.
The main thing left to you in this is the computation of potential next moves. You can do this manually using a table. The value for potential_next_moves will be the contents of the table MINUS any point that is already within (gesture_list).
I believe that given the small scope of the problem, this will probably take under one second to brute force any key.
What makes this problem much easier for brute forcing is that there are a finite number of possible NEXT values, and this list of possible next values decreases very quickly as the gesture gets longer. For example, when you have 7 spaces filled, there may be AT MOST 2 possible next moves (as few as ZERO -- for example, using this gesture: 1,4,5,6,9,8,7 -- there are no possible next moves from there, so if that gesture doesn't compute, that branch will immediately return false without trying anything further.
Take a more complex brute force.... you have a 512 bit key, then you have 2^512 possible keys to test. Thats 1.34x10^154 -- an unimaginably big number. Even if your CPU could run 1 key per cycle (which it can't, not even close) at 2GHz, that would take you 6.7x10^144 seconds = 2x10^137 years!!! http://en.wikipedia.org/wiki/Brute-force_attack
But again, we have the advantage of no repeated numbers and a fixed/finite selection of next_steps.
sud0x3 said:
This research could be of use but i cant get it to work yet http://moshe.nl/android/
My idea was to hex a load of key files, store them in a db and then compare. But this guy may have really cracked it.
Click to expand...
Click to collapse
Ha ha. Yes. Nice find.
He's doing exactly what I said right above.
BTW: It works perfectly.
And as I predicted, takes under a second to compute.
You will note one thing about it though; if you throw in random data, it will calculate a gesture that is impossible. This is because he is ignoring one of the characteristics that I mentioned: adjacency! It would be much more efficient if he included this characteristic.
lbcoder said:
Ha ha. Yes. Nice find.
He's doing exactly what I said right above.
BTW: It works perfectly.
And as I predicted, takes under a second to compute.
You will note one thing about it though; if you throw in random data, it will calculate a gesture that is impossible. This is because he is ignoring one of the characteristics that I mentioned: adjacency! It would be much more efficient if he included this characteristic.
Click to expand...
Click to collapse
If i were to write something to recover the gesture i would probably either md5 the keyfile or the hexcode then generate a kind of rainbow table list.
example
md5:1234
md5:2345
md5:5321
Then you could compare md5 hashes to find the correct key. This would eliminate the problems in the script above.
lbcoder said:
Think about it;
There are precisely 9 points. You can't cross a point more than once, and each point you connect to has to be adjacent to the previous one.
Click to expand...
Click to collapse
You can cross a point more than once, I do it in my unlock.
While poking around today, I discovered that I could deterministically cause "rild" to segfault - every time I tried it.
The method I used was to turn on WiFi with the Mobile Data network already running, and then I would launch the app "Wifi Analyzer" (farproc). Almost immediately the "rild" (Radio Interface Layer Daemon) would segfault. (Strictly speaking, I don't know if using WiFi Analyzer was necessary - my WiFi has beacons turned off, and sometimes I can't establish a session straight away; using a scanner seems to get my AP to come out of it's sleep).
That consistency convinced me to use strace to attach to the already-running "rild" daemon, and spew to a log file.
Note that historically, the SIGSEGV faults that were logged to the logcat output at the moment of the "undead call" implicated a problem in the fclose() call - almost as if something was trying to close a file that had not been opened correctly.
So, there in the strace output, was this:
Code:
16:43:23 writev(6, [{"\3", 1}, {"HTC_RIL\0", 8}, {"(t=1297817003)%% $HTC_3GIND:0\\r\\n\0", 35}], 3) = 44
16:43:23 open("/data/data/com.android.dmportread/history", O_WRONLY|O_CREAT|O_APPEND, 0666) = -1 ENOENT (No such file or directory)
16:43:23 chmod("/data/data/com.android.dmportread/history", 0666) = -1 ENOENT (No such file or directory)
16:43:23 writev(6, [{"\3", 1}, {"HTC_RIL\0", 8}, {"at_notify_cdma_g23_data_entry():Can't open /data/data/com.android.dmportread/history successfully \r\n\n\0",102}], 3) = 111
16:43:23 --- SIGSEGV (Segmentation fault) @ 0 (c) ---
a quick peek at /system/lib/libhtc_ril.so shows that - yep - buried in there is a reference to
/data/data/com.android.dmportread/history
So, I tried the following:
Code:
[COLOR=green][B]
mkdir /data/data/com.android.dmportread
chown radio:radio /data/data/com.android.dmportread
touch /data/data/com.android.dmportread/history
chown radio:radio /data/data/com.android.dmportread/history
[/B][/COLOR]
and guess what - no more segfaults. [SIZE=+3]YES![/SIZE]
If this is the cause of the "undead" call (seems highly likely), the explanation appears to be due to a bug in the HTC vendor library lbhtc_ril.so : a file open() fails, but the corresponding "close()" operation takes place anyway, and that is where the fault (segmentation violation) occurs. There is a stupid dependency of the libhtc_ril.so file on the DMPortRead.apk app.
Probably the only reason that this bug does not express itself in HTC "factory" 2.1 ROMs is because of the presence of DMPortRead.apk app - presumably that creates/maintains the history file.
[SIZE=+1]See the 3rd post of this thread for downloadable patch/script files[/SIZE]
If any of you are consistently experiencing the "undead call" problem, please consider testing the above to see if you think it is the fix. (I believe it is.)
bftb0
I knew I liked you!
I'll have to try this out when I get home.
Here's a flashable .zip and also a shell script which may be used in Gscript lite - you need to unpack the "unpackme.zip" file to get to them. ("unpackme" is NOT flashable).
I realized after I was 95% of the way through putting together the installer script that there was absolutely no reason to do this in an offline fashion (that is, "overflashing" it during a recovery boot) - it is perfectly fine to do what needs to be done in a shell script any time you please with the regular OS is running. Oh well, the ROM devs can look at it and use whatever they want from it (or nothing at all).
You can run the CureUndead_v0.9.sh script either from within the Gscript Lite app (you need to give the script root privilege), or you could use adb to push it to /data/local and chmod it and execute it by hand. Note that Gscript Lite on GingerBread has this annoying bug where it prints "stderr:" for every line in the original script. It's not my script that's doing that - it's either a problem with Gscript Lite, or something unusual about GSB.
Oh, yeah - the way the script is written, you can run it as many times as you want; as a side effect, this will truncate to zero length any prior history file.
MD5's and sizes of contents of "unpackme.zip":
0bf8c49312e61c436d379a24255b12f3 CureUndead_v0.9.sh - 421 bytes
9d459f9f598f51fffa98cf832c524e50 CureUndead_v0.9.zip - 2,678 bytes (this one is flashable)
Going to try it out... Thanks for this!
nice work...
Very interesting... so this is something that would need to be done post flash, what do you think...
... we use that lights.sh script conap put together in /system/xbin/ that runs @ every boot to initialize the lights for trackball/notifications... would it work if I added the lines to that? I'm not sure if it would cause issues running it @ each boot or not?
Trying to figure out a different way to add this pre-build too.
This is huge if it's the fix. Incredible work.
oceanminded said:
This is huge if it's the fix. Incredible work.
Click to expand...
Click to collapse
I think it is the fix
workshed said:
Very interesting... so this is something that would need to be done post flash, what do you think...
... we use that lights.sh script conap put together in /system/xbin/ that runs @ every boot to initialize the lights for trackball/notifications... would it work if I added the lines to that? I'm not sure if it would cause issues running it @ each boot or not?
Trying to figure out a different way to add this pre-build too.
Click to expand...
Click to collapse
Well, I'm putting together a flashable "fix" file that just uses the installer script, so it could be rolled up into a ROM install as well.
The one thing you might want at boot (rather than only at ROM install time) is some kind of zero-ing out of the history file every once in a while, so that it doesn't grow without bound. I only watched it for a short period of time, and it was only 4 lines long; it might not ever grow big, but that seems like the right thing to do.
So I guess I'll wait until one of you genuises makes this "point and click" simple. I don't have a clue how to implement this on my own. Awesome work bftb0 !
Sheesh you're a brain OP. Awesome job!
Sent from my Ginger Tazz using XDA App
Interesting... what's the undead call bug you're talking about? I've been getting this funny bug on long calls where sometimes the phone app just crashes after 15-30mins or so. I get the crash window, and if I force quit, it shows no signal until I reboot the phone. If that's the one, a fix would be really nice. Running KaosFroyo v39 and never flashed a new radio BTW.
I've also seen the same thing on the WiFi signal. I have SSID broadcast turned off, and it takes it's sweet time picking it up on its own, but running WiFi analyzer seems to wake it up.
ufmace said:
Interesting... what's the undead call bug you're talking about? I've been getting this funny bug on long calls where sometimes the phone app just crashes after 15-30mins or so. I get the crash window, and if I force quit, it shows no signal until I reboot the phone. If that's the one, a fix would be really nice. Running KaosFroyo v39 and never flashed a new radio BTW.
I've also seen the same thing on the WiFi signal. I have SSID broadcast turned off, and it takes it's sweet time picking it up on its own, but running WiFi analyzer seems to wake it up.
Click to expand...
Click to collapse
What he is referring to is during a call you get the tones and vibration like the call has been dropped but then you can hear the person on the other end again and the call was never dropped. What you are describing is a new one to me...
CondemnedSoul said:
What he is referring to is during a call you get the tones and vibration like the call has been dropped but then you can hear the person on the other end again and the call was never dropped. What you are describing is a new one to me...
Click to expand...
Click to collapse
Ah yeah, I've had that happen too. I didn't think of it, though, since it wasn't all that annoying to me. I already ran the fix anyways, so I'll see if it helps either problem.
I haven't had the problem for some reason, but I just entered all that in a terminal window on my phone (and wasn't that tedious). Thanks!
Scott586 said:
So I guess I'll wait until one of you genuises makes this "point and click" simple. I don't have a clue how to implement this on my own. Awesome work bftb0 !
Click to expand...
Click to collapse
I put up a script in the 3rd post in this thread which you could use in the Gscript Lite app. You will still need to figure out how to use Gscript Lite, but at least no "adb" or command-prompt typing is needed.
Everybody else - I would appreciate hearing back from you after you try this, especially if you have been experiencing the "undead call" bug frequently. (I've used my phone for calling so little recently I don't think it has happened to me in more than 5 weeks.) The more often it was happening to you in the past, the more valuable your feedback is now.
bftb0
bftb0 said:
I put up a script in the 3rd post in this thread which you could use in the Gscript Lite app. You will still need to figure out how to use Gscript Lite, but at least no "adb" or command-prompt typing is needed.
Everybody else - I would appreciate hearing back from you after you try this, especially if you have been experiencing the "undead call" bug frequently. (I've used my phone for calling so little recently I don't think it has happened to me in more than 5 weeks.) The more often it was happening to you in the past, the more valuable your feedback is now.
bftb0
Click to expand...
Click to collapse
thanks for the script bf, that's all I needed to add it in the rom. I'll be a tester also, as I do experience the bug quite often, but only on long calls which isn't as frequent for me currently. Bravo sir!
P.S. I will be sure to add "# Undead call fix by bftb0" in the rom and OP page
workshed said:
thanks for the script bf, that's all I needed to add it in the rom. I'll be a tester also, as I do experience the bug quite often, but only on long calls which isn't as frequent for me currently. Bravo sir!
P.S. I will be sure to add "# Undead call fix by bftb0" in the rom and OP page
Click to expand...
Click to collapse
dope
this is good news. great job op and workshed if u add it to your gb rom lol
love you both!
flashed it on gsb1.4. i'll let you know how it goes.
:O OMG! That always happens, but I thought I was crazy XD So I'm going to try this.
Sent from my Droid Eris ♥ (running Ginger Tazz v5 [eat your heart out Jobs])
So, I'm running MDJ's CM7 2.6. I've fixed almost any issue I've had. But there's something really annoying me, my g sensor has a small offset. And as far as I know there is no built in calibration tool. I've tried some I found in the market, but those didn't work, still an offset. I was reading a lot and found AngelDeath's thread about a possible fix. http://forum.xda-developers.com/showthread.php?t=902129
But this is only for Froyo. So I was asking myself if there is any possible solution for Gingerbread?
And if possible, would you mind to add your AK8973Prms.txt? It can be found under /data/misc. Maybe this is a possible solution..
Edit: Please only if you have 2.3
Thx anyway
Cheers
The g-sensor from what I know has been fixed since I posted about the fix, the first question I have for you is what kernel are you using? I know that MDJ had removed the calibration setting from most of his roms, I dont know if this rom he did also, but when you say there is a offset, can you explain what type of offset and also if you compensated for the slight angle that the phone has due to the camera?
Frm what I read in another thread, the ak8973prms.txt values can be altered, and saved. also you can delete this file and upon reboot I believe it gets recreated..Also did you happen to backup your bma150_usr file and try adding mine in place? Or is that whats giving you the small offset?
http://forum.xda-developers.com/showthread.php?t=803242
This thread has info about the offset. It's a little old but offset adjustment still works. (freeze was fixed in kernel)
AngelDeath said:
The g-sensor from what I know has been fixed since I posted about the fix, the first question I have for you is what kernel are you using? I know that MDJ had removed the calibration setting from most of his roms, I dont know if this rom he did also, but when you say there is a offset, can you explain what type of offset and also if you compensated for the slight angle that the phone has due to the camera?
Frm what I read in another thread, the ak8973prms.txt values can be altered, and saved. also you can delete this file and upon reboot I believe it gets recreated..Also did you happen to backup your bma150_usr file and try adding mine in place? Or is that whats giving you the small offset?
Click to expand...
Click to collapse
Thanks for your reply
I'm using the stock MDJ 10.4. And he did, I'm pretty sure.
Well when I am playing for example doodle jump I have to tilt my phone to the right, right side to the floor (not very easy to explain, hope you know what I mean ) otherwise, if I hold my phone normal this doodle thing always jump to the left. It's not very much, but it is annoying..
Yes, that was already told somewhere, but in fact i dunno what values should be in there. It gets recreated, but if I am not wrong it will be wrong again.
Haha, I've read your thread, my problem is that such a file doesn't even exist, so I was not sure if I it is a good idea to just copy it in there.
memin1857 said:
http://forum.xda-developers.com/showthread.php?t=803242
This thread has info about the offset. It's a little old but offset adjustment still works. (freeze was fixed in kernel)
Click to expand...
Click to collapse
Well, I've tried.. but it seems not to work, still this f***in offset
Thanks anyway
Obviously you would know this but if your phone isnt rooted I dont think you will see it, its located in data/misc
Here is the contents of my file, unzip it and use a root explorer and go to data/misc and drop this in, let me know if it works, if not I have another idea for you Guaranteed to work
AngelDeath said:
Obviously you would know this but if your phone isnt rooted I dont think you will see it, its located in data/misc
Here is the contents of my file, unzip it and use a root explorer and go to data/misc and drop this in, let me know if it works, if not I have another idea for you Guaranteed to work
Click to expand...
Click to collapse
I think you have to tell me your other idea
Download GPS Status from Market (Its free), hit the home key then tools then pick calibrate pitch and roll. See what that does for you.
AngelDeath said:
Download GPS Status from Market (Its free), hit the home key then tools then pick calibrate pitch and roll. See what that does for you.
Click to expand...
Click to collapse
I gave up, even your second idea didn't work. I think I have to live with this annoying offset. I could try to change the kernel, but afaik that's no good idea, because everytime it was working like it should I changed something and boom, eveything was f***ed up again
But thanks for your help mate
Hi,
Have you found a solution to this, or am I too late? I seem to be having the same problem on an otherwise fast and stable build. I'm using TyphooN CyanogenMod 7 v3.7.0
For the info, the parameters and some values in the said file are completely different, so I don't know if I should replace them.
Thanks,
jk
okay, so apparently SCEF02 FW users r stuck with video recording fps drop when recording in low light conditions (and no official solution from samsung yet)
more about the problem here:
http://forum.xda-developers.com/showthread.php?t=1443658
the only FW that seems to fix the problem is the SIEG03, which indicates that the problem is software related and CAN be fixed
however it disables flash in video recording mode & LED torch
so can't the devs figure a way to edit SIEG03 firmware to give us flash support?
links that may help (thanks bartekaki for providing it):
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
personally, I'll pay 10$ if it happens (or more if necessary)
who else???
you copied the link from my post wrong way and it doesn't work:
correct is:
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
suzaku said:
https://github.com/GalaxySII/samsung...a/video/m5mo.c
Click to expand...
Click to collapse
Dude, you can't even copy/paste links from others's posts...
I'll chip another 10$.
As much as I love the idea, I think having the source for the phone SIEGE03 comes from also might help. Because the hooks for flash would have to be cross referenced and switched over to properly work (If it is that simple.)
bartekaki said:
you copied the link from my post wrong way and it doesn't work:
correct is:
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
Click to expand...
Click to collapse
thx man
radkor said:
Dude, you can't even copy/paste links from others's posts...
Click to expand...
Click to collapse
I thought that since I linked to the original whole thread then it's ok...sorry I'll fix it
karendar said:
As much as I love the idea, I think having the source for the phone SIEGE03 comes from also might help. Because the hooks for flash would have to be cross referenced and switched over to properly work (If it is that simple.)
Click to expand...
Click to collapse
this FW came from the I997 (infuse 4G), and this phone already has flash so I think it's possible
what do u mean by source? sorry I'm a newb
suzaku said:
this FW came from the I997 (infuse 4G), and this phone already has flash so I think it's possible
what do u mean by source? sorry I'm a newb
Click to expand...
Click to collapse
SIEGE03 is a firmware. This firmware is required to run the camera... To access the camera functions, we need a driver. This driver is compiled from source code which is what the link above is...
What probably happened here is that the Infuse uses the same camera module and interface. The flash though might use a different register or address scheme in the source code of the Galaxy S2 to interface with the firmware. So someone would have to figure out the difference between the m5mo.c source code from the Galaxy S2 and the I997 to see if it can be fixed through driver. Otherwise we'd have to reverse engineer the firmware which is too much energy wasted.
The problem with this method is that we'll need to compile a new version of the camera driver. And that, I am not the person to do it.
Another solution would be to pull the camera driver from a stock I997's ROM and overwrite it on our phone to see if it works.
I got a galaxy s2 here last friday (coming from a htc desire), and this week i got around to using the camcorder function. Immediately noticed the stutter issue, checked the forums and the current firmware situation, and switched out my SCEF02 for the SIEG01. Of course it fixed the stutter but broke the flashlight, so i spent an evening looking into fixing it. Here's how far i got...
The firmware binary
First of all the SIEG01 firmware binary itself. I did a hex compare with SCEF02 and there are so many differences (hundreds when set to 16 byte difference comparison) it'd be almost impossible to find the incorrect memory address for the flashlight function control (at least in my limited ability).
Next up i tried looking for seperate sections within the firmware to frankenstein a fix. There was only one certain boundary i found with an identical address, that's around the 166FF area, where both files are padded with FF's to the same position (following is ASCII denoting the firmware version). That's a pretty clear indicator that it's a seperate part of the rom, so, i switched out the bottom half of SCEF02 into SIEG01. The result was no stutters, no flashlight. Likewise replacing the bottom half of SCEF02 with that of SIEG01 resulted in stutters and a working flashlight.
So in short, regarding the firmware itself, the section controlling the flashlight function is somewhere before 166FF in the binary. Everything in that first half of the firmware is reasonably similar between the two firmwares, but not identical. Mostly it's single byte changes (probably just the same variables stored in different addresses), and most of the similar sections are offset by roughly a word of data or more. I didn't spend hours looking through to discover where the extra words of data crept in though.
The driver
You could spend weeks tinkering with values within the first 1300KB of the binary trying to find the flashlight section alone, never mind the specific variable/register for the flashlight mode itself, so i moved on to checking the right values were being set by the driver (m5m0.c).
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
the relevant function appears to be m5mo_set_flash on line 858, and the function works pretty simply. First there's a case switch to set the values of two variables called flash and light which will be sent to the firmware. The final case is the one for the flashlight function, and needs flash to be -1 and light to 0x03:
Code:
case FLASH_MODE_TORCH:
light = 0x03;
flash = -1;
break;
If flash is less than 1 then no control command is sent to the firmware for the flash, so we can disregard that (i think). That just leaves the light function. i'll just quote the code here:
Code:
m5mo_writeb(sd, M5MO_CATEGORY_CAPPARM,
M5MO_CAPPARM_LIGHT_CTRL, light);
m5mo_writeb is the function sending (writing) the command to the firmware, sd i believe is the device itself, M5MO_CATEGORY_CAPPARM and M5MO_CAPPARM_LIGHT_CTRL are describing where to send the value of light to, on the device. I think it's safe to say M5MO_CATEGORY_CAPPARM is correct since the flash works fine and the same constant is used for the flash control code directly below the light code. It's also used for a bunch of other functions such as capture size etc.
In C code, variables that're defined in all uppercase are usually constants, so you need to go into m5m0.h to find the value for M5MO_CAPPARM_LIGHT_CTRL. line 272 will show you "#define M5MO_CAPPARM_LIGHT_CTRL 0x40". For the sake of being sure, line 180 also has "#define M5MO_CATEGORY_CAPPARM 0x0B".
Time to check out the Infuse source code and compare...
https://github.com/Entropy512/linux_kernel_sgh-i997r/tree/master/drivers/media/video
first of all m5m0.c, line 1411 you'll find m5m0_set_flash. The layout of the function is slightly different, it's still a switch case, but instead of using temporary variables to hold the values to send the flash and light, the values are just sent within the cases themselves. Anyhow, the light control section:
Code:
case FLASH_MODE_TORCH:
err = m5mo_writeb(client, M5MO_CATEGORY_CAPPARM, M5MO_CAPPARM_LIGHT_CTRL, 0x03);
CHECK_ERR(err);
break;
Again no command is sent to the flash, only the torch, and that value is 0x03 again. The same function and arguments are being sent as with the i9100 code earlier, so all that's left is to check the constants being used. Time to hop to m5mo.h for the infuse.
Line 183 "#define M5MO_CATEGORY_CAPPARM 0x0B" matches our i9100 driver. Line 282 "#define M5MO_CAPPARM_LIGHT_CTRL 0x40" matches our i9100.
Now there are some differences between the m5m0_set_flash functions and also in the m5m0_writeb functions for the two devices, but the values they're using to control the light are the same in both cases.
One thing of interest is that the infuse doesn't support autoflash which is light 0x04 and flash -1. However if you hook up the phone to your pc, run ADB and use the camcorder in low light or any flashlight apps, you can use dmesg to verify 0x03 is being sent, as the dmesg output will contain "m5m0_set_flash: E, value 0x03".
Essentially i think this rules out it being a driver issue. I mean i could be wrong, but it looks like the flashlight control values are identical for both devices. It seems like the issue is within the first section of the firmware binary, somewhere.
Hopefully this is of some use to anyone looking into a fix for the SIEG01 flashlight problem.
Thanks for share your investigation Myshkinbob. Very interesting.
I do believe is an "easy" firmware fix too.
As you did, i compared both firmwares binaries and took the hope for finding the flash part in the code. Without a reference there is too many unknown data for a trial and error. I mean i tried to copy-paste some code differences in the firmwares but no succes.
Since nothing looks broken i will keep trying...
It'd be good to get SGS II simulator on Windows. Without it, it's PITA to load every time APK into phone and reboot it to test one variable lol
Something occured to me this morning, that might help if people are trying to hex edit the firmware binary to fix the flashlight.
Rather than messing with SIEG01 trying to enable the flashlight, you could get far more success editing SCEF02 to disable the flashlight. How so?
Well it's common sense that it's far easier to break something than to fix it.
Apply that logic to this firmware, it's a lot easier to replace a specific working value with a random wrong value, than it is to replace a specific wrong value with a specific working value.
What i mean is it'll be a lot easier to break the working flashlight in SCEF02 than guess the right value for SIEG01. Once you break SCEF02 you'll know where the flashlight control values are in the firmware, and from there you can attempt to insert them into SIEG01.
By FF'ing out small sections of the SCEF02 firmware prior to the boundary section around the 16000 offset, testing the firmware on the phone, then repeating, you could eventually get to where you break the flashlight for it. I'd suggest working back from the face detection copyright notice at the beginning of that 16000 boundary.
Once you break the flashlight in SCEF02, you've just identified which part of the firmware controls the flashlight.
From there it'd just be a matter of locating that similar section within SIEG01, and further narrowing down the specific values(s) that need correcting.
I'm not saying it'd be guaranteed to work, but it'd be an approach worth trying if people are already attempting random hex edits on the firmware.
I guess the success of it depends on the structure of the binary, whether it's a raw assembly code executable image referencing memory and register addresses, or some sort of packed OS image that is expanded and then runs on the camera chip with it's own driver embedded into it for the flashlight.
wish i could help somehow...
Myshkinbob said:
Something occured to me this morning, that might help if people are trying to hex edit the firmware binary to fix the flashlight.
Rather than messing with SIEG01 trying to enable the flashlight, you could get far more success editing SCEF02 to disable the flashlight. How so?
Well it's common sense that it's far easier to break something than to fix it.
Apply that logic to this firmware, it's a lot easier to replace a specific working value with a random wrong value, than it is to replace a specific wrong value with a specific working value.
What i mean is it'll be a lot easier to break the working flashlight in SCEF02 than guess the right value for SIEG01. Once you break SCEF02 you'll know where the flashlight control values are in the firmware, and from there you can attempt to insert them into SIEG01.
By FF'ing out small sections of the SCEF02 firmware prior to the boundary section around the 16000 offset, testing the firmware on the phone, then repeating, you could eventually get to where you break the flashlight for it. I'd suggest working back from the face detection copyright notice at the beginning of that 16000 boundary.
Once you break the flashlight in SCEF02, you've just identified which part of the firmware controls the flashlight.
From there it'd just be a matter of locating that similar section within SIEG01, and further narrowing down the specific values(s) that need correcting.
I'm not saying it'd be guaranteed to work, but it'd be an approach worth trying if people are already attempting random hex edits on the firmware.
I guess the success of it depends on the structure of the binary, whether it's a raw assembly code executable image referencing memory and register addresses, or some sort of packed OS image that is expanded and then runs on the camera chip with it's own driver embedded into it for the flashlight.
Click to expand...
Click to collapse
interesting approach indeed
it'll be a lot easier to break the working flash on SCEF02, problem is, it's gonna take a lot of time since it's based purely on trial and error
suzaku said:
interesting approach indeed
it'll be a lot easier to break the working flash on SCEF02, problem is, it's gonna take a lot of time since it's based purely on trial and error
Click to expand...
Click to collapse
I'm pretty sure that's how samsung codes anyway, we're just lending them a hand in doing so. haha
how's it going guys? any news?
wish I could help but I'm a complete noob
just thought id bump the thread to get some attention...
btw, does the firmware actually improve camera quality? for pics that is...
blunted09 said:
just thought id bump the thread to get some attention...
btw, does the firmware actually improve camera quality? for pics that is...
Click to expand...
Click to collapse
Well this firmware really improves the overall quality of the pics but in shooting vids it really shines. Only thing so far missing is flash light during video capturing.
I would have moved to SIEG03 if it had had support of LED
me too, flashlight is a little bit to important for me
Ok people, after scrolling from forum to forum looking for a way to edit my build.prop for better data performance I've come to a couple of conclusions........The main one is that the majority of people end up bricking their phones. Either from being noobs or even a developer simply forgetting to change permissions. The other is that pretty much ALL of the lines people say to edit or even add just simply do not work. I'm posting a method I found in a forum,I can't remember which one but it's the one I use and have found to be the most helpful in getting a better signal.
You must be rooted!!!
First download an app from the play store called #SHORTCUT MASTER#
https://play.google.com/store/apps/details?id=org.vndnguyen.shortcutmaster.lite
This app let's you access the G3's hidden hidden menu. You can scroll into numerous hidden folders and files. Some I wouldn't mess with!!! Open the app and go to the settings within the app. Click on "Secret Code Explorer". Scroll down until you see this folder below..........
""""33233323 com.lge.hiddenmenu .ErrFatalErrFatalBroadcastReciever""""" CLICK ON THIS!!!!
Scroll down until you pass a couple "Rat_Selection" folders. I believe you want the third but incase I have placed some screenshots below to help out. Rat_Selection let's you instantly switch from 2G, 3G, 4G, LTE depending on your coverage area. Not sure about which coverage area you are in? Here's another useful app that allows you to check ALL CARRIERS COVERAGE AND ALL NETWORK SPEEDS to help you get some Info about what speed you should switch to if any.
Download "Open Signal" from the play store.
https://play.google.com/store/apps/details?id=com.staircase3.opensignal
Again check the screenshots if you don't believe me. This app is extremely useful!!! Ok so go ahead and finaggle with these two apps and see if it helps any of you and post some feedback. Good or Bad. Last but not least if you just want to edit your build.prop for whatever reasons here are a few lines I have added to mine just to see if they would help and as of right now I'm not sure if they helped but adding these lines did not brick my phone. Changed permissions rebooted and everything seems fine. As I said I'm not sure if they work but obviously doesn't hurt anything. As of now
ro.ril.gprsclass=34 ---- gprs (edge) speed settings
ro.ril.hsdpa.category=28 ---- HSPA+ Download speed settings by category. Cat 28 is the highest
ro.ril.hsupa.category=7 ---- HSPA+ Upload speed settings by category. Cat 9 is highest, 7 seems to work just fine tho
ro.ril.hsxpa=5 ---- setting to enable hspa+ for the upload and download
#Better signal.
persist.cust.tel.eons=1
PS........
I know I said that changing or adding certain lines don't seem to work but I think "hypothetically" that if you switch to say,3G that maybe adding these lines could help with the DN and UP SPEEDS?? Not sure but just saying
FYI I'm not taking credit for anything just sharing what I've learned. These are not my own edits but found on different forums. If this is a repeat post just go ahead and delete. If this helps anyone please hit the thanks button, if not then please feel free to leave constructive criticism or just plain out bash me......