Database Info

[PATCH][KERNEL] EB13 camera video lag & sports mode FC fix

Attached is a kernel source patch that fixes the EB13 camera video lag and "Sports" scene mode force-close. It's actually the same kernel bug that's responsible for both.
Also attached is an Odin/redbend-flashable, otherwise stock EB13 kernel with this patch applied. It's intended for anyone who wishes to further test the fix and who is familiar with Odin and/or redbend_ua. For others, I'd recommend waiting until one of the custom kernels integrates the patch or until Sprint releases an official update.
I'll update this post in the morning with a workup of the bug (done, see below), since it's a bit interesting/illustrative. And yes, it's very simple and very silly. One of those things that really never should've happened. Thanks to everyone in the solutions thread for providing clues that were instrumental in locating it.
Bug details:
Shortly after the release of EB13 folks reported lag when recording videos, particularly in low light. Although not obviously related at the time, folks also reported that switching to "Sports" scene mode results in a force-closed (and in my experience, renders the screen inoperable as well, sigh). Folks in the solutions thread also reported that (i) these problems are new to EB13, they weren't present in DK28; and (ii) replacing the user-space camera components (app, libraries, etc.) with DK28 versions did not resolve the problems, implying they were likely due to one or more kernel bugs.
Unfortunately we do not have the DK28 source code to compare EB13 against, but at least knowing that these problems weren't present in DK28 helps narrow down the possible bug locations quite dramatically. Furthermore, it's quite likely that this bug was introduced rather recently, as I imagine it would've been caught by internal testing had it been present in say, December.
So with that in mind, I sorted the kernel source files by modification time and started looking for the most recently-changed files that might be relevant to the camera driver. "include/linux/videodev2_samsung.h" was the first hit with a modification date of 2/8, and indeed it's used by the camera driver ("drivers/media/video/victory/ce147.c", itself last modified on 12/1). Again, we don't have DK28 sources for comparison, but fortunately header files typically don't change too significantly and a comparison (diff) against the DI18 version was rather easy to follow.
And yes, a snippet of code stood out right away as rather strange, especially given the cirumstances of the problem:
Code:
enum v4l2_iso_mode {
ISO_AUTO = 0,
ISO_50,
ISO_100,
ISO_200,
ISO_400,
ISO_800,
ISO_1600,
ISO_FIREWORKS, // Added since DI18.
ISO_SPORTS,
ISO_NIGHT,
ISO_MOVIE,
ISO_MAX,
};
For folks less-familiar with C, this code defines an enumerated type, basically a mapping of "descriptive labels" to numeric values; in this case: ISO_AUTO=0 ISO_50=1, ISO_100=2, etc. This enables kernel code to contain descriptive statements like "iso_mode = ISO_200;" instead of the more arbitrary "iso_mode = 3;".
Now, as the above comment (which I added, but the diff points it out) suggests, ISO_FIREWORKS is a new speed that was added to the middle of the enum since DI18. Seasoned C programmers will recognize that, this is often something that leads to trouble. To understand why, compare the "before" and "after" enum mappings:
Code:
Before: After:
ISO_AUTO: 0 ISO_AUTO: 0
ISO_50: 1 ISO_50: 1
ISO_100: 2 ISO_100: 2
ISO_200: 3 ISO_200: 3
ISO_400: 4 ISO_400: 4
ISO_800: 5 ISO_800: 5
ISO_1600: 6 ISO_1600: 6
ISO_SPORTS: 7 ISO_FIREWORKS: 7
ISO_NIGHT: 8 ISO_SPORTS: 8
ISO_MOVIE: 9 ISO_NIGHT: 9
ISO_MOVIE: 10
The addition of ISO_FIREWORDS to the middle of the enum shifts the mapping of any labels below it, in this case ISO_SPORTS, ISO_NIGHT, and ISO_MOVIE. This isn't fatal, but it does mean that all code that uses the enum needs to be recompiled to reflect the new mapping. Often, kernel header files contain data types that are exclusive to the kernel, so any relevant code gets recompiled as part of the process of compiling a kernel.
But as it turns out, the entries in this enum are used in exactly one location (on the Epic anyways) in the kernel: as a case in a switch statement in the camera driver that sets the ISO mode in a camera hardware register. This means, assuming these values are used at all, they must be provided by a user-space library. In other words, the enum mapping is an integral part of the driver API, and not something that can be altered willy-nilly.
So basically, on EB13 when the Camera app goes to record a movie, it sets mode ISO_MOVIE (9), which the kernel interprets as ISO_NIGHT and sends to the camera hardware. Presumably ISO_NIGHT biases picture quality over shutter speed, hence the blurry laggy video when recording. Similarly, ISO_NIGHT => 8 => ISO_SPORTS (which no one noticed), and ISO_SPORTS => 7 => ISO_FIREWORKS. Except ISO_FIREWORKS isn't implemented, so the driver call fails which results in the force close. Oops!
The fix is fairly simple, just remove ISO_FIREWORKS from the enum. This allows the kernel and the user-space libraries to agree on the mapping. And since ISO_FIREWORKS isn't even implemented in the kernel, no harm can possibly come from it.
Finally, as I stated earlier, this is a bug that never should've happened, for two reasons. First, it was introduced into the Epic kernel source tree after DK28. Now, keep in mind that DK28 was effectively a Froyo "release candidate", especially given that it was packaged up as an OTA update and accidentally pushed to some handsets. Any changes made to the kernel post-DK28 should be limited to strict bug fixes only. The addition of ISO_FIREWORKS to the enum is not part of any bug fix (indeed it introduces one), rather one would consider it a "new feature". But "new features" shouldn't creep into stable code trees. This suggests poor code management.
Second, this alteration would've been a non-issue had ISO_FIREWORKS been appended to the end of the enum, just before ISO_MAX (which, presumably just reports the numer of entries in the enum as opposed to describing a particular mode). This would've assiged ISO_FIREWORKS to an unused value, instead of remapping existing values. Adding ISO_FIREWORKS to the middle of the enum is a particularly short-sighted choice, as it immediately renders any code that uses it unnecessarilly incompatible with new kernels. Adding ISO_FIREWORKS to the end preserves backwards compatibility, for free, with absolutely no downsides--why not do that instead?
So, in short, the failure to properly consider both of these issues, as well as the neglect to notice the change, bespeaks of an incompetent moment on the part of Samsung. If the change really was made on 2/8, one can't really blame Sprint for failing to pick it up during last-minute testing. I'm not sure how much this particular bug was a factor in Sprint pulling the EB13 update, but it's pretty embarassing that it made it out there in the first place.
Mirror links (does not require forum login):
epic_camera_fix-EB13.diff
epic_camera_fix-EB13.tar
epic_stock-EB13.tar (for flashing back to the stock EB13 kernel)

