I ported the LHA Decompressor for Java library to a .NET library called LHA Decompressor.
PicoSharp
I'm working on a PICO-8 emulator written in C# called PicoSharp.
AgileVR Manager
We wrote this desktop application in WPF which injects leg movement data into SteamVR or Oculus hardware.
BM70/71 Firmware Backdoor
Hey Microchip I think I found a backdoor in your BM70/71 firmware!
Gigabyte Aero 15 v8 (FB0A BIOS Unlocked)
Disclaimer: Do this at your OWN RISK! I will not be held responsible for anyone bricking their machine!
I made the mods based on @Lost_N_BIOS's post here and by following the How-2-Rip-It-Open-Yourself guide here.
This patch has been confirmed to work with both 15X v8 and 15W v8 models. Make sure you have your Aero's BIOS flashed to version FB0A using the official release on the Gigabyte website here before attempting the following.
First you must run command prompt (as Administrator) and run "FPTw.exe -bios -d biosreg.bin". You can get FPTw.exe from Intel CSME System Tools v12 r18 (located in the "Flash Programming Tool" folder).
Next you will need to run UEFITool 0.26.0 and open biosreg.bin. Select File->Search... Text tab and enter AMITSE. A list of search results will show at the bottom. Double click on "Unicode text "AMITSE" found in User interface section at offset 0h". Right click on the "PE32 image section" and select "Replace as is...". Browse to the (unzipped) file attached (Section_PE32_image_AMITSE_AMITSE.zip). File->Save image file... and call it biosmod.bin.
Then you need to run AMIBCP 5.02.0031 and open biosmod.bin to set the menu access to USER like so:
Once you File->Save run "FPTw.exe -bios -f biosmod.bin".
If you get the following error:
Quote:Error 167: Protected Range Registers are currently set by BIOS, preventing flash access.
This is caused by the BIOS Lock variable set to 0x01 (Enabled):
Code:
BIOS Lock, VarStoreInfo (VarOffset/VarName): 0xA12
How to set the BIOS Lock variable to 0x00 (Disabled):
- Make sure you have following values set in BIOS:
- Legacy Support: Disable
- Secure Boot: Disable - Take USB stick and format to FAT32
- Create directory structure EFI\Boot
- Download and unzip bootx64.7z
- Put BOOTX64.EFI into Boot directory
- Boot from this USB stick
- Run command: setup_var 0xA12 0x00
- Run command: reboot
Attempt to write the modified BIOS again using FPTw.exe.
If successful this time run "FPTw.exe -greset" to reboot.
Press F2 to enter BIOS you should (hopefully) be greeted with some extra menus...
Big thanks to @Lost_N_BIOS!
USB KVM
Menu bar software for macOS 64-bit to support ActionStar chip based KVM hardware.
Vendor ID 0x2101 / 0x0835 is ActionStar (www.actionstar.com.tw)
Supported Hardware:
2101:1403, 2101:1404, 2101:1406, 2101:1407, 2101:1411, 0835:1403, 0835:1404, 0835:1406, 0835:1407, 0835:1411
Credits:
Source
BrcmPatchRAM2 for macOS 10.15 Catalina
I'm just going to run through some of the changes I made to RehabMan's BrcmPatchRAM project for it to function in macOS Catalina. I don't really have time to go any further with it but hopefully my research and testing can help get an official working version out.
I'm using BrcmFirmwareData.kext
, BrcmPatchRAM2.kext
and BrcmBluetoothInjector.kext
and place them inside EFI/CLOVER/kexts/Other
BrcmBluetoothInjector.kext was not required on previous macOS releases but is on Catalina because of the following missing IOCatalogue
methods:
kxld[com.no-one.BrcmPatchRAM2]: The following symbols are unresolved for this kext:
kxld[com.no-one.BrcmPatchRAM2]: IOCatalogue::addDrivers(OSArray*, bool)
kxld[com.no-one.BrcmPatchRAM2]: IOCatalogue::removeDrivers(OSDictionary*, bool)
kxld[com.no-one.BrcmPatchRAM2]: IOCatalogue::startMatching(OSDictionary*)
Since these methods are no longer available they must be removed from the project. The easiest way to do this is to comment out publishPersonality()
and publishResourcePersonality()
methods from BrcmPatchRAM.cpp
/ BrcmPatchRAM.h
. Also remove all calls to these methods in BrcmPatchRAM.cpp
.
The next issue is dealing with the 0xe00002c2 error when reading and writing to the BRCM hardware. Starting with BrcmPatchRAM::continuousRead()
and BrcmPatchRAM::readCompletion()
we need to add an kIODirectionIn
option.
ie.
mReadBuffer = IOBufferMemoryDescriptor::inTaskWithOptions(kernel_task, kIODirectionIn, 0x200);
IOReturn result = mReadBuffer->prepare(kIODirectionIn);
IOReturn result = me->mReadBuffer->complete(kIODirectionIn);
Next in BrcmPatchRAM::bulkWrite
we need to add kIODirectionOut
options.
if (IOMemoryDescriptor* buffer = IOMemoryDescriptor::withAddress((void*)data, length, kIODirectionOut))
if ((result = buffer->prepare(kIODirectionOut)) == kIOReturnSuccess)
if ((result = buffer->complete(kIODirectionOut)) != kIOReturnSuccess)
Now that we don't have IOCatalogue::addDrivers
, IOCatalogue::removeDrivers
and IOCatalogue::startMatching
methods to switch from using the uploader driver to native macOS driver we have to use BrcmBluetoothInjector.kext
instead.
So my Bluetooth device is a BCM20702A0 with VendorID 0x0A5C and ProductID 0x216F (Dell DW1560 4352+20702 M.2) located in internal USB port HS14. So I'll use it as an example for the following modifications.
In BrcmPatchRAM2-Info.plist
we need the following entry. Note the addition of the IOProbeScore
. When the kext is loaded it will call BrcmPatchRAM::probe
which will update the firmware and return NULL and then the BrcmBluetoothInjector.kext
should load instead.
<key>0a5c_216f</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.no-one.$(PRODUCT_NAME:rfc1034identifier)</string>
<key>DisplayName</key>
<string>DW1560 Bluetooth 4.0 LE</string>
<key>FirmwareKey</key>
<string>BCM20702A1_001.002.014.1443.1572_v5668</string>
<key>IOClass</key>
<string>BrcmPatchRAM2</string>
<key>IOMatchCategory</key>
<string>BrcmPatchRAM2</string>
<key>IOProviderClass</key>
<string>IOUSBHostDevice</string>
<key>IOProbeScore</key>
<integer>4000</integer>
<key>idProduct</key>
<integer>8559</integer>
<key>idVendor</key>
<integer>2652</integer>
</dict>
In BrcmBluetoothInjector-Info.plist
we need the following entry. Note again the addition of the IOProbeScore
. We want the BrcmBluetoothInjector.kext
to load the macOS kext after the firmware has been uploaded to the hardware. Since BrcmBluetoothInjector.kext
has not been updated in a long time you may need to add your hardware manually to the plist. Note that your Bluetooth device VendorID / ProductID is not the same as your WiFi hardware and will not show up in your PCI list. You will need to look at the USB ports to get this info.
<key>0a5c_216f</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport</string>
<key>IOClass</key>
<string>BroadcomBluetoothHostControllerUSBTransport</string>
<key>IOProviderClass</key>
<string>IOUSBHostDevice</string>
<key>IOProbeScore</key>
<integer>3000</integer>
<key>idProduct</key>
<integer>8559</integer>
<key>idVendor</key>
<integer>2652</integer>
</dict>
You will know the firmware is uploaded when its version in About This Mac->System Report...->Bluetooth shows something like:
Firmware Version: v14 c5668
If it shows 4096 then the upload has failed.
I will attach my compiled versions for people to help test. I'm not 100% sure if this is method is going to work so I'd appreciate feedback on it.
GameEx Evo Default Themes
What do you guys think of the default themes?
GameEx Evo Screenshots
Here are some screenshots of the new GameEx Evolution default theme.
GameEx Evo Map Files
GameEx Evolution still supports Map Files. What do you guys think? Are they still useful?