OpenWrt 12.09 on rtl8196c 4 mega rom 16 mega ram

For Developers
1

Hello every body, my name is Fabio and I have been for long time interested on putting openwrt on NETIS 2411 cheap router ( and other thousands of router with same specifications )

Before continue reading, as suggested from many members on this forum, would advice that the result could be affected from some vulnerabilities so it must be considered as a "study case " and not a production environment

Do it at your risk , not suggested for daily use

It has cpu RTL8196c , wifi RTL8188ce, only 4 mega of rom and 16 mega of ram, but finally I managed to make it run on it. I did not write ANY code, all the work has been made from other people and all the credits go to this people and their big work, such as the job from @wifisky
Here i talk about openwrt 12.09 and not of LEDE , where there is a specific post
The image i made ACTUALLY has some limitations:

  1. for booting is needed a bootloader not LOCKED to any vendor and one bootloader suitable of this is found ( by accident, must recognize ) in WS-WN523N2 Wireless-N Router

  2. wifi is working but only in WEP ( no wpa/wpa2) but i think is more a misconfiguration that a missing driver or maybe i missed any info

  3. and of course NO LUCI at all, but is already a miracle that is booting and working

Since I am more a Frankenstein doctor ( copy paste pieces of hex codes ) and not a programmer , here looking for some interested in understanding and studying/debugging about

  1. generating an image that flashes the bootloader too

  2. understanding why wpa/wpa2 doesn't work

of course my actual work is avaible for anyone but would love to publish a final work with all things working out of the box

2

OpenWrt 12.09 is completely insecure at this time (out of kernel support for years) and it is not recommended for any connected use or any wireless use (severe, known insecurities in the 802.11 protocols from that era).

I'm not sure that a 4 MB flash and 16 MB RAM device is worth any further attention. Not only is 4 MB of flash typically insufficient for any current, secure Linux-based OS, but 16 MB of RAM will most likely be unstable in even the simplest of applications.

Getting a current version of a Linux-based OS, OpenWrt or otherwise, to run on that device will most likely require building from source. Hex-editing can only change a couple of primitive things, nothing like changing the bootloader or device configuration.

Devices with similar chip selection are not necessarily binary compatible, as how the OEM/ODM decides to "wire them up" changes, which changes the firmware requirements, often significantly.

Suitable replacement devices with at least 16 MB of flash and at least 128 MB of RAM are available starting at under US$20.

3

hello @jeff ty for your replay and yes I totally agree with you but you know sometimes is worthly more the study than the effective use
later. And in any case if you consider unsecure 12.09 I would you investigate the original code where access login and password where HARDCODED in firmware :crazy_face: , and since that firmware is used as base for thousand of clones you can easily understand how many potential holes people have in their houses

Even more modern routers but still based on original SDK

Stated this , I would explain better my precedent affirmation : I didn't copy paste pieces of code, the code is 100% PURE Openwrt code with integration for rtl ( i didn't do this, I just cloned and effectively I compiled from scratch), what i did is just try to understand the mechanism to make it bootable and use, with all the benefit of a highly configurable system based on openwrt instead of monolitic BOA or GOhaed original wrapper. At the moment I'm writing you trought my netis-openwrt router.

Unfortunately as I said I am not a programmer 100%, i can read and understand some basics as I did with the original realtek wlan.sh to bring up the wifi, and is exactly the reason of asking here for help from peole that surely know codes better than me.

I just studied the behaviour of an original netis via rs232 and the openwrt one.

E.G. i truly would love to understand if the wpa encryption not working because misconfiguration or missing binaries in kernel/userspace

well netis binaries fit on this version of openwrt , with thei libraries so e.g. i used " flash get_mib" instructions instead of rtkmib, just one example

well i do collaboration with italian isp and we have more than 3000 of those :smile:

Last thing : in this compilation still 282 kb free in df -h :+1:

4

Yes, this is one of the "problems" with open-source code. OEM/ODMs take some old version as the base for their firmware and don't ever update it (as well as doing "stupid" things, like the hard-coded credentials you found).

Interestingly, I only see one device mentioned that uses an RTL8196 SoC, and the DIR-410 isn't listed as supported for any release. I don't find 8196 anywhere in current OpenWrt code. I didn't find DIR-410 anywhere in the git commits of the OpenWrt project.

Based on the above, you appear to have a device that was never supported by OpenWrt and are running OEM firmware that is loosely based on an ancient version.

I would still be careful flashing one firmware onto another device, as there is often different interpretation of the flash, as well as how devices are "wired" to the SoC. Overwriting device-specific information, such as the "cal" data for the wireless (or MAC addresses) is not recoverable. In contrast to "disks", flash doesn't have the equivalent of an MBR or GPT, all the interpretation of "format" is done by the kernel, either coded in or from the boot loader passing command-line args.

There isn't anything that can be done to secure 12.09, which remains the basis of "cheap" devices out there. Moving to a kernel still under support, such as 4.14, will likely increase RAM consumption and will require updating all drivers and patches from any OEM source you might have.