Thank you! This will be in the ACS kernel team's kernel.

Excellent, patching up as we speak.
Sent from my SPH-D700 using XDA App

Just wanted to be 3rd
Sent from my SPH-D700 using Tapatalk

Cool, looks good.
Sent from my SPH-D700 using Tapatalk

patching myself too thx will be in Genocide Kernel 0.3a

THANKS! leave it up to xda to do a better job then Samsung lol
Sent from my SPH-D700 using XDA App

Sweet,
tested working perfect. the LSD trails in video are gone and no FC in sports mode. TY so much.

fix worked great! i just released genocide 0.3a with this patch included! thanks again!

Gotta love 1 line fixes

Would like to try this but only have mac os so odin...

Awesome, thanks man!
Sent from my SPH-D700 using XDA App

Noob question.
Do you put this in PDA? Also no need for PIT or modem file right?
Via TapaTalk on Nook Tablet
-Edit-
Okay, used Odin, put patch in PDA with nothing else set. Worked perfectly! Thanks to all!

You sir a genius....thx for this fix!!!

What is sports mode? I can't find it.

Silent25r said:
What is sports mode? I can't find it.
Click to expand...
Click to collapse
Still camera, settings (gear button)>Scene Mode> Sports Before the fix it's an automatic FC

Can't wait to hear the details behind the bug.
Sent from my SPH-D700 using XDA App

This patched worked perfectly on the genocide kernal!! Thanks For Your Hard Work!!
Now Just Waiting For Bonsai!!

The geniuses at XDA strike again! Brilliant! Thanks!

MoCoTerp said:
Noob question.
Do you put this in PDA? Also no need for PIT or modem file right?
Via TapaTalk on Nook Tablet
Click to expand...
Click to collapse
Help please? I've flashed lots of roms but never a kernal like this. i'd like to stay with the stock ROM. Can't find anything on a search. Can someone either post a link or instructions.

GB Vibrant -> Sidekick kernel compile

Just to see what would be involved, I tried modifying Samsung's Vibrant GB kernel source tree, hoping to form a basis for a Sidekick GB tree.
Going on the assumption that the Sidekick was very similar to the Vibrant except where it wasn't, and using the Sidekick Froyo sources as a guideline, I forked off a CONFIG_S5PC110_SIDEKICK_BOARD config option from the existing CONFIG_S5PC110_VIBRANT_BOARD.
Then I tried to bend it back toward being more like the Sidekick Froyo setup.
Then I beat on it repeatedly until I got it to compile.
If none of this makes you feel confident, well, it shouldn't.
I tried to methodically sort out the differences, but I'm pretty sure that the sound driver and GPIO assignments need serious help. Since GPIO is the way the handset's CPU communicates with its peripherals, it probably needs to work right for best results. Or any results.
Anyhoo, you're welcome to see my patches. Sorry, I haven't gotten a github repo set up yet.
https://carbon.flatlan.net/nxd/vibrant-gb-to-sidekick-v001-danger-brick-likely.patch
Also in that directory are my patches to disable the unfortunate keystroke logger Samsung shipped in their GPL source drop. Every custom ROM I've tried has had this keystroke logger. It would be just wonderful if we could eradicate it. Our keystrokes do not need to go into dmesg. But that's a digression.
My willingness exceeds my skill. But perhaps we can organize a project to overcome the obstacles to GB on the SK4G, one by one.

Here's my basic comparison of the Sidekick and Vibrant Froyo trees.
I fetched both sources. Both are KD1 versions.
I did `make distclean` to make sure the trees were empty of build files. Before this would work, I had to create two directories containing empty (zero byte) Makefiles. Samsung had created these directories in the source tree, but removed them before distribution.
drivers/fsr/Makefile
fs/rfs/Makefile
Then I generated sorted lists of the filenames in each source tree:
Code:
cd sidekick-froyo/
find * -type f | sort > ../sidekick_froyo_files.txt
Code:
cd vibrant-froyo/
find * -type f | sort > ../vibrant_froyo_files.txt
Then I diffed the files to see which files existed in one source tree, but not the other:
Code:
diff -u sidekick_froyo_files.txt vibrant_froyo_files.txt > sidekick_froyo_vs_vibrant_froyo_files.txt
I've attached that file.
Note that some files appear different only because of filename case differences, eg all the net/netfilter stuff.

Improving the jailbreak

