yashsingh1/xdaforums huggingface dataset:
[Hardware Hacking General] Renate:
Ok. We have luck. The test points are reasonably accessible.

There is a loader that works: https://github.com/bkerler/Loaders/...480e100000000_cc3153a80293939b_fhprg_9x07.mbn

I put in a little magnetic reed switch. Jeez, I'm running out of these, I put them everywhere.

The storage is NAND. It probably works with bkerler stuff. I've only half-baked for NAND on my EDL client. I have to work on it.

Found EDL 9008
HWID: 000480e100000000, QC: 000480e1, OEM: 0000, Model: 0000
Hash: cc3153a80293939b-90d02d3bf8b23e02-92e452fef662c749-98421adad42a380f
Sending loaders\qualcomm\factory\mdm9x07\000480e100000000_cc3153a80293939b_fhprg_9x07.mbn 100% Ok
Waiting for Firehose... Ok

<log value="[FLASH_INFO]"/>
<log value=";This section provides flash info"/>
<log value="FLASH_NAME=NM14F2KSLAXCL-3B"/>
<log value="SECTOR_SIZE_IN_BYTES = 4096"/>
<log value="NUM_PARTITION_SECTORS = 131072"/>
<log value="num_physical_partitions = 1"/>
<log value="TOTAL_SECTOR_SIZE_IN_BYTES= 4352"/>
<log value="PAGES_IN_BLOCK = 64"/>
<log value="CONFIGURATION SELECTION FOR THIS DEVICE: BLOCKSIZE:256KB and PAGESIZE:4KB"/>
<log value=""/>
<log value="[BAD_BLOCK_LIST]"/>
<log value=";This section provides bad block list"/>
<log value="BAD_BLOCK=1536"/>
<log value="BAD_BLOCK=1537"/>
<log value="BAD_BLOCK=1822"/>
<log value="BAD_BLOCK=1992"/>
<log value="TOTAL_BAD_BLOCK=4"/>
<log value="{&quot;storage_info&quot;: {&quot;total_blocks&quot;:2048, &quot;block_size&quot;:262144, &quot;page_size&quot;:4096, &quot;mem_type&quot;:&quot;NAND&quot;, &quot;prod_name&quot;:&quot;NM14F2KSLAXCL-3B&quot;}}"/>
<response value="ACK" />
[Hardware Hacking General] Renate:
Ok, so who's good with this stuff? root:$1$uH6tuGYf$bjaX370zwmzgNHP/YhrAQ/:0
[Hardware Hacking General] rich hathaway:
Professional Cloud Password Testing & Recovery Services

OnlineHashCrack is a Professional Cloud Password Testing and Recovery Services ensuring ethical practices for cybersecurity experts

www.onlinehashcrack.com

you can try them, I have used it before with success, it is a slow service though, I did a md5crypt on there it was successfully reversed but took 4 days.

or try john the ripper program, but really you don't need it you sent the loader so just send hello now then you can dump the firm and from there it should be fairly easy to enable the ports so u can just use adb with no need for a root pass.
[Hardware Hacking General] Renate:
Um, I've got 500 MB of raw dump, not directories and files.

It's easy enough to find the password file in there but I'm not really sure what I'm looking at/for.
[Hardware Hacking General] Renate:
I fixed a bit of a bug in my edl.exe for NAND devices. Get the May 5th one in the sig.

I ran about 2 hours of cracker with no success yet.

I'll run some more today.

Edit: I'm still working on this, >4 days so far...

That works out to about 250 billion passwords tried.

Also: Power consumption isn't bad, average of 150 mA or so and peak of 450 mA.

Erm, hits a solid 500 mA when transmitting.
[Hardware Hacking General] Renate:
OMG, I've been running this JtR for almost 5 solid days now (I only run it when it's sunny).

I was beginning to doubt that JtR could crack a walnut.

For some reasons the LM1200 regenerates a password file each boot and if I modify it it doesn't generate it.

I've been using my (recently updated) EDL client to try to overwrite the password file.

I put in the password "$1$abcdefgh$rV6RhG4no19bGJfmub3Ui1".

I tried JtR on that and it came up in a fraction of a second that the password was "root".

Just to be clear, I didn't crack anything, yet.
[Hardware Hacking General] rich hathaway:
thats good, does it work, thats usually the user lol

