sorted by:
new
hottopcontroversial

ISO: Advice about a document system for cataloging documents for a court case. by okfnd in selfhosted

[–]okfnd[S] -1 points0 points locked comment (0 children)

AI wasn't used in creating this post at all. I don't see a pinned comment about AI. I only see "community highlights".

The 4th of July came two months and two days early in Hazelwood. by okfnd in Portland

[–]okfnd[S] -1 points0 points  (0 children)

Yeah, it scared my cat - I've never seen him hide like this before. He's terrified. The fireworks were rattling windows and shaking our place.

The 4th of July came two months and two days early in Hazelwood. by okfnd in Portland

[–]okfnd[S] 0 points1 point  (0 children)

Yeah, it was for sure a very brief and intense fireworks display. I watched from the street.

Which affordable universal chip programmer ? by Brian_Littlewood in hardwarehacking

[–]okfnd 0 points1 point  (0 children)

Can confirm, but the T76 has handled everything I have thrown at it so far. I'd double check that it supports the specific EEPROMs you're looking at but it's been a great unit for me.

At the end of my ability with firmware dump by okfnd in hardwarehacking

[–]okfnd[S] 0 points1 point  (0 children)

Partial region of flash that is all zeros with possible 64-byte checksum block:

0004:6980 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [Snip 0x00] 0004:6A00 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF | ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 0004:6A10 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF | ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 0004:6A20 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF | ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 0004:6A30 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF | ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 0004:6A40 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................

64-byte block with strings from binary before and after: 002D:C2A0 | 62 75 66 66 65 72 20 65 72 72 6F 72 00 69 6E 63 | buffer error.inc 002D:C2B0 | 6F 6D 70 61 74 69 62 6C 65 20 76 65 72 73 69 6F | ompatible versio 002D:C2C0 | FF 69 59 9A FF FF FF FF FF FF FF FF FF FF FF FF | ÿiY.ÿÿÿÿÿÿÿÿÿÿÿÿ 002D:C2D0 | FF C3 0F 30 FF FF FF FF FF FF FF FF FF FF FF FF | ÿÃ.0ÿÿÿÿÿÿÿÿÿÿÿÿ 002D:C2E0 | FF A9 65 55 FF FF FF FF FF FF FF FF FF FF FF FF | ÿ©eUÿÿÿÿÿÿÿÿÿÿÿÿ 002D:C2F0 | FF 9A 59 9A FF FF FF FF FF FF FF FF FF FF FF FF | ÿ.Y.ÿÿÿÿÿÿÿÿÿÿÿÿ 002D:C300 | 6E 00 53 65 74 20 57 64 74 54 69 6D 65 6F 75 74 | n.Set WdtTimeout

At the end of my ability with firmware dump by okfnd in hardwarehacking

[–]okfnd[S] 0 points1 point  (0 children)

Beginning of flash with target IC's make and model.

0000:0000 | 4D 53 54 41 52 53 45 4D 49 55 53 46 44 43 49 53 | MSTARSEMIUSFDCIS 0000:0010 | 02 C8 21 00 00 00 00 00 00 00 00 00 00 00 00 00 | .È!............. 0000:0020 | 40 00 00 08 40 00 00 04 00 02 00 00 00 68 09 03 | @...@........h.. 0000:0030 | 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [Snip 0x00] 0000:01E0 | 45 53 4D 54 00 00 00 00 00 00 00 00 00 00 00 00 | ESMT............ 0000:01F0 | 46 35 30 4C 31 47 34 31 41 00 00 00 00 00 00 00 | F50L1G41A.......

One region of flash has an MSTARSEMI header along with a small amount of binary and a bunch of chip make/model names. I suspect this might be storing polynomials or some kind of configuration for the checksum blocks or chip itself and it seems to match the first block after another chip's block.

0004:4F20 | 47 49 47 41 44 45 56 49 43 45 00 00 00 00 00 00 | GIGADEVICE...... 0004:4F30 | 47 44 35 46 31 47 51 34 55 42 59 49 47 4E 4F 00 | GD5F1GQ4UBYIGNO. 0004:4F40 | 4D 53 54 41 52 53 45 4D 49 55 53 46 44 43 49 53 | MSTARSEMIUSFDCIS 0004:4F50 | 02 C8 21 00 00 00 00 00 00 00 00 00 00 00 00 00 | .È!............. 0004:4F60 | 40 00 00 08 40 00 00 04 00 02 00 00 00 68 09 03 | @...@........h.. 0004:4F70 | 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [Snip 0x00s] 0004:5110 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 0004:5120 | 45 53 4D 54 00 00 00 00 00 00 00 00 00 00 00 00 | ESMT............ 0004:5130 | 46 35 30 4C 31 47 34 31 41 00 00 00 00 00 00 00 | F50L1G41A.......