So, I'm working on a new jailbreak that I hope will be more reliable and faster. I have my DLL injected into csrss.exe and now need to exploit the kernel.
The exploit itself is rather limiting: you can only decrement an aligned dword whose new value will be greater than zero in a signed sense. If you decrement a dword whose value then becomes zero or negative, the kernel will bugcheck (BSOD). Same if you try to decrement an unaligned dword, because the InterlockedDecrement instructions will throw an exception on ARM.
The ultimate goal is to set g_ciEnabled in ntoskrnl.exe to zero. The current jailbreak works by decrementing that dword almost 0x80000 times to lower g_ciEnabled from 8 to 0. However, this is unreliable for several reasons, mostly due to other flags in that same dword.
The other way to accomplish this is to get arbitrary code running in the kernel, then just write to g_ciEnabled directly. This is a lot easier said than done.
Directly attacking function pointers in the kernel or drivers doesn't work. This is because all kernel pointers have their high bit set, and therefore would bugcheck when decremented.
Setting bits in g_CiDeveloperMode in ci.dll would allow loading of kernel drivers signed with a self-signed certificate - this is test signing mode from the desktop Windows. However, this value is zero, and decrementing it to -1 bugchecks due to being negative.
The function pointers in the system service dispatch table are encoded specially, such that they end up not having their high bit set. This makes them interesting targets. However, this table is stored at an unknown runtime address. This address is unknowable to user mode. Also, the ARM kernel has PatchGuard, meaning that changing the SSDT will bugcheck the next time the PatchGuard DPC runs.
Another idea I had is to poke at our trap frame from a second thread, in order to set the saved status register's privilege level to system - to make the kernel return to a kernel thread but in our space. This is problematic because the trap frame is at an unknown address.
A timing attack could be used, where one thread pokes at the kernel stack of another thread while it executes a system call. This has interesting possibilities, but how would we know the address of the kernel stack for a thread?
Getting a handle to \Device\PhysicalMemory would be nice, but difficult. Also, how would we get the physical address of ntoskrnl.exe? The virtual address is easy by comparison.
Just ramblings of my thought process on this. =)

Myriachan said:
So, I'm working on a new jailbreak that I hope will be more reliable and faster. I have my DLL injected into csrss.exe and now need to exploit the kernel.
Click to expand...
Click to collapse
The main speed issue is that something is out of sync for the first 100 seconds or so after booting that causes the kernel call we exploit to crash.
Myriachan said:
The exploit itself is rather limiting: you can only decrement an aligned dword whose new value will be greater than zero in a signed sense. If you decrement a dword whose value then becomes zero or negative, the kernel will bugcheck (BSOD). Same if you try to decrement an unaligned dword, because the InterlockedDecrement instructions will throw an exception on ARM.
The ultimate goal is to set g_ciEnabled in ntoskrnl.exe to zero. The current jailbreak works by decrementing that dword almost 0x80000 times to lower g_ciEnabled from 8 to 0. However, this is unreliable for several reasons, mostly due to other flags in that same dword.
Click to expand...
Click to collapse
I haven't noticed many, if any issues with it doing that (except that we're not editing g_ciEnabled)
Myriachan said:
The other way to accomplish this is to get arbitrary code running in the kernel, then just write to g_ciEnabled directly. This is a lot easier said than done.
Click to expand...
Click to collapse
Especially since g_ciEnabled doesn't exist on ARM.
Myriachan said:
Directly attacking function pointers in the kernel or drivers doesn't work. This is because all kernel pointers have their high bit set, and therefore would bugcheck when decremented.
Click to expand...
Click to collapse
All kernel code is loaded at 0x80000000 or higher.
Myriachan said:
Setting bits in g_CiDeveloperMode in ci.dll would allow loading of kernel drivers signed with a self-signed certificate - this is test signing mode from the desktop Windows. However, this value is zero, and decrementing it to -1 bugchecks due to being negative.
Click to expand...
Click to collapse
I've been trying to do something like that, but I've hit a wall since all the pointers, as you said, have the negative bit set. I wanted to hijack a pointer in the HalDispatchTable.
Myriachan said:
The function pointers in the system service dispatch table are encoded specially, such that they end up not having their high bit set. This makes them interesting targets. However, this table is stored at an unknown runtime address. This address is unknowable to user mode. Also, the ARM kernel has PatchGuard, meaning that changing the SSDT will bugcheck the next time the PatchGuard DPC runs.
Click to expand...
Click to collapse
Again, all kernel code is loaded at 0x80000000 or higher.
Myriachan said:
Another idea I had is to poke at our trap frame from a second thread, in order to set the saved status register's privilege level to system - to make the kernel return to a kernel thread but in our space. This is problematic because the trap frame is at an unknown address.
A timing attack could be used, where one thread pokes at the kernel stack of another thread while it executes a system call. This has interesting possibilities, but how would we know the address of the kernel stack for a thread?
Click to expand...
Click to collapse
Even if you somehow pull that off, how is that going to be better than the current tool?
Myriachan said:
Getting a handle to \Device\PhysicalMemory would be nice, but difficult. Also, how would we get the physical address of ntoskrnl.exe? The virtual address is easy by comparison.
Click to expand...
Click to collapse
A handle to PhysicalMemory can only be opened by ring-0 code.
g_ciEnabled doesn't exist on arm, we're editing an unnamed variable that controls the required signing level (not rather signing is enabled). See clrokr's blog for more information, and read/search through the Hacking Windows RT to run Desktop Apps thread to see that we've tried quite a few of the things you listed.
All the things you suggested are either impossible (with current knowledge, or just flat out impossible), or far more likely to cause issues than the current jailbreak. Also, what stability issues are you having with the current jailbreak? It works 100% of the time for me.

CobaltDebugger

