First Post! - Reflashing BIOS chip for Chinese CCTV DVR

[michel thomasius]

Hi All,

Some of you met me yesterday, when I popped down to the rLab. It was an absolute pleasure to talk to you all! :)

I have a project here that I am looking for some advice for; Its a cheap Chinese "Kare" 4x Channel CCTV DVR. The old analogue type. No PoE here! ;)

I have forgotten the password for the blasted thing, because I upgraded all my cameras to PoE. So this box sat around for well over a year before I decided that I wanted to use it for something. Unfortunately, it doesn't have a reset function. So once the password is set, you are very limited. There's some tools floating around, which allow you to generate a one-time generic password, but none of those have worked for me. I spent 2 days working on this, without any success!

So..... I found out that one can re-flash the bios on this thing. I have also found another BIOS image that I could write over the top. The BIOS chip that this thing uses is a Winbond 25Q128FVSG (1634 https://www.winbond.com/resource-files/w25q128fv_revhh1_100913_website1.pdf). 

There's a chap on Youtube who's shown how to flash the bios, using a MiniPro. You'd have to desolder the chip from the MB tho. (link: https://www.youtube.com/watch?v=zU7bKB0mb2o)

Before you ask, I have already tried the reset procedure for this chip, which is apparently to pull pin 7 down to ground for more than 1uS. Didn't appear to make any difference, though it could be an issue at Layer-8.

I have extremely limited electronics experience. So assume I know nothing. I have a 20+ year IT background tho, including building PC's and Servers. So I am not afraid to play with this stuff. 

Would you recommend flashing the bios with the image show in the Youtube clip? The chap is flashing the same chip, and these CCTV DVR's are all very generic. I suspect that it will be fine!

What do you reckon?

This is the chip:

And this is where it lives on the MB (screwdriver pointing at it):

[michel thomasius]

[POSTING DZ's REPLY INLINE, IN CASE ANYONE IS INTERESTED IN THE THREAD]

Hi DZ!

Many thanks for the reply :)

You wanted all the gory details, so here goes:

• As I am very security minded, and a little paranoid around Chinese firmware and equipment, I decided to disable Telnet, FTP and SSH when I originally configured the device. Of course, now I am kicking myself!
• I ran an NMAP portscan across the device, for all 65535 Ports (TCP & UDP) but couldn't find anything open that would give me an attack point
• I scanned the Web Interface for vulnerabilities, but again, and highly unusually so(!) it didn't have any severe vulnerabilities that I could have exploited to gain access to the device
• Looked all over the web for standard/hard-coded users and their passwords. Tried a bunch, none worked
• Tried 4x different password generators for these chips, numerous times. None worked
• Tried the battery remove technique, even leaving it out for weeks didn't make a difference to the time settings in the BIOS. The thing will run quite happily without the battery, and maintain a current date!
• There's no obvious jumpers on the MB
• There's no UART Pins on the motherboard...

So, am I concerned with flashing a randomly downloaded image onto this chip? Just a little, but not too much. 

Why? Because this thing would not go onto the network. And most certainly would never go onto the Tinterwebs! I used to work for Akamai (the Prolexic Anti-DDoS side of the Business), so I saw first hand what kind of damage these little IOT devices can generate, when they get hijacked! ;)

The reason I want to get this thing back up and running, is because I have a very sneaky rat that is getting into the cavity wall of my house, and it travels up and down. To the attic and under the raised floor. I need to find out where it is getting into the wall, so I wanted to setup cameras at various strategic points to monitor its night movements. I already have a PoE camera under the floor and one in the attic, so I can see when it gets there, but i am still not 100% sure how it gets into the wall. I suspect through the garage somewhere. Which is why I wanted to place a bunch of cameras there for a while, to see what's happening. :)