what is the filesystem do you know

yaffs2 or ubi ?
[Hardware Hacking General] Renate:
It's UBI, because I've seen this:

000000 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 00 UBI#............
000010 00 00 10 00 00 00 20 00 25 a5 06 c3 00 00 00 00 ...... .%.......
000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000030 00 00 00 00 00 00 00 00 00 00 00 00 94 9e c8 d8 ................
000040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................

The Python EDL client can print out partitions, but the support for NAND doesn't seem finished/working.

I don't know anything at all about UBI, but I did update my EDL client to correctly erase and write NAND.

There are 6 occurences of the $1$salt$hash in a complete dump.

The first two are in a different position each time you boot.

The middle two and the last two are identical, that is: A/B, A/B.

The last two you can change without any noticeable effect.

If you modify the middle two (overwriting the same number of chars) when you do a dump after rebooting there are only four $1$salt$hash and it's the first two that are missing.

So, I don't know if there is some checksum on files that I'm changing or what.

Who ever heard of passwd and shadow getting generated at each boot?

Is there some sort of secure repository that is sourcing this data and is my editing invalidating it?
[Hardware Hacking General] rich hathaway:
send me your dump and if its complete ill decompile it for you, and you cannot change the root pass without passing security first.

you said you have more than one dump, are they all the same size?
[Hardware Hacking General] Renate:
I am disliking this NAND, Sam-I-am.

Well, I screwed up and erased the whole NAND.

Then I erased it, wrote back my backup copy, read back and it was the same.

But then upon rebooting it did a whole bunch of stuff including scrubbing then came back with 16 USB endpoints but not working as a modem.

I rebooted and it came up with less drama, but now it says:

-- deleted pointless log dump --

I haven't gone back to try to write it again yet.

I know that both read and write skip bad blocks so you always subtract the bad blocks from your sector count.
[Hardware Hacking General] rich hathaway:
You have usb endpoints because you erased the efs, without a filesystem it will default to all ports open, now that they are open you should still dump the full nv and the full efs as well as make either a qcn or xqcn backup or both even if they are incomplete
[Hardware Hacking General] Renate:
Well, I get that all the interfaces being open is a fallback.

But I'm clearly missing some information and am delusional.

The NAND flash is 131072 x 4k pages or 2048 x 256k eraseblocks.

There are 4 bad eraseblocks: 1536, 1537, 1822, 1992 (they have never changed)

I read a backup when things were working, it skips bad blocks.

I did a stupid erasure.

Then I wrote my backup, then I verified it.

Why are things not like they were? i.e. working

That is to say: Is there more storage in this beast than the NAND flash?

And if I creamed the NAND flash, how could it destroy this other storage?
[Hardware Hacking General] rich hathaway:
well it can really only be a couple of things, to write a dump back it needs the spare so no ecc calc is needed, did you dump with the spare? I am not real familiar with EDL nor do I know which of the EDL's you are using there are 3 that I know of but check the command you used to dump it and check the keys that you used and the keys that are available so you can know what you have and after doing that check that you are using the needed keys when you try to write it back, in my experience, EDL's are somewhat temperamental and can be unpredictable, this is why I use qtools instead. if you still can't get it written to where it will function you will need to cut your dump into the correct partitions then decompile at least the non-mbn parts back to human readable form then make the ubi's for system, modem and recovery and load them all one by one so if one fails you will know where (which partition) you need to work on it
[Hardware Hacking General] Renate:
I'm using mine, of course. It's also on my Beagle USB480 so that I can double check everything.

The pages are 4096, the full size is 4352.

I presume that a 4096 write operation will write nice things in the 256 bytes?

Else how could they ever flash this in the factory?

Edit: I'm working on a proof-of-concept.

TLDR: never write a page with all 0xff.

Edit^2: WHOOOOPPPPIEEE (it worked).

Edit^3: Corrected wrong numbers.
[Hardware Hacking General] Renate:
There are a few idiosyncracies with NAND memories.

They have bad blocks (unusable blocks of 262144 bytes each in this case) which Firehose will enumerate.

Read and write Firehose operations will skip over them silently.

Erasing a block (262144 bytes) sets all data to 0xff, but also the hidden 256 bytes of ECC and CRC for each page of 4096.

