Chat freely about anything...

User avatar
By Israel Lot
#19857 My goal was to discover the signature of this function reported in the symbols : ppTxPkt . It appears to me to be the central point for all packets sent over the air, regardless of ap association. Would be a key piece for making a open source 802.11 implementation.

I took this function as a starting point: ieee80211_send_probereq , on most FreeBSD branches it has the same signature ( here's an example https://github.com/freebsd/freebsd/blob ... 1_output.c ) :

Code: Select allieee80211_send_probereq(struct ieee80211_node *ni,
   const uint8_t sa[IEEE80211_ADDR_LEN],
   const uint8_t da[IEEE80211_ADDR_LEN],
   const uint8_t bssid[IEEE80211_ADDR_LEN],
   const uint8_t *ssid, size_t ssidlen)



The only unknown is the ieee80211_node argument. It turns out the ESP has a basic config struct at the address _irom0_text_start+0xc, it appears everywhere on the disassembled code.
Looking at the function eagle_lwip_getif,


Code: Select all40213200 <eagle_lwip_getif>:
40213200:       f38341          l32r    a4, 4021000c <_irom0_text_start+0xc>
40213203:       62cc            bnez.n  a2, 4021320d <eagle_lwip_getif+0xd>
40213205:       4428            l32i.n  a2, a4, 16
40213207:       32dc            bnez.n  a2, 4021321e <eagle_lwip_getif+0x1e>
40213209:       020c            movi.n  a2, 0
4021320b:       f00d            ret.n
4021320d:       0b1266          bnei    a2, 1, 4021321c <eagle_lwip_getif+0x1c>
40213210:       5428            l32i.n  a2, a4, 20
40213212:       228c            beqz.n  a2, 40213218 <eagle_lwip_getif+0x18>
40213214:       0228            l32i.n  a2, a2, 0
40213216:       f00d            ret.n
40213218:       020c            movi.n  a2, 0
4021321a:       f00d            ret.n
4021321c:       f00d            ret.n
4021321e:       0228            l32i.n  a2, a2, 0
40213220:       f00d            ret.n


it became clear the ROM has two ieee80211_node structures, one for the soft ap, the other for the station client. One is on offset 16 from the main config struct, the other on offset 20.
Guessing the signature was easy :

Code: Select all struct ieee80211_node * eagle_lwip_getif(int id);


Passing 1 returns a pointer to the access pointer node, 0 for the station ap.
Using this pointer as first argument on the ieee80211_send_probereq function allows me to successfully inject a probe request packet.

A second step would be writing a function in C that replicates the ieee80211_send_probereq,
basically creating a management frame using ieee80211_getmgtframe, configuring it and finally outputting the frame via ieee80211_mgmt_output which internally calls ieee80211_raw_output which in my opinion is replaced by ppTxPkt in ESP, so maybe the signature is similar. But I didn't go down that road so much. Help would be appreciated.
User avatar
By cal
#19966 Moin,

it's fun, isn't it? :)

Note that
- l32r loads the content from that address so that contains a pointer to your address
- it is not returning the content at offset 16 but there is another indirection.

I suggest: Try to rewrite that function in c first. Define simple structures, name not very important
consting of int, void *p and pointers to your struct.
Compile that with gcc --save-temps maybe with ’-Os’ and look at the generated assembler code
to get a fealing for code patterns and indirection.

Have fun,
Cal

I guess you have the ISA manual of the xtensa processor at hand. If not, read it.
User avatar
By cnlohr
#22191 I know it's been a while, but I keep checking every few days to see if anyone's been able to send arbitrary packets. Have either of y'all gotten any closer to figuring out how to make this go?

*EDIT* Just found this instance of ppTxPkt's use and disassembly... not sure if everyone's already seen it.

https://github.com/angelovAlex/esp-blob ... 1ec686f4d6