282 kB is probably OK, given a typical erase-block size of 64 kB and a need for a minimum of three erase blocks for a jffs2 file system to function properly.

Any proprietary firmware and scripts (such as wlan.sh) are unfortunately outside the scope of what OpenWrt supports, even if that firmware was originally based on OpenWrt.

My suggestion would be to obtain the "mach" file from the OEM GPL drop and properly port the device to OpenWrt. I don't know the complexity of this task as a quick search on Google suggests that there hasn't been any sort of support for this SoC since Linux 2.6, which dates back to 2004 and went out of support two years ago. (Note that Linux 4.14 or later is "required" for OpenWrt at this time.)

Edit: This looks to be a "Lexra" core, which is not supported

See further

1 Like
5

"lexra" would be the keyword to search for in the forum, you will find a number of previous explanations about it.

The problem here, although I'm mostly repeating jeff's previous explanation:

  • 4 MB flash is insufficient
  • 16 MB RAM is impossible for current code (you will have real problems booting in the first place, combined with all required drivers (wlan, ethernet, switch) it will crash)
  • lexra isn't supported, neither upstream (kernel, libc/ musl, binutils, …), nor in OpenWrt
  • the wlan drivers provided by Realtek are not nl80211 based, they won't work in AP mode - and getting them to work on more recent kernels is likely to be a lot of work

There simply is no way forward for these devices, so much below (absolutely rock bottom) minimum system requirements - and the security implications also makes it a really bad idea to stick to old versions (OEM or OpenWrt), as there are serious and exploitable issues even behind the WAN gateway.

2 Likes
6

@jeff
i am interested in this topic since this post on old forum
https://forum.archive.openwrt.org/viewtopic.php?id=46606&p=1

and is thanks to those great people that i have gone further to this point.
My soc in supported in the compilation from Roman Yeryomin at advem and in fact this is my starting point

BTW your nick sounds me familiar I am sure I have read it on some posts, surely.

And, do you know how many times i bricked the router ? So instead of
solder and disolder the SPI I made a homemade ZIFF socket with integrated spipgms reader/writer for any evenience , but now I am skilled and I don't erase anymore the bootloader :sweat_smile:

IMG_20190521_195802

@slh

false, it fits

I am writing from it

again i founded a ready out of box that finishes the compile

they work since i use them

I will put my job on here but of course this is very " study case"

EDIT:

for me happens to compile even in virtualbox sandbox but I repeat : this is not my work, other have done it

IMG_20190521_201729
IMG_20190521_2017291181×886 246 KB

7

Consider the harm you do by making this seem sort of possible... people may try to make it work, using up tons of time... and then maybe even GET it to work... and then they use highly insecure firmware from around a decade ago with known bugs in dropbear and WPA and whatever whatever... so that it becomes an easy target for all those scans I see daily in the logs on my network (people probing my router to see if they can crack into its security).

Instead of spending $20 and very little time, and getting a cheap up-to-date router with secure software, potentially people see these kinds of posts, and spend tens of hours of their time getting insecure software and making the internet a worse place security wise...

In my opinion it seems actively harmful to offer information about how this "works". Better to say "although it's possible to get something to load and run, it does not "work", it is a bad idea, please recycle this hardware asap"

4 Likes
8

@dlakelan

you are terribily right, on our AS border router we see tons of scan/probes/whatever so I should indded correct the post with a " MIGHT WORK" and not " IT WORKS"
But you know is also nice study and learn ( for me is big learning ) and come here in the hope of searching infos, but may be you right , I will throw it in the rubbish

1 Like
9

Of course, learning is useful, and perhaps it enables people to do some other things that are useful, like get a router working using some similar hardware that supports more modern software, but it's important to give the right impression, so people don't waste time or use insecure stuff... As you say I literally have hundreds of automated probes every day. if I run insecure software on my router I will be hacked rather quickly, sometimes even faster than you can download patches and update the system.

1 Like
10

@dlakelan

we do use mikrotik for routing and ubiquity for subscribers, now migrating in some areas on cambium
Ubiquity has been hacked and we lost around 1000 units .
Ubiquity is running openwrt and proprietary tdd time slots
Do you know the lack of security ?
Was in CURL a widely used binaries.
So...
any way ty

11

<bad car="analogy">
You have a 55 year old Peel P50


The brake pads and -cylinders are worn (read, security analogy), the frame and brake lines are rusty.

Now, with a 'car', you can replace the brake pads, fix the brake cylinders, weld the frame and replace the brake lines. Your replacements might not be original, but you can make them fit and do the job. That will not make the car fit for 2019 security standards, but at least to mid-sixties standards (and you may be able to carefully up-rate components to ~seventies standards, e.g. disc brakes instead of drum brakes, retrofitting seat-belts, etc.). With a cherished classic car, your safety, your life is also to a significant amount down to your own care and driving style, you mostly endanger yourself, not others. The MOT will only hold you accountable to 1962 standards, not 2019 standards.
</bad>