If you actually write a page with these same 0xff values (with no effect there) it will clear bits in the 256 bytes and the page will no longer be "virgin".

Therefore, whenever you write you must leave all 0xff pages untouched.

A plain old read and write and read will look like nothing has changed but it will mark up all your 0xff pages and cause problems.

I wrote a proof of concept to divide up my big flash file into contiguous pieces without any 0xff pages and also to generate a batch file to flash those ~500 files.

At least it unbricked my LM1200.

Since it is inefficient and also has my bad blocks hard coded in it's not a real solution.

I'm working on expanding my native Windows EDL client to deal with bad blocks and to not flash 0xff pages.

Edit: My math was wrong. I have corrected the numbers.
[Hardware Hacking General] rich hathaway:
glad you got it resolved
[Hardware Hacking General] Renate:
I've just updated my EDL client to work with NAND memories. The web page documents the issues. Grab a new edl.exe

I ran into an idiosyncracy with the Firehose loader and I'd appreciate if somebody could check something for me.

It only involves reading, so your device is not in any danger.

The Orbic 400 and the LM1200 use the same Firehose loader.

Load this loader and rename it lm1200.bin, then:

edl /llm1200.bin
edl /r /s0 /c0 lm1200_1.img
edl /n /r /s0 /c0 lm1200_2.img
edl /z
fc /b lm1200_1.img lm1200_2.img

Please don't post 1 GB of stuff!

lm1200_1.img will be bigger by (number of bad blocks) x 262144 bytes

The two files may be identical or maybe 30 locations different for each (clump of bad blocks).

Please post your "Bad blocks:" and the differences.

Thank you!
[Hardware Hacking General] Renate:
Ok, let's make this easier. Here is a utility for looking at NAND (UBI) dumps.

C:\>ubi dump.img

2001 .... ...............................................................
<a completely erased erase block>

1968 UBI# UXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
<a completely full erase block>

1813 UBI# UX.............................................................
<an erase block using one page of data

1810 UBI# U..............................................................
<an erase block with a UBI! header but no data>

1799 UBI# ...............................................................
<an erase block with only the UBI# header>

1536 0000 UXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
<a completely full erase block, but somehow the first header got wrecked>

2047 DEAD XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
<attempt to read an erase block but because of bad blocks you've already read past the end>

If you do the tests in the previous link, please use ubi.exe on the dumps.

Please quote just the lines with 0000 in the second position and the last few lines with DEAD or clean.

Edit: ubi.exe can now be found at the bottom of my EDL page in my sig.
[Hardware Hacking General] rich hathaway:
I got a lm1200 today someone sent to me :)

got the firmware backed up and made some tools for it

got it broken down to root filesystem if you need it for whatever you are doing

im going to make a build tomorrow to enable the ports so they always stay on.

IMEI MEID ESN TTL and FID are changeable like the other sierra devices it seems to not be very locked down other than no ports and read only filesystem by default but easy to correct those.
[Hardware Hacking General] Renate:
I'm confused. Where are you going from Sahara? It doesn't look like you are using a Firehose loader.

Can you see bad blocks? Are 1536, 1537 standard (reserved?, special?) "bad blocks".

Do you have a complete raw backup? Is it 2048 EB long or (2048 - bad blocks)?

Could you run ubi.exe on your raw image, please?
[Hardware Hacking General] rich hathaway:
No I told you I do not use edl unless it is just for a challenge response. no firehose is needed, I use the real loader for these devices in this case from 9008 mode it is ENPRG9607p.bin. and I am going thru the usb-C port for read/write

My device has 2 bad blocks both are in user data they are as follows

List of defective blocks

00000600 (0:usr_data+1e0)

00000601 (0:usr_data+1e1)

there are no "standard" bad blocks, they are just bad spots in the memory that come from the factory like that, you can remove the "bad block" label from them and on occasion they will work and be fine, normally not though and it can bork things up for you until you relabel them bad again.

yes I also made a complete backup from 0 -7ff the size with the spare is 557,056KB

and your edl does not perform anything on my raw dump

because I did not use a firehose loader on it.

its output it as follows

0000 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0001 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0002 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0003 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0004 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0005 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0006 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0007 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0008 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0009 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0010 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0011 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0012 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0013 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0014 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0015 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0016 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0017 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0018 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0019 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0020 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0021 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0022 0000 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0023 0000 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0024 ???? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