Lastly, I also dabble in Automotive Diagnostics. So I would actually be very interested in the process of de-soldering chips from motherboards, to read their content. This can be useful for re-programing body control units (a Peugeot BSI for example), if you ever need to replace on. It basically allows you to extract the key codes from the BSI, or even overwrite them. So that you can get new keys to work with a second hand BSI. 

P.S. if you right-click on the images and open them in a new tab, they are show to original (40 Mpx!) size! :)

Kind regards,

Michel

On Fri, 5 Oct 2018 at 08:26, dz wrote:

glad you find Rlab it is indeed a great place with fantastic people around.

like yourself I have very little electronics acumen but have played with a server or two in my 20+ years of career :)

as motherboards go... have you looked for any other jumper points on the board or the good old battery extract and thus a force reset?

personally I'll be mindful with any custom code running on any IOT device this days.

Will be interesting to hear if you ever got around gaining access to the unit.

p.s. have you tried other users , maybe there have other hard coded creds, also maybe other access path (telnet/SSH etc) and last thought , does it have UART pins you can hook into?

p.p.s the photo is super small and does not enlarge so hard to see the details of the board :)

Good luck.

dz

[Tom G]

Hi Michel,

The reset procedure you did will only turn the chip off and on (warm reboot), it won't clear any information it has stored. Even turning off the chip won't clear it as it's non-volatile.

The fact that the clock didn't go wrong when you removed the battery either means that there is still power stored to run the clock or the clock is being updated when you turn it on. If you can rule out the second option then the clock must still be running despite the battery being missing. It's entirely possible that it could run off capacitors for a couple weeks depending on how it's been designed. You could get around this by shorting out the battery terminals (preferably with a resistor).

You could try the process shown in the YouTube video. If you do it's definitely worth reading the contents of the chip before flashing anything new to it. That would allow you to revert back to your current state if the upgrade does something weird. Also it may be worth using the GNU strings program on the flash dump, I wouldn't be surprised if the password popped out in plain text.

There's always the possibility that the password isn't stored on that flash chip, so good luck!

Regards,

Tom

[michel thomasius]

Hi Tom,

Many thanks for the suggestions! As part of my original attempts to re-set the date, I did try shorting the battery terminals. Didn't do diddly squat! 

I've been to the rLab and desoldered the chip from the MB. Unfortunately, and despite turning the electronics area upside down (not literally...) I have not been able to find any device that can read the chip. Like a MiniPro. Do you happen to know whether there should be on at rLab? If not I'll have to order one online, to continue this quest.

Lastly, according to all the info that I have found online, the password is supposed to be stored in the chip. If not, it doesn't matter too much either, because I'll be able to overwrite the entire OS with that new image from the Youtube link. So, as long as I can read (and backup) the chip, and re-write it, I should be good. Emphasis on "should" ;)

Kind regards,

Michel

[Gavin]

V interesting - and welcome!

As far as I’m aware we don’t have such a programmer at rLab though I imagine it is the sort of tool that some of our more experienced members might have. I think your best bet would be to use a proper programmer, though I did notice that here there is discussion about using an Arduino Mega to program them via SPI. It may be possible to use a lower spec Arduino (which we do have in the wooden rack on top of the left-hand electronics bench) to do it, though you’ll have to consider the points made in the thread about which pins are broken out and block size vs micro controller RAM size

Gavin

--
You received this message because you are subscribed to the Google Groups "rLab / Reading's Hackspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reading-hacksp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom G]

Unfortunately I'm not sure what we've got at rLab as I only joined a couple weeks ago myself. There's a loads of ways you could program it, you just need something with an SPI interface (so basically anything):

• As Gavin said you could use an Arduino but this will require some programming.
  
• You could also use a raspberry pi, no programming required: https://libreboot.org/docs/install/rpi_setup.html
  
• You could use a FT232H USB to SPI converter, also no programming required, used here: http://jcjc-dev.com/2016/06/08/reversing-huawei-4-dumping-flash/