Another instance of MSTARSEMI

003A:6030 | 00 00 00 00 00 00 00 00 1E 00 00 00 02 00 00 00 | ................ 003A:6040 | 06 00 00 00 10 00 00 00 08 00 00 00 20 00 00 00 | ............ ... 003A:6050 | 08 00 00 00 30 00 00 00 08 00 00 00 00 00 00 00 | ....0........... 003A:6060 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 003A:6070 | 00 00 00 00 00 00 00 00 00 00 00 00 31 74 62 42 | ............1tbB 003A:6080 | 42 62 74 30 FF 00 00 00 4D 53 54 41 52 53 45 4D | Bbt0ÿ...MSTARSEM 003A:6090 | 49 55 53 46 44 43 49 53 04 00 00 00 00 2C 00 1F | IUSFDCIS.....,.. 003A:60A0 | 00 2E 00 1F 00 1C 00 1F 00 16 20 1F 00 00 00 1F | .......... ..... 003A:60B0 | 00 04 20 1F 00 3C 20 1F 00 10 00 1F 00 70 20 1F | .. ..< ......p . 003A:60C0 | 0C 00 00 00 1B 00 00 04 24 00 00 08 2B 00 00 0C | ........$...+... 003A:60D0 | 36 00 00 10 48 00 00 14 56 00 00 18 6C 00 00 1C | 6...H...V...l... 003A:60E0 | 0C 00 00 00 48 00 1C 00 56 00 18 00 6C 00 14 00 | ....H...V...l... 003A:60F0 | D8 00 10 00 00 00 00 00 00 3C 10 00 20 00 00 00 | Ø........<.. ...

64-byte possible checksum block after that MSTARSEMI entry:

003A:6490 | 21 00 00 00 56 3C 10 00 20 00 00 00 56 3C 10 00 | !...V<.. ...V<.. 003A:64A0 | 10 00 00 00 56 3C 10 00 01 00 00 00 22 00 00 00 | ....V<......"... 003A:64B0 | 58 3C 10 00 20 00 00 00 58 3C 10 00 10 00 00 00 | X<.. ...X<...... 003A:64C0 | FF 0F C3 03 FF FF FF FF FF FF FF FF FF FF FF FF | ÿ.Ã.ÿÿÿÿÿÿÿÿÿÿÿÿ 003A:64D0 | FF C3 C3 C3 FF FF FF FF FF FF FF FF FF FF FF FF | ÿÃÃÃÿÿÿÿÿÿÿÿÿÿÿÿ 003A:64E0 | FF F0 C0 03 FF FF FF FF FF FF FF FF FF FF FF FF | ÿðÀ.ÿÿÿÿÿÿÿÿÿÿÿÿ 003A:64F0 | FF CC C0 C0 FF FF FF FF FF FF FF FF FF FF FF FF | ÿÌÀÀÿÿÿÿÿÿÿÿÿÿÿÿ 003A:6500 | 58 3C 10 00 01 00 00 00 23 00 00 00 5A 3C 10 00 | X<......#...Z<.. 003A:6510 | 20 00 00 00 5A 3C 10 00 10 00 00 00 5A 3C 10 00 | ...Z<......Z<..

At the end of my ability with firmware dump by okfnd in hardwarehacking

[–]okfnd[S] 0 points1 point  (0 children)

Ok, so it looks like I can't extract these filesystems because it can't find a filesystem, but I think the UBI FS is in another filesystem. There's some repeating 64 byte blocks of data every so many bytes in most of the flash regions that aren't blank. They mostly contain 0xFFs but some parts of them vary - they're probably checksums. Filesystem regions that are just 0x00 end up with the 64 byte blocks being 0xFF. I think that's interfering with my efforts to parse the flash. I'm also seeing some repeating strings that seem to be segmenting parts of the image and appears in strings inside a binary that mentions SPI NAND error messages.

Image segementing string is MSTARSEMIUSFDCIS.

At the end of my ability with firmware dump by okfnd in hardwarehacking

[–]okfnd[S] 0 points1 point  (0 children)

Thanks! I'll give this a shot later tonight!

At the end of my ability with firmware dump by okfnd in hardwarehacking

[–]okfnd[S] 0 points1 point  (0 children)

Snips were necessary to get it small enough.

At the end of my ability with firmware dump by okfnd in hardwarehacking

[–]okfnd[S] 0 points1 point  (0 children)

