Anyone skilled in disassembling/hex editing?

[TheConnactic]

We're working to add Quartz Extreme/Core Image support to an Intel integrated graphics card closely related to the GMA950 family. The card in question is the GMA3150. For this task, we choose to work with the 10.7.x GMA950 kext, only because it's the one with we're getting better results until now, and Lion is the last iteration of OSX that supports GMA950. But Mountain Lion is a mid-term goal, and adding full GMA950 support under 10.8.x could be a good side effect of this effort we're making (possibly using the 64-bit GMA950 10.6.2 kext, which is already being used with partial success).

Here's what we already achieved:

- The GMA950 kext load and recognizes the 3150 card. QE/CI is enabled, but the drivers are unusably slow (the boot time can exceed 30 min. or more just to get to the desktop);
- Other side effect was a cursor corruption that meklort was able to correct;
- When we add the correct same subsystem vendor and device IDs to the kext, the slowness is corrected and we get OpenGL support, but no QE/CI;
- In Mountain Lion, loading the patched kexts results in slowness and no QE/CI, but it's probably related to the fact it's unsupported in ML;
- By analizing the Linux drivers and other data for both GMA950 and GMA3150, we managed to isolate the parameters we should look for to correct the above issues. The problem is that, since we don't have access to the source of the GMA950 kexts, we have to work with the binaries, which means that hex editing/disassembling are crucial to the complete success we're so close to achieve. Unfortunately, neither arches (who's made the better part of the work, patching and research) nor me are skilled enough in these fields to effectively do something. So we're asking for your help.

Here's the webpage where we're posting our results: http://www.osx86.net/video-graphics/9447-gma-3150-a-1.html

Thank you!

 

[SJ_UnderWater]

general disassembly uses `otool` from Terminal (installed w/ Xcode), there are a few good uses, among others:

otool -XL <binary>

otool -XD <dylib>

otool -Xl <binary>

otool -Xl <binary> | grep -A 3 MAC

otool -qXVo <binary>

otool -qXVt <binary>

otool -qXVt <binary> | c++filt

--edit

nm <binary>

Note that "q" above uses the llvm (low-level virtual machine, the Clang compiler toolchain, replaces GCC) which generally produces better assembly. If you see functions like __ZN, use c++filt to unmangle the function names. "X" strips any headers or addresses from the output.

--edit
i forgot to mention that using `otool` to read the mach/fat-binary header is usually more trouble than just using `file <binary>`. File will tell you the type (dynamic, archive, executable, etc) and architecture(s). Rarely the "k" flag is necessary (keep-going). Of course `man otool` and `man file` will provide more comprehensive info.