I would imagine that each of those items above are available at rLab, if not they're all pretty cheap and useful for other things. You'll also need a way to connect to the chip, options in increasing cost:

• SOIC8 breakout board (required soldering)
• SOIC8 test socket
• SOIC8 test clip

I doubt there are any of these at rLab but I could be mistaken.

Tom

[Gavin]

I think I might have a SOIC8 breakout 

[michel thomasius]

Hi All,

thank you all for the very helpful suggestions! This whole thing is already a bit of a palaver, so I don't want to deepen the rabbit hole too much, by adding another layer of complexity (through the Raspberry PI). I can't afford a MiniPro right now. But I did just order this thing, which apparently works quite well with Linux: https://www.ebay.co.uk/itm/162948990821

It comes with a SOIC-8 adapter, so I don't even need to disturb the solder on the chip, more than necessary. 

I'll report back once I've received the adapter and had some time to play around with it. It'll be next week before this thing will show up.

Bye!!

You received this message because you are subscribed to a topic in the Google Groups "rLab / Reading's Hackspace" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/reading-hackspace/LOi4HvtzB9M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to reading-hacksp...@googlegroups.com.

[michel thomasius]

So, good news and bad news. ;)

First the good news:

• I've received the CH341 USB Chip Programmer
• It wasn't particularly hard to get it working
• I managed to read the chip and make a backup of the image
• I've used the Sysinternals Strings utility to read through the file, but I couldn't find any strings that looked anything like the password I used ( I partially remember the password, just not all of it!)
• I've then decided to write the .bin file I got from Youtubings onto the chip
• I soldered the chip back onto the motherboard, and the device boots fine!!
• I can login to the device without a password now

(right-click on the images and select "Open image in new tab" to see the original size)

New OS boots fine....

Bad news:

• Whilst the OS boots, and the CCTV DVR seems to work, it doesn't recognise any of my cameras
• I suspect that the motherboard is not fully compatible with this DVR image, so it doesn't recognise the camera input ports 

It's kind of funny! I managed to flip the situation 180 degrees! :D

I can now login to the DVR, but I can't see my cameras. Before, I could see my cameras, but I couldn't log in.......

Does one of you know how to 'mount' this .bin file, and see if it contains any useful info that would help find the original password, or other ways into the OS? Like re-enabling SSH, or default accounts, or anything useful? 

Here's a copy of the .bin file I pulled from the chip: https://drive.google.com/file/d/19epXpqNXnw5TfAj3lQKDtSYABqXgOM86/view?usp=sharing

On Thursday, 4 October 2018 19:38:23 UTC+1, michel thomasius wrote:

[michel thomasius]

I've been doing some more research into this mysterious file I dumped from the BIOS.

From what I can gather, its basically a Master Boot Record, + some other partitions, which appear to contain a bootable Linux Kernel. I've used HxD Hex Editor to get this far.

So, I can partially read stuff from the file, but its not particularly helpful. I have used DD to write the .bin file to a USB stick, in the hope that I can actually mount and explore the various partitions. But that didn't work. 

I used 2x different file recovery utilities, to see if they can read the files, and that didn't yield much either.

I booted up Gparted, attempting to read the USB Key, but it didn't recognise the partitions on the USB key.

So, my question is this:

Assuming (maybe incorrectly...) that this is a simple master boot record and some other partitions, how would you go about mounting these partitions, so that they can be read? (to ultimately extract the password) 

I've posted the question on the SuperUser Forum, but have so far had very little traction. (https://superuser.com/questions/1366884/mount-read-the-contents-of-a-binary-dump-from-a-bios-eeprom?noredirect=1#comment2056004_1366884)

Kind regards,

Michel

[Hugo Mills]