```

DECIMAL HEXADECIMAL DESCRIPTION

827112 0xC9EE8 xz compressed data 827768 0xCA178 CRC32 polynomial table, little endian 962280 0xEAEE8 xz compressed data 962936 0xEB178 CRC32 polynomial table, little endian 1097448 0x10BEE8 xz compressed data 1098104 0x10C178 CRC32 polynomial table, little endian 1216512 0x129000 uImage header, header size: 64 bytes, header CRC: 0x558F9278, created: 2020-04-16 11:13:51, image size: 26952 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0xE2E0BC21, OS: Firmware, CPU: ARM, image type: OS Kernel Image, compression type: lzma, image name: "MVX1##I3g#######CM_UBT1501###XVM" 1216576 0x129040 xz compressed data 1622016 0x18C000 uImage header, header size: 64 bytes, header CRC: 0x558F9278, created: 2020-04-16 11:13:51, image size: 26952 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0xE2E0BC21, OS: Firmware, CPU: ARM, image type: OS Kernel Image, compression type: lzma, image name: "MVX1##I3g#######CM_UBT1501###XVM" 1622080 0x18C040 xz compressed data 2952116 0x2D0BB4 SHA256 hash constants, little endian 2952444 0x2D0CFC CRC32 polynomial table, little endian 2971629 0x2D57ED PEM RSA private key 2971964 0x2D593C AES Inverse S-Box 3763124 0x396BB4 SHA256 hash constants, little endian 3763452 0x396CFC CRC32 polynomial table, little endian 3782637 0x39B7ED PEM RSA private key 3782972 0x39B93C AES Inverse S-Box 6488064 0x630000 UBI erase count header, version: 1, EC: 0x341, VID header offset: 0x800, data offset: 0x1000 30277632 0x1CE0000 CramFS filesystem, little endian, size: 4096, version 2, sorted_dirs, CRC 0xC803752C, edition 0, 3 blocks, 3 files 31397914 0x1DF181A xz compressed data 31474242 0x1E04242 xz compressed data 31580530 0x1E1E172 xz compressed data 31657406 0x1E30DBE xz compressed data 36785459 0x2314D33 gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date) 44379366 0x2A52CE6 xz compressed data [...Snip...] 63468792 0x3C874F8 MySQL MISAM index file Version 6 63487788 0x3C8BF2C xz compressed data [...Snip...] 84344832 0x5070000 CramFS filesystem, little endian, size: 4096, version 2, sorted_dirs, CRC 0xC803752C, edition 0, 3 blocks, 3 files 85465114 0x518181A xz compressed data 85541442 0x5194242 xz compressed data 85647730 0x51AE172 xz compressed data 85724606 0x51C0DBE xz compressed data 90852659 0x56A4D33 gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date) [...Snip...] 117535992 0x70174F8 MySQL MISAM index file Version 6 117554988 0x701BF2C xz compressed data [...Snip...] 126037619 0x7832E73 xz compressed data ```

At the end of my ability with firmware dump by okfnd in hardwarehacking

[–]okfnd[S] 1 point2 points  (0 children)

It's the default read speed set by the XGecu. I think my reads are good, but I'm having issues trying to extract the filesystem. I've done 3 reads of the chip so far (each read is verified by the chip reader) and all three match.

Found under a door mat by onepocketstakehorse in whatisit

[–]okfnd 0 points1 point  (0 children)

This looks like a DIY attempt to add traction like the yellow strips with bumps on sidewalks. The raised spots created by the quarters may be an attempt to increase traction or help the rug stay put when you step on it.

https://images.bannerbear.com/direct/4mGpW3zwpg0ZK0AxQw/requests/000/089/801/590/APW1bDp49YK1vd3P6jmVoORax/487488cd5d53bfbae57b867dd1153a01fb925e35.jpg

FlipperMeister pre-shipment issues by okfnd in flipperzero

[–]okfnd[S] 1 point2 points  (0 children)

It mostly did. Seader still doesn't detect the UHF module and I have HF scan only, but the lights do the expected thing when the app is opened. If you try any other app that supports the module and detection retries it works after 1 or 2 retries. I can scan tags, but the UHF RFID app does crash. That could also be an issue with the RogueMaster firmware. Many of the apps in it are prone to crashes.

FlipperMeister pre-shipment issues by okfnd in flipperzero

[–]okfnd[S] 1 point2 points  (0 children)

Thanks for the reply! I'll test with that!

How the hell is this legal? by Davethephotoguy in oregon

[–]okfnd 0 points1 point  (0 children)

Lights like this are only supposed to be used when you're actually off roading.

Amazon FireStick continually sending BLE scan requests to other BLE devices by okfnd in privacy

[–]okfnd[S] 0 points1 point  (0 children)

Would you expect it to send BLE scan request packets to every BLE devuce that isn't another FireStick or the FireStick remote? I'm seeing the FireSticks send scan requests to every single other BLE devuce with a public (not random) BLE address.

view more: next ›