Database Info

[Q] What is this doing in init.rc? LogMeIn svc RescueStarter /system/bin/RescueStarte

The last line of my /init.rc file:
Code:
# +++++++++++++++++++++++++++++++++++++++++++++
# NAGSM_ANDROID_FRWK_JUSTIN_20101013 TMO LogMeIn
service RescueStarter /system/bin/RescueStarter
user nobody
group input graphics
oneshot
I'm just wondering what's this doing here? I would think this is a T-Mobile service, based on the "TMO", but I cannot find anything about the RescueStarter service online. RescueStarter & RescueServer are in /system/bin/, and hex-dump seems to insinuate (although you can gather this just from the names of the files) it's a remote control that opens a port and listens for a request. I'm assuming that because the user is "nobody", that it cannot run... but not sure. Another assumption is that it provides graphics, like VNC, since it belongs to the groups "input" & "graphics". Again, just a guess. I normally work on Debian Linux systems, btw, not Android. Port scan shows nothing open (TCP 1-65535, and I didn't find anything with a non-conclusive UDP scan, either).
Maybe there's someone smart out there that can shed some light on this for me? Or maybe tell me the proper place to ask? Thanks!

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.

Local root exploit

Hi,found one exploit from 2013 year, but its in exploit database as exploit from Feb.2014 ! Need some help for understanding something. Exploit is http://www.exploit-db.com/exploits/31574/
I understand principe, completed all steps expect 2 things which I not understand!
1. thing 1 - How to get thing which is explined in comment on line 34
2. thing - what is on line 39 !! How to get that || what is that || what is usage of that ??? Is that a phys address of the kernel func adress near sys_ni_syscall || sys_ni_syscall ???
Anyone explain, please?

Anyone?

May be this helps
http://lxr.free-electrons.com/ident?i=sys_ni_syscall
Ps - I have no knowledge of development :/

That not helps

The address 0xc01217c0 is the sys_ni_call
system call, the address 0xc011ac50 is the
sys_exit system call, etc.
http://www.symantec.com/connect/articles/forensic-analysis-live-linux-system-pt-2
Again jz searched... i dont know if this useful or not...

No mate, thats not helpfull, you found adress from kallsyms but thats not what I need! I need a thing how to get into userspace landing point page-aligned address which is defined as a 0x720cd000, since we know only kernel mem which is at 0xcXXXXXXX . I don't understand how|where to get these landing page aligned adress which is 0x7XXXXXXX, how he get them? What is that? How he found them on 0x7xxxxxxx ? Why it is on 0x7xxxxxxx ? Thats a only thing which I need to understand to get started!
If you look into line 34 you will see a comment! Comment is:
/* we need to know the lower halfword of the original address of sys_ni_syscall to tailor MMAP_AREA and MMAP_OFF accordingly. * you can aid yourself with a NOP block. the higher halfword will in any case become 0x720c. on one of my boxes, the other * halfword was 0xdac4. MMAP_AREA must be aligned appropriately. you can extract all the data in question at runtime from * /proc/kallsyms and dmesg (not that hard to set off infoleaks with this bug) as long as there are no contraints in place */
Click to expand...
Click to collapse
Thats what I not understand! He say: we need to know the lower halfword of the original address of sys_ni_syscall
I need original adress of the sys_ni_syscall and NOT ONE FOUND IN KALLSYMS ! Thats what I need to understand!!!

Master munjeni its way beyond my knowledge and scope .this is some veteran android core stuff
:/ m a dental intern :silly:

No problem, you tried to help and I like that, tnx!

Okay sir last attempt...
This link to pdf explains quite a few stuff... (Still i dont know if it is useful or useless)
http://www.google.com/url?q=http://...sQFjAA&usg=AFQjCNHr20jDgbz5jzlF5o1uIsbdx_GvHg

see https://www.codeaurora.org/projects...hecks-putusergetuser-kernel-api-cve-2013-6282

[Completed] LCD replacement resulting to incorrect Display Resolution and Orientation

Good morning folks!
I have initially consulted my project with the hardware experts regarding a tablet getting new Replacement LCD. Turns-out that the LCD is somewhat incompatible yet displays somehow correct and crisp Images.
To start; here are the things or components I have.
* An FnF iFive Mini 2 7" tablet, broken Screen/Touch panel - Motherboard is all good. I had a VNC installed that still enables me to control the Broken tablet without a physical display.
* A dead ACER Laptop with very good 15" LCD
YES you got it right! I am about to salvage a 15" Laptop LCD as replacement for the 7" screen from the tablet.
I am halfway there. I manage to interface the 15" LCD panel which has 30 PIN LVDS connector, the 7" also happens to have the same set of Connection, except for their physical dimension for the connector. But I got it loading and displaying.
The Only challenge is the Screen Resolution or the ORIENTATION itself.
What I have done so far:
I installed Screen Resolution App as well as Screen Rotation. Both did not work.
I figured, both app only covers the user interface. I figured the adjustment should be made during boot.
The tablet has the i5 logo loading image landscape by default during boot. Yet it is displayed Vertically On the 15" LCD upon powering on both the 15" LCD and the tablet. Yet the 2 apps mentioned are unable to make the correct adjustments.
This leads me to seek for help in making adjustments with the PRE-BOOT environment. The phase where the Boot loader calls on to activate the display.
A hint I got was from an LCD Manufacturer wherein they specifically ships and assist in interfacing their Manufactured LCD as replacement from other Android/Linux tablets/PCs.
They have specifically indicated:
Linux kernel allows to assign manual LCD resolution in bootargs supplied by u-boot. This is usually done by script called “boot.scr” in “boot” partition that is loaded and executed by u-boot. “boot.scr” has special format and usually is created with the help of “mkimage” util from source file called “boot.txt”. Below is example of my “boot.txt” that I use for Android (Linaro build 12.01):
Click to expand...
Click to collapse
Yet I am unable to Find the said file from the Tablet runing Android 4.1.1 or ateast I am hoping someone would be able to point me to the equivalent File.
A file that gives me this;
setenv initrd_high "0xffffffff"
setenv fdt_high "0xffffffff"
setenv bootcmd "fatload mmc 0:1 0x80200000 uImage; fatload mmc 0:1 0x81600000 uInitrd; bootm 0x80200000 0x81600000"
setenv bootargs "console=ttyO2,115200n8 rootwait ro earlyprintk fixrtc nocompcache vram=48M omapfb.vram=0:24M,1:24M [email protected] [email protected] [email protected] init=/init androidboot.console=ttyO2"
boot
Click to expand...
Click to collapse
Also, your expertise in making modification for the said file and re-compiling thru MKIMAGE as mentioned.
Additional info:
You should consider above “boot.txt” files as examples only, because they highly depend on OS and baseboard that you use.
The most important bootarg here is “[email protected]” – that’s exactly where we setup LCD resolution. 1024×600 sets resolution, “M” indicates the kernel will calculate a VESA mode on-the-fly instead of using modedb look-up, the “R” indicates reduced blanking which is for LCD panels, “16” is the color depth, “@60” is the # of frames per second.
Lets generate “boot.scr” file with the following commands:
mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Run uImage" -d boot.txt boot.scr
chmod a+x boot.scr
“mkimage” is available in package “uboot-mkimage”.
Now copy generate “boot.scr” file to boot partition on your
Click to expand...
Click to collapse

Here comes the Silver Lining! A sign of hope for my project.
It turns out the both the 7" and 15" were almost Identical. Except for the following details:
Orientation: the 15" is tagged as Normally HORIZONTAL while the 7" is tagged as Normally Vertical. They even have the opposite Resolution at 1280x800 for the 15" and 800x1280 for the 7"
The resulting display was, the android environment is drawn starting from the upper Right side going to the left. So I do not have visibility on the NAV bar.
When I make use of the Screen Rotate, the display indeed rotates except that only the first 800 pixels are displayed, so the resulting Image gives me 800x800 resolution, the other Horizontal 400pixels mirrors the same image from the First 800 pixels.
I am hoping to provide you pictures.
EDIT: I guess I still need a couple more post to enable links.

My recent research indicates I should look for a file inside the Android system that contains the following strings:
static struct omap_video_timings sharp_ls_timings = {
.x_res = 480,
.y_res = 640,
.pixel_clock = 19200,
.hsw = 2,
.hfp = 1,
.hbp = 28,
.vsw = 1,
.vfp = 1,
.vbp = 1,
};
----------------------
I am hoping someone here in XDA can lead me the correct Direction.
Also a SHARP LCD specialist indicates how to add driver on to a GB system via;
Implement display_lcd_init(), display_lcd_enable() and display_lcd_disable() and link to display driver. Where DSS module will use it in runtime. e.g. @arch/arm/mach-omap2/board-omap3evm.c

Hi,
Try posting your question here:
Android Q&A, Help & Troubleshooting
The experts there may be able to help.
Good luck!

malybru said:
Hi,
Try posting your question here:
Android Q&A, Help & Troubleshooting
The experts there may be able to help.
Good luck!
Click to expand...
Click to collapse
Thank you, I have just reposted my inquiry to: http://forum.xda-developers.com/subscription.php?do=addsubscription&t=3307045

Removed

Removed

I just google things and muddle my way through a couple of articles / code comments until they get to the point and give me information I can understand. The trick is to skip past the technical "how" and "why" that often flies over my head too, and find the actual "what" that explains each option's effect. Then I pass things on the way I understood them so you get the condensed version.
Do you notice any hiccups or delays with these settings? They all put battery over performance.
One note: sched_tunable_scaling isn't just enabled or disabled. At least in the stock version (as in all the way upstream, not your phone's default software) its values are:
0 = don't adjust sched_latency_ns
1 = adjust sched_latency_ns logarithmically
2 = adjust sched_latency_ns linearly