With a router that's been built to minimum system specs a decade ago, you don't have that luxury. The software is non-standard, the wlan cards are unusual (for AP operations), without good enough drivers, the arch is running a special reduced ISA (lexra instead of normal mips), no toolchain or kernel/ libc support. And sorry to contradict you, but 16 MB RAM isn't enough to run a kernel released this decade - at least not without sacrificing wlan support (rather large drivers) and more (I did try it recently with kernel 4.14.x on brcm47xx and 16 MB RAM, yes, with significant and painful trimming I can get it booting - but loading wlan and switch drivers, it's game over, before even getting to pppd, NAT, firewall, etc).
Yes, you can stick to a decade worth of security issues (~= worn brake pads and leaky brake lines), but even the wireless side of it is vulerable (KRACK) - making it an active security issue for yourself and others (vulnerable to participation in botnets).

<bad car="analogy">
Now if you had a 1959 Cadillac convertible, you might be able to fit a Lada engine and transmisson (as in replace flash/ RAM), to get away with lots of filler, paint and prayers, Cuba has set a lot of precedence, but with a Peel P50 and a rusted frame/ ceased engine…
</bad>

This situation can be rectified with ~20 USD for a new device (<bad car="analogy">which would not be equivalent of a Tata Nano or P45, but significantly better than that</bad>) or pretty decent used devices easily matching OpenWrt's current minimum system requirements in the 1-5 USD range, which would be the equivalent of a cold beverage up to a burger.

2 Likes
12

the ubiquity costs around 40/50 euros/dollars each, still vulnerable and I repeat again, the vulnerabilty wasn't the openwrt firmware but curl
Just to mention it happened december 2018 not in the 50's
And Cuba is lovely :smiling_face_with_three_hearts:

Anyway will rectify the first post so it will be more clear

13

What vulnerability is this and which airOS versions are affected ?

14

https://www.reddit.com/r/Ubiquiti/comments/6017lt/airos_vulnerability_issue_update/

Google's your friend.

15

@Sharkam52
Hello Hamed, yes @lleachii already posted the answer.
But what mostly tremendous washow the hack was spreading:

of course we have borders firewalls but many our customers have dvr/nvr with " cloud" for viewing streams
They open some ports acting as a sort of " upnp"
Those nvr/dvr are badly compiled, again with vulnerability iside such as default hard coded user and pass
The attacker gained access to the nvr , and trought the dvr spred on antennas.

No firewall lack, but ALL others lack
For whom interested

16

All of these are old ( and some are very old) vulnerabilities.

17

Please can any one just point me in this direction:

to run wpa/wpa2 tkip or aes on any other platform, let say atheros, which are the minimum, but very minimum required packages?
wpa supplicant ? in the kernel crypto aes and what else.

Or point me on any info regarding it, thanks

18

the standard package is wpad-lite if you're just doing PSK, comes pre-installed on release versions, if you're doing WPA2 enterprise you need wpad which is the full version

1 Like
19

A userspace program (in OpenWrt, it is hostapd) authenticates and negotiates the session keys. The kernel driver along with (almost always) acceleration hardware in the wifi chip does encryption of data packets. TKIP was a stopgap to run on old chips that only have WPA compatible hardware and can't do AES.

20

Ty both for kind replay.
Let me try to explain what I am missing:
the rtl8188ce wifi is widely used and it can be controlled in several ways as stated in this document :
rtl wifi application notes

It can be controlled with iwconfig, with iwpriv and with a conf file
The important is pull down the iface, put the needed instruction in it by
hands, or via a script or the config file, and re open the iface ( ifconfig wlan0 down in this case first, all needed and ifconfig wlan0 up later)

`E.G the essid will be on fly given by

ifconfig wlan0 down
iwpriv wlan0 set_mib ssid=hello_word
ifconfig wlan0 up`

Since the calibrations and other stuff are buried in the rom just after bootloader ( a sort of art partition ) , at boot time a scripts scans the capabilities of the board reading the art, makes a conf file with frag, thresolds, ht capability leds behaviour etc etc , leaving out just channel, essid, and encryption type that can be edited by user and " uploaded" to the driver in one shot before the iface is up.

Infact the name of userspace configuration script is realtek.sh that calles a normal hostapd.sh and writes a /var/run/hostapd-wlan0.conf passed to the rf chip

Now comes the question : since wep is working fine but wpa says " key not in cam" what is the problem?

Is directly the rtl 8188 chip that can handle completely the tkip or aes stuff , or still needed anything in the kernel space ?

Is not possible that the original works on 2.8.9.30 and not able to replicate here on opernwrt

I already made a simple script for reading, manipulating , reuploading the infos but still wpa not working

EDIT : analyzing the original sdk i found a wpa/tkip example conf

# WPA-PSK/TKIP

ctrl_interface=/var/run/wpa_supplicant

network={
	ssid="example wpa-psk network"
	key_mgmt=WPA-PSK
	proto=WPA
	pairwise=TKIP
	group=TKIP
	psk="secret passphrase"
}