Latest Version 0.5.1 (beta)
What is CobaltDebugger? An ARM Processor Simulator/Emulator/Debugger. At its current state, it reads Android bootloader files, and runs them in a simulator, giving you control over which instructions execute and when. For optimal experience, use this in conjunction with IDA Pro.
Hint: Try setting the PC Register to an interesting address found in IDA.
https://youtu.be/cwvz8Cj70Ac <- newer but still old
https://youtu.be/L5NDob2rCmI <- even older
Unzip contents
Run CobaltDebugger.exe
Load up your aboot.mbn or sbl1.mbn
If you want to display referenced strings, open your binary in IDA, go to View > Subviews > Strings, then copy and paste the contents of the strings window into a new text file, then load that text file into CobaltDebugger.
Memory file will grow to 4GB
Click "Load Binary"
Then click "Step Into" or "Run"
You can
- Set breakpoints by address: use >, and < to define break-ranges
- Alter register values, condition flags, psr modes, instruction sets (ARM and Thumb)
Memory edits are not yet implemented but will most likely come as time permits
Page Up, Page Down, Up, and Down keys can be used to navigate the memory viewer - or you can type an address and click "Go" to go there - There's a bug in here somewhere - I'll get to it
The output from the bottom right window is saved as output.xxxxxx.txt, although the file may not get flushed until you click "Unload" or close the application.
All ARM and Thumb instructions were implemented in C# by hand by me. There may be bugs here and there as this is a work in progress and beta. Not all instructions have been implemented so you may encounter a message that states such and such instruction not implemented. If you see that, let me know which instruction and I will implement it as time permits, or you can wait until the next release. I plan on continuing this project until all instructions are implemented.
Originally built with the binaries from the AT&T Samsung Galaxy Note 3 (NC2) in mind, but focus switched to the Verizon Samsung Galaxy S4 (NK1), then back to Note 3 (OC1). This should work with other similar binaries as well.
I'm hoping this will help us discover new ways to unlock bootloaders. But at the very least it's fun to watch the files run.
Change Log 0.5.1
Added image verification steps thanks to Tal Aloni
Bug fixes
More instructions implemented
Slight redesign
Change Log 0.5
Bug fixes, UI improvements, a few more instructions implemented
Now the "Next" instruction is actually the Next instruction as opposed to the most recently executed instruction, so you can see the instruction highlighted BEFORE it executes.
Change Log 0.4.1
Fixed some bugs
Implemented some more instructions
AT&T Note 3 NC2 aboot runs to completion again, although you may find some instructions I've missed if you start jumping around editing the PC value.
Change Log 0.4
Complete refactor
Verizon S4 NK1 aboot runs to completion, although you may find some instructions I've missed if you start jumping around editing the PC value.
Broke some things with the Note 3 aboot instructions
Change Log v0.3:
set default breakpoint for Verizon S4 aboot - Either it's actually *supposed* to start executing code at 0x880C7000 after an MCR and BX instruction, or I may have mis-coded something, but it seems odd, so a breakpoint is set to 0x88E0E4BC until I can figure that one out.
Output to file - C:\temp\output.HHmmss.asm - Now you can review the log after the program has run.

Subscribed. This is going to be epic.

Taking the trash out then going to have some fun hopefully with this.

Next feature to add is the ability to load and run elf files like tz and sdi

v0.2
I Implemented the SP Minus Immediate instruction, which should resolve the NotImplemented exception reported by @dmt010 . I also implemented a bunch more instructions needed by the S4 aboot, although I'm still not done. I went ahead and uploaded an update anyway. This one doesn't blow up like the first version, but rather displays the missing instruction if it encounters one. To skip to a specific address and start executing code, you can modify the PC register and click Apply Edits, then step or run. Sometimes you have to do it twice for it to take, for some reason. If you want to play around with this with your own abootmbn or sbl1.mbn, feel free to post any Not Implemented messages here so I can add them, just make sure no one else has already posted it. Make sure you copy and paste the whole line including the instruction mnemonic and "Pattern" which will help me to identify the desired encoding.

Instruction [Thumb16,LDRB] not implemented. Pattern: [01111iiiiinnnttt]. Address: [0x88E1C470]
Cheers

I just uploaded v0.3. Now it runs the Verizon S4 aboot file without exception until it gets to a section where keeps incorrectly executing ANDEQ R0, R0, #0x3. I know that's not what it is supposed to do, and that it is a result of BX R14, when R14 is holding 0x880C7000, but 0x880C7000 has only zeros because the s4 aboot is running out of context, isolated. Maybe there is supposed to be code at 0x880C7000, ready and waiting to run. Or maybe there was a calculation error in my code and R14 should not have held the value 0x880C7000. I don't know. I will relook at the preceeding steps and make sure the calculations are correct. Might add a unit test or two. I may need to spend more time looking at the line before the branch (MCR p15, 0, R0,c1,c0, 0) MCR was one of the first instructions I implemented months ago. I may need to re-look at that logic and make sure I did it right...

Cobaltikus said:
I just uploaded v0.3. Now it runs the Verizon S4 aboot file without exception until it gets to a section where keeps incorrectly executing ANDEQ R0, R0, #0x3. I know that's not what it is supposed to do, and that it is a result of BX R14, when R14 is holding 0x880C7000, but 0x880C7000 has only zeros because the s4 aboot is running out of context, isolated. Maybe there is supposed to be code at 0x880C7000, ready and waiting to run. Or maybe there was a calculation error in my code and R14 should not have held the value 0x880C7000. I don't know. I will relook at the preceeding steps and make sure the calculations are correct. Might add a unit test or two. I may need to spend more time looking at the line before the branch (MCR p15, 0, R0,c1,c0, 0) MCR was one of the first instructions I implemented months ago. I may need to re-look at that logic and make sure I did it right...
Click to expand...
Click to collapse
What did I say? Glad I snagged the first post, I knew this project would take off.

It is possible that at some point I will consider sharing my source code to the public. But first I need to look into different licensing steps I should take to make sure that if I do release it, it will remain open source and not be stolen and licensed by someone else, forcing me to take my code down, or something else that could be bad for me. I want to make sure that if I do it, I do it right. Another issue for me is that I like to copy and paste the psuedocode from ARM directly into my code, commented, so I have it for reference. I'm fairly certain I would have to take that out before releasing, so I'm not infringing on ARM's copyright policies. But it would be nice to collaborate. Possibly. Maybe.

Cobaltikus said:
... (MCR p15, 0, R0,c1,c0, 0) MCR was one of the first instructions I implemented months ago. I may need to re-look at that logic and make sure I did it right...
Click to expand...
Click to collapse
Yep. I need to re-implement MCR. I wasn't doing all that needed to be done.

v0.4
v0.4 runs Verizon S4 NK1 aboot to completion, and you can view and modify the active Instruction Set (ARM vs Thumb).

v0.5
v0.5

I got a bit side tracked. Thanks to Tal Aloni, Cobalt Debugger now shows and validates the certificate chain and image signature, which started me down the rabbit hole of potentially cracking RSA. When I come back up for air I'll post my latest changes.