On Mon, Oct 15, 2018 at 09:19:46AM -0700, michel thomasius wrote:
> I've been doing some more research into this mysterious file I dumped from
> the BIOS.
>
> From what I can gather, its basically a Master Boot Record, + some other
> partitions, which appear to contain a bootable Linux Kernel. I've used HxD
> Hex Editor to get this far.
>
> So, I can partially read stuff from the file, but its not particularly
> helpful. I have used DD to write the .bin file to a USB stick, in the hope
> that I can actually mount and explore the various partitions. But that
> didn't work.
>
> I used 2x different file recovery utilities, to see if they can read the
> files, and that didn't yield much either.
>
> I booted up Gparted, attempting to read the USB Key, but it didn't
> recognise the partitions on the USB key.

Does it say why it's not recognising it? Or is it just telling you
that there's no partition table on the device?

Note that you can always use the loopback driver to turn (a copy
of) your file into a block device -- you don't have to dd it to a USB
stick. "losetup -f image.bin" to set up the loopback and print the
device; "losetup -d <device>" to detach it again.

> So, my question is this:
>
> Assuming (maybe incorrectly...) that this is a simple master boot record
> and some other partitions, how would you go about mounting these
> partitions, so that they can be read? (to ultimately extract the password)

I'd probably first look really hard at the data in the partition
table and see if it makes any sense in the context of the device.
i.e. do the numbers correspond to something inside the size of the
file you've got, and do they represent something big enough to be a
useful filesystem? Also verify the checksum for the whole MBR block --
it's possible that they've written a bad checksum there and their BIOS
equivalent simply doesn't bother to verify it.

You might also consider using testdisk [1] on the image to see if
it can identify the filesystem(s) directly.

Hugo.

[1] https://www.cgsecurity.org/wiki/TestDisk

--
Hugo Mills | "I lost my leg in 1942. Some bastard stole it in a
hugo@... carfax.org.uk | pub in Pimlico."
http://carfax.org.uk/ |
PGP: E2AB1DE4 |

[Vance Briggs]

Michael,

I guess from what you have written that you can see the contents of one of the MBR partitions as you say it contains the bootable Linux kernel.  It is usual for this "bootable" partition to be on a FAT partition, which is maybe why you can read it on your current machine.  The other partitions will likely contain different file systems, most likely some form of EXT partition, but could be some other kind.  Usually the MBR has a code associated with the partition that helps to identify the filesystem.  However if gparted hasn't recognised the partitions you may be a little stuck.  With a DVR type system they could conceivably just write their own filesystem to handle the fast framerate video better, but that seems like a lot of effort if you can just reuse somebody else's work...

Vance

--

[michel thomasius]

Hi Hugo,

thanks a million. You've hit the nail squarely on the head with your suggestions!! 

I've download TestDisk and have been able to read some of the data. Unfortunately, due to my limited knowledge about partitioning, I've only managed to scratch the surface of this ever deepening mystery. But at least I feel like I am getting somewhere :)

I attach some pictures of what I have found. It looks like the two partitions within the image are of the type CRAMFS. I have tried to mount the .bin file on OSX and Ubuntu 16.04 as cramfs, but failed. OSX refuses, Ubuntu at least gives me a "cramfs: wrong magic" error in the DMESG log. Unfortunately this exhausts my partitioning knowledge, so I was wondering whether you know of a way to drive this forward? 

I suspect that something within the partitioning table is still corrupt or misconfigured. But I don't know how to fix that. Would you be happy to lend a hand with this?

(right-click on the images and select "Open Image in new tab" to see the original size)

Kind regards,

Michel

[Hugo Mills]

On Mon, Oct 15, 2018 at 01:53:16PM -0700, michel thomasius wrote:
> Hi Hugo,
>
>
> thanks a million. You've hit the nail squarely on the head with your
> suggestions!!
>
> I've download TestDisk and have been able to read some of the data.
> Unfortunately, due to my limited knowledge about partitioning, I've only
> managed to scratch the surface of this ever deepening mystery. But at least
> I feel like I am getting somewhere :)
>
> I attach some pictures of what I have found. It looks like the two
> partitions within the image are of the type CRAMFS. I have tried to mount
> the .bin file on OSX and Ubuntu 16.04 as cramfs, but failed. OSX refuses,
> Ubuntu at least gives me a "cramfs: wrong magic" error in the DMESG log.
> Unfortunately this exhausts my partitioning knowledge, so I was wondering
> whether you know of a way to drive this forward?

