Hello
I am having troubles getting my roms to compile. I keep getting the same error in each one. If someone could let me know what I am doing wrong that would be great. I am using linux ubuntu 12.10 and go through all the instructions on building the roms. Even on ones where it says that it is completely set up I get the same error. Here it is.
make: *** No rule to make target `/home/paulg/android/rootbox/out/target/product/ville/obj/lib/libmmjpeg.so', needed by `/home/paulg/android/rootbox/out/target/product/ville/obj/SHARED_LIBRARIES/camera.msm8960_intermediates/LINKED/camera.msm8960.so'. Stop.
I guess the solution would be to take the file from another rom and put it into the directory but there has to be another way to do this besides doing that.
I also have another error where it says the libril directory from hardware/lib/libril is conflictin with the direcory msm-8960-common/libril ( not excatly like that but close enough). To fix this I just erase the hardware/lib/libril directory and leave the msm8960-common intact and let it compile from there. I don't know if this is right or not. If someone knows this one let me know.
Thank you.
Paul
atrus5 said:
Hello
I am having troubles getting my roms to compile. I keep getting the same error in each one. If someone could let me know what I am doing wrong that would be great. I am using linux ubuntu 12.10 and go through all the instructions on building the roms. Even on ones where it says that it is completely set up I get the same error. Here it is.
make: *** No rule to make target `/home/paulg/android/rootbox/out/target/product/ville/obj/lib/libmmjpeg.so', needed by `/home/paulg/android/rootbox/out/target/product/ville/obj/SHARED_LIBRARIES/camera.msm8960_intermediates/LINKED/camera.msm8960.so'. Stop.
I guess the solution would be to take the file from another rom and put it into the directory but there has to be another way to do this besides doing that.
I also have another error where it says the libril directory from hardware/lib/libril is conflictin with the direcory msm-8960-common/libril ( not excatly like that but close enough). To fix this I just erase the hardware/lib/libril directory and leave the msm8960-common intact and let it compile from there. I don't know if this is right or not. If someone knows this one let me know.
Thank you.
Paul
Click to expand...
Click to collapse
Never mind I figured it out and compiled rootbox for Htc One S
atrus5 said:
Never mind I figured it out and compiled rootbox for Htc One S
Click to expand...
Click to collapse
What was your solution for the libmmjpeg.so error? I'm having the same problem for another device
Thanks,
Mike
mikshepard said:
What was your solution for the libmmjpeg.so error? I'm having the same problem for another device
Thanks,
Mike
Click to expand...
Click to collapse
You can get this file and all the other proprietary files by entering extract-files.sh from your device/devic_company/device_name directory from whatever rom you are trying to build. If you have done this then there should be a file that will automatically copy it or else you will have to copy it to the out/target/product/device_name/system/lib directory. You might want to also check that you have the correct manifest files in local_manifest for whatever device you are trying to build. usually there is a cm.dependencies file in the device/device_company/device_name directory that will tell you exactly what manifest to use. If you have any other questions let me know. I hope this helps.
atrus5 said:
You can get this file and all the other proprietary files by entering extract-files.sh from your device/devic_company/device_name directory from whatever rom you are trying to build. If you have done this then there should be a file that will automatically copy it or else you will have to copy it to the out/target/product/device_name/system/lib directory. You might want to also check that you have the correct manifest files in local_manifest for whatever device you are trying to build. usually there is a cm.dependencies file in the device/device_company/device_name directory that will tell you exactly what manifest to use. If you have any other questions let me know. I hope this helps.
Click to expand...
Click to collapse
oh wow, hahaha, I was in such a hurry, I completely missed that. I never used the extract-files.sh as all the proprietary files for my htc devices used to be hosted on github but recently got pulled due to a legal problem with the camera drivers. I had the files backed up on my old computer but forgot to copy them over to the new one. Wow, amateur mistake but one that would have taken me a while to catch. Many thanks man!!
-Mike
mikshepard said:
oh wow, hahaha, I was in such a hurry, I completely missed that. I never used the extract-files.sh as all the proprietary files for my htc devices used to be hosted on github but recently got pulled due to a legal problem with the camera drivers. I had the files backed up on my old computer but forgot to copy them over to the new one. Wow, amateur mistake but one that would have taken me a while to catch. Many thanks man!!
-Mike
Click to expand...
Click to collapse
No problem.
I had the same problem with ville. Got the files pulled so made up my own repo with all the files that are needed.
Sooo yeah.... anybody got some help for this one? I have searched google and the forums but can't clearly figure this out, but how do I get a Boot.img for this phone??? I have rebuilt the kernel 3 or 4 different ways and the output never yeilds one, however I apparently NEED one so I can peel away the ramdisk x( any ideas?
EDIT: Okay, so now that I can compile a working stock kernel for the Sidekick, where should I start now? I know we already have a working voodoo lagfix kernel, but I want to make CWM for the stock kernel, that sounds like a good spot. And adding in init.d sounds like another good start. Making my own may help me in understanding it all. I AM taking notes too
Zydrate_blue said:
Sooo yeah.... anybody got some help for this one? I have searched google and the forums but can't clearly figure this out, but how do I get a Boot.img for this phone??? I have rebuilt the kernel 3 or 4 different ways and the output never yeilds one, however I apparently NEED one so I can peel away the ramdisk x( any ideas?
Click to expand...
Click to collapse
If I recall correctly, I used the split_bootimg.pl script, and accompanying instructions, found here:
http://www.android-dls.com/wiki/?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images
Start by unpacking and repacking a kernel that you already know is functional -- i.e. a copy of a kernel you have already successfully flashed. Once that repack can be flashed successfully, you can move on to making modifications to it, or packing a whole new initramfs and kernel.
I had to remove references to a few of Samsung's proprietary modules to get the kernel to build -- Samsung helpfully supplies the places for those sources to be put (IN TREE -- shame on you Samsung), but not the sources themselves. One such module was rfs, IIRC. I removed the Makefile references so I could finish a compile, then used copies of the compiled modules from an existing initrd. Where you run into compile failures, where the source code appears to be simply missing, this is probably the cause.
I found that I had to manually strip at least the modules that resulted when I built from sources, otherwise the finished image was far too large. Compare the sizes of your compiled kernel and module files to those of a known-working reference image. They should not be too far out of line.
I wish I had saved more notes from my own kernel builds. Regular Linux kernels are so easy, but earlier Android kernels are unnecessarily horrible to build. Still, if you run into any more issues, I'll try to help...
Oh, and please disable the keystroke logger!
nxd said:
If I recall correctly, I used the split_bootimg.pl script, and accompanying instructions, found here:
http://www.android-dls.com/wiki/?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images
Start by unpacking and repacking a kernel that you already know is functional -- i.e. a copy of a kernel you have already successfully flashed. Once that repack can be flashed successfully, you can move on to making modifications to it, or packing a whole new initramfs and kernel.
I had to remove references to a few of Samsung's proprietary modules to get the kernel to build -- Samsung helpfully supplies the places for those sources to be put (IN TREE -- shame on you Samsung), but not the sources themselves. One such module was rfs, IIRC. I removed the Makefile references so I could finish a compile, then used copies of the compiled modules from an existing initrd. Where you run into compile failures, where the source code appears to be simply missing, this is probably the cause.
I found that I had to manually strip at least the modules that resulted when I built from sources, otherwise the finished image was far too large. Compare the sizes of your compiled kernel and module files to those of a known-working reference image. They should not be too far out of line.
I wish I had saved more notes from my own kernel builds. Regular Linux kernels are so easy, but earlier Android kernels are unnecessarily horrible to build. Still, if you run into any more issues, I'll try to help...
Oh, and please disable the keystroke logger!
Click to expand...
Click to collapse
Wow thanks nxd! I don't know if you have seen my other posts, but I'm a newbie at this stuff. Never too late to learn though right?
Now, as for the issues in the build, when I first tried to compile I was getting errors of an undeclared SEGMENT_SIZE in binfmt_aout.c so I searched around and was informed that the aout method is outdated? So I removed it from the config as instructed, seeing as it wasn't needed.
I've gotten to a compile resulting in the zImage and about 8 modules created. Now, the zImage is incomplete at this point if I am correct? If it's flashed, it will simply bootloop. (Because there is more to be done? i.e the ramdisk gz that loads the rom at the bootloader?)
Also, I will check the link about the logger, so I can disable it.
I appreciate all your help I really want to get this stuff down-pat eventually.
Zydrate_blue said:
I've gotten to a compile resulting in the zImage and about 8 modules created. Now, the zImage is incomplete at this point if I am correct? If it's flashed, it will simply bootloop. (Because there is more to be done? i.e the ramdisk gz that loads the rom at the bootloader?)
Click to expand...
Click to collapse
Correct, you need to put the modules onto an initramfs, and then assemble the zImage and initramfs into a boot.img. The URL I posted has instructions to both unpack and repack. I suggest that you obtain repack settings (command line, perhaps memory addressing) from an existing working image.
You can probably use the initramfs from an existing image as the basis for your new boot.img as well, replacing the modules from the old imitramfs with your new modules.
nxd said:
Correct, you need to put the modules onto an initramfs, and then assemble the zImage and initramfs into a boot.img. The URL I posted has instructions to both unpack and repack. I suggest that you obtain repack settings (command line, perhaps memory addressing) from an existing working image.
You can probably use the initramfs from an existing image as the basis for your new boot.img as well, replacing the modules from the old imitramfs with your new modules.
Click to expand...
Click to collapse
I hate to ask this because I'm afraid of being a pain in the a**.... but I hope you won't mind working with me, I'm in for the long run. Anyway, am I supposed to have a initramfs after the compile somewhere within the source? Or is this something I acquire from an an outside source? I promise I have done like 30-40 searches before hand. I have a feeling am missing something obvious -_-
Again, thank you for your generous help
Zydrate_blue said:
I hate to ask this because I'm afraid of being a pain in the a**.... but I hope you won't mind working with me, I'm in for the long run. Anyway, am I supposed to have a initramfs after the compile somewhere within the source? Or is this something I acquire from an an outside source? I promise I have done like 30-40 searches before hand. I have a feeling am missing something obvious -_-
Again, thank you for your generous help
Click to expand...
Click to collapse
The kernel compile will NOT produce an initramfs for you. It will produce the zImage (compressed kernel image) and modules.
The initramfs is an archive containing some files. During boot, when the kernel reaches the end of device initialization, it then creates an empty memory-backed filesystem, and extracts the initramfs contents into that new filesystem.
Ideally the initramfs would be generated by the Android build system, using the binaries produced by the kernel compile. But Samsung provides the bare minimum for GPL compliance, and so we don't get all the pieces we'd need for that. Presumably assembling those pieces is a big part of what windxixi has done, however.
When I worked up my boot.img, I used someone else's existing initramfs, dropped in my compiled modules and a few other minor changes, and then re-assembled it with my compiled zImage. If you're already working with windxixi's build kit and kernel sources, it might save you some time to use his initramfs as a basis for your own.
Really, once you've unpacked basically any SK4G boot.img, and extracted the files from the initramfs, I think you'll see the layout and that aspect the process will be clearer to you.
nxd said:
The kernel compile will NOT produce an initramfs for you. It will produce the zImage (compressed kernel image) and modules.
The initramfs is an archive containing some files. During boot, when the kernel reaches the end of device initialization, it then creates an empty memory-backed filesystem, and extracts the initramfs contents into that new filesystem.
Ideally the initramfs would be generated by the Android build system, using the binaries produced by the kernel compile. But Samsung provides the bare minimum for GPL compliance, and so we don't get all the pieces we'd need for that. Presumably assembling those pieces is a big part of what windxixi has done, however.
When I worked up my boot.img, I used someone else's existing initramfs, dropped in my compiled modules and a few other minor changes, and then re-assembled it with my compiled zImage. If you're already working with windxixi's build kit and kernel sources, it might save you some time to use his initramfs as a basis for your own.
Really, once you've unpacked basically any SK4G boot.img, and extracted the files from the initramfs, I think you'll see the layout and that aspect the process will be clearer to you.
Click to expand...
Click to collapse
I haven't found any boot.img from another kernel, however I have finally figured out how to unpack the zImage D I think I'm a bit closer now, however, now I need to figure out how to un-cpio the initramfs.cpio and/or use the intramfs folder I now have. (in the unpacked zImage)
Then the next step I suppose would be learning how to incorporate the modules that I have. hmm..
Zydrate_blue said:
I haven't found any boot.img from another kernel, however I have finally figured out how to unpack the zImage D I think I'm a bit closer now, however, now I need to figure out how to un-cpio the initramfs.cpio and/or use the intramfs folder I now have. (in the unpacked zImage)
Then the next step I suppose would be learning how to incorporate the modules that I have. hmm..
Click to expand...
Click to collapse
On the page I linked to in my first reply, under "Alternative Method", those instructions worked for me to split, unpack, repack, and assemble. Did they not work for you?
Regarding how to incorporate the modules, you would copy them into the extracted directory in the same locations in the initramfs as the existing module files. Generally something like /lib/modules. Look for files ending in '.ko'. They may be spread out a bit in your compiled kernel sources, but they should all be in one directory in your extracted initramfs directory.
As for an existing boot.img, it's a Froyo kernel, but there's this: http://forum.xda-developers.com/showthread.php?t=1663622.
nxd said:
On the page I linked to in my first reply, under "Alternative Method", those instructions worked for me to split, unpack, repack, and assemble. Did they not work for you?
Click to expand...
Click to collapse
I tried this method of repacking, but so far I have not been able to re-pack my zImage successfully. (I feel pretty close to getting this) Maybe I am putting the modules in the wrong place? Or perhaps I am skipping a step. I believe I need to assign more room for the modules. I am getting the error that initramfs_cpio is too large.
My initramfs has 2 directories in it- and I created a folder within called lib and placed the modules in there... that may be the wrong way, but I don't think it changes the need for more room in the kernel. Something to do with padding values maybe? /:
Also, the script I am using for this is from JunYoung- it is repack-zImage.sh a tool for de-compiling and recompiling a zImage. That's how I got to my initramfs directory in the new zImage I built with the source.
Zydrate_blue said:
I tried this method of repacking, but so far I have not been able to re-pack my zImage successfully. (I feel pretty close to getting this) Maybe I am putting the modules in the wrong place? Or perhaps I am skipping a step. I believe I need to assign more room for the modules. I am getting the error that initramfs_cpio is too large.
My initramfs has 2 directories in it- and I created a folder within called lib and placed the modules in there... that may be the wrong way, but I don't think it changes the need for more room in the kernel. Something to do with padding values maybe? /:
Click to expand...
Click to collapse
I think your extracted initramfs should have more than two directories.
Would you paste a listing of the files and directories here? Do this:
Code:
cd [path_to_extracted_initramfs] && find *
nxd said:
I think your extracted initramfs should have more than two directories.
Would you paste a listing of the files and directories here? Do this:
Code:
cd [path_to_extracted_initramfs] && find *
Click to expand...
Click to collapse
This is what I have after I unpack the zImage:
cpio-t
decompression_code
initramfs
initramfs/root
initramfs/dev
initramfs.cpio
kernel.img
padding3
padding_piggy
part3
piggy
piggy.gz
piggy.gz+piggy_trailer
piggy_trailer
ramfs+part3
sizes
EDIT: I also tested unpacking another zImage that is working, in fact I tried it on the Bali SK4G that we use currently (I hope that was okay with you /: I probably should have asked) but it just keeps displaying code as if it won't finish unpacking. It makes sense because there is a lot more to unpack, I think it is because it is compressed.
Zydrate_blue said:
This is what I have after I unpack the zImage:
cpio-t
decompression_code
initramfs
initramfs/root
initramfs/dev
initramfs.cpio
kernel.img
padding3
padding_piggy
part3
piggy
piggy.gz
piggy.gz+piggy_trailer
piggy_trailer
ramfs+part3
sizes
EDIT: I also tested unpacking another zImage that is working, in fact I tried it on the Bali SK4G that we use currently (I hope that was okay with you /: I probably should have asked) but it just keeps displaying code as if it won't finish unpacking. It makes sense because there is a lot more to unpack, I think it is because it is compressed.
Click to expand...
Click to collapse
You don't need my permission to use my Bali-based Linux kernel image or patches.
Where can I get a copy of this other boot.img you're working with? It seems clear the hacks and workarounds I used with the Bali-era kernel don't translate directly across. I'd like to take a look and see what I can make of it.
nxd said:
You don't need my permission to use my Bali-based Linux kernel image or patches.
Where can I get a copy of this other boot.img you're working with? It seems clear the hacks and workarounds I used with the Bali-era kernel don't translate directly across. I'd like to take a look and see what I can make of it.
Click to expand...
Click to collapse
Well, I never really found a literal "boot.img" from what I read I have to compile a zImage and in the sidekick's style system boots this as a boot.img??? And I have only used the one from kernel source so far, seeing as I could not get the Bali zImage to split.
As for the initramfs.cpio that us within the zImage, I tried to un-cpio it and I get an error about removing '/ from name?
I could send you the zImage I got from source o.e
EDIT: I never found a copy of boot.img, I couldn't even get one from an outer-source.
Sent from my SGH-T959V using xda app-developers app
Zydrate_blue said:
As for the initramfs.cpio that us within the zImage, I tried to un-cpio it and I get an error about removing '/ from name?
Click to expand...
Click to collapse
That's more of an advisory than an error. It's just telling you that it's stripping off the leading /, i.e. extracting to a relative path.
It sounds like you probably succeeded in extracting the initramfs.
nxd said:
That's more of an advisory than an error. It's just telling you that it's stripping off the leading /, i.e. extracting to a relative path.
It sounds like you probably succeeded in extracting the initramfs.
Click to expand...
Click to collapse
Well, then that sounds better! But what about this one:
cpio: dev/console: Cannot mknod: Operation not permitted
1 block
I forgot there was a following error
Zydrate_blue said:
Well, then that sounds better! But what about this one:
cpio: dev/console: Cannot mknod: Operation not permitted
1 block
I forgot there was a following error
Click to expand...
Click to collapse
You'll probably want to extract the files as root. Otherwise device nodes won't be created, like above, and permissions won't be kept on any of the files.
Be careful to be in a safe (i.e. empty) working directory when you do that. It will extract the files into your current working directory.
nxd said:
You'll probably want to extract the files as root. Otherwise device nodes won't be created, like above, and permissions won't be kept on any of the files.
Be careful to be in a safe (i.e. empty) working directory when you do that. It will extract the files into your current working directory.
Click to expand...
Click to collapse
Okay so now after I execute as root, it gives me this message:
cpio: /dev/console not created: newer or same age version exists
So the directories are empty after extracted?
Zydrate_blue said:
Okay so now after I execute as root, it gives me this message:
cpio: /dev/console not created: newer or same age version exists
So the directories are empty after extracted?
Click to expand...
Click to collapse
There's another argument you needed: --no-absolute-filenames
Unfortuantely it looks like cpio will have kept the absolute path and overwritten files on your real machine.
Extract into a directory using --no-absolute-filenames and see what files on your host system were overwritten. Those files should be recovered somehow before proceeding.
Sorry I didn't catch that.
nxd said:
There's another argument you needed: --no-absolute-filenames
Unfortuantely it looks like cpio will have kept the absolute path and overwritten files on your real machine.
Extract into a directory using --no-absolute-filenames and see what files on your host system were overwritten. Those files should be recovered somehow before proceeding.
Sorry I didn't catch that.
Click to expand...
Click to collapse
Oh god -_- wow I messed up then. well....the only file that was within the cpio was a file named console.... so I think I need to fix that?
I'm not mad or anything, it's a risk you take ya know? But I may need help.
EDIT: Okay so I reboot my laptop and it reboot fine, no issues. I don't think it actually overwrote any file (luckily because that cpio file didn't have anything in it...heh) So should I now try the command with the new argument?
Zydrate_blue said:
Oh god -_- wow I messed up then. well....the only file that was within the cpio was a file named console.... so I think I need to fix that?
I'm not mad or anything, it's a risk you take ya know? But I may need help.
EDIT: Okay so I reboot my laptop and it reboot fine, no issues. I don't think it actually overwrote any file (luckily because that cpio file didn't have anything in it...heh) So should I now try the command with the new argument?
Click to expand...
Click to collapse
I'll take a look at the boot image this evening. It would seem very odd to me if the only file on the initramfs was /dev/console.
Hello I am trying to flash the factory image on to my Nexus 5 with the flash all option in the zip file and it keep going missing boot.img as seen in the picture and I am unsure what to do at this point cause I disconnect my phone and it does boot up in to android 4.4.4 but I need help here
hell I would let some one remote connect if that helps any lol
Buckii said:
Hello I am trying to flash the factory image on to my Nexus 5 with the flash all option in the zip file and it keep going missing boot.img as seen in the picture and I am unsure what to do at this point cause I disconnect my phone and it does boot up in to android 4.4.4 but I need help here
hell I would let some one remote connect if that helps any lol
Click to expand...
Click to collapse
1) "Stuck" is NOT a question. Please use descriptive thread titles
2) You haven't unzipped the image-hammerheadxxx.zip that contains the images :/
but I have I followed the instructions to a T and put all file in the folder under platform tools
Buckii said:
but I have I followed the instructions to a T and put all file in the folder under platform tools
Click to expand...
Click to collapse
Not sure what instructions you've followed. Either they're incomplete or you made a mistake. Like I said, your screenshot shows a zip file. You need to unzip that in the location that it is in now
picture
rootSU said:
Not sure what instructions you've followed. Either they're incomplete or you made a mistake. Like I said, your screenshot shows a zip file. You need to unzip that in the location that it is in now
Click to expand...
Click to collapse
This is now what I have done you were right but still missing boot.img
Buckii said:
This is now what I have done you were right but still missing boot.img
Click to expand...
Click to collapse
Just fastboot flash it then.
Link to guides in my signature.
I have similar issues. Mine complains that the archive doesn't contain boot.sig and recovery.sig, and then it fails to allocate space and the update package missing system.img.
Going to do it manually now to see if it works
Desca said:
I have similar issues. Mine complains that the archive doesn't contain boot.sig and recovery.sig, and then it fails to allocate space and the update package missing system.img.
Going to do it manually now to see if it works
Click to expand...
Click to collapse
Mine shows same as you, but just reboot and it is working
Hello all.
I haven't posted here for years. My account is still active, but I am no longer allowed to post in specific forums regarding ROMs, so I am asking here.
[moderators: sorry if this is the wrong topic. It is the closest I could find, since my question is not device specific]
I have an Android 9 box which is signed with AOSP test certificates.
I also have an update.zip file for this box.
This box has A/B OTA support, it is working and verified through fastboot.
I want to edit and repackage the update.zip
I know how to do it on old ROMs, but I could not find any tool that can repackage payload.bin
There are several tools to unpack it, and I used one to extract boot.img and system.img
But I can't find any way to package these files back in to payload.bin format.
I tried various google searches and even analyzing the open source unpacking tools, but building a packaging tool from scratch is too complex for me at this point.
Any advice?
Have you found anything for this? I am trying to repack the payload.bin as well from modified IMG files, but I cant find anything on the web.
I extracted this script from linux-86 tools, pretty sure this is the one that repacks all the images into payload.bin, but donno what's the exact code inside it that makes it possible... Understand the last 100 lines & you might succeed.
MPK99 said:
I extracted this script from linux-86 tools, pretty sure this is the one that repacks all the images into payload.bin, but donno what's the exact code inside it that makes it possible... Understand the last 100 lines & you might succeed.
Click to expand...
Click to collapse
MPK99 said:
I extracted this script from linux-86 tools, pretty sure this is the one that repacks all the images into payload.bin, but donno what's the exact code inside it that makes it possible... Understand the last 100 lines & you might succees
Click to expand...
Click to collapse
Please Teach me, how to repack .img files into payload.bin
Did u Already Know How To Repack .img Files Into Payload.bin?
MPK99 said:
I extracted this script from linux-86 tools, pretty sure this is the one that repacks all the images into payload.bin, but donno what's the exact code inside it that makes it possible... Understand the last 100 lines & you might succeed.
Click to expand...
Click to collapse
Hello do you still have this script trying to repack a QCM6125 with magisk and twrp
Edit: Its advised to use superR's kitchen
SuperR Kitchen
forum.xda-developers.com
Hey
I've also tried everything, how do you pack it back into a payload.bin, I only wanted usb rights in the Platform.xml, I didn't want that anymore, that's enough for me, but how do I pack it again, thanks
I'm asking here as I never got an answer, sorry
don't want root
Thanks
Hello all, I am trying to unpack man files to add volte support to a device that has all the hardware needed, but it is not enabled in software and I would like to try and change that. From all my research the files I need are all in the baseband and in .mbn file format, but I cannot find out how to unpack them. Any help would be appreciated!
ghidra or IDA
I'm more conversant with Qualcomm ELF files, hashing, signing and certs.
These seem to have replaced the older MBN.
MBN files are signed. If you mod you'll have to work around this somehow.
See: https://github.com/openpst/libopenpst/blob/master/include/qualcomm/mbn.h
https://github.com/jnaulet/dloadtool/blob/master/mbn.h
Renate said:
I'm more conversant with Qualcomm ELF files, hashing, signing and certs.
These seem to have replaced the older MBN.
MBN files are signed. If you mod you'll have to work around this somehow.
See: https://github.com/openpst/libopenpst/blob/master/include/qualcomm/mbn.h
https://github.com/jnaulet/dloadtool/blob/master/mbn.h
Click to expand...
Click to collapse
I see. This device is quite old and well, to say the least it isn’t an android device either. I’m assuming I would need to find a workaround for this even as it’s running an os that’s nearly a decade old now?
I know that the carrier bundles on this device are signed as well, but people were able to get around that, and this chip was supposedly made with the hexagon DSP and Qualcomm has documentation on how to program for this specific chip/version
aIecxs said:
ghidra or IDA
Click to expand...
Click to collapse
Unfortunately these don't appear to work, or im using them incorrectly
well, maybe you're not an reverse engineer
aIecxs said:
well, maybe you're not an reverse engineer
Click to expand...
Click to collapse
Maybe it’s my first time even hearing of either of those programs and can’t even get one of them to launch without insta crashing, and the other spitting out an error whenever I try to unpack the files.
no problem. just 10 year studying stuff and try again
https://github.com/lololosys/awesome-baseband-research
Hi,
I've probably managed to reverse engineer the MBN. I was able to create my own MBN and load it back.
If anyone wants to get an information, send me a message
RockL79 said:
Unfortunately these don't appear to work, or im using them incorrectly
Click to expand...
Click to collapse
rename it to *.zip
Vortuks said:
Hi,
I've probably managed to reverse engineer the MBN. I was able to create my own MBN and load it back.
If anyone wants to get an information, send me a message
Click to expand...
Click to collapse
they are only ELF files packed in an image, aren't they?
yeah ELF files, with 3 segments. I'm not sure about my knowledge about ELF vs MBN, but I've managed & have a program to extract $ repackage back. I've tested it on Pixel 2 XL and it's working (added support for my country).
WoKoschekk said:
rename it to *.zip
Click to expand...
Click to collapse
unfortunately that didnt work for me either. It could be that the device im trying to work on is quite old and maybe something else has changed since then