Related
If this doesn't exist, just tell me but I'd figure this was the best place to ask...
I'm looking for something like a C compiler for Android (please note I mean a C Compiler running ON android, not to compile FOR android). If there's a website that will run on android and will run C code like for learning purposes that would be great too.
Basically I'm learning C by reading on the train, and would love to be able to try my examples rather than just reading them. Appreciate any advice you might have. Worst case I just buy a netbook.
http://www.dignus.com/dcxx/compileit.html
I found this but it only outputs assembly language, which doesn't really tell me if my code is doing what I was hoping for. anything else along these lines?
Thanks again
There's a few websites that let you paste code and compile and run it. One such site is www.codepad.org. They're running in some virtual machine type environment for security purposes.
Another option would be to use something like ConnectBot to ssh to a computer somewhere and run gcc there.
On my Palm I fiddled a bit with OnBoard C. Would be great to get that one ported to Android.
http://onboardc.sourceforge.net/
Or an onboard version of Java for that matter.
[email protected] said:
There's a few websites that let you paste code and compile and run it. One such site is www.codepad.org. They're running in some virtual machine type environment for security purposes.
Another option would be to use something like ConnectBot to ssh to a computer somewhere and run gcc there.
Click to expand...
Click to collapse
Yeah I've considered the remote option, I can always do that. I guess I'm not really going to get a good experience no matter what when I'm on a tiny phone screen without a keyboard, right?
I really do appreciate that site though, that will be nice for playing around at work with.
christine600 said:
On my Palm I fiddled a bit with OnBoard C. Would be great to get that one ported to Android.
http://onboardc.sourceforge.net/
Or an onboard version of Java for that matter.
Click to expand...
Click to collapse
That looks sweet
Hi !
As far as I know, the Palm Pascal Compiler designer (PP and also PIAF and BIRD used by some onboardC users) is coding an onboard compiler for Android. It generates ARM executable code directly.
At this time, the application is not fully functionnal, but it nicely compiles some pieces of ISO Pascal code. It will also include an assembler (the disassembler is working well).
Once functionnal, I think it would be easy to create a C compiler (as it has been done with IZBasic)
Probably a bit late but for any others looking for something similar
berardi said:
If this doesn't exist, just tell me but I'd figure this was the best place to ask...
I'm looking for something like a C compiler for Android (please note I mean a C Compiler running ON android, not to compile FOR android). If there's a website that will run on android and will run C code like for learning purposes that would be great too.
Basically I'm learning C by reading on the train, and would love to be able to try my examples rather than just reading them. Appreciate any advice you might have. Worst case I just buy a netbook.
Click to expand...
Click to collapse
I just found this, it may not be 100% free but give it a look eitherway
https://compilr.com
First of all, when I searched for doing programming on an android device, I got a kazillion results on programming an android app. I don't want that. Currently, what are the languages that I can write and compile on an android device? Is java one of these?
I've always wondered why noone has posted a static gcc build for android. gcc g++ gcj, they all should cross compile. You might have to enable swap to use them though.
Android basically runs Java. That's the simple answer.
You might find some interesting reading on Eclipse with the google plugins.
If WYSIWYG/RAD environments are more to your liking, check out the "google app inventor."
goodintentions said:
First of all, when I searched for doing programming on an android device, I got a kazillion results on programming an android app. I don't want that. Currently, what are the languages that I can write and compile on an android device? Is java one of these?
Click to expand...
Click to collapse
http://forum.xda-developers.com/forumdisplay.php?f=613
Um, guys, I said I don't care about building apps. I wanted to know if I could write and compile java on an android tablet.
Not quite java...
First, Android doesn't *quite* run Java. It runs Dalvik. That's a tweaked version of Java to help google not use the lawsuit with Sun/Oracle. There's a preprocessor you have to run over he Java bytecodes to get Dalvik code. This is why you can't simply port (or rather, build, given that there's a Linux under there) gcj and use it as is - you need the jvm->Dalvik translator.
The good news is - that runs on Android. There's a Clojure (a JVM/.net language) port for android that uses that translator to run code. While it's not up to building production code, it's fine for writing/testing code on android. I assume the JRuby port also uses it.
If all you're interested in is programming on a g tab, there's lots of options, most notably Google SL4A package (python, ruby, beanshell, sh - I think). But you can find Scheme, BrainF*ck, Pascal, Basic, etc. No Java, but I found at least three languages that run on the Dalvik VM (Clojure, JRuby, and Frink) that let you access some or all of the Android APIs. If you want to explore the Android APIs, one of these will probably work.
Finally, there's IDEDroid. That runs locally, but looks like it exports the compile and execution to their web server. It has support for lots (and lots and lots) of languages - including Java. If you just want edit/run small programs to play with the language, this might be just the ticket. I think I'm going to install it so I can play with haskell....
I wonder. Why in the world hasn't anyone developed a way to write and compile java code on android?
GNU has gcj, I'm fairly certain the same tools you use to compile a kernel would work to make an ARM/Android version.
muqali said:
GNU has gcj, I'm fairly certain the same tools you use to compile a kernel would work to make an ARM/Android version.
Click to expand...
Click to collapse
Could you please clarify? I guess I'm seeing the potential to incorporate the gtab into my work at the lab. Let just say we're a bunch of engineers trying to act like IT programmers. Why hire an honest to god programmer when you could have your engineers lose sleep over trying to program the machines?
So, please could you stop giving me single sentence answers? If I get the gtab will I be able to use it to write, debug, compile, etc. java codes? We've been doing our own things with java and it's too late to switch to something else. I'm sure it's possible, I'm just having trouble finding the answer in search as it seems noone has ever brought this up before. Ever.
Would the following be what I'm looking for?
http://www.getjar.com/mobile/38541/java-programming-for-android-os-all/
So, I take it that it is not possible to write, debug, and compile java code on an android tablet?
goodintentions said:
So, I take it that it is not possible to write, debug, and compile java code on an android tablet?
Click to expand...
Click to collapse
I did mis-understand you initial post on my first reply.
Now that I understand you question, I'm a bit baffled as to 'Why?'
A tablet just doesn't seem to be a very conducive platform to entering and compiling code.
I don't know about any development tools meant to run on android directly. But there are people running ubuntu on their tablets.
Zaphod-Beeblebrox said:
I did mis-understand you initial post on my first reply.
Click to expand...
Click to collapse
I don't understand how you could have misunderstood my original post. Here it is.
I said, and I quote:
First of all, when I searched for doing programming on an android device, I got a kazillion results on programming an android app. I don't want that. Currently, what are the languages that I can write and compile on an android device? Is java one of these?
Click to expand...
Click to collapse
I don't how else I can make it clearer. I'm an engineer, not an idiot. A simple google search turned up millions of links to how to manage android projects on a pc. Why in the world would I be asking this? And I even said I google searched and it turned up nothing.
Now that I understand you question, I'm a bit baffled as to 'Why?'
Click to expand...
Click to collapse
For the sake of convienience... and to baffle my colleagues.
I don't know about any development tools meant to run on android directly. But there are people running ubuntu on their tablets.
Click to expand...
Click to collapse
The whole point of having a tablet is its light weight and the touch screen. I'd like to be able to take it to meetings, take notes with a stylus, show colleagues basic autocad drawings, write and debug java codes for some of our projects, etc. This is not to say I want to use it as my main device. I will still be using either my laptop or my desktop for my projects, but having something like the viewsonic gtab to carry around and do these things seem cool to me.
I'm just baffled why there hasn't been an app development to run/compile java code on the android OS.
Here is a Online IDE that works pretty good (not for java): http://www.coderun.com/ide/
Or
This one will let you compile and run just about anything including java: http://ideone.com/
Sure glad I tried to help.
Prick.
Zaphod-Beeblebrox said:
Sure glad I tried to help.
Prick.
Click to expand...
Click to collapse
Yes, I'm a prick. I fully admit this. This attitude came from years of experience with 1337s online. When I first started getting into linux, and this was back in the days when there was no visual interface for installation and you had to type in a dozen commands for every step of the way while it asks you for the specific models of your peripherals, I searched for several days on solutions pertaining to a problem I ran into. After being fairly confident that there was no answer to it, I signed into a linux forum and asked about it. I got a couple one-liner answers that made no sense, a couple answers that assumed I was an idiot so they answered the wrong thing, and half a dozen "you're an idiot, go away" answers.
My first rule of thumb is if you could interpret a person's question at least 2 ways, then without further info assume the interpretation that doesn't include assuming the other person is an idiot. And this is for an obscure question. My original post clearly stated I was talking about debuging and compiling java on the android tablet itself. I specifically worded my question like that because I knew people were going to assume I was talking about the thing you assumed.
This 1337 attitude online is getting old.
the3dman said:
Here is a Online IDE that works pretty good (not for java): http://www.coderun.com/ide/
Or
This one will let you compile and run just about anything including java: http://ideone.com/
Click to expand...
Click to collapse
Thanks. I guess this is what I will have to go with for now. I'm sure I'm not the only one who has thought of this before. Surely, if you could run it on a linux distro such as ubuntu, then I'm sure it's possible to do the same thing on a different OS that runs on the same processor. Why in the world hasn't anyone come up with this yet?
goodintentions said:
Why in the world hasn't anyone come up with this yet?
Click to expand...
Click to collapse
Sounds like its up to you to save the day!
adampdx said:
Sounds like its up to you to save the day!
Click to expand...
Click to collapse
I'm a materials/structural engineer who's an amateur programmer. I practically live in my lab. Sure, the other engineers often look at my programming work with oohs and aahs, but I assure you they look like something put together by an idiot if you're a software engineer. Something like this is several miles above my head. Most of my work look like spaghetti code anyway.
goodintentions said:
I'm just baffled why there hasn't been an app development to run/compile java code on the android OS.
Click to expand...
Click to collapse
B/c any real programmer would probably blow a hole in his head trying to write/debug code on a tablet.
HKChad said:
B/c any real programmer would probably blow a hole in his head trying to write/debug code on a tablet.
Click to expand...
Click to collapse
The same could be said about autocad, and yet there is an autocad app for it, given that the capabilities are limited.
Hello people,
after some conversation with early ICS-on the transformer developer paulburton, I have a git repository of a mostly working linux 3.1 mainline kernel with some patches from paulburton to make it actually work.
Icluded are (as of now) :
improved atmel mXT1386 touchscreen driver
tegra_v4l2 camera driver
ov5640 soc camera driver
prox_lds6202 proximity sensor driver
fm34-500 voice processor driver
asusec keyboard driver (for dock)
al3000a ambient light driver
The purpose of this is not to port things back from some linux 3.X kernel to our 2.X kernel, but to have a fully working 3.X source tree some day, from which we could port to further linux versions in the future. This can also be helpful if we want to port android 5.X in the future.
The github is at https://github.com/skirata/linux/tree/android-tegra-tf101-3.1 .
(It's my github, if someone wants to become a collaborator, please let me know, I'll add you to the collab list.
WE NEED EVERY DEVELOPER WE CAN GET.
I will spend some time on this, but I think I can hardly finish this project on my own.
Totally support this, looks promising!
Thanks for the initiative.
Are you and guever working on this together? I can test and maybe help make aokp or megatron versions.
Sent from my Transformer TF101 using Tapatalk 2
Of course I'm willing to work, you know I've helped all I could.
My kernel has much of the code updated to 3.1, so may be we can use much of it.
This can be done in two ways, by modifying the code in paul whatever it takes, or modify mine. I have nothing clear which will be easier, because over time I have made several test on my code and unfortunately, when the kernel does not boot can not be debugged, so you have to turn back.
Until wednesday I will not be able to devote almost no time, so I think the first thing would be to check the operation of the kernel of paul (if not already done) with a current rom.
It is possible that the graphics drivers (most are binary system level) may not work with that kernel.
Well, it is what I think, that first we must see is what should be changed in the kernel to function properly (or whether to change the rom).
Teamwork is how it's meant to be done.!
I will setup a working kernel konfig in the next days to push this a little forward.
at Guevor :
I'm adding you in as a collaborator so we can work together on this.
Let's improve paulburton's drivers and add new ones based on latest nvidia images.
The advantage of upstream-porting rather than downstream-porting is we can port future kernel versions more easily with own written drivers.
Also, android 5.X porting will be a lot easier, as I think it won't support 2.6.X kernels at that time. And even if it would, we can have a massive performance boost if using 3.1 mainline kernel with improvements all over the world.
Glad to count you in, guevor.
I owe you so much already.
EDIT : Just in case, be sure to use the 3.1 branch of the linux repository, as the master branch is forked from torvalds (linux 3.4.X) and will get some love when we get the 3.1 kernel to work as good as we are satisfied.
Well, the main problem I see, thinking about future versions (5.x) is that we do not have the source code for video drivers, only a small part that exists in the kernel. This added to the fact that nvidia does not provide (at least I do not know) the binary drivers for android (as they made for linux), I think that may be, we do not see tegra2 drivers for 5.x. That does not mean we can not do something, but will be less optimal and more complicated.
Hopefully I'm wrong and nvidia make things easy , but I think no manufacturer will use tegra2 for new products, and do not think they will update current products to that version ....
guevor said:
Well, the main problem I see, thinking about future versions (5.x) is that we do not have the source code for video drivers, only a small part that exists in the kernel. This added to the fact that nvidia does not provide (at least I do not know) the binary drivers for android (as they made for linux), I think that may be, we do not see tegra2 drivers for 5.x. That does not mean we can not do something, but will be less optimal and more complicated.
Hopefully I'm wrong and nvidia make things easy , but I think no manufacturer will use tegra2 for new products, and do not think they will update current products to that version ....
Click to expand...
Click to collapse
Have you tried contacting Nvidia about this?
For the record, I am not a Linux user, even with what Im going to say, keep that in mind... My history is firmly routed in WinBlows land!
This has me all sorts of excited, I remember saying it back in paul's thread before it fell off the face of the earth (read, first few pages of the forum).
As stated at the top, while NOT a Linux user, I was trying to build CM9 for one of my tablets, to do so, I had setup a Linux box (tried a few distro's), and kept having issues, so a friend of mine walked me through updating to a 3.4.x kernel (3.4.0.-5 iirc), and things definitely FELT smoother vs the 3.0 (on the distro I was using before he berated me for it and moved me to a different one) and then 3.2 kernel in use (ill note hardware issues where also at play with the actual issues, but the smooth feeling after updating was definitely something I noticed).
I have no benchmarks or performance statistics to back that up, but as I said in paul's thread, and have now experienced in a "full" Linux environment, the future with Kernel v3.1 and up has me VERY excited as to what can be done with the OG Transformer! (vs mass backports to 2.x)
On that note, Subscribed thread, and time to get an RMA for my Tablet... the top basil part is starting to come off the unit
I haven't coded a lot with linux and android source, but I do have experience with coding and especially with reading through source code and finding syntax and other errors i.e. proofreading
So if you want me on the team I'm game!
Orkeren said:
I haven't coded a lot with linux and android source, but I do have experience with coding and especially with reading through source code and finding syntax and other errors i.e. proofreading
So if you want me on the team I'm game!
Click to expand...
Click to collapse
Every help is welcome !
Please tell me your github name and I will add you as a collaborator
If my help is welcome i am willing to test your builds on my TF101G B90 with dock. So let me know if you have to do something.
ajohn117 said:
If my help is welcome i am willing to test your builds on my TF101G B90 with dock. So let me know if you have to do something.
Click to expand...
Click to collapse
Will do for sure, but it could take some time until we can push out the first build for testing.
rayman33 said:
Hello people,
after some conversation with early ICS-on the transformer developer paulburton, I have a git repository of a mostly working linux 3.1 mainline own.
Click to expand...
Click to collapse
With my git every things works but usb hotplug,cam,hdmi-audio. ( usb works fine when insert add boot ) , also i will stop dev for it as i'm selling my tab :crying: but would be nice if this got finished.
also major thanks to paul
Do you started the project?
I tried some things yesterday, but it did not boot. I will have a look into spark rom and try some other things, I think I have some ideas.
Btw, kernel compiles fine, zImage is there, perhaps some early device drivers have to be updated. I will look into the ramdisk I created and fix some things ...
Just to let you people know. Progress is being made.
First progress
I managed to make it boot on revolver 4.1.1 rom. I modified the video drivers to be compatible with the actual binary drivers.
The touch screen is not working, but I really have not looked at it, maybe even compile options I chose are not the most adequate, but just wanted to get it to boot with video graphics working.
We better get each other updated via pm in the future ..
What touchscreen driver did you define in the kernel config ?
The new mxt1386 or the old one from the 2.6.39.4 kernel?
Maybe we need to rewrite the mxt1386 drivers.
rayman33 said:
We better get each other updated via pm in the future ..
What touchscreen driver did you define in the kernel config ?
The new mxt1386 or the old one from the 2.6.39.4 kernel?
Maybe we need to rewrite the mxt1386 drivers.
Click to expand...
Click to collapse
Well, I tested whether simply boot and graphics drivers failed as expected, and I've tried to change it and make it working. I think that is the basics (make it boot) to further adjust problems.
About the drivers, yes, I used mxt1386 but not detected coordinates, just click. I used a USB mouse to verify that the graphics drivers work.
I updated the repository with my changes.
Did you get a log cat already ?
It may reveal if the mxt1386 driver fails to load.
rayman33 said:
Every help is welcome !
Please tell me your github name and I will add you as a collaborator
Click to expand...
Click to collapse
easy as pie!
Code:
orkeren
So I know pretty much how my jailbreak is going to work from end to end, except with regard to PatchGuard. I don't need to burn my "Holy Grail" exploit in order to release a jailbreak, but it means that I have to deal with PatchGuard.
In Windows 8.1, Microsoft modified the kernel and ci.dll so that PatchGuard protects the signing enforcement mode variables. This means that if you modify the variables that were modified by 8.0's jailbreak, some random time in the next hour from that point, your system will bugcheck (bluescreen) because PatchGuard detected something tampering with the kernel. It is very obvious that the addition of these variables to PatchGuard's protected list was a deliberate attack against the RT jailbreak, because there is little other reason to care about enforcing these variables' integrity after startup.
I need to get around PatchGuard somehow. PatchGuard itself is designed to be an obfuscated mess, deliberately difficult to modify in a stable manner. It does a lot of nasty tricks, things that you would typically find in copy protection systems. Obviously, disabling it would be nice, but quite difficult. So is stopping it from bugchecking.
I can load kernel drivers, so I know of a way in which I can hook parts of the system that would not anger PatchGuard such that arbitrary unsigned DLLs and drivers could be loaded without hassle. For things like the lockdown in WinDbg, VBScript and PowerShell, I can hook NtQuerySystemInformation in the user-mode ntdll.dll and intercept the request to check the lockdown setting. Even though the system lockdown state would still be active, as long as user mode programs don't know about it, it won't be enforced. (The kernel doesn't care at all.)
However, this leaves one thing to be desired: executing ARM code. I already know how we can patch the kernel so that ARM code can execute without the CPU being switched back to Thumb2 all the time. However, patching the kernel definitely will get PatchGuard's attention, so there's no way to pull that off without defeating PatchGuard.
The optimal solution is definitely to defeat PatchGuard, but I don't know how. I'm not an expert in the field of low-level NT kernel stuff.
please release your jailbreak so that other people can help you.
If i got it correctly, it will BSOD in a hour of running, so releasing it to public is not a good idea. Maybe via PM to other devs, but that depends on OP.
why not change the variables back after you launch your unsigned exe?
windowsrtc said:
why not change the variables back after you launch your unsigned exe?
Click to expand...
Click to collapse
I think about doing this too. Can we discard hacked? If it can done. Will it have problem with running unsigned exe? And did we know exactly when did PatchGuard notice about hack?
Myriachan said:
However, this leaves one thing to be desired: executing ARM code.
Click to expand...
Click to collapse
Perhaps I'm missing something, ... why do you want to do this? The reason I ask is because this seems to be your motivation for wanting to "defeat" patch guard.
WRT simply running native applications/driver - If you can successfully load a driver, even once, then there are a few easy ways to support this without a patch guard defeat.
Cheers!
bfosterjr said:
Perhaps I'm missing something, ... why do you want to do this? The reason I ask is because this seems to be your motivation for wanting to "defeat" patch guard.
WRT simply running native applications/driver - If you can successfully load a driver, even once, then there are a few easy ways to support this without a patch guard defeat.
Click to expand...
Click to collapse
That it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported. Fixing that would require patching two context-switch routines in ntoskrnl.exe.
You're right that there are various ways of loading unsigned executables and drivers once the initial driver is bootstrapped. ci.dll and ntoskrnl.exe have so many variables that aren't protected by PatchGuard that this is pretty much inevitable. Ironically, removing the lockdown from WinDbg, PowerShell and VBScript is actually harder than running unsigned code when using this attack.
Defeating PatchGuard would be the optimal experience for users.
...
...
Myriachan said:
That it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported.
Click to expand...
Click to collapse
Actually, I don't agree. There is no hard requirement for ARM code that I can see. The major reason for a lack of FF port is that the native RT community is too small to get behind the port to sort out re-writing parts of the code base. There is also the large build system/process that needs to be shifted to VS. Throw in the lack of a public RT 8.1 JB.. and there is little motivation for this community to invest the time/effort in making FF work.
Don't get me wrong, FF will likely come to RT (even 8.1) eventually.. but I don't see the lack of ARM code being the roadblock. Its time and effort along with a new JB.
bfosterjr said:
Actually, I don't agree. There is no hard requirement for ARM code that I can see. The major reason for a lack of FF port is that the native RT community is too small to get behind the port to sort out re-writing parts of the code base. There is also the large build system/process that needs to be shifted to VS. Throw in the lack of a public RT 8.1 JB.. and there is little motivation for this community to invest the time/effort in making FF work.
Don't get me wrong, FF will likely come to RT (even 8.1) eventually.. but I don't see the lack of ARM code being the roadblock. Its time and effort along with a new JB.
Click to expand...
Click to collapse
The javascript JIT engine is to ARMv7 not THUMB_2 though.
SixSixSevenSeven said:
The javascript JIT engine is to ARMv7 not THUMB_2 though.
Click to expand...
Click to collapse
I gathered as much. I'm suggesting a re-write of that as part of the port.
Cheers!
Possible, but not easy. The result would likely be significantly less efficient... but better than no JIT at all. It substantially increases the effort required for porting, though.
As for PatchGuard... I don't know as much about it as I'd like, but the fact that it only checks periodically suggests something that we can anticipate and head off, assuming we can get our own drivers loaded... hmm. This is a pretty "out there" solution, but is there any chance that the version of PG from RT8.0 could be substituted in? That may assume a greater degree of encapsulation of PG functionality than is actually warranted, but it does seem to me that, if we can't modify it, we might be able to just replace (or possibly remove) it. Another option: rather than modifying the value itself, modify the code that checks it? I mean, if they were smart, that's under PG as well, but it *might* not be. Either bypassing the check for the values, or the signature check, or just spoofing the signature check, or taking it a level even further and replacing the whole loader function with a clone that lacks the check (which allows the original to remain intact, aside from however the shim is injected).
Any which way, a lot of binary RE... ick, but that's life.
A few ideas:
1) Put a memory read breakpoint on the memory addresses you wish to change, check the context reading it and change it to what it should be if it's PatchGuard, and what you want if it's not.
2) Hook BugCheck to make it just return if PatchGuard calls it (I seem to recall reading something about PG wiping the stack/any context before calling BugCheck, so this may not work)
3) Forcibly enable Debug mode VIA setting the required kernel flag/calling the proper function (kdStartDebugger? something like that; I had found it at one point) to enable the debugger. I have no idea if PG will sense this on pre-existing threads or not, but if it does then it should shut itself down.
4) Check if THIS approach works in 8.1 (I suspect not, since it was published for 8.0 previews)
5) (This would work for g_ciOptions, but not patching the interrupt handlers), hook the usermode function that queries the state of the signing, make it call a driver that changes the bit back, check, then call the driver to set it to default again. You would only get a BSoD if you were really unlucky and PatchGuard happened to run during the 30ms that the flag was changed.
I'd like to play with some of these ideas, but without access to the current prototype (hint hint), and not having a PC I want to upgrade to 8.1 right now, it's difficult.
netham45 said:
A few ideas:
1) Put a memory read breakpoint on the memory addresses you wish to change, check the context reading it and change it to what it should be if it's PatchGuard, and what you want if it's not.
2) Hook BugCheck to make it just return if PatchGuard calls it (I seem to recall reading something about PG wiping the stack/any context before calling BugCheck, so this may not work)
3) Forcibly enable Debug mode VIA setting the required kernel flag/calling the proper function (kdStartDebugger? something like that; I had found it at one point) to enable the debugger. I have no idea if PG will sense this on pre-existing threads or not, but if it does then it should shut itself down.
4) Check if THIS approach works in 8.1 (I suspect not, since it was published for 8.0 previews)
5) (This would work for g_ciOptions, but not patching the interrupt handlers), hook the usermode function that queries the state of the signing, make it call a driver that changes the bit back, check, then call the driver to set it to default again. You would only get a BSoD if you were really unlucky and PatchGuard happened to run during the 30ms that the flag was changed.
I'd like to play with some of these ideas, but without access to the current prototype (hint hint), and not having a PC I want to upgrade to 8.1 right now, it's difficult.
Click to expand...
Click to collapse
1. You can't set a read breakpoint because PatchGuard is also checking the contents of the interrupt vectors/registers. It would notice that someone is using the hardware breakpoints before it tried to read kernel memory.
2. Yes, PatchGuard overwrites KeBugCheckEx with a pristine copy among other tricks.
3. PatchGuard knows that the debugger was not enabled at boot, and will not allow it to be enabled. It will bugcheck if you try to enable it.
4. It's possible that the approach where you look for the self-decryption code at the beginning of the DPC handlers would work.
5. There is a better way, closely related to how I'm writing my installation program, to allow unsigned PEs to load. It would escape PatchGuard's notice. A user-mode hook would be required in order to neuter wldp.dll, though, since ntoskrnl.exe would still tell programs that the current policy was locked down.
I think I can do everything I need to do except execute ARM code reliably without harassing PatchGuard.
Melissa
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
sahack said:
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
Click to expand...
Click to collapse
There is a lot of software that we would like to port over that is written in arm assembly. We would have to rewrite it to THUMB-2 to use it on Windows RT, though. Porting software is (relatively) easy, rewriting it is difficult.
sahack said:
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
Click to expand...
Click to collapse
Common one that needs the ARM instruction set would be a javascript engine. V8 which is the javascript JIT used in chrome only has x86 and ARMv7 versions available, it doesn't have a THUMB_2 version. Although V8 itself can compile for THUMB2, that is only the JIT'er itself, it will only ever JIT to the full instruction set. So to port chrome we wouldnt be able to use V8, there might be a way to get it to compile using the windows javascript engine (which is slower than V8 but perfectly fine) or something but its still a significant obstacle.
The same applies to quite a few other softwares.
Then as netham says, we have software written in arm assembly which people have requested, thats great but it takes alot of effort to rewrite it in thumb2 assembly.
If you have software which can indeed compile for thumb2 and function on thumb2, yeah thats great. But there is some which doesnt.
netham45 said:
There is a lot of software that we would like to port over that is written in arm assembly. We would have to rewrite it to THUMB-2 to use it on Windows RT, though. Porting software is (relatively) easy, rewriting it is difficult.
Click to expand...
Click to collapse
Okay... I used to think that only JIT compilers and media decoders needed that...
But that gives another question.... Were we able to let the CPU stay in ARM mode in Windows RT 8.0?
(And if PatchGuard checks periodically, is it possible to just reset its timer once in a while?)
sahack said:
Okay... I used to think that only JIT compilers and media decoders needed that...
But that gives another question.... Were we able to let the CPU stay in ARM mode in Windows RT 8.0?
(And if PatchGuard checks periodically, is it possible to just reset its timer once in a while?)
Click to expand...
Click to collapse
First question, no.
Second question, thats what the thread is discussing although your suggestion is perhaps worth a look into (if myriachan hasnt already)
SixSixSevenSeven said:
First question, no.
Second question, thats what the thread is discussing although your suggestion is perhaps worth a look into (if myriachan hasnt already)
Click to expand...
Click to collapse
Sure, you could reset the timer on PatchGuard continuously, if you can find all its timers and perfectly distinguish them from those that were created by legitimate drivers. That's the harder part, unfortunately. =/
Asking this question because the attempt to get TWRP on my device is becoming a compound problem as the distance to being able to build it approaches 1. Otherwise known as the law of inverse noobness: Hindsight is always 20/20. Personally, not even half way to 1 in being able to do this, as am fairly new to doing things at the operating system level of programming. Not brand-new though, and knowing how and where to look things up helps, so if you have hints or can point me in the right direction that'd be great. First question is sort of along the lines of "how do you setup your dev environment" if you want to make it modular? More precisely:
So right now, the build page for AOSP concerning my device says to use Ubuntu 14.04 and do all those things to set it up for that. Do I need to do that in order to get TWRP built for my device? To have it set up the same way as the AOSP advises? Having a different computer for each dev environment would be a bit much, but running them in qemu seems even more ridiculous. Perhaps a better idea is to set up a "build environment" on bootable USB sticks that do all the work? That would simply a lot of things, like not having to swap out hard drives, and being able to easily clone a USB drive to "just work" and build AOSP/TWRP at will on any computer.
For reference, it is the Moto G Power (2021) "Sofia" device. They've released sources for it, but not much development going on. So learning how to do this for my device might just unlock TWRP (and with it, probably the Nethunter kernel/chroot environment) for other devices not yet supported.
Help me, help you. Thanks.
(Have other questions, too).
Why not use WSL2?
How to install Linux WSL2 on Windows 10 and Windows 11
The latest version of the Windows Subsystem for Linux is a significant upgrade; for most, it's now easier than ever to install.
www.windowscentral.com
jwoegerbauer said:
Why not use WSL2?
Click to expand...
Click to collapse
I don't use windows.
Bump.
Asking this because it seems that, being new to programming and having no formal training, I'm missing something from tutorials (like the TWRP git page, or some of the tutorials here on this forum that haven't been updated since 2013) and other material that might be thought to be "known" or "implied" and I just can't seem to understand what. Because when I go to build projects or whatever, following tutorials to the letter, still end up with errors and other problems that aren't covered in the tutorial. Part of that problem is installing dependencies, and then having them conflict with other installed things, like having two of python and three versions of java. So having a "build environment" to prevent conflicts is something that wasn't taught, but learned through trial and error, but that isn't the only problem I'm having.
McChadwicke said:
For reference, it is the Moto G Power (2021) "Sofia" device.
Click to expand...
Click to collapse
Hmm. I have the same model, but it's "borneo".
Did you build TWRP for your device? Any pointers or tips?
I usually just modify stock recovery to have rooted, permissive ADB.
I really don't need more than that in a recovery.
I haven't done much with my GP21 since the Firehose loader is restricted.
Renate said:
I usually just modify stock recovery to have rooted, permissive ADB.
I really don't need more than that in a recovery.
I haven't done much with my GP21 since the Firehose loader is restricted.
Click to expand...
Click to collapse
Not sure why the last reply didn't quote you...
Setting up a build environment is an evolving problem. As of this writing it seems the Ubuntu team is switching to a "pro version" system, a paywall, for some services...
Also, AOSP recommends Ubuntu 14 for a build environment. Gave up trying to run it from USBs lol, it is running on a dedicated system. But android-sdk is no longer available in apt, while running Ubuntu 14.04 + latest updates? So went to check why and now AOSP is using its own system for build environment setup and management. Tried running it in Ubuntu 14, but gave errors with the setup script provided.
Seeing now if I can't get the android sdk to run in Mint-XFCE... Will check back. TWRP build page says I need these things to build it (TWRP), right?
Also, how much of the preinstalled vendor crud can be pruned before it breaks?
Thanks.
Edit: reference on the TWRP guide I'm using is https://forum.xda-developers.com/t/...ompile-twrp-from-source-step-by-step.3404024/ (posted 2016)
I think that all build environments are getting more restricted.
"Just do it OUR way" seems to be the new corporate slogan.
I build Android apps without Android Studio, Gradle or an IDE.
Renate said:
I think that all build environments are getting more restricted.
"Just do it OUR way" seems to be the new corporate slogan.
I build Android apps without Android Studio, Gradle or an IDE.
Click to expand...
Click to collapse
Does TWRP have its own build control system? Considering all these changes, should it?
To keep things isolated, clean and manageable on host system, that has no dev tools
or anything extra besides standard desktop stuff. (under main linux distros)
#1 For smallest , fastest deployment of various build/dev environments i use schroot
on devuan/debian , it is a system to manage/automate the use of chrootable containers.
like regular manual chroot but most thigs are automated/preconfigured with
just a few commands and config files.
Basicaly a new root filesystem (userspace) that is independent of hosts root filesystem and just
uses hosts kernel (or as much/little acces to kernel as you give it trough schroot config files)
has its own packages and dependencies and will only see specific sections of hosts filesystem sections you give it access to like say /src/myproject from host. can be a separate /home
or shared with host, all depends on your config.
Using debootstrap to create the filesystems for containers of specific distributions/verions.
Or can just manualy copy an install and rip out the kernel etc...
(Can install ubuntu userspace in debian with debootstrap , if need be.)
(like lineageOS was hard to find all the correct/matching dev tools under devuan, so ubuntu it was)
#2 For something a bit beefier LXC on top of libvirt.
(regular chroot wont run services, or have its own networking , LXCs can , with some extra configuration)
#3 For when you just need an actual full blown VM os installation use KVM/qemu on top of libvirt .
(like installing 15 year old redhat 5.1 in a container wont work, kernels and main libs too far apart)
(or anything that is just too different from current linux kernel , other OS s etc...)
virt-manager is nice for graphicaly managing VMs and LXCs
#1 But schroot is essential and will suffice for more then 90% if not whole 100% of your needs.
if you want a clean host system from being clobbered by constant installing and testing and such . Keeps the environment contained in its own filesystem namespace , have as many as you need .
start fresh,rollback,clone etc.............
Once configured just start another tab in a terminal emulator and schroot in to the container
and your main host system in unaffected, always clean .
#4 Running all of this on top of ZFS takes it a step up, to the next level of effeciency.
zfs helps quite a bit with cloning,branching,snapshots, rollbacks but not essential,
like git versioning for things that are too big for or are not made for git management
(but is another system on to itself to learn, so ignore it if new to linux )
just cloning a 300Mb-1Gb base bootstrap install folder takes no time on regular filesystem on ssds .
With these 3 tools , you can have 10s if not 100s of different environments on a single host
quickly deployable once you get to know the procedures. all usable at the same time without
reboot,
#5 The most important is learning how to hunt for the right version of tools and all of the
dependencies and the correct versions of those , as each project will have their own
and will base it on their own distribution of choice at a specific point in time.
(by being able to install/test/restart in container makes this whole process , easier)
you can test many different ideas at the same time , and merge what works in
to your own dev-build-env for a specific project.
(like hunting down correct tutorial for specific/old/obscure phone and a rom and recovery
and rooting tools associate from a time long past. using wayback machine to source
correct versions of each , as normal web has erased them )
even used schroot to install games for nephew from untrusted sources without hesitation,
and just delete the container when done, but that was a bit more involved as proprietary
nvidia drivers had to be installed on host and partially in containers.
dandudikof said:
To keep things isolated, clean and manageable on host system, that has no dev tools
or anything extra besides standard desktop stuff. (under main linux distros)
#1 For smallest , fastest deployment of various build/dev environments i use schroot
on devuan/debian , it is a system to manage/automate the use of chrootable containers.
like regular manual chroot but most thigs are automated/preconfigured with
just a few commands and config files.
(like hunting down correct tutorial for specific/old/obscure phone and a rom and recovery
and rooting tools associate from a time long past. using wayback machine to source
correct versions of each , as normal web has erased them )
Click to expand...
Click to collapse
neat. schroot looks like a solution. answers a lot of questions, anyway. that last part scares me though. using the wayback machine to source things jeez. there's gotta be a better way, but probably not unless i want to do it myself which will only add time to "the project".
McChadwicke said:
neat. schroot looks like a solution. answers a lot of questions, anyway. that last part scares me though. using the wayback machine to source things jeez. there's gotta be a better way, but probably not unless i want to do it myself which will only add time to "the project".
Click to expand...
Click to collapse
That was just worse case scenario if you get in to very obsolete/old/abandoned stuff (10-20 year old) projects/hardware etc...
dandudikof said:
10-20 year old
Click to expand...
Click to collapse
yeah some of the hardware is in that range. actually upgraded one of the old rigs (because parts are cheap) from an athlon to a phenom lmao thing has 16gb ram, it is stacked now with top of the line things from that era. keeping it around for nostalgia's sake at this point since it still works.
xmrig gets abysmal hash rates, not even worth running on older hardware.