cramfs is, as far as I know, a Linux-specific filesystem, so OSX
not knowing about it is expected. It's designed to have a small
footprint for the purposes of embedded systems, so it's not surprising
that it's found here.

"wrong magic" -- most filesystems contain a particular string at a
known location (for example, btrfs has "bHRfs_M_", starting at 65600
bytes from the start of the partition). This is referred to as the
"magic string", and is usually checked by the kernel when it's asked
to mount a filesystem of a particular type. If the right string isn't
found, you get messages like "wrong magic".

So, either it's actually a cramfs image and it's been corrupted, or
it's a non-standard cramfs image with a different magic, or it's
something else, but it happens to look like a cramfs in some other
respect.

Although... did you actually create the partition table entries?
You said you're trying to mount the .bin file, but that in itself
won't mount as cramfs -- you'll have to make the partition table (or
do loopback with the right offsets), and mount from the right place in
the image.

> I suspect that something within the partitioning table is still corrupt or
> misconfigured. But I don't know how to fix that. Would you be happy to lend
> a hand with this?

Sure, although I'm only really around tomorrow evening from 18.30,
and Friday evening this week.

How large is the image file? Could you stick it somewhere that I
could download it?

Hugo.

> (right-click on the images and select "Open Image in new tab" to see the
> original size)
>

> [image: Screen Shot 2018-10-15 at 21.01.37.jpg] <about:invalid#zClosurez>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [image: Screen Shot 2018-10-15 at 21.01.48.jpg] <about:invalid#zClosurez>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [image: Screen Shot 2018-10-15 at 21.01.58.jpg] <about:invalid#zClosurez>
>
>
>
>
>
>
>
>
>
>
>
> [image: Screen Shot 2018-10-15 at 21.00.00.jpg] <about:invalid#zClosurez>

[michel thomasius]

Hi Hugo, 

really appreciate your help with this! You clearly know more about partitioning than I do ;)

You can find a copy of the file here: https://drive.google.com/file/d/19epXpqNXnw5TfAj3lQKDtSYABqXgOM86/view?usp=sharing

Kind regards,

Michel

--
You received this message because you are subscribed to a topic in the Google Groups "rLab / Reading's Hackspace" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/reading-hackspace/LOi4HvtzB9M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to reading-hacksp...@googlegroups.com.

[Hugo Mills]

Well...

I recreated the partition table as suggested by testdisk, and then:

hrm@amelia:~ $ sudo losetup --show -f -P Kare_CCTV_Backup_13-10-18.bin
/dev/loop1
hrm@amelia:~ $ mkdir p1 p2
hrm@amelia:~ $ sudo mount /dev/loop1p1 p1
hrm@amelia:~ $ sudo mount /dev/loop1p2 p2
hrm@amelia:~ $ df -T p1 p2
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/loop1p1 cramfs 4808 4808 0 100% /home/hrm/p1
/dev/loop1p2 cramfs 16 16 0 100% /home/hrm/p2

This is good, so far. All as expected. But...

hrm@amelia:~ $ ls p1
ls: reading directory 'p1': Input/output error
hrm@amelia:~ $ ls p2
''$'\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377'

... which is not so good. I think we're back to "not actually cramfs",
or "custom FS code modifications", or possibly "corrupt data". I'd
have to track down the cramfs disk format documentation to check out
the first of those. The last one -- there's some systematic errors
that should be easy enough to check (like the wrong endianness).

Hugo.

[Hugo Mills]

Michel, do you happen to know what architecture this thing runs? Is
it ARM, MIPS, x86? cramfs is sensitive to host endianness...