TrenchFullOfSlime said:
I just google things and muddle my way through a couple of articles / code comments until they get to the point and give me information I can understand. The trick is to skip past the technical "how" and "why" that often flies over my head too, and find the actual "what" that explains each option's effect. Then I pass things on the way I understood them so you get the condensed version.
Do you notice any hiccups or delays with these settings? They all put battery over performance.
One note: sched_tunable_scaling isn't just enabled or disabled. At least in the stock version (as in all the way upstream, not your phone's default software) its values are:
0 = don't adjust sched_latency_ns
1 = adjust sched_latency_ns logarithmically
2 = adjust sched_latency_ns linearly
Click to expand...
Click to collapse
Got it
I don't have any performance issues. I usually play Fifa and PES on my device and they seem to have no problem with the modifications.
Thank you

This is by no means universal. You didn't include the phone you use, the kernel you used, the version of Android.. These settings 'work' for your phone and the way you use it, but that does not mean it will work for all phones and how other people use their devices.
I think you need to go research what you are suggesting and don't rely on 5-10 year old linux kernel discussions on stackoverflow. Glancing over your suggestions I see a few settings that make no sense at all.

bobbarker2 said:
This is by no means universal. You didn't include the phone you use, the kernel you used, the version of Android.. These settings 'work' for your phone and the way you use it, but that does not mean it will work for all phones and how other people use their devices.
I think you need to go research what you are suggesting and don't rely on 5-10 year old linux kernel discussions on stackoverflow. Glancing over your suggestions I see a few settings that make no sense at all.
Click to expand...
Click to collapse
Thanks
Could you please mention which ones doesn't make sense and guide me to a place where I can learn more about it?

@arter97
Sir, I know this might never reach you. But if you could take two minutes of yours and point out the things that are wrong in this post, it would make my day.
Thank you