ALFA AWUS036NHA hacking EEPROM via UART/JTAG

[mrflash]

Hi,
@mrflash:

- There's no need to remove the EEPROM from the card. It's a I2C memory, so you could just solder 2 thin wires (SDA and SCK) if you've got a i2c programmer.
(I'm using a raspberry pi as i2c programmer)

I ordered up a new 036NHA that I can use for testing and I also got my FlashCAT I2C reader. I tried to read the eeprom without removing it but that did not work. What I did was just connect all wires to the chip (using the clip that came with the programmer) and started the read program.
I did not connect USB power to the board.
Do you power the board first before you read it?
Also what about WP that is default high. How do you lower it to be able to write to the chip?

[brunoaduarte]

I ordered up a new 036NHA that I can use for testing and I also got my FlashCAT I2C reader. I tried to read the eeprom without removing it but that did not work. What I did was just connect all wires to the chip (using the clip that came with the programmer) and started the read program.
I did not connect USB power to the board.
Do you power the board first before you read it?
Also what about WP that is default high. How do you lower it to be able to write to the chip?

No, i did not power the board... I just connect SDA, SCK and GND, and i can read the chip.

To write, i manually bridge WP to GND using a tweezer and press the keyboard to execute the write script, then remove the tweezer.

FIY: I'm not able to read the chip when WP is connected to GND, so i only do it when i need to write, and then i remove the tweezer from the pins to verify the written data.

[mrflash]

No, i did not power the board... I just connect SDA, SCK and GND, and i can read the chip.

To write, i manually bridge WP to GND using a tweezer and press the keyboard to execute the write script, then remove the tweezer.

FIY: I'm not able to read the chip when WP is connected to GND, so i only do it when i need to write, and then i remove the tweezer from the pins to verify the written data.

How does the chip get power if you don't connect VCC or the USB cable to the pcb?
Is your reader powered with 5v or 3.3v?
I still cant get it to work

[brunoaduarte]

How does the chip get power if you don't connect VCC or the USB cable to the pcb?
Is your reader powered with 5v or 3.3v?
I still cant get it to work

My reader is a RaspberryPi, so it's 5V.

It's not needed to power the alfa card. Only those 3 lines connected are enough.

[mrflash]

My reader is a RaspberryPi, so it's 5V.

It's not needed to power the alfa card. Only those 3 lines connected are enough.

Ok.
Do you send the bit pattern 1010<3 high bit address>0 followed by 8bit low address and then 1010<3 high bit address>1 followed by 8bit low for then to read 1 byte data?
Something like tihis:

i2c_start();
i2c_write((0xa0|(BYTE)(address>>7))&0xfe);
i2c_write(address);
i2c_start();
i2c_write((0xa0|(BYTE)(address>>7))|1);
data=i2c_read(0);
i2c_stop();


And I guess since you don't mention it you don't use any pullups on SDA/SCL.

[mokba]

No, i did not power the board... I just connect SDA, SCK and GND, and i can read the chip.

To write, i manually bridge WP to GND using a tweezer and press the keyboard to execute the write script, then remove the tweezer.

FIY: I'm not able to read the chip when WP is connected to GND, so i only do it when i need to write, and then i remove the tweezer from the pins to verify the written data.

Hi

I've been struggling with openwrt device trying to read the chip from tplink usb adapter, but i2cdetect does not find any. At first i wasn't sure if my connection is good, but even now following your example with GND wire and 10K pullups between SDA/SCL - 3.3V lines does not return anything.

Can you tell us what should be default state of SDA/SCL gpios when proper connection is made and what is the voltage between these two gpios and GND? I've got about 1.40V between SDA and GND and 1.36V between SCL and GND. Both default to low:

 gpio-16  (scl                 ) in  lo    
 gpio-17  (sda                 ) in  lo

[mokba]

serial output use baudrate 19200

ASIC-ROM_1.8
1. 40Mhz
2. post
3. eep chk
[%s+]
patch.offset: 0x%04x, patch.size : 0x%04x
[%s+]
CheckSum: 0x%08x
	size: %d bytes
	ld_addr: 0x%08x
	fun_addr: 0x%08x
copy %d bytes from 0x%08x to 0x%08x[%s-]
[%s-]
4. cold start
5. usb only!!
6. read usb_conf(0x%04x) to ram(0x%08x)
7. usb_hclk rdy
8. download
- custom usb config
- custom usb config
	[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
	[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
	[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
	[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
	[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
	[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
	[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
	[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
	[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
	[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
	[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
	[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
	[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
	
==>[cUSB_REQ_COMP]: 0x%08x
VendorCmd: DownloadComplete!
5. usb only!!
 A_WDT_INIT()
 ==>cold start<==
ALLOCRAM start 0x50d80c size 106484
Enable Tx Stream mode: 0x30f
USB mode: 0xf
[+++Magpie_init]
[+++VBUF_init(100)]
[+++VBUF_init(100)]
<wlan_pci_probe>: Attaching the driver
<wlan_pci_probe>: Vendor id 0x168c Dev id 0x24
ath_pci_probe 24
 ath_hal = 0x00510928 

	=>[dnQ] 0x0050f288 
[	=>[upQ] 0x0050f264 
[	=>[hp dnQ] 0x0050f240 
[	=>[mp dnQ] 0x0050f21c 
[Tgt running

[mittie]

Hi. I was able to achieve 26dBm out of awus036nha, not sure if it is possible to get more, since inside the driver it adds +5 dBm constantly, so it ends up being 31dBm.
And it is unclear for what setting this alfa card is rated for external 30dBm (iwconfig wlanX txpower 30), or to the internal representation including those +5dBm.
Unfortunately I can not make proper RF measurements, so I use WIFI monitor, and I can clearly see that there is a 5-6 dB difference in power level of RF signal from my AP that uses awus036nha. And it was not like that before, when it was stuck at 20 dBm no-matter what power I set above that value.
So basically you do not need to touch EEPROM at all, just regular RegDB patches plus a change in backports-4.4.2-1/drivers/net/wireless/ath/ath9k/eeprom_4k.c (I am using https://www.kernel.org/pub/linux/ker...4.4.2-1.tar.xz).
I was reluctant to create a patch since I was not working under any version control, so here is the source snippet I changed:

 682         if (test)
 683             return;
 684 
 685         for (i = 0; i < Ar5416RateSize; i++){
 686                 if (ratesArray[i] && (ratesArray[i] < powerLimit))
 687                         ratesArray[i] = powerLimit;
 688 
 689                 ratesArray[i] -= AR5416_PWR_TABLE_OFFSET_DB * 2;
 690                 printk("ratesArray[%d]=%d\n", i, ratesArray[i]);
 691         }
 692 
 693         ENABLE_REGWRITE_BUFFER(ah);

[mokba]

nice, i'll give this a try.

for +5dBm offset consider it being -5dBm actually, probably because of EIRP calculation with default little antenna. i don't care about EIRP, but am looking to get ERP at nominal value

[mittie]

Yes but I do not understand if alfa card itself rated for 30dBm, it means 26dBm in iwconfig txpower or it needs to be 30 there too?
Anyway i am waiting for my USB power meter to come to see actual power drain for different power levels.

[mittie]

Anyway I tested alfa with USB power meter, apparently this power meter interfere somehow with USB, since alfa can only work through it on 20dBm power, anything more and it just enters some weird state where it consume almost no power, I also tested tw-722 and can confirm that its maximum is 23dBm, and weirdly it works ok through power meter. Need to play with FW sources, maybe I can further raise power from there.

[mokba]

Found some info about the checksum here:
http://lxr.free-electrons.com/source.../eeprom_9287.c
At line 231 they calc the checksum.

So it looks like the eeprom struct

struct base_eep_ar9287_header {
442         u16 length;
443         u16 checksum;
444         u16 version;
445         u8 opCapFlags;
446         u8 eepMisc;
447         u16 regDmn[2];
448         u8 macAddr[6];
449         u8 rxMask;
450         u8 txMask;
451         u16 rfSilent;
452         u16 blueToothOptions;
453         u16 deviceCap;
454         u32 binBuildNumber;
455         u8 deviceType;
456         u8 openLoopPwrCntl;
457         int8_t pwrTableOffset;
458         int8_t tempSensSlope;
459         int8_t tempSensSlopePalOn;
460         u8 futureBase[29];
461 } __packed;

Starts at offset 0x80 in the 24c08 eeprom and are 0x178 bytes long.

So when I take my original data from offset 0x80 and xor it like they do I get 0xFFFF as result.
Will have to remove the chip again and calc new checksum.
Also I notice some interesting in the struct.
There are two bytes there called rxMask and txMask. They are set to 01 in my eeprom. Wonder if they have anything to do with tx power??

Anyway. Here is the code I made to verify the checksum.

	DWORD i;
	WORD *w = (WORD*)eeprom; //eeprom point to offset 0x80 and sizeof(eeprom) is 0x178
	WORD sum = 0;

	for(i = 0; i < sizeof(eeprom)/2; i++)
	{
		sum ^= w[i];
	}

	printf("%04X\n", sum); //If sum == 0xFFFF then all is good

rxMask and txMask might stand for number of antennas, since we know 2 chainz should output more power than single chain you could try to set them to 02 and see if the card will give more output power. if it will work you could probably control tx/rx gain ratio by setting only one of the two to 02.

do you have a bash script for checksum fix?

[ericderace]

For the guys with the custom regdb (regulatory.bin), did you try aireplay-ng --deauth... ? I've edited my regdb to allow above 20dBm under GB, but anything I put above 20dBm causes the driver to crash when I run aireplay-ng --deauth afterwards. AWUS036NHA on Kali rolling.

[crypto-dmtized]

I was able to change the txpower to 30 dbm by regulatory.bin and CRDA. I have not had any issues using the card at 30 dbm.

Kernel 3.14.35
Awus036nha

[mokba]

before i start real testing i want to make sure this checksum thing won't slow me down again, so, in case the checksum fix method for ART partitions will work, at which offset in dump the checksum is stored?

alternatively, maybe it would not even be necessary to deal with checksum if its code from eeprom_4k.c is removed? someone can verify this?

	if (sum != 0xffff || ah->eep_ops->get_eeprom_ver(ah) != AR5416_EEP_VER ||
	    ah->eep_ops->get_eeprom_rev(ah) < AR5416_EEP_NO_BACK_VER) {
		ath_err(common, "Bad EEPROM checksum 0x%x or revision 0x%04x\n",
			sum, ah->eep_ops->get_eeprom_ver(ah));
		return -EINVAL;

[mokba]

I was looking at the AR9271 datasheet and found this:

To ensure that the
FCC limits are observed and the output power
stays close to the maximum allowed, the
transmit output power is adjusted by a closed
loop, digitally programmed, control loop at the
start of each packet. The ARXXXX provides a
closed loop power control based on an on-chip
power detector.

so does that mean that a modified Reg.db won't work to increase the Tx power on anything with the AR9271 chipset?

no, it means a modified reg.db only will be insufficient to achieve txpower increase. have you noticed "digitally programmed" ? it means this loop power control mechanism will probably require it's settings re-adjustment too.

quick google search returns some info: http://www.virtualbox.org/svn/vbox/t...r9003_eeprom.h

/* Delta from which to start power to pdadc table */
/* This offset is used in both open loop and closed loop power control
 * schemes. In open loop power control, it is not really needed, but for
 * the "sake of consistency" it was kept. For certain AP designs, this
 * value is overwritten by the value in the flag "pwrTableOffset" just
 * before writing the pdadc vs pwr into the chip registers.
 */

[mokba]

TL-WN722N.bin.zip

got the dump from TL-WN722N, i had to unsolder one side of the chip because ch341a could not read while it was on board. there is some difference when compared to TL-WN721NC, next i will try to write region 0x1ff as i've found in driver it is debug code. later will try it on alfa too.

UPDATE:

debug country code did not work as the driver expected regpair too but removing checksum code from eeprom_4k.c worked and the driver did not complain about mismatch anymore. this can be helpful between multiple tests since you don't have to calculate checksum every time a bit in eeprom is changed.

[mokba]

Hi

I was able to reach almost? full power with both adapters after changing driver property

alfa would connect to network and drop, looked at dmesg to see that the usb resets so i used y-usb cable. The sound coming from the card was also louder.

tl-wn722n worked with single port supply but the wifi rates dropped to 18-36 Mbps and throughput very low at ~2km distance

There should be a way to manually change fixed rate like it is possible with ath9k

[CryptoMeth]

Any conclusions yet on how to raise the tx power of the locked down AWUS036NHA?

[mokba]

sure there are any conclusions..

in eeprom.h look for AR5416_PWR_TABLE_OFFSET_DB and set it to -11 if your card is locked to 20dBm

[mokba]

Hi,


BTW @mokba: EEPROM address 0x147 to 0x18A seems to hold the power table

AWUS036NHA -> 0x147 = 2Eh = 46d (half dBm) / 2 = 23 dBm (maximum)

TL-WN721NC -> 0x147 = 24h = 36d (half dBm) / 2 = 18 dBm (maximum)

From my tests i can tell (with original backports driver + open ath9k_htc firmware):

- iwconfig txpower 18 sets the maximum practical output power for the AR9271.
There seems to be a bug where values over 18 simply have no effect, even though the driver still sets higher half-dbm values in the firmware.

maybe because driver checks the EEPROM content and find this value as it's limit (firmware limit)?

- iwconfig txpower 18 to 23 dBm
Causes changes in the driver (half dbm values are reported to the firmware), but as i said, have no practical effects (no power increase occurs).

- iwconfig txpower 23 to 33 dBm
Is capped by the driver, that will always report 23 dBm to the firmware (28 dBm considering the +5 dBm internal driver offset)

So before worrying about the driver 23 dBm cap (that is very easy to bypass, just by adding +10dBm to the driver routine that sets the firmware power), we must find this firmware bug that make 18-23 dBm settings ineffective.

are you sure it is a firmware bug? maybe the card EEPROM allows the driver to set half dbm values up to 23dBm to the firmware but caps the firmware from setting the actual txpower.

take a look at these addresses

18B -> 11 -> 17 (offset at which PA turns off?)
18C -> 12 -> 18 (offset at which PA turns on or offset at which firmware caps further power increase?)
18D -> 15 -> 21 (min power required to enable high power mode?)
18E -> 17 -> 23 (driver limit/max power allowed to be reported to the firmware?)

what do you think?

update:

i've checked with tplink adapter, and if i change 0x147 to 0x18A values to the alfa style ones (30 29 28 27 rather than 30 30 30 30) i get some different reading of txpower in ubiquity utility:

G mode

CH1 600mW
CH2-CH10 1000mw
CH11 800mw

N mode HT20

CH1 600mW
CH2-CH10 1000mW
CH11 600mW

N mode HT40

CH1 126mW
CH2-CH10 300mW
CH11 126mW

next i tried this same EEPROM bin with 18D changed to 16 (22) and 18E changed to 19 (25) and got these results:

G mode

CH1 600mW
CH2-CH10 1000mw
CH11 800mw

N mode HT20

CH1 600mW
CH2-CH10 1000mW
CH11 800mW

N mode HT40

CH1 1000mW
CH2-CH10 1000mW
CH11 1000mW

so maybe these two offsets are only related to lowest/highest channel HT power settings in FCC domain (these power limits were not present with CN country code), but they could also have double meaning as they look convenient for well-known power limit

values starting at 138 also look interesting to change

[cameronkali]

maybe because driver checks the EEPROM content and find this value as it's limit (firmware limit)?



are you sure it is a firmware bug? maybe the card EEPROM allows the driver to set half dbm values up to 23dBm to the firmware but caps the firmware from setting the actual txpower.

take a look at these addresses

18B -> 11 -> 17 (offset at which PA turns off?)
18C -> 12 -> 18 (offset at which PA turns on or offset at which firmware caps further power increase?)
18D -> 15 -> 21 (min power required to enable high power mode?)
18E -> 17 -> 23 (driver limit/max power allowed to be reported to the firmware?)

what do you think?

update:

i've checked with tplink adapter, and if i change 0x147 to 0x18A values to the alfa style ones (30 29 28 27 rather than 30 30 30 30) i get some different reading of txpower in ubiquity utility:

G mode

CH1 600mW
CH2-CH10 1000mw
CH11 800mw

N mode HT20

CH1 600mW
CH2-CH10 1000mW
CH11 600mW

N mode HT40

CH1 126mW
CH2-CH10 300mW
CH11 126mW

next i tried this same EEPROM bin with 18D changed to 16 (22) and 18E changed to 19 (25) and got these results:

G mode

CH1 600mW
CH2-CH10 1000mw
CH11 800mw

N mode HT20

CH1 600mW
CH2-CH10 1000mW
CH11 800mW

N mode HT40

CH1 1000mW
CH2-CH10 1000mW
CH11 1000mW

so maybe these two offsets are only related to lowest/highest channel HT power settings in FCC domain (these power limits were not present with CN country code), but they could also have double meaning as they look convenient for well-known power limit

values starting at 138 also look interesting to change

mokba, how are you getting past the checksum error? I have tried a few things with no luck, any advice would be appreciated. Thanks.

[mokba]

Check out this thread the OP posted modded drivers as well as a VMWare image with everything ready to go. Tx power is set to 69 dB and the signal is really stronger. I have a 10dB difference compared to original drivers with airbase-ng.

https://hackforums.net/showthread.php?tid=5578652

a wildstyle method... not recommended

10dB stronger signal, very unstable.. @81Mbps rate i measure -66dBm in access point, @90Mbps (which was max in HT mode) -36dBm... legacy mode best rate 36Mbps -33dBm in access point, @24Mbps -65dBm. an obvious throughput regression so i didn't even bother to do iperfs. same conditions, only turned off virtual kali machine, with my current driver 150/150Mbps -43dBm.

i've finished modding tl-wn722n device but my eeprom died in the end, need to get few new chips and re-check backup, otherwise it works stable with 26dBm output @11b rates, 23dBm @11g and 20dBm @11n HT40 rates. same or better (depending on xPA) mod can be applied to alfa eeprom.

[Hestati]

Sorry to bring this back. Seems like you guys found a way to raise power of a locked card. Can someone please give more specific instructions on how to do that? I read the whole thread 3 times and still couldn't fully understand

[zeraoo98]

Just found this thread and I'm interested in the topic as well. Can someone who knows this stuff here reply please?

[mokba]

download compat-wireless or backports, do what i wrote in comment 70, build the driver, restart. use as short as possible and HQ USB cable. do some bandwidth/range tests (iperf?) and post results here

[zeraoo98]

What steps are required in order to get and edit the eeprom.h? What hardware is necessary and is there some soldering going on? I really want to learn how this unlock is done but i just never had any experience with eeprom editing before.

[zxcvcxzz[not_a_spammer]]

@mokba my awus036h died and I remain with awus036nha .. any progress so far with modded divers to increase txpower ?!

[Kess78]

Check out this thread the OP posted modded drivers as well as a VMWare image with everything ready to go. Tx power is set to 69 dB and the signal is really stronger. I have a 10dB difference compared to original drivers with airbase-ng.

https://hackforums.net/showthread.php?tid=5578652

[mstrmnn]

^^ Thanks! Unluckily registration is needed there to see the thread. Hackforums.net does not send me an activation code. I asked for resending - without any effect. Edit: With a delay of 30 hours the activation mail(s) arrived.

It would be nice to post the info here!