Hugo.

Hugo Mills | emacs: Eats Memory and Crashes.
hugo@... carfax.org.uk |
http://carfax.org.uk/ |
PGP: E2AB1DE4 |

[michel thomasius]

Hi Hugo, 

I believe the processors used in the DVR's are based on an ARM Architecture. Mine has got a HI3515 processor: https://www.burglaryalarmsystem.com/pdf/Hi3515.pdf

BTW, I've started reading up on forensics and found an article on "file carving" (https://resources.infosecinstitute.com/file-carving/), which allows you to recover data straight from the Hex. I have identified 11 different segments in the .bin file, but they are definitely not single files. So whilst very interesting, I think the method you are pursuing is probably going to yield fruits much sooner! :)

I have put the file segments here, if you want to have a look at them. Not sure whether it is of much use tho: https://drive.google.com/drive/folders/1OLpivIDKHaMVJ0s__VULISTfmZ54Nej9?usp=sharing

Kind regards,

Michel

[michel thomasius]

Hi Hugo,

Been doing some more research into this and found a Linux set of utilities that is designed to extract firmware images from embedded systems, including DVR's: https://code.google.com/archive/p/firmware-mod-kit/wikis/Documentation.wiki

I originally got to the link through a security advisory: https://blog.rapid7.com/2013/01/28/ray-sharp-cctv-dvr-password-retrieval-remote-root/

I'll have a go to see if I can extract the image using the utilities. Lets see if it can 'mount' the .bin image. I'll report back later! :)

[michel thomasius]

OK, 'nother update!

The firmware extraction utility has not really worked. It has however pointed me in the direction of another utility called 'binwalk', which appears to be more capable for cramfs's

https://github.com/ReFirmLabs/binwalk

I've run it across the firmware image and it has reported the info in the attached binwalk.log file. I'll work some more on this. Maybe I can actually get it extracted with my (very) limited skills!

[Mark Robson]

Ok,

There is a cramfs root filesystem at offset 0x100000 (512k) from the beginning of the image. This appears to be the root filesystem but it doesn't contain all the files.

The trick is to examine /etc/init.d/rcS, which contains these lines:

mount -t squashfs /dev/mtdblock2 /usr
mount -t squashfs /dev/mtdblock3 /mnt/web
mount -t squashfs /dev/mtdblock4 /mnt/custom
mount -t cramfs /dev/mtdblock5 /mnt/logo
mount -t jffs2 /dev/mtdblock6 /mnt/mtd

Which mount the other filesystems.

However, I cannot see a standard partition table, I think the mtd (memory tech device) offsets are provided by the bootloader, using this Linux command line parameter:

mtdparts=hi_sfc:512K(boot),4M(romfs),5632K(usr),1536K(web),3M(custom),256K(logo),1280K(mtd)

Your password won't be on a squashfs or cramfs, because they're readonly. So I am guessing it's on /dev/mtdblock6 which is a jffs

So I extracted the partition mtdblock6, which has an offset of 15104k, like this:

dd if=Kare_CCTV_Backup_13-10-18.bin bs=1k skip=15104 of=mtd.bin

Mounting jffs2 filesystems can't be done using a standard loop mount ( like the cramfs above), you need to use this incantation:

# Add kernel modules for the ram mtd driver

modprobe mtdram
modprobe mtdblock

# Copy the part of the image

dd if=Kare_CCTV_Backup_13-10-18.bin bs=1k skip=15104 of=/dev/mtdblock0

mount /dev/mtdblock0 /mnt/mtd/ -t jffs2

# Now the filesystem is mounted in /mnt/mtd.

It didn't take me long to find the passwords in the files Config/Account1 and Config/Account2 - I assume they are unencrypted, they don't look encrypted.

The whole extracted filesystem is here as a .zip file for easier inspection:

https://drive.google.com/open?id=1ErmCeTZgvIkhzwSWzRkJLPUH6jHQy2pr