ive been trying to crack that thing for months now! haha join in the telegram again for info and we can collaborate live. from what i understand we're dealing with an RSA-SHA1 sig with PKCS#11 padding

Sorry to be somewhat off-topic, but RSA is a method of encryption. So Samsung/Verizon used this to encrypt the bootloader. So if we can crack it, we have access to the bootloader and can Loki it/ another exploit?
Oh yeah, I subbed. I'm teaching myself python and Java(was already on my to do list) to try and offer limited help.

XxD34THxX said:
Sorry to be somewhat off-topic, but RSA is a method of encryption. So Samsung/Verizon used this to encrypt the bootloader. So if we can crack it, we have access to the bootloader and can Loki it/ another exploit?
Oh yeah, I subbed. I'm teaching myself python and Java(was already on my to do list) to try and offer limited help.
Click to expand...
Click to collapse
can you do much with python on android?

What exactly does this thing do ? I"m a bit confused This is some kind of simulator so that you can see how it impacts memory during execution ? But then again, if it can't access hardware then what's the use ? What does it offer over IDA pro ? I'm confused

Not now. Still on the basics of python. I have python and ide on my pc waiting if you need me to test something.

kcarden said:
ive been trying to crack that thing for months now! haha join in the telegram again for info and we can collaborate live. from what i understand we're dealing with an RSA-SHA1 sig with PKCS#11 padding
Click to expand...
Click to collapse
Ah right, getting now what the use of this is As long as stuff is not done in hardware, which it most likely wont be anyway (cause kernel is not up lol) then this could function as a simulator to debug the bootloader. Makes sense

XxD34THxX said:
Sorry to be somewhat off-topic, but RSA is a method of encryption. So Samsung/Verizon used this to encrypt the bootloader. So if we can crack it, we have access to the bootloader and can Loki it/ another exploit?
Oh yeah, I subbed. I'm teaching myself python and Java(was already on my to do list) to try and offer limited help.
Click to expand...
Click to collapse
i've been looking a lot at recovery.img and the recovery partition. and what happens is the image is encrypted and then signed to be accepted by other software sig checks

[DEV][APP] waut.ch! - Calibration for Android - version 145

