19 May
https://bshastry.github.io/2019/01/18/Deconstructing-LPM.html
https://youtu.be/xzG0pLM4Q64?t=1595
https://chromium.googlesource.com/chromium/src/+show/master/testing/libfuzzer/libprotobuf-mutator.md
https://chromium.googlesource.com/chromium/src/testing/libfuzzer/+/HEAD/libprotobuf-mutator.md
14 May
Learning the trick from Paul E McKenney:
https://paulmck.livejournal.com/53002.html
The answer is to use ccache:
http://nickdesaulniers.github.io/blog/2018/06/02/speeding-up-linux-kernel-builds-with-ccache/
http://linuxdeveloper.blogspot.com/2012/05/using-ccache-to-speed-up-kernel.html
Questions:
How ccache integrate with Make during compilation?
What the activities involved? Is it suspectible to vulnerability? Will it be easily exploited?
8 May
The WiFi adapter is from Amazon (Alfa Network AWUS036NHA, https://www.amazon.com/Alfa-AWUS036NHA-High-Wireless-Adaptor/dp/B004YD7UBQ/ref=sr_1_1_sspa?keywords=Alfa+Network+AWUS036NHA&qid=1557279660&s=gateway&sr=8-1-spons&psc=1, buying anywhere else and I may likely get a fake product)
This is what I get from “dmesg”:
And the firmware which is loaded dynamically by the kernel (seen from “dmesg” above) – is inside the /lib/firmware directory:
Or diagrammatically illustrated below (diagram is from: https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/)
In summary, the firmware is loaded by kernel into PC’s RAM, and then uploaded into the RAM of the WiFi chip. Doing a “strings” on the firmware:
_wmi_cmd_rsp usb_reg_out_patch ath_enable_aggr_tgt A_WDT_INIT() ==>WDT reset<== ==>warm start<== ==>cold start<== ALLOCRAM start 0x%x size %d Enable Tx Stream mode: 0x%x USB mode: 0x%x Tgt running %s: buffer allocation for event_id %x failed! [+++Magpie_init] [+++VBUF_init(%d)] Cold reboot initiated. EP4 FIFO Bug? Buffer is too big: %x %s: Filed to get new buffer. %s: Data length on EP4 FIFO is bigger as allocated buffer data! Drop it! ath_hal = %p <wlan_pci_probe>: Attaching the driver <wlan_pci_probe>: Vendor id 0x%x Dev id 0x%x Cannot malloc softc !USB suspend ![SOURCE_0] bit7 on !USB reset !USB resume change clock to 22 and go to suspend now! <null> 0123456789 0123456789abcdef 0123456789ABCDEF ath_pci: no memory for device state ath_pci_probe %x ath_pci ath_pci_tgt SEEPROM Read fail: 0x%08x Buf null VERY LONG PACKET!!!!! ds_tmp is NULL [%s] enable_aggr with invalid tid %d(node = %d) found bc_hdr! 0x%x beacon tid[%p]->incomp is not 0: %d drop frame due to TID reinit TID REINIT DONE for tid %p
From above, Google search for “ath_pci: no memory for device state” immediately leads me to:
https://github.com/qca/open-ath9k-htc-firmware
which is the openfirmware branch of Qualcomm.
Among the strings, “VERY LONG PACKET” looked interesting. And so searching the source code:
And this thus indicated a high likelihood of match between firmware binary and source codes in github.
Nevertheless, doing a “make toolchain” and “make -C target_firmware” according to:
https://github.com/qca/open-ath9k-htc-firmware
result in the creation of the firmware:
make[3]: Entering directory '/home/peterteoh/vuln/open-ath9k-htc-firmware/target_firmware/build/k2' [ 2%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/init/app_start.c.obj [ 5%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/init/init.c.obj [ 8%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/init/magpie.c.obj [ 11%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/adf/adf_nbuf.c.obj [ 14%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/adf/adf_net.c.obj [ 17%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/adf/adf_os_defer_pvt.c.obj [ 20%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/adf/adf_os_dma.c.obj [ 23%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/adf/adf_os_irq_pvt.c.obj [ 26%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/adf/adf_os_timer.c.obj [ 29%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/buf_pool/buf_pool_static.c.obj [ 32%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/cmnos/dbg_api.c.obj [ 35%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/cmnos/cmnos_sflash.c.obj [ 38%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/hif/usb_api_main_patch.c.obj [ 41%] Building C object CMakeFiles/firmware.dir/wlan/ah.c.obj [ 44%] Building C object CMakeFiles/firmware.dir/wlan/ah_osdep.c.obj [ 47%] Building C object CMakeFiles/firmware.dir/wlan/ar5416Phy.c.obj [ 50%] Building C object CMakeFiles/firmware.dir/wlan/ar5416_hw.c.obj [ 52%] Building C object CMakeFiles/firmware.dir/wlan/ar5416_phy.c.obj [ 55%] Building C object CMakeFiles/firmware.dir/wlan/ratectrl_11n_ln.c.obj [ 58%] Building C object CMakeFiles/firmware.dir/wlan/if_owl.c.obj [ 61%] Building C object CMakeFiles/firmware.dir/wlan/if_ath.c.obj [ 64%] Building C object CMakeFiles/firmware.dir/wlan/if_ath_pci.c.obj [ 67%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/wlan/wlan_pci.c.obj [ 70%] Building C object CMakeFiles/firmware.dir/wlan/ieee80211_output.c.obj [ 73%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/htc/htc.c.obj [ 76%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/wmi/wmi_svc.c.obj [ 79%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/hif/k2_HIF_usb_patch.c.obj [ 82%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/hif/usb_api_k2_patch.c.obj [ 85%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/cmnos/k2_cmnos_clock_patch.c.obj [ 88%] Building C object CMakeFiles/firmware.dir/magpie_fw_dev/target/cmnos/k2_fw_cmnos_printf.c.obj [ 91%] Linking C static library libfirmware.a make[3]: Leaving directory '/home/peterteoh/vuln/open-ath9k-htc-firmware/target_firmware/build/k2' [ 91%] Built target firmware make[3]: Entering directory '/home/peterteoh/vuln/open-ath9k-htc-firmware/target_firmware/build/k2' Scanning dependencies of target gen-firmware make[3]: Leaving directory '/home/peterteoh/vuln/open-ath9k-htc-firmware/target_firmware/build/k2' make[3]: Entering directory '/home/peterteoh/vuln/open-ath9k-htc-firmware/target_firmware/build/k2' [ 94%] Generating fw.elf [ 97%] Generating fw.bin [100%] Generating htc_9271.fw
Looking at the compiler generated by the toolchain:
The compiler is “xtensa-unknown-eff”:
https://www.lortex.org/posts/esp32/2018/03/28/the-xtensa-architecture.html
https://0x04.net/~mwk/doc/xtensa.pdf
And the linker scripts provide details on how the binary (htc_9271.fw) is created.
And both gHidra and IDA Pro cannot recognize this architecture (xtensa). :-(.
Luckily for us, the toolchain does generate all the objdump* tools:
And doing a disassembly listing of “fw.elf”:
This is the format (fw.elf) before it cut converted into htc.fw format.
As for the details of how buffer is managed some details are described here (with some unknowns):
https://github.com/vanhoefm/modwifi-ath9k-htc/wiki/Buffer-Management
https://github.com/vanhoefm/modwifi
References:
https://esden.net/blubb/xtensa/programmers_guide.pdf
https://stackoverflow.com/questions/54387723/how-to-map-reset-vector-in-xtensa-architecture
https://studylib.net/doc/18130530/xtensa-instruction-set-architecture–isa–reference-manual
https://www.cadence.com/content/cadence-www/global/en_US/home/training/all-courses/86037.html
https://www.lortex.org/posts/esp32/2018/03/28/the-xtensa-architecture.html
https://0x04.net/~mwk/doc/xtensa.pdf
https://2018.zeronights.ru/wp-content/uploads/materials/19-Researching-Marvell-Avastar-Wi-Fi.pdf
https://github.com/vanhoefm/modwifi-ath9k-htc/wiki/Timing-Functions
Kernel Planet LWN news Android Developer BlogResearch scattered with thoughts, ideas, and dreams
Offensive Techniques & Methodologies
@astr0baby on Twitter for fresh randomness
playing around with open data to learn some cool stuff about data analysis and the world
Data | ML | NLP | Python | R
Just a thought
A Graduate Course Offered at Université de Montréal
Philippe Paradis - My solutions to the image inpainting problem
Pedro Emanuel Almeida Cardoso
Pulkit's thoughts on the course project
No man but a blockhead ever wrote except for money -- Samuel Johnson
a random walk through Computer Science research, by Adrian Colyer
Shakir's Machine Learning Blog
My Technical Blog 
You must be logged in to post a comment.