NB: All of the above was done on a normal Ubuntu Linux VM.

If you are really interested, it should be possible to extract the other readonly partitions which contain the runtime code for the rest of the app.

Mark

[michel thomasius]

Hi Mark,

i've successfully extracted the partitions using binwalk!! :D

If you download the utility and run it against the image with the following options, it extracts all the partitions. I was blown away by how capable that little utility is!

binwalk -Me firmware.bin

I'm now working on the password portion. My first bet would be on the password being located inside the squashfs-root/etc/auth.dat file. 

Not 100% sure what format that is, but it's not Base64. Already tried that. So I'll have to investigate password cracking tools now. This is turning out to be one hell of a rabbit hole!!! ;D

[Mark Robson]

Michel,

Sorry if it wasn't clear in my last post - I think the passwords are in the jffs2 partition at offset 15104k in files Config/Account1 and Config/Account2.

The squashfs partitions are interesting but unlikely to contain any user-changable passwords because squashfs is read-only.

I posted a zipfile of the contents of the jffs2 partition, those are plain text files (nicely formatted JSON) so you should see the passwords there. I don't think they're encrypted.

Mark

[Hugo Mills]

Nice one, Mark. How did you detect the filesystem locations?
testdisk didn't find the jffs2 or squashfs, and clearly misdiagnosed
the cramfs ones when I tried it last night.

It's interesting to note that the first 4 bytes of the image are
32-bit ARM assembly for "b(ranch) #0x1328". My dim memories of a much
older ARM system are that that's the reset vector, so there's probably
the bootloader code in the image at 0x1328.

I concur that there's no MBR partition table on there -- but I
wouldn't really expect one on something like this.

Hugo.

--
Hugo Mills | Comic Sans goes into a bar, and the barman says, "We
hugo@... carfax.org.uk | don't serve your type here."
http://carfax.org.uk/ |
PGP: E2AB1DE4 |

[Mark Robson]

Hugo,

I used "strings" on the image file, and I found in the bootloader partition somewhere, the kernel command-line parameters:

bootargs=mem=104M console=ttyAMA0,115200 root=1f01 rootfstype=cramfs mtdparts=hi_sfc:512K(boot),4M(romfs),5632K(usr),1536K(web),3M(custom),256K(logo),1280K(mtd)

So I looked up what the "mtdparts" parameter does (For example, the explanation here https://www.denx.de/wiki/view/DULG/BootTimeConfigurationOfMTDPartitions )

Then I did some arithmetic to calculate the offsets, and used a hex editor to confirm that they looked plausible.

I don't know if there are any partition tables in the image, but it doesn't need any if the partitions size are all passed to the kernel.

Mark

--

You received this message because you are subscribed to the Google Groups "rLab / Reading's Hackspace" group.

To unsubscribe from this group and stop receiving emails from it, send an email to reading-hacksp...@googlegroups.com.

[michel thomasius]

Hi Mark,

no need to apologize. I think that you were probably quite clear, if I had actually been able to understand what you were trying to tell me. Clear case of the info going over my head! ;)

I've downloaded your zip now. Let me have a look at it and report back. And thanks a million to both you and Hugo for all the *MEGA* effort you two have put into this!!

[michel thomasius]

Mark, Hugo, (and all the other's who have been extremely helpful!)

I am very grateful for the help you guys have given me. I would almost certainly not have been able to do this without you! :)

I've looked at the passwords in the Config/Account1 and Config/Account2 files, and they definitely do *NOT* look like the password I have set. Which is weird. But it may also explain why I couldn't get in... 

I've re-flashed the chip with the original image yesterday, but I am unable to boot the device for some reason. I will open a separate thread for that, as this is a completely different rabbit hole. :)

I am now trying to figure out if this thing has a serial port on the MB, which I could tap into to read the log out from the boot process! ;)

Thanks again, and see you in the other thread (hopefully)!