Utility for background calibration, curation and tuning of the device towards an intuitive interface.
Subsystems being battery, entropy, encryption, disk, cpu, memory, filesystem, ui, scheduler, and network, all safe and open source technology.
Presented in this educational gaming metric format with infinite feedback and an interestingly assymetric chance. scribble anywhere, check in some stress, or find the 8!
waut.ch! does one hope to receive from this?
Well, increasing degrees and amounts of a certain "Je ne sais quoi" or responsiveness from the user interface for a start. Better battery life perhaps. Better quality of life, maybe.
And waut.ch! can only perhaps be described as "A qualified quantification of the placebo effect"
waut.ch! might benefit from this?
In the Android device space:
Designers
Users
Manufacturers
Recyclers
Developers
Compilers
Support personnel
OEMs
The Friendly Neighborhood Nerd/Technician.
“Make the most of yourself....for waut.ch! is all there is of you.” - Ralph Waldo Emerson ( paraphrase )
All along the waut.ch! tower - Bob Dylan
waut.ch! - Sometimes used in some colloquium as "watch!", keen upon reducing the TDP of mobile devices to 1.0 watt!
ARM variants of Android only Donut 1.6+
Please uninstall either Seeder or CrossBreeder prior to using this.
Root recommended, else reactivity metric is interesting and introduces uniqueness into the entropy pool anyway. Metric may demonstrate a certain asymmetry that is expected from predictable human actions. Efforts have been made to remove time seed logic from haveged in order to improve upon encryption and system-wide performance and security.
Also numerous other subsystems require careful calibration to facilitate this process.
Rewritten code, subset of functionality for upstream project - CrossBreeder ( https://forum.xda-developers.com/showthread.php?t=2113150 )
Please feel free to view and analyze source and functionality and report bugs and discuss etc on the XDA forum:
( https://forum.xda-developers.com/android/apps-games/app-waut-ch-calibration-android-t3549967 )
Google Play store:
( https://play.google.com/store/apps/details?id=ch.waut )
Please visit: /data/data/ch.waut/files/bin on the device itself for partial shell source code and XDA Downloads section and Github for full source code.
Reboot at convenience liberally or sparingly to reseed the entropy pool or as is known in common parlance, for good luck!
Thanks.
Havged source code:
https://github.com/Openand-I/haveged
Adhoc Payment URL to support development efforts : https://paypal.me/openand/10
Frappe ( "free-paid" ) same-version to support development efforts : http://waut.ch
Custom haveged source code as used in this piece of software: https://github.com/Openand-I/haveged
=====
Version Name: 59a6333e-9ed9-43f8-8dad-51ed46c17e28
cb.sh: cache pressure - 500
cb_io.sh: read_ahead - 0
cb_io.sh: nr_requests - 0
$ md5sum *.apk
661c30b02b2321300624af98feaa5bad *145-waut.ch.apk
661c30b02b2321300624af98feaa5bad *oi.apk
$ sha256sum *.apk
6d23b8da87dc5516583a55a3203c9f5068ea8fe8765ece489080ef663c8aee15 *145-waut.ch.apk
6d23b8da87dc5516583a55a3203c9f5068ea8fe8765ece489080ef663c8aee15 *oi.apk
https://github.com/Openand-I/haveged
https://github.com/openand-inc/waut.ch
https://forum.xda-developers.com/devdb/project/?id=19218#downloads
https://forum.xda-developers.com/android/general/app-waut-ch-calibration-android-version-t3858365
https://github.com/openand-inc/waut.ch/raw/cb0c60025f86a4fdc4778506e97ee80eb1c00b45/oi.apk
https://github.com/openand-inc/waut.ch/raw/master/145-waut.ch.apk
-------------------------
Recommended:
- ntp: automatic system time update from internet is enabled.
please check the clock and fiddle around with the timezone settings in case of any issues. one may need to set the timezone manually.
then simply run the app to initiate a time sync
the network time sync happens at around 3am. so the time to check is in the morning.
- Please disable mount namespace separation in the superuser app to take advantage of the mount optimisations.
- Reboot once and occasionally to reseed the entropy pool. It's good luck!
- Do ensure that the waut.ch service has started upon reboot. Just run if it doesn't start it automatically!
Note: Please note that the haveged binary in the APK is a static binary and works on both PIE and non-PIE environments. It is also UPX compressed. UPX for Android didn't compile. So UPX for linux was used to compress the executable file. It is an elegant solution as both on disk and in memory space(?) is reduced by 70% per executable. One is welcome to decompress the file using 'upx -d'.
Full source code is provided on Github and build scripts are attached here and on Github.
There is no license required to both install the app or distribute it, both within the developer ROM community or in commercial form. Adhoc payment URL to support development - https://www.paypal.me/openand/10
Again do note that the license to use the APP and source code is free worldwide and irrevocable in full or partial form. All other open source components simply inherit their license. But under no circumstances is any use thereof legally binding or relevant.
--------
Utility for background calibration, curation and tuning of the device towards an intuitive interface.
Subsystems being battery, entropy, encryption, disk, cpu, memory, filesystem, ui, scheduler, and network, all safe and open source technology.
Presented in this metric format with infinite feedback and an interestingly assymetric chance. scribble anywhere, check in some stress, or get lucky for that matter!
-----
ARM variants of Android only Donut 1.6+ ( should even be compatible with the latest ARM Android 9+ )
Please uninstall either Seeder or CrossBreeder prior to using this. And other "mods" or "tweaks".
Root recommended, else reactivity metric is interesting and introduces uniqueness into the entropy pool anyway. Metric may demonstrate a certain asymmetry that is expected from predictable human actions. Efforts have been made to remove time seed logic from haveged in order to improve upon encryption and system-wide performance and security.
Also numerous other subsystems require careful calibration to facilitate this process.
Rewritten code, subset of functionality for upstream project - CrossBreeder ( https://forum.xda-developers.com/showthread.php?t=2113150 )
Please feel free to view and analyze source and functionality and report bugs and discuss etc on the XDA forum:
( https://forum.xda-developers.com/android/apps-games/app-waut-ch-calibration-android-version-t3858365 )
Google Play store:
( https://play.google.com/store/apps/details?id=ch.waut )
Please visit: /data/data/ch.waut/files/bin on the device itself for partial shell source code and XDA Downloads section and Github for full source code.
The app will amongst other maintenance tasks tune sqlite databases regularly and reseed the entropy pool or as is known in common parlance, for good luck!
Thanks.
Payment URL: https://paypal.me/openand/10
XDAevDB Information
waut.ch!, App for all devices (see above for details)
Contributors
idcrisis
Source Code:
[url]https://github.com/Openand-I/haveged[/URL]
[url]https://github.com/openand-inc/waut.ch[/URL]
[url]https://forum.xda-developers.com/devdb/project/?id=19218#downloads[/URL]
Previous Version Information - 144
305bd30f-0c8a-40d8-baf5-330c68f62d51
Status: Stable
Created 2017-01-01
Last Updated 2020-08-18
$ md5sum *.apk
8ea8e8c132a584767a12e394f7975654 *144-waut.ch.apk
8ea8e8c132a584767a12e394f7975654 *oi.apk
$ sha256sum *.apk
4925066a106c83b18ac6e563f03331c56b72777e66973db591c9776d706595e3 *144-waut.ch.apk
4925066a106c83b18ac6e563f03331c56b72777e66973db591c9776d706595e3 *oi.apk
https://github.com/Openand-I/haveged
https://github.com/openand-inc/waut.ch
https://github.com/openand-inc/waut.ch/raw/master/144-waut.ch.apk
https://github.com/openand-inc/waut.ch/raw/f699d3763507ec1f91d82b9ce25c53036b460a9e/oi.apk
-----
Version notes:
haveged: static non upx binary used
cb.sh: lock fixes
Recommended:
- ntp: automatic system time update from internet is enabled.
please check the clock and fiddle around with the timezone settings in case of any issues. one may need to set the timezone manually.
then simply run the app to initiate a time sync
the network time sync happens at around 3am. so the time to check is in the morning.
- Please disable mount namespace separation in the superuser app to take advantage of the mount optimisations.
- Reboot once and occasionally to reseed the entropy pool. It's good luck!
- Do ensure that the waut.ch service has started upon reboot. Just run if it doesn't start it automatically!
Please support development, simply use https://paypal.me/openand/10 or the payment URL.
Or you can simply buy the "frappe" ( free-paid ) version of the app: http://waut.ch

Recommended:
- ntp: automatic system time update from internet is enabled.
please check the clock and fiddle around with the timezone settings in case of any issues. one may need to set the timezone manually.
the network time sync happens at around 3am. so the time to check is in the morning.
- Please disable mount namespace separation in the superuser app to take advantage of the mount optimisations.
- Reboot once and occasionally to reseed the entropy pool. It's good luck!
- Do ensure that the waut.ch service has started upon reboot. Just run if it doesn't start it automatically!

Issues:
- superuser - Please disable mount namespace separation in the superuser app ( for optional but recommended mount options ). Also please revisit the app entry inside the superuser app to ensure the waut.ch service can run on boot unattended. One can see the logs on another day to ensure that the scheduler ran correctly in the night.
- Non root users - User Interface can help in clearing the random device. Please try and obtain root to avail of most features
- Some Samsung users - One is also requested to raise a ticket with Samsung who may be running old PE detection rules that flag any compressed EXE.
- x64 users - Reports are that the binaries run on 64 bit as they are static! Please compile one's variant of the binary if required. Entropy generations removes CPU jitter and hence runs cooler and more secure.
- Intel users - User Interface can help in clearing the random device. Please compile one's variant of the binary if required. Entropy generations removes CPU jitter and hence runs cooler and more secure.
- Maintenance scheduler VACCUUMS and INDEXES "ALL" SQLITE databases. Some folks may not like that. But given that they're no WAL mode anyway, it's a bottleneck worth removing safely.
- There is a concerned effort to state that 32-bit ARM Android Go/One < 1 GB RAM devices are all that's required for long term functioning. Higher no issues.
- Please try and use a heap size of 96MB. Attempts have been made to set heap size dynamic but ideally this should be done in the build.
- Please clear cache or factory reset upon issues to gain at least another year of MTTR ( Mean Time To Recovery ) for each device.
Thank you!

License
License concerns:
haveged - inherited - https://github.com/Openand-I/haveged
busybox - inherited - https://github.com/openand-inc/busybox
- Busybox simple extract, possibly edit the .config file in 'vi' and type 'make'
The requisite tools are installed using:
apt-get install gcc-arm-linux-gnueabi
apt-get install libncurses5-dev
apt-get install gawk
The following is a step in another direction as the 'make' command works perfectly after extraction, but this is provided for posterity:
wget http://busybox.net/downloads/busybox-1.24.1.tar.bz2
tar -xjf busybox-1.24.1.tar.bz2
cd busybox-1.24.1/
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig
At the menu, you can configure BusyBox options. Once configured, you can build BusyBox:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
sqlite3 - inherited - https://github.com/openand-inc/sqlite
waut.ch - 'none', non legally binding, and non legally relevant on a worldwide scale and irrevocable ( derived works are allowed to add their own licenses as long as the import ( meaning ) of the phrase "non legally binding and non legally relevant" is implied throughout ( not required to include text at all )) and does not reflect upon future updates of this software in any manner adversely.

He is back! Welcome back! Looking forward to this great new project! The only thing I might be missing is the dnsmasq filtering, which in my opinion if by far better solution than any kid of firewall/blocker
Sent from my Galaxy Tab 2 3G using Tapatalk

qWantUS said:
He is back! Welcome back! Looking forward to this great new project! The only thing I might be missing is the dnsmasq filtering, which in my opinion if by far better solution than any kid of firewall/blocker
Sent from my Galaxy Tab 2 3G using Tapatalk
Click to expand...
Click to collapse
Mate!
There are some serious issues with DNSMASQ.
- It crashes on wrong syntax of any option. Cannot do for a server.
- Command line syntax changes between original branch, Android and Cyanogen MOD. Not merged.
- Android fork far behind main branch
- Consumes port 53 on server run without sharing interfaces. This is on the Android branch. Main branch has this resolved.
- CPU loop for most Android DNS versions that show up only upon server run, rather than the tethering run. Possibly hijacked open source branch.
- Tethering modifications to Android branch ( command line addons ) not required any more as the main branch has incorporated methods to dynamically change IP addresses on the fly.
- It is probably encumbered by coding standards and export issues with only one developer. It is emblematic of most such over-reused projects.
- Hash table in memory, therefore future block list will use up RAM. Some others have disk based caching.
- Static blocklists are fairly not scalable for 10 years hence. Needs wildcard blocklists.
- DNS cache poisoning/overloading ( leading to denial of service) possible by any process/app.
It is therefore recommended to use either of:
pdnsd
unbound
djbdns
and standalone dhcp clients and servers from the Entware repository. And also these are interesting:
DANE
DNSSEC over TLS
BTW, all Android is encumbered by simple denial of service attack simply by reading from /dev/random by any app.
In order to try and package this into a simplish product, deleting /dev/random was not implemented.

idcrisis said:
Mate!
There are some serious issues with DNSMASQ.
- It crashes on wrong syntax of any option. Cannot do for a server.
- Command line syntax changes between original branch, Android and Cyanogen MOD. Not merged.
- Android fork far behind main branch
- Consumes port 53 on server run without sharing interfaces. This is on the Android branch. Main branch has this resolved.
- CPU loop for most Android DNS versions that show up only upon server run, rather than the tethering run. Possibly hijacked open source branch.
- Tethering modifications to Android branch ( command line addons ) not required any more as the main branch has incorporated methods to dynamically change IP addresses on the fly.
- It is probably encumbered by coding standards and export issues with only one developer. It is emblematic of most such over-reused projects.
- Hash table in memory, therefore future block list will use up RAM. Some others have disk based caching.
- Static blocklists are fairly not scalable for 10 years hence. Needs wildcard blocklists.
- DNS cache poisoning/overloading ( leading to denial of service) possible by any process/app.
It is therefore recommended to use either of:
pdnsd
unbound
djbdns
and standalone dhcp clients and servers from the Entware repository. And also these are interesting:
DANE
DNSSEC over TLS
BTW, all Android is encumbered by simple denial of service attack simply by reading from /dev/random by any app.
In order to try and package this into a simplish product, deleting /dev/random was not implemented.
Click to expand...
Click to collapse
Very comprehensive explanation indeed! I am no expert in Linux, only an average user [emoji6]
I was not aware of so many obstacles using dnasmasq, but aware of it's unreliability while using it for blocking stuff in pfsense. But I must say, I had similar experience with unbound, however, probably due to the lack of linux knowledge.
The way I understand is that host blocking is no longer viable due to scales of blocking required today. But sadly there is no alternative for that on android. I have been trying another tool, called sharkmasq but developer sadly abandoned it, while it seems very unfinished and unreliable. I also understand the reasons behind leaving netfiltering out of your development, just, in desperation, I search for the hope [emoji3]
P. S.
Thank you very much for your reply and for your time putting it together. Nevertheless I will look forward to further developments of this new exciting project!
Sent from my LG-D855 using Tapatalk

Uhm, my device seems more responsive even when I use a very low CPU frequency, but is it normal that the app doesn't ask for root permission even if I'm fully rooted? I'm using a Nexus 5 running Nougat. Thank you
Inviato dal mio Nexus 5 con Tapatalk 2

Hi, yes, part of the design criteria. Without root, the metric is interesting. With root, it will automatically start the background processes including the daily cleanups.
Best way to know that the background processes are running is to install Seeder ( but whatever you do don't start it! . Entropy should show around 4096.

Still in the testing phase, does it worth excluding the app from "android optimisation list"? I also use "power nap", not sure will that cause any side effects...
Sent from my LG-D855 using Tapatalk

Let us know If Seeder has RNGD off and still reports ~ 4096 entropy then all is hunky dory.

The new update asked me for root permission, all right here now

Have been busy lately with life, but had occasionally played with phone. So my findings so far: I use this app on my old galaxy tab 2 3g on slim6. Seeder shows entropy being filled in no time at all. Can't really say much about performance, but it seems that it behaves a little smoother. I also use it on my daily LG G3 on stock MM rom with custom kernel, but seeder is reporting very low entropy, if seeded is left on for 1 minute, I can see that entropy never goes above 900? Goes up slowly but then gets used, and then very slowly goes up again and gets used.
Sent from my LG-D855 using Tapatalk

Reboot once after first install kicks in the animation changes. And good luck
New version uploaded with haveged updates. Build scripts also added.
Feedback solicited about the compiler flags etc. Basically the idea is that the ARM v5 binaries should work for all past and future versions of 32-bit Android without modification.
UPX binary could only be compiled for x86 linux.
To answer question, second device, not running, may need to check su logs
Also backend binaries are 32 bit, may not work on 64 bit. GUI's ok.

I am very confused about the frontend of this app that looks like some number game that I really don't understand . Also, I don't understand the description very well. Finding the 8??? Reboot when animation kicks in? What animation?? Nothing seems to happen. I just see a still of a beach with a red number
But something DID happen though, so I am in business. I will keep you curious for a moment, while firstly giving you a good reason for a hard laugh:
I am trying to revive an LG L3 E400! Yep, that's right . Just for fun and educion. In fact I already succeeded quite a bit. I flashed JellyCast V7rev1, used some stuff from V6 SuperCharger (not entropy thingie coz I already intended to use CrossBreeder for that) and 3 scripts from Fly-On Mod. I came here via the CrossBreeder thread (of course). I have already tried CrossBreeder 7.2.13 (I followed advise from @f3tus here, he advised to use that older version). Entropy went up (so it worked) but I did not experience much performance improvement. I did experience more "not responding" issues though. So I reverted to the pre-CrossBreeder backup. And then came your app.....
So that's a very short summary of the many, many, many hours I spent last 2 weeks on this ancient minimalistic but very adorable phone. Now... back to this Waut.ch! app. Presuming that it had done something, I checked the entropy level after first reboot: still a jumpy number between 150 and 200 or so. Despite the fact that the service shows up as running. Then, a lot more playing with the "game" without understanding what I was doing. Just hoping for some wonder. Some message.... just...... something! But nothing. Just a beach with a red number. And a clock. And a questionmark. Or exclamation mark. Pffffff.. So.... let's reboot again. Then eat a sandwich and drink (more) coffee. Then check entropy again. And there it is! Steady at 4089! At first I thought his app was failing because the number didn't change anymore. Just steady. With the old CrossBreeder 7.2.13 I got 4096 a lot but it was a very jumpy number, going even below 1000 a lot. Well, some time passed while writing this post so let's check again: Wow, right now it says 4091 (99%)! One hour later: 4092! (It had spontaneous reboots inbetween).
I am testing it now for a few hours and have these problems:
"Not responding" issues (same as old CrossBreeder).
Spontaneous reboots (3 already). One of them failing to boot at all (stuck at JellyCast logo).
Two times, after a reboot, GPS was disabled. Not consistently though.
No noticable performance gain.
By the way, I am testing like real world usage. Just opening, using and closing apps. I use the same apps all the time so that gives a very good feeling about performance. More meaningful than benchmarks to me. My goal is to make this phone suitable for normal daily usage.
Your app is using a combination of serveral mods, right? I would like to be able to enable / disable each one separately. How can I do that? For example, I have a gut feeling that my "not responding" issues (and reboots?) do not come from the entropy mod but perhaps from governor tweaks or something else. Any chance that you will add enable buttons in the app? Or supply seperate scripts?

Update: I DO have performance gain! Not consitently though. Apps sometimes starting faster than ever. Also still the aforementioned quirks. Last hours no more auto-reboots. Entropy reaching 4096 now, just a little bit wobbly. There seems to be a lot of potential.

The stutter was an issue with the last version.
Do try the latest one and let us know.
Also better if you install the Play store also so the updates are automatic.
Version name is changed GUID if comparing. Better than comparing version numbers.
GUI is non functional, just a visual representation of haptic feedback and actual randomness spread.
It's like drawing points in the whites of a poached egg. If you can see a pattern, you'll be rich in the stock market

Today I removed the app. The biggest problem is random reboots for me. As said, it has potential because sometimes apps started faster than ever on my ancient LG L3. But not consistently. So maybe I 'll try again later.
Sorry for my first post, probably tl;dr. I will repeat my most important question: can you provide us with separate scripts? I mean: I would like to test the entropy thing without the other tweaks as you described in the OP.

Dude!
You're probably using an old version. We'll never know. Will we? Will we now?
There's a small trick that borders on superstition. The famous random device block gremlin tends to disappear if you run the GUI in scribble mode. Basically what may be happening is the block is hit and then the stupid kernel makes whatever decision it makes. Usually at the cost of usability in favour of some stupid religious Linux fervour. Someone should report that to LINUX.
Or another entropy generator, haveged or RNGD or Seeder may be running. Which is a big no! Best to run it on stock ROMS or full custom ROMs ( please ask the developer if they're running any variant of above and to recommend coexistence or better variant of any subcomponents or piece of code. ). In other words, open source!
Also, the separate scripts are in the /bin directory on the phone itself. May require bash and ADB skills.
And full source on XDA and GitHub.
I'll construe this as a possible request to also post the shell scripts from GitHub into the XDA project as separate attachments. Which I can do. In due course
Cheers.

Well, I took it from Play Store. Is that an old version?