0025 0000 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[Hardware Hacking General] rich hathaway:
what ubi info are you wanting to see with that edl script?

I can show you what ever you need, below is ubi info for the partition 18 which is the system partition

18-0-system.bin

Volume rootfs

alignment -a 1

default_compr -x lzo

fanout -f 8

image_seq -Q 1180449597

key_hash -k r5

leb_size -e 253952

log_lebs -l 4

max_bud_bytes -j 8388608

max_leb_cnt -c 2146

min_io_size -m 4096

name -N rootfs

orph_lebs -p 1

peb_size -p 262144

sub_page_size -s 4096

version -x 1

vid_hdr_offset -O 4096

vol_id -n 0
[Hardware Hacking General] Renate:
Yes, you've said that, but you were never clear on what you were using.

Ok, I can't find this loader anywhere.

The (non-real, EDL) loader that I am using does know about NAND and accomodates bad blocks.

Isn't it peculiar that "random" bad blocks on three devices are all the same?

Your LM1200, my LM1200 and my Orbic 400 all have 1536, 1537 (0x600, 0x601) as bad.

Your full dump includes OOB or CRC32 or ECC or spare or whatever we're calling it so obviously it will not align with my ubi.exe
[Hardware Hacking General] rich hathaway:
I will clear that BB label and check it, sorry I did not ck your BB address's you posted, if they are they same then I am betting that after clearing the BB label they will be usable again.

I have several orbics here they are also toshiba nand devices and with different BB's I think I have one without any, the partition layout is different as they are 16 partitioned devices so I am thinking this is just a bad tag from the factory.

I can remove the spare from my full dump and try your tool again.

the output is the same with no spare or ecc
[Hardware Hacking General] Renate:
Erm, "same" in what sense?

Could you please just quote 1530-1545 and 2040+ ?

Note that the LM1200 can't walk and chew gum at the same time.

The JSON AJAX control panel stalls out if the modem is scanning.

It appears that the connection is more reliable if you turn Settings > Mobile > Preferences > Network selection mode to Manual.

Since I only have VZW it makes no sense to even notice other networks.
[Hardware Hacking General] Renate:
@rich hathaway Thank you for trying.

As I said, my utility works on 64 pages of 4096 bytes.

Using the Firehose loader I don't have access to the 256 bytes extra for each 4096 bytes.

As you can notice from the print out that everything is out of sync but that UBI# appears every 17th line.

17 x 64 x 4096 = 16 x 64 x (4096 + 256)

So we can safely say that the file that is being analyzed here has 4352 bytes per page.

Obviously analyzing this at 4096 bytes per page will tell us nothing.
[Hardware Hacking General] rich hathaway:
so this is an interesting device, Netgear moved away from the norm with Quectel instead of Sierra which is different.

it has the same file structure as sierra though but no challenge generator and such.

with the ports enabled it is pretty much an open book for everything, full root efs the nv the entire raw filesystem etc

with the exception of and like most qualcomm devices the nvm folder in the efs is locked out and for access to it one must go thru the filesystem to get to it.

above is the culprit for no ports on this device, but easily patched

the one that isnt loaded yet is the rndis port, I did not load the driver for it because I dont need it right now, this device gets service on verizon and also works with tmobile I have not tried at&t yet. it has alot carries profiles already added

which is handy but the prob is they pick the apn for you and for carriers like at&t it means unless edited it will want to use broadband when it is the slower apn and NXTGENPHONE is a much faster apn to use.

fastboot works fine for loading properly made up partitions in quick fashion on this one as you can see it loaded and wrote my made custom system file in 11 seconds, when I write it with a proper loader from 9008 mode it takes about 5 min for either system or system_b to complete.

@Renate​

did you get root access working on yours?
[Hardware Hacking General] Renate:
After 9+ days JtR still has not been kind enough to give me the password.

Yes, I know that there are other ways around this, but this would be a useful factoid for the community.

I've only had ADB access when I massacred the system.

So, what's the opposite of "CHRG_ONLY"?

I didn't time it, but it's under 15 seconds to write everything using the improper loader and my EDL.

I did notice that the MiFi 8800L and the Orbic 400 are pretty similar.

Since the LM1200 has no mention at all of "nvtl" I knew that it was different.
[Hardware Hacking General] rich hathaway:
change it to DEBUG_MODE
[Hardware Hacking General] rich hathaway:
I made a tool to enable the ports including the adb port.

I am not making it public as this is what I do for a living but you can use it if you keep it to yourself if you want to.
[Hardware Hacking General] Renate:
Thanks! But that would be no fun.
[Hardware Hacking General] rich hathaway:
Ok I can respect that
[Hardware Hacking General] Renate:
I've updated ubi.exe so that it shows the volume table.

It can now be found at the bottom of my EDL page in my sig.

2045 .... ...............................................................
2046 .... ...............................................................
2047 .... ...............................................................

Max erasure 19

Name Offset Size Flags
---------------- ------ ------ --------
0:SBL 0 10 000001ff
0:MIBIB 10 10 00ff01ff
0:EFS2 20 88 00ff01ff
0:sys_rev 108 20 000001ff
0:RAWDATA 128 12 000001ff
0:TZ 140 5 000001ff
0:RPM 145 5 000001ff
0:aboot 150 5 000001ff
0:misc 155 5 000001ff
0:boot 160 36 000001ff
0:boot_b 196 36 000001ff
0:modem 232 232 000001ff
0:modem_b 464 232 000001ff
0:netgear_fs 696 140 000001ff
0:netgear_fs_b 836 140 000001ff
0:netgear_dat 976 80 000001ff
0:usr_data 1056 512 000001ff
0:system_b 1568 240 000001ff
0:system 1808 240 000001ff
2048

Edit: Oh, the thing with password/shadow: Copies are kept in (read-only) system and system_b and are copied to usr_data on booting.

Edit^2: It now identifies superblocks with 'S'. You should see lots of:

1820 UBI# USXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

If you don't, your copy of ubi.exe is probably too old already.
[Hardware Hacking General] Renate:
As Freddie Prinze says, "Looking good!"

mdm9607 login: root
Password:
~ # id
uid=0(root) gid=0(root) groups=0(root)
~ #

Edit: Ok, I'll tell you what I did. I haven't cracked the stock password (yet), but I found etc/shadow in the system_b volume, edited the Hash$MD5 for root then fixed the CRC32. I hadn't bothered to look around before, but now I will and see about turning on ADB. Right now this only has utility for people who have the UART hooked up.
[Hardware Hacking General] Renate:
I've updated my native Windows EDL client so that it understands UBI volumes.

You can refer to whole volumes or parts.

For example, this is the makefile that I use to fix the password.

password:
edl /n /r /psystem_b /s10048 /c64 chunk
modfile chunk 15b09 /a "root:$$1$$abcdefgh$$rV6RhG4no19bGJfmub3Ui1"
modfile chunk 15adc /l f966bba4
crc32 chunk 62cc48c5
edl /n /e /w /psystem_b /s10048 /c64 chunk

The doubled dollar signs is necessary for Gnu Make. The 2nd modfile fixes the UBI CRC32. The crc32 command checks the CRC32 of the chunk to make sure that the modifications were correct.

C:\>edl /n /g
Found EDL 9008
Configuring... Nope, configuring... Nope, configuring... Ok
Requesting info on LUN 0... Ok
Bad blocks: 1536, 1537, 1822, 1992
Requesting volume table... Ok, receiving... Ok

# Name Start Count
-- ---------------- ---------- ----------
1 SBL 0 640
2 MIBIB 640 640
3 EFS2 1280 5632
4 sys_rev 6912 1280
5 RAWDATA 8192 768
6 TZ 8960 320
7 RPM 9280 320
8 aboot 9600 320
9 misc 9920 320
10 boot 10240 2304
11 boot_b 12544 2304
12 modem 14848 14848
13 modem_b 29696 14848
14 netgear_fs 44544 8960
15 netgear_fs_b 53504 8960
16 netgear_dat 62464 5120
17 usr_data 67584 32768
18 system_b 100352 15360
19 system 115712 15360
[Hardware Hacking General] rich hathaway:
I know you are building out your edl but Just for the purposes of education the root pass can easily be changed to most anything with the passwd tool on the device, see below.
[Hardware Hacking General] Renate:
Yes, I tried passwd once with a crippled system and there was a problem with it.
[Hardware Hacking General] rich hathaway:
Yes it has to have a full filesystem to work, I used it thru adb and it worked fine