Hey guys,
I've done some dev on *NIX before, including writing ways to sign my own packages using encrypted hashes and the like. Does anyone know the method that HTC is using to sign the zip files?
The reason that I ask is because I'm interested in trying my hand at reverse-engineering the signature. I am sure some of you guys have already done some work in that area, and I'd rather not repeat someone else's effort if y'all have already taken steps to break the signature. My CSI teacher told me to never start from scratch if someone else has already done good work. It's insulting to them, and makes more work for you.
Where are you folks at with breaking the signature? Is the method known (i.e., is it based on files inside the zip, is based on the bits of the zip, is an additional hash or added metadata, etc)? I would really appreciate any feedback on this if you have the time.
EDIT: For those of you who are leakers or users et. al. DO NOT get any hopes up about this thread. I'm just getting started and this idea could fizzle within minutes of you reading this particular sentence. Anyone posting, please focus on practical suggestions or comments such as sickbox's initial comment below. Thank you!
I've wondered about this since the beginning.
I understand just how complex signing can be (to some degree, I'm not a math guy but I understand scale).
My thought though is we can utilize several tools to make this process possible - though I have no idea how to implement most of this to make this possible. Maybe I'm nuts, but here goes...?
- We now have what, three or four different HTC signed images in the wild with another on the way (OTA). Would it be possible when trying to reverse the sig to utlize the differences between the packages to narrow the cope a bit?
And next
- Using GPUs to process data like this has been shown to be exponentially more efficient and effective than CPUs. What would it take to use some of our awesome GPU power ( a la CUDA) to attempt this task?
Lastly:
- Can we break up the processing required among several of us to speed things further?
I know this has probably been thought of before and discarded for good reason, but I guess the more ideas the merrier.
I'm no CS guy, but I would love to help! I'm one of those unfortunate leakers but rather than whine I'm looking for ways to help. Reversing the HTC key would make life sooo easy. Who knows, maybe they'll use the same key on the next few phones?
Pretty much why I'm asking NOW is because I have enough packages for me to examine and compare and test against. I'm not the best or the most experienced at it, but this kind of thing is fun for me and fits into my spare time. When I have spare time.
It's not the signing we need to know how to do its the cryptographic key that they use to sign their packages that we need. The private key changed with the last bootloader so even if we cracked the key before the couple hundred years it would have taken us to crack the one used for 1.5 we would have to do it again now for 2.1 stuff.
Just look around for test signing and such and you can find the test key that people use to sign stuff as well as the method used to sign the package.
As far as getting the key... you will have to know someone from HTC who would risk their job to get you a copy of their private key.
Greetings Sickbox,
I guess my intention isn't clear. I want to be able to sign packages regardless of what key HTC uses. We have a signature, and we have keyhole. I've noted that the behavior on my Eris is that the signed packages check out just fine each time no matter what version I'm trying to flash (obviously, cannot downgrade, I know, but trying to downgrade still passes the signature and it is the version that fails). So what I would like to do is reverse engineer the signature not necessarily to find the key, but to discover how to create keys. I have 4 different packages, and two test keys that I can examine.
I'm only wanting to know if someone knows how the packages are signed so that I can eliminate looking at all the signing methods. In my research so far, I haven't been able to google, bing, or yahoo anyone who knows what method is used to sign the HTC official packages.
That help, Sickbox? Thanks for your input, I really appreciate it.
So the intent is to reverse engineer the key correct? Then we can sign whatever we want...
Or are you trying something else?
Just want to see if we're on the same page.
1234567ten
I don't necessarily want to reverse engineer the specific key that HTC used to sign any one package, but rather the template for the keys. A prime example of this kind of key decryption would be DeCSS written by DVDJon. He quit trying to reverse engineer the keys used to encrypt DVDs and reverse engineered the decryption of DVD signatures.
I'm not using technical terms for the following, but basically when you sign or encrypt something, the key used is not found within the package or signature, nor is it in the program used to verify the signature or decrypt the package.
If I can do nothing with the signatures of the Eris roms, it's no waste to me. I have fun with this because I want to design an open source DRM system someday. *Sigh* dreams.
Try these. I'm still not sure if I fully understand your question but this as much as I could come up with.
Found by searching "android signing" & "android sign rom" on google if you wanna see what else might come up.
http://developer.android.com/guide/publishing/app-signing.html
http://androidforums.com/developer-101/8665-how-signing-roms.html
sickbox said:
Try these. I'm still not sure if I fully understand your question but this as much as I could come up with.
Found by searching "android signing" & "android sign rom" on google if you wanna see what else might come up.
developer.android.com/guide/publishing/app-signing.html
androidforums.com/developer-101/8665-how-signing-roms.html
Click to expand...
Click to collapse
Hmm... maybe I was being too specific when looking for "htc sign rom" and "eris htc sign rom," etc. I'll see what I can cull from those broader searches. Thanks for the tip, sickbox.
np
34567ten
You might have noticed that there is a little bit of confusion in the posts here when "signing" is brought up; there are two completely different signing methods in use.
The first applies to applications (.apk bundles), "update.zip" files (which could be used with Amon_RA's recovery), and OTA-delivered update files. The distinguishing feature of these .zip files are: 1. They have a META-INF folder in them with two Manifest files and a RSA public key file, and 2. there is nothing "unusual" about the zip file itself. (The contents of the zip file are signed, but the whole zip file is not.)
The second type is the "rom.zip" files buried inside the MR1/MR2 " RUU" updates. These files, when renamed to PB00IMG.ZIP, can be used with the bootloader to update the phone. The distinguishing feature of this type of file is that: it has a mystery blob of binary data at the front of the zip file - 256 bytes. The rest of the file is an ordinary .zip file, and if you unpack it you will find that there are no manifests, no META-INF file, and no public key certs. (In this case, the entire zip is signed, but none of the individual content files are.) I think it is this second type of signing you were referring to in your posts, but honestly I am not certain.
The first form of signing is perfomed with a java tool called "jarsigner", and its behavior is well understood: it creates the first manifest file by computing SHA-1 hashes for every file to be included in the .zip archive. Then, it creates a second manifest file which shadows the first one, and for each SHA-1 hash value, it "signs" them using the signer's private key. In this 2nd file, it also computes the hash for the complete (1st) manifest file, and signs that hash. In any event, what I mean by " well understood" is that this is just a standard use of RSA public key cryptography, using widely deployed Sun Java tools. Break it and you will have made quite a name for yourself.
Now, as for the 2nd type of file - rom.zip/PB00IMG.ZIP, I have not seen anyone (yet) describe the format of that MIC (Message Integrity Check) 256-byte blob. I poked at it a little, but certainly not exhaustively.
If you want to add to the knowledge here, try and discover what the "format" of that MIC is. I suspect that even if you do that, you will find that the sig uses exactly the same PK tools that are already built in to the bootloader - from the standpoint of practicality, it really doesn't make any sense why HTC would " roll their own" when they already went to the effort of coding RSA tools into their botloader(s).
bftb0
Hey bftb0,
You answered my question PERFECTLY. Nobody I've spoken with elsewhere has yet brought up the RSA encryption that's already built into it. You're probably only second guy to mention it, beyond some dude in an IRC somewhere (and I think he was drunk at the time).
Knowing that it is just additional bits on the zip, has anyone thought off hacking it off and paring it to another zip in an attempt to "sign" the zip (I've done this successfully with various signed ISOs)? Also, the public key could be arrived at, given two factors, 1. The same key was used for all Eris 2.1 packages; and 2. The "blobs" of data can be sufficiently compared and I have enough computing power.
Thank God I may be getting an intel I7.
Or I'll just borrow my friend's PC.
I hope I'm not just blowing steam, because it would suck to get working on this and then find it's impossible. But they say that about a lot of key encryption schemes. LIKE RSA on Blu-Ray.
Thank you so much bftb0
Don't read too much "encouragement" into my post; I responded in order to shed some light on the way that HTC is doing things, and that's about all.
If you think about it carefully, you will understand that the manifest-signing operation gives you hundreds, if not thousands, of individual plaintext/crypt-text pairs that are all signed with the same private key. That doesn't mean that a known-plaintext attack is easy, though.
The EFF commissioned a project a couple of years back where they built custom hardware that would brute-force key searches for short keys- 256 bit keys IIRC. The machine they built was a parallel processor built from fpgas/DSPs, and it could recover keys in a few days. Their budget for that was in the low 100,000s. Offhand, I don't know what key length HTC is using, but I doubt it is 256 bits.
I don't recommend you spend any cycles trying to brute force a key recovery.
bftb0
bftb0 said:
Don't read too much "encouragement" into my post; I responded in order to shed some light on the way that HTC is doing things, and that's about all.
I don't recommend you spend any cycles trying to brute force a key recovery.
Click to expand...
Click to collapse
Dude, I was so encouraged that I want to rip open my PS3 and put it to work RIGHT NOW.
Not really. I'm too lazy-assed to spend much time brute forcing it. I'd rather pick it apart and see if there's anyway to mimic the signature. Your advice that it may be RSA based is more exciting in that it helps me know what I may be dealing with. I hope to pick at the binary data appended to the signed roms either tomorrow or next weekend.
And thats what I appreciate.
I'm not sure what you're trying to do. You either brute force the private key, using various bits of super-math (e.g. elliptic curve cryptography?), or you give up and move on -- perhaps looking at patching the subsystem responsible for validating signatures (dangerous for production use).
There are no "mimicing" possibilities and swapping blobs/zips around is just silly. You should spend your time elsewhere, like reading up on how public-key cryptography works.
Thanks WithinRafael,
I think some of what I've written above shows I'm researching public-key cryptography. I really appreciate your thoughts, and it became clear by the end of sunday that the signature is specific to the package. Without me doing much work, mostly research. RSA is a load of work and I do not want to mess with trying to crack that.
I recently became interested in trying to turn S-off. Someone recently gained RW access to NVRAM, and I'm hoping this weekend to move on as you mentioned. Thanks for the good discussion, guys!
with a pen....duh j/k
Anyone have a supercomputer? ...lets brute force it.
Is there a way to check if a rom passes the signature test without trying to load into the phone? Can we check if the signature passes on a computer?
If so we could sign it with all possible keys and see which one passes.
Is this frowned upon and shouldn't even be discussed? or would it just take too long to do? ... or is it just not possible to check the signature on a computer?
... or all of the above?
DarthMowzy said:
Anyone have a supercomputer? ...lets brute force it.
Is there a way to check if a rom passes the signature test without trying to load into the phone? Can we check if the signature passes on a computer?
If so we could sign it with all possible keys and see which one passes.
Is this frowned upon and shouldn't even be discussed? or would it just take too long to do? ... or is it just not possible to check the signature on a computer?
... or all of the above?
Click to expand...
Click to collapse
We can check the signatures based on what is stored in the Manifest file inside the PB00IMG.zip file.
It is possible to brute-force it but it would take years to do so it isn't really worth the effort.
Related
Hi.
I was wondering how hard it would be to create a simple application that would connect to a server or website checking for updates. I plan on loading font .apk's on the server or website, and would like a application to periodically check for updates or manually check for updates, be able to preview the font, and then download the .apk if wanted. How hard would it be to create such an application?
Thanks.
Jzero88
jzero88 said:
Hi.
I was wondering how hard it would be to create a simple application that would connect to a server or website checking for updates. I plan on loading font .apk's on the server or website, and would like a application to periodically check for updates or manually check for updates, be able to preview the font, and then download the .apk if wanted. How hard would it be to create such an application?
Thanks.
Jzero88
Click to expand...
Click to collapse
Well, this depends on how you approach it, but I think the easiest way to do this would be to create a feed using XML. So if you were doing your font updater, you would load a file like this:
<FontDetails>
<Font name = "Font1" example = "http://www.myfontsite.com/FontExamples/Font1.png" location = ""http://www.myfontsite.com/Fonts/Font1.apk"\>
<Font name = "Font2" example = "http://www.myfontsite.com/FontExamples/Font2.png" location = "http://www.myfontsite.com/Fonts/Font2.apk"\>
</FontDetails>​
The problem with this is that you will have to maintain this XML file, making sure its always up-to-date(Easily manageable with some simple scripts).
If you aren't willing to do this, you could go down the road that is wrongly mislabeled as "The Easy Way" and hard-code the locations of all your APK's and all of your example images, but I would only do this if you were planning on dumping all the APK's and images in the same place(For example, if all your APK's were here: http://www.myfontsite.com/Fonts/). You would request the directory information from the server and parse that into your list of font APK's and correspond them with their example images(probably by naming them the same; i.e. Font1.apk and Font1.png).
If you decide to use the first option, you could do a bunch of cool things with the organization, like break things into categories and apply taggings and it would only require one request to the server per update. If you go with the second method, organization is guaranteed to be a mess if you try anything large scale, and adds a layer of complexity if you try to break things into folders and categories. This would require a ping per folder you have to check, which can have a high complexity factor if you have a lot of folders.
I just want to point out that even though this is directly related to development, this is a type of question that belongs in the General section(Questions ALWAYS belong in General). I'm sure a Mod will come around, scold you, then move the thread.
Anyway, I do hope this helps,
Good luck,
Tyler
Edit: Having a bit of problems getting the XML looking correct. Sorry if it looks ugly :S
Even easier would be to manage the updater as an RSS feed. Then it becomes quite trivial, as there are several examples of RSS readers online already.
Great! Thanks for the reply!
Yeah, the XML approach I think would be the better option as well, just because we could use this thread to hold everything I currently do no have any hosting at this time. Would you be up to making such a application? It seems you have the know abouts to so.... I would be the one to maintain everything and update it. I would monitor this thread and when new ones pop up, I wouldn't mind adding it to in the XML.
Also, how would the RSS feed work?
Thanks
jzero88 said:
Great! Thanks for the reply!
Yeah, the XML approach I think would be the better option as well, just because we could use this thread to hold everything I currently do no have any hosting at this time. Would you be up to making such a application? It seems you have the know abouts to so.... I would be the one to maintain everything and update it. I would monitor this thread and when new ones pop up, I wouldn't mind adding it to in the XML.
Also, how would the RSS feed work?
Thanks
Click to expand...
Click to collapse
Wish I could...I've got about 50 projects already on the back-burner and no time to finish them Tell ya what though...I've finished a mini project a couple weeks ago with some buddies at school for my friends website. Its an Open-Source RSS reader that was made to read in the latest articles of his site. With some slight tweaking, I'm sure you(or some other dev) could mod it to work in your favor...Here's the github address:
http://github.com/pencilo/Absolute-Android-RSS.git
I don't think this is the latest code, but all the working elements you need are in here.
Someone mentioned this in another thread, but this is a topic that should have it's own separate thread.
Some of you may have already read the news: Michigan: Police Search Cell Phones During Traffic Stops
Don't assume it won't come to your town.
I can't say I plan to do anything that would warrant police suspicion, yet I don't like the idea of anyone being able to easily pull data from my device. And we know cops won't be the only ones with these devices. So I've been wondering, how can we protect our Android devices from the CelleBrite UFED?
Check out this video that shows some of the features it has, keep in mind it does much more and can even extract DELETED data.
See the company's product page here: http://www.cellebrite.com/forensic-products/ufed-physical-pro.html
This research paper talks about the CelleBrite UFED and other extraction methods. (CelleBrite UFED is talked about starting on page 9.) I doubt there's a means to prevent all of those methods given some involve long term handling of the device, but CelleBrite UFED can extract data when a device is retained by the CelleBrite UFED user for a short period of time. It looks like HTC Android type devices can only be extracted from via the (micro)USB Port and it requires USB Storage and USB Debugging turned on. The CelleBrite UFED has to gain Root Access. It can get by screen passwords and root even a device that was not yet rooted.
There's another thread where someone was requesting a ROM that would not work with the CelleBrite UFED. I'm not sure how to make a ROM or anything else that would not work with the CelleBrite UFED without limiting certain features we all may use from time to time.
Over on Slashdot, someone said they hacked their device (Nexus One) to not do USB client mode. This is another option that would limit some features many of us may use.
So, how can we protect our privacy and our data? Does it mean sacrificing some features like USB storage mode?
The biggest problem is what's missing from Android itself. Meego might be protected but not Android.
You would need an encrypted boot loader that retains root for some users.
A kernel and os files that support different users so the default user is not root like Linux and a prompt with a password for superusers not just an Allow like now for Android.
Encryption libraries that would support truecrypt encryption of both internal and external (SD card) encryption in toto not just individual files.
A true trash system that overwrites files like srm in linux and sswap for wiping the swap file after every system reboot.
Ultimately I don't see it happening. In theory if you were running Ubuntu on your phone then yes cellbrite would just crap out not knowing what to do with your phone. Same possibly with meego. But then no real app support, no navigation and driver support is crap even for ROMs using the same os let alone a different OS like true linux.
It's amazing how many don't even bother deleting thumbnails hanging around on their computers or securely wiping files on their computer. Same with swap files retaining passwords or even website cookies that have the same password as their computer.
Best thing to do, don't keep anything that could be bad on your phone. Use a cloud system or home server sync that requires a seperate login every time and keeps no local files. Or as I do, encrypt the hell out of anything you find valuable, which currently is only my complete backups...
Sent from my Xoom the way it should be, rooted and with SD card.
This is where that cheap Boost Mobile phone comes in, or any other prepay phone. Just hand the officer that one. Store your personal data on your smartphone.
chbennett said:
Best thing to do, don't keep anything that could be bad on your phone. Use a cloud system or home server sync that requires a seperate login every time and keeps no local files. Or as I do, encrypt the hell out of anything you find valuable, which currently is only my complete backups...
Sent from my Xoom the way it should be, rooted and with SD card.
Click to expand...
Click to collapse
Hello, All. This is my first post at xda-developers!
Since I'm new to Android, data security has concerned me. Climbing the learning curve of rooting and tweaking my SGH-T989, I've focused on control, security, and privacy. So far pretty good, thanks largely to members' posts at this site. Thank you very much!
Then this thread crushed me. Visions of "1984", "THX 1138", "Terminator", etc.
I considered the suggestions here. Thoughts about the OS seem right to me, but that's beyond my abilities. I did try following chbennett's advice: I enabled encryption in my backups and moved them to the internal SD.
But I don't yet know how to do the 'home server / log in on demand' scheme for contacts and calendar. I will appreciate any help with that.
Meanwhile, I looked for a way to make a 'panic button' that would let me wipe my phone immediately. What I chose was making a contact whose phone number is the USSD code for Factory data reset.
Maybe Tasker, etc. could streamline this approach; but my trials showed that, unlike MMI codes (e.g., to toggle caller ID blocking), USSD codes cannot be submitted to the OS indirectly. So swiping a contact, direct dial shortcut, etc. did not work. On my phone, all that worked was either 1. manually dialing the code, or 2. dialing the contact name, then tapping the contact.
So the routine to use this 'panic button' is:
1. launch Dialer
2. dial the contact name
3. tap the contact name in the search results
4. tap "Format USB storage" in the "Factory data reset" dialog
5. tap "Reset phone" button in the "Factory data reset" dialog.
It sounds clunky, but it's actually pretty quick. I named the panic button contact "XXX" to avoid confusability when dialing (it needs only "XX" for a unique match.)
If you can suggest improvements to this scheme, or think it is misguided, please let me know. Thanks.
Any updates on this? I'm curious as to how to guard against ufed.
I think an instant hard brick option would be better so theres nothing to recover as i dont believe the factory reset is a secure wipe
Possibly a voice activated secret phrase or keypress u could say/do super fast in a tricky situation that autoflashes a corrupt/incompatible bootloader and recovery to device after secure superwipe that should stump them for awhile
im still interested in this i disabled usb debugging on my phone but unsure if the UFED can still access anything on my ICS full encrypted passworded evo3d im assuming they could dump the data at most but i highly doubt they could access the decrypted data unless you used an insecure pass
If you have encryption enabled for your data partition, then all you need to do is to turn off your phone when you see a cop. If they take it from you, they can turn it on and hook up their device, but they will only be able to snarf the system partition, which does them no good. They'd need your password to mount the data partition.
If you look around on this forum, you can find the steps necessary to switch the lock screen back to a simple pattern lock while leaving the disk encryption enabled.
Are you sure Cellebrite and UFED or w/e can't access encrypted data partion? I know it can take an image of the phone "hard drive". They then can run password tools against image to unlock it no?
dardack said:
Are you sure Cellebrite and UFED or w/e can't access encrypted data partion? I know it can take an image of the phone "hard drive". They then can run password tools against image to unlock it no?
Click to expand...
Click to collapse
I'd like to know about this too. I am about to set up encryption on my device and I'd like to know more about what type of attacks it can beat.
Edit to add: I assume brute force attack protection is like any other type of encryption.....dependent on the strength of your password. But, assuming we all know that already, I'm still curious about this.
If the question is how to protect your device when you think someone would scan your phone, you'd have to have some sort of inclination that a scan is about to happen. I'm assuming this is many people's concern as they're considering wiping their device through a quick process. In that scenario, just turn off your device. Unless you warrant suspicion of something fairly bad, they wouldn't be confiscating your cell phone.
smokeydriver said:
...Unless you warrant suspicion of something fairly bad, they wouldn't be confiscating your cell phone.
Click to expand...
Click to collapse
We all wish all law enforcement was just and honest, but so far in world history that has not been the case. Even a pretty woman may have her phone scanned by a curious cop snooping for pics.
Sent from my HTC One using Tapatalk 2
I would still like to know if there is an answer here...
So I recently had some dealing with assisting in a Cellbrite search. We initiated and enlisted the help of law enforcement for an employee who was doing some illegal activity which is not relevant to this discussion other than the person used an iphone. Anyway, the investigator came in and wanted to know if I can enable the bypass for the automatic screen lock in 5 minutes because when it locked, it disabled the Cellbrite copy.
Now, couple things here, he was only doing what he was "allowed' to do in the local municipality, and he did say they sell a more expensive Cellbrite device which would be able to crack it. I did find it interesting that the simple corporate Activesync policy I have set up was actually having this effect. Anyway I removed the policy and it worked. Funny thing is he could have done it himself had he known anything about that kind of thing. He was presented to us as an expert but I guess that mainly covered a basic Cellbrite expertise.
So, I do think encryption would be a great answer as the partition would be hard to bust in to. Nothing is impossible but I would rather not smash my phone on the highway next time I get pulled over so I would like to know definitively that this is the right approach. This is definitely not paranoia as there are at least 3 states where it looks like it happens regularly.
Time to look at a 2600 group for stuff like this I guess. I am early in my investigation
Later
UPDATE:
So it seems as though i have solved that problem, and now i just away the kernel modules. Thanks for all your help guys.
Code:
adb shell /data/local/kexec /data/local/uImage
MSTART= 12668952828585181184 MEND=18014435486466048 MEMTYPE=0 NR_SEGMENTS=0 ULONG_MAX= 4294967295
MSTART= 12668952829122052096 MEND=18014435822010368 MEMTYPE=0 NR_SEGMENTS=0 ULONG_MAX= 4294967295
MSTART= 12668952829390487552 MEND=18014436090445824 MEMTYPE=0 NR_SEGMENTS=0 ULONG_MAX= 4294967295
start= AFD1297980000000 mem_min= 0 hole_min=0 end=4000089C000000 mem_max =FFFFFFFF hole_max=FFFFFFFF
Cannot open /proc/atags: No such file or directory (Doesnt really matter from what ive read)
kexec_load failed: Function not implemented (The module)
entry = 0x80008000 flags = 280000
nr_segments = 2
segment[0].buf = 0x2e4e8
segment[0].bufsz = 10
segment[0].mem = 0x80001000
segment[0].memsz = 1000
segment[1].buf = 0x403ff048
segment[1].bufsz = 2c4214
segment[1].mem = 0x80008000
segment[1].memsz = 2c5000
So hears the deal myself and gameman73 have been working our a**es off trying to get this KEXEC to compile and work. The problem is the current memory will not allow for certain calls to the iomem.
We need to find a way to have this line of code compile and be true on our devices. If someone could sift through the code alittle that be well appreciated:
Code:
kexec/kexec.c 230: while ((j < info->nr_segments) && (([B](unsigned long)info->segment[j].mem) <= mend[/B]))
Apparently it thinks info->segment[j].mem is a const * void
Here's the source http://horms.net/projects/kexec/kexec-tools/kexec-tools-2.0.2.tar.bz2
When I work on something, I often find that having a complete understanding of the problem makes the solution clear. Perhaps this will help you understand the problem better:
SEE ATTACHED FILE, FIRST LINK*
Related. Looks like you aren't the first person to have a problem with the way memory is called in kexec. You might be able to work something out from this discussion, however old it may be.
SEE ATTACHED FILE, SECOND LINK*
This is something else about disabling kexec from executing. A workaround is discussed, but I am by no means a developer and I can't make any sense of it. Just giving you what I find.
I don't mean to spam, and I don't want to be the typical noob getting in the way, but I do want to help. Research, it seems, is about all I can do until my unit arrives (hopefully tomorrow).
*edit: since this is my first post, please excuse the attached file. It is only because with less than 8 posts I cannot put the links in the body of my message.
twodollaz: research is awesome. digging that crap up is a giant pita.
loglud: did you guys get kexec-mod compiling and loading? i haven't had time to look at it much, but all the sources i've found require a huge amount of work to compile, let alone load and run. do y'all have more information on that? i'd look at why the line you mentioned isn't working but i have no frame of reference if i can't reproduce it myself :-/
Actually you really don't need the module to reproduce the error that I am talking about. But gameman73 does have a fully compiled module loading into insmod. And it is showing as installed. You can ask him.
As for you links twodollaz there actually very useful, however not for our problem. The problem that they are incurring is that of the memory not being malloced, or assigned to the process. Our problem is that according to the program there is no memory existing, (the page is there but the lines are not). I think i might have found a solution last night while sleeping ironically, however i am in work and cant test till I get home.
You've gotta love it when your subconscious does the work for you.
If you guys need more help with this I would be glad to join in. I have literally no experience with kernels, hardware, etc though so I will need some hand holding to get kexec loaded and testing. Once I have the build/run setup I might be able to help. I am a programmer by trade, mostly java based, but can write c/c++ when pressed. Alot of what I do on a day to day basis is pull apart other people's code and fix it, optimize it, etc - mostly in a JVM but I have done this some for system cores.
zambien said:
You've gotta love it when your subconscious does the work for you.
If you guys need more help with this I would be glad to join in. I have literally no experience with kernels, hardware, etc though so I will need some hand holding to get kexec loaded and testing. Once I have the build/run setup I might be able to help. I am a programmer by trade, mostly java based, but can write c/c++ when pressed. Alot of what I do on a day to day basis is pull apart other people's code and fix it, optimize it, etc - mostly in a JVM but I have done this some for system cores.
Click to expand...
Click to collapse
zambien you are my new best friend. If you could take a look at what are valid memory locations in the locate_holes function that would be amazing. So far when i do an
Code:
fprintf(stderr, "mem= %li...",(unsigned long)info->segment[j].mem))
i always get nothing. I think this might be because j needs to start at 1 but idk. if you could find a way to iterate through
Code:
info->segment[j].mem
and find where it is valid, we might be on our way.
Forgive me if I'm way off, but how does this sound? I don't know if this device is EFI compliant, but if it is - and apparently some ARMv7 devices are - then it could allow kexec to reference a more complete memory map provided by EFI. The patch behind the link is for x86, but perhaps there are some ideas it might provide.
Just trying to help.
See attached for link..
twodollaz said:
Forgive me if I'm way off, but how does this sound? I don't know if this device is EFI compliant, but if it is - and apparently some ARMv7 devices are - then it could allow kexec to reference a more complete memory map provided by EFI. The patch behind the link is for x86, but perhaps there are some ideas it might provide.
Just trying to help.
See attached for link..
Click to expand...
Click to collapse
Hmm thats very interesing... Ill try this when i get home. Im looking though it more and im starting to think that this could be our problem. Im going to pull one of the patched files down tonight and try seeing what happens.
Hello @all,<br>I'm kinda new to "asking a question on a forum" hence I kindly ask you in advance to be a bit apologetic for any blunder I'm going to 'produce' .. thx
The reason me being 'new' is because usually I find my way around—not that I consider myself almighty but a simple Google-search does it's magic .. usually. This time I ran out of luck, which surprised me (even a search-string-overhaul was to no avail).
I'm looking for a neat text/script editor that is capable of monitoring file-changes that may happen in the background while a file is open .. a standard for any given IDE on a PC-environment (in fact, the simplest notepad replacement would cover such basics). Or a precocious check upon file-saving would be sufficient. As of now every App I tried so far failed to notice when I "sneak into my own phone and 'secretly' modify a file" currently open by this very App (of course, there are different scenarios conceivable why a file might have changed, though). QuickEdit looked promising but .. alas .. and why the heck is no there UltraEdit available for Android .. but I reckon this would be an entirely different topic and too much to ask.
ps: chose the 'post'-icon because it seemed fit .. although in a slightly different way than probably intended
pps: for the non-working line-break .. just use your imagination
So for quite awhile, I was doing a lot of source code modifications, my buddy tossed me this S8+ kind of giving up on it and knowing myself I ventured back here to XDA like I did many years ago and I had seen the complications with the time it took to gain root for the S8/S8+. I figured i'd access my mac's shadow files to see what I could fine, in essence the root of where memory dumps to such as passwords, backup cache info e.t.c. While I was viewing Sampwnd's files for systemroot I figured knox would detect the implementation of such apk however, what if we technically rewired it to be MD5 Hash and or that of another hash form? Would it sitll detect? i'm still rather new to developing stuff and have decided to just have a little fun and play around with it and see what I find.
I imagine the trouble I could see from it would rather be the boot files and getting it implemented with SSH just not sure if ultimately it comes down to a text issue or hardware coded issue
Any ideas? I mean I know it comes off tideous but really what it comes down to is file names, essentially we would just hash everything and keep a base orig root copy on hand to translate or decode to text when we need to research.
ReqNet said:
So for quite awhile, I was doing a lot of source code modifications, my buddy tossed me this S8+ kind of giving up on it and knowing myself I ventured back here to XDA like I did many years ago and I had seen the complications with the time it took to gain root for the S8/S8+. I figured i'd access my mac's shadow files to see what I could fine, in essence the root of where memory dumps to such as passwords, backup cache info e.t.c. While I was viewing Sampwnd's files for systemroot I figured knox would detect the implementation of such apk however, what if we technically rewired it to be MD5 Hash and or that of another hash form? Would it sitll detect? i'm still rather new to developing stuff and have decided to just have a little fun and play around with it and see what I find.
I imagine the trouble I could see from it would rather be the boot files and getting it implemented with SSH just not sure if ultimately it comes down to a text issue or hardware coded issue
Any ideas? I mean I know it comes off tideous but really what it comes down to is file names, essentially we would just hash everything and keep a base orig root copy on hand to translate or decode to text when we need to research.
Click to expand...
Click to collapse
Any luck? Rooting our s8+??
Sent from my SM-G955U using XDA Free mobile app