Buddha machine teardown with flash dump
Вставка
- Опубліковано 24 сер 2024
- This is one of many devices on eBay sold as buddhist meditation aids.
They generally have a large number of well-compressed audio files that loop to provide an ambience that will help achieve the state of ultimate-shamoo whereby they may drink holy-beer and party. (My understanding of religion may not be accurate.)
When I took another more glorious solar powered unit apart in a different video I was asked if I could dump the flash memory chip to see if it could be repurposed with alternative music files.
Keep in mind that the memory is just 16 Mbit, equating to 2 Megabytes of 8 bit memory, which is only enough for 2 minutes of decent quality MP3 music. That's just enough for random fart noises or a Rickroll.
The unit may possibly use an ordinary MP3 player chip like a gpd2856a or it may have a microcontroller with proprietary software and some form of file protection for the music on the chip.
Here's a link to a dump of the flash contents if you wish to try and solve the puzzle of the data format. www.bigclive.co...
If you enjoy these videos you can help support the channel with a dollar for coffee, cookies and random gadgets for disassembly at:-
www.bigclive.co...
This also keeps the channel independent of UA-cam's advertising algorithms allowing it to be a bit more dangerous and naughty.
#ElectronicsCreators
![АЛАУДИНОВ у Скабеевой: эти их ВСУ нас НЕ ДОГОНЯТ 😁 [Пародия]](http://i.ytimg.com/vi/an0anqU4WGQ/mqdefault.jpg)
“Three things cannot be long hidden: the sun, the moon, *and the working of items.* ”
and an affair.
@Philip Carpenter Not even BEHIND the sun ;-)
Almost half the Moon remained hidden for a very long time.
@Philip Carpenter thats a type of moon mate
the sunshine the moonlight and the boogie
The volume suddenly "jumping" high is most likely the result of a Linear Pot. Proper audio pots are logarithmic which adjusts the resistive track to more be in line with how hearing works. A linear pot only has a very small range at the end that's usable for audio.
There's a similar effect when the load, here the speaker, has a much lower impedance than the resistance value of the pot.
You beat me to it LOL - Could be anti-log pot too but those are rare as hen's teeth...
Are linear pots any cheaper than log ones? I was wondering if this was another way to reduce the cost
maybe, theres cheap switched pots on ebay, supposedly sold as volume controls, but are linear, with this sudden volume issue 😉
It obviously doesn't employ a true potentiometer, so why even call it a pot. it's more of a switch imo.
Some observation: look at 0x0000-0x0580, assume this is some 32-byte headers, we can infer that offset is at byte 4-8, that is:
1F 3E 7A F8
1F 3E 02 F8
1F 3E F2 F8
1F 3E EB F8
1F 38 5A BC
and so on.
Assume the first file begins at 0x00000600, we should XOR those with "1F 3E 7C F8". Then we get a nice offset table:
# some 3 unknown files
0x00000600, 0x00007E00, 0x00008E00,
# 39 tracks
0x00009700, 0x00062644, 0x00071944, 0x0007E5BE,
0x0008EA95, 0x00094E50, 0x000C3E60, 0x000E3D16,
0x000EBC86, 0x0010521F, 0x0010958D, 0x001105B9,
0x001124AA, 0x00116C5D, 0x0011F6A1, 0x00128D16,
0x00133083, 0x0013AFCA, 0x001530B6, 0x0015F689,
0x00177364, 0x001814CF, 0x0018BFBF, 0x00192B9F,
0x0019AD58, 0x001A694F, 0x001A85BA, 0x001AE47F,
0x001B7935, 0x001C2E36, 0x001CAA37, 0x001CD6AB,
0x001D023D, 0x001D1901, 0x001D947E, 0x001DED1B,
0x001E4D8E, 0x001E5793, 0x001E7145,
# the last unknown file
0x001F0A00,
Maybe I'll work on this later...
And file length at offset 8-12, with XOR mask "F0 C1 A3 67".
This is a list of headers and lengths (in DEC) of all 39 tracks:
cb 80 bf f0 06 67 72 aa 66 17 f7 8a 3f 44 0d c1 length=364356
cb 80 bf f0 06 67 72 aa 66 17 f7 8b af 63 54 5c length=62208
cb 81 bf f0 06 67 72 aa 66 17 f7 9b d0 85 aa 98 length=52346
cb 81 bf f0 06 67 72 aa 66 17 f7 9a df 44 51 81 length=66775
cb 81 bf f0 06 67 72 aa 66 17 f7 9c 47 6a 0b fe length=25531
cb 81 bf f0 06 67 72 aa 66 17 f7 9c eb 95 4b 99 length=192528
ca 45 ff 80 33 3b 95 53 34 bf bc a9 b3 a0 a0 97 length=130742
ca 4d ff 80 33 3b 95 53 34 bf bd d0 fa 44 a0 9b length=32624
ca 4d ff 80 33 3b 95 53 34 bf bd c2 f7 c5 b1 73 length=103833
ca 4d ff 80 33 3b 95 53 34 bf bd d0 fa 45 16 2e length=17262
ca 4d ff 80 33 3b 95 53 34 bf bd cf 0f cb aa 9c length=28716
ca 4d ff 80 33 3b 95 53 34 bf bd bd 77 60 18 66 length=7921
ca 4d ff 80 33 3b 95 53 34 bf bd c2 f7 06 b2 fe length=18355
ca 4d ff 80 33 3b 95 53 34 bf bd cd 2c 9f fb b9 length=35396
ca 4d ff 80 33 3b 95 53 34 bf bd b6 87 3d b7 95 length=38517
ca 4d ff 80 33 3b 95 53 34 bf bd c9 f9 8d 8b 99 length=41837
ca 4d ff 80 33 3b 95 53 34 bf bd c8 0f ec 97 64 length=32583
ca 4d ff 80 33 3b 95 53 34 bf bd cb f8 f0 03 2e length=98540
ca 4d ff 80 33 3b 95 53 34 bf bd b2 f5 8a a0 9d length=50643
ca 4d ff 80 33 3b 95 53 34 bf bd c4 a6 e0 b6 ea length=97499
ca 45 ff 80 33 3b 95 53 34 bf bc cb f7 2e 60 e1 length=41323
ca 4d ff 80 33 3b 95 53 34 bf bd cd 0f db a9 86 length=43760
ca 4d ff 80 33 3b 95 53 34 bf bd d0 99 85 fe b9 length=27616
ca 4d ff 80 33 3b 95 53 34 bf bd c1 f8 88 04 00 length=33209
ca 4d ff 80 33 3b 95 53 34 bf bd d4 f9 a5 17 34 length=48119
ca 4d ff 80 33 3b 95 53 34 bf bd d2 0e 8a a9 99 length=7275
ca 4d ff 80 33 3b 95 53 34 bf bd c6 f6 0a 00 81 length=24261
ca 4d ff 80 33 3b 95 53 34 bf bd d1 fa 0a 42 e5 length=38070
ca 4d ff 80 33 3b 95 53 34 bf bd b8 94 60 3d 9a length=46337
ca 4d ff 80 33 3b 95 53 34 bf bd c8 88 7f fb 53 length=31745
ca 4d ff 80 33 3b 95 53 34 bf bd d8 c9 bf 66 1c length=11380
ca 4d ff 80 33 3b 95 53 34 bf bd c6 f8 05 28 b8 length=11154
ca 4d ff 80 33 3b 95 53 34 bf bd bf f5 9c b9 85 length=5828
ca 4d ff 80 33 3b 95 53 34 bf bd d3 fa 02 01 12 length=31613
ca 4d ff 80 33 3b 95 53 34 bf bd c6 f8 85 e0 20 length=22685
ca 4d ff 80 33 3b 95 53 34 bf bd c0 f5 f4 41 3a length=24691
ca 4d ff 80 33 3b 95 53 34 bf bd d2 88 5c f1 79 length=2565
ca 4d ff 80 33 3b 95 53 34 bf bd d2 a6 c5 cc e6 length=6578
ca 4d ff 80 33 3b 95 53 34 bf bd bf f7 62 12 e2 length=38884
Then I have no more ideas, at least for now...
Excellent work. I came to the same conclusion.
I figured this was some kind of rolling or rotating XOR cypher, and funny enough, if you look at that sequence "1F 3E 7C F8" in binary...
00011111
00111110
01111100
11111000
A bunch of these 4-byte values start with EF. XOR the two masks you guys found F0C1A367 ^ 1F3E7CF8 = EFFFDF9F which nicely decodes some other stuff, such as an index counter from 0 to 2A.
EF = 11101111
FF = 11111111
DF = 11011111
9F = 10011111
No such nice pattern as before. What I do notice is that in this 4-byte value, there is only 1 bit difference between each adjacent byte. For 1F3E7CF8, it is 2 bits difference. For F0C1A367 it is 3 bits.
Another point is that if you XOR adjacent bytes in the sequence EFFFDF9F 1F3E7CF8 F0C1A367, it doubles between each byte except when it doesn't. It goes 10 20 40 80 21 (first 2 bytes of the 2nd value) 42 84 08 31 (first 2 bytes of the 3rd value) 62 C4. The next in the sequence would be 88 which XORs 67 into EF and I guess the sequence then repeats. However this doesn't decode the file into anything I recognise.
@@userPrehistoricman well spotted. I think there is probably some rolling algorithm or perhaps they are starting with one character for the XOR and then shifting and rotating it with every character that gets XOR'd.
More relaxing than Yoko Ono..but then again, so are root canals.
HA HA, but whats even more funny I had root canals done by a Japanese dentist. Guess what her name was? I rest my case.
From what I can hear, the chanting sounds like Chinese Chan Buddhist chants. It's a sect of Mahayana Buddhism. Mostly, as is usual for the sect, the chanting focuses on Amitabha. It's kind of the laziest form of Buddhist chanting. The belief is that the chanting or calling out the name of this aspect/incarnation/avatar of Buddha can grant you or others good karma, if not safe passage to an in-between place/realm where the avatar allows the faithful to slowly reach enlightenment under its good graces. This particular light is often used next to shrines or columbariums for a deceased relative or several deceased individuals. It's played on loop to slowly gain the deceased person(s) good karma.
I don't imagine anyone has the music copyrighted, as it's often given for free on CDs or DVDs by temples, monks, devotee elderly folk looking to gain good karma in their twilight years, etc... Plus, the sutras from which the prayers come are cultural heritage and freely available, and monks chant them in temples multiple times a day for anyone to record. Seems very un-Buddhist to remain attached to the mortal monetary gains one might be able to gain from controlling such a transient thing.
I should probably be transparent that I'm a lay Theravada buddhist living in a Chinese Mahayana buddhist majority county. I studied this stuff as part of two of my minors while in university. So, I'm not an expert, but, I'd like to think, I'm not some random crackpot either.
Cheers for the breakdown review, by the way!
Have you tried running it with the flash chip off? I've got a different buddha machine (with a different flash layout), and if there's no chip it plays some built-in stuff.
I don't need a buddha lamp to put me in a meditative mood. Listening to Clive does it for me.
Well, of course the music chip needs to be re-flashed to play Nirvana.
I got a chip to play 'Black Jesus' in my 2PAC shrine.
Or The Beatles Sergeant pepper-
@@echelonrank3927 Do you have a video of that and the process you did to reprogram it? Also I hope you put 2pac back on after.
@@coondogtheman Theres no real programming. Its basically a microSD card that can be taken out and audio files written to it such as Black Jesus by 2PAC. He was a 90s rapper. I might make a video of how I built the shrine if i get a few more thumbs up.
@@echelonrank3927 Theres another thumbs up for ya. I know 2pac is a 90s rapper I was born in 80. I'm a pretty big fan of him and sad that he is gone.
This video is no longer available due to a copyright claim by Siddhārtha Gautama. Sorry about that.
As an Australian I'm quite familiar with a flash dump, it's what many of us do if we suspect there might be a snake or spider in the toilet
Ebay must really love you for the sheer amount of junk you buy. And then many of us enjoy how you entertain us by pulling apart and explaining what makes it tick. Whatever you do, don't stop. :)
That music copyright strike is a real PITA when you get a strike on some music that DOESN'T belong to them. Yes SONY I'm looking at you. Some orchestral pieces have been recorded and placed into the public domain but because YT can't tell the difference, it assumes we've stolen them! Sure you can appeal but that takes months and every time you upload a new version you have to start over. It's doubly annoying when you see huge amounts of stolen material (video and audio) on here that for some reason is never caught.
@@JC-gu5cf Well perhaps, but it's the fact that the AI jumps on legitimate usages of public domain material that really irks me. I get that it's hard to determine which orchestral version of a piece of music that has been around for centuries is (this is one example I've been hit with repeatedly) but Sony and those like them need to realise that once something has been placed into the Public Domain then they can't claim rights to it everywhere its heard unless they can prove it's their actual recording. As it, I can't even put my work up for preview without having it removed as a strike. It's utterly bizarre. And yea, you're probably right, a lot of UA-cam (and other large publisher's content moderation) is probably done in countries outside of the USA where English is not the first language and that slows things down.
This is another reason to move away from UA-cam and to federated systems that exist outside of the control of vast corporations that answer to (in effect) no one. You know, the way the Internet always was supposed to be before the American mega-rich took it back for themselves.
if you ever figure out how to upload an mp3 to it, you should upload that popular reverb fart sound effect you can find on youtube.
then give it to ralfy.
Or a Rickroll!
@@BRUXXUS Never gonna give you up, never gonna give you up, never gonna give you up, never gonna give you up, never gonna give you up.
prrrrrr
use youtube-dl to download the mp3, you can select the filesize
This, but also make it play indefinitely, make it so that it can't be turned off and fill the thing with glitter.
Needs an Ozone generator building into it, IMO :-)
Don't be silly. A USB charging port would be much more practical.
@@IanTester i can confirm, a urb port charged withte blessings of budda, to allow your device to live a long and healthy lifetime
It needs ultrasonic mist
And a whoofler.
Just taken a look at that .bin file using HxD - seems like the first 7x256 byte blocks of flash are used to store file information.
You get regular repeating pattern all the way from 0 up to 0x0700 with some wierd dead zone 0x580 to 0x600.
My guess is the first 7 blocks are offset addresses for the start and end of the tracks, with some additional information as only 3 bytes for start and 3 bytes for end would be strictly required (so only 239 bytes total needed, in fact we have almost 1800).
The data after 0x700 becomes more random as you'd expect with audio data, however importing as a RAW into Audacity in a multitude of PCM bitrates and endianness yielded no results. As others have stated it makes little financial sense to compress such a small amount of data then add a more expensive microcontroller to decode it, when there's only a couple of cent difference between say 2mb and 4mb SPI flash chips.
I suspect it will be something like the BTC algorithm by Roman Black so they don't need to implement a proper DAC in the output stage - I can't post a link here but it's worth checking out.
It doesn't seem to be pure BTc algorithm's bytes in case this algorithm has been used. I heard at the sound created by the decoder/simulator on his site (the Perl script) feeded with the bytes of Clive's dump, only noise. But thanks for mentioning the possibility, I didn't even know this approach before.
@@steiniapproved thanks for testing, I forgot about the Perl script! Oh well it was worth a try
I have managed to decrypt the start of the file and it is indeed a lookup table complete with filenames, offsets and sizes that match up with other parts of the file. The audio files have an .f1a extension but I have no idea what that is. I can't post links but if you can find the Reddit post for this video, I posted my code if there if you are interested in investigating further.
My guess is the music is probably just straight 8-bit binary, maybe there's a table at the beginning with offsets to the start of each clip. Otherwise they'd have to use a more powerful processor to decode the format.
I could have so much fun making MP3 files for that chip.
Lots of quite bird sounds with fart sounds at random times.
Smiles will be had. 😁
I would buy that 😏
The Data in the file appears to be possibly semi-compressed. At the beginning of the file there is a table of contents for each of the 39 sound streams, most likely the pointers to data offsets. There isnt any textual content in the data. The only content readable is right at the end with a string of counting characters (these are usually for helping microcontrollers print on character displays). Imediately after the blank area at the beginning of the data, there are 11 bytes which are repeated exactly once further on. I have no idea why. What I can not work out is how the audio data is compressed as or what format of audio data it is. I even tried using a tool called binwalk and surprisingly it couldnt match anything on contents. It is not compressed audio in the sense of an MP3. It may be compressed in the sense that a couple of bytes represents a pulse shape that the chipset emits. 2MB for 39 audio chunks is quite small. It could be possible that the chipset is processing a byte as two sets of 4 bits per audio clock. There may also be a small amount of runtime code in the data too.
Likely uncompressed PCM audio, since it keeps things small and simple in the firmware, minimizing testing. Putting anything like a MP3 decoder would require a more expensive microcontroller or a separate MP3 codec. For something as cheap as a chanting machine, you might as well just buy a large enough flash chip.
Yes.
if it were 4 bits per sample then when reading audio at 8bit per sample we'd still listen something resembling the original audio, just twice as fast.
So that's not 4 bits per sample.
g.729 is one obvious guess to try.
@@unperrier5998 Thats not how it works XD - If you read two samples of 4 bits as a single byte youd be hearing garbage because the most significant 4 bits (first sample) would be summed on top of the least significant 4 bits (second sample). Each samples signed range is -4 to +3, adding two pairs of 4 bit samples would end up you adding an additional upper signed range of -120 to + 119 which in the 4 bit range is impossible.
This stuff makes me so happy because it turns out I'm not the only one who loves to take things apart simply to see what is in them. It's almost like having a friend...
I have seen similar thing made as promotion item for new car. You got a box and when opened LDR turned on the circuit and personalized message played.
Same blob and memory chip construction and same speaker. From what I found after dumping the eeprom it could be based on sonix snc712 type of chip based on some strings in bin file. Never really managed to extract the files as it was proprietary format.
The PCB construction in this reminds me of the ones in cheap Cassette players in the late 90s! i love that. Keep up the good work Clive!😁
Looks like there's more than just the audio in the flash file... binwalk with cpu_rec says there's 6502 machine language in there, and looking at the entropy, I think I agree. A 6502 actually reminds me of the Sunplus chips that are in Tamagotchis and (the older) Furbies... according to the datasheet, they do 4-bit ADPCM.
Edit: Threw the code into a disassembler, it's no 6502 unfortunately. If the audio is ADPCM, it's not in any format Sox recognizes.
Heheh. I immediately took it to binwalk too.
Sunplus (now mostly GeneralPlus) tends to load things from maskrom unless the code is large enough to enable XIP. Not sure if that's an option for their 6502 chips, but it is for some μ'nSP chips. Probably not the case here though.
@@caralynx Agreed. That plus the fact that what I thought was the interrupt vector region turns out to be too weirdly formed to be an interrupt vector region... I'm not 100% sure anymore if there's any code in flash. There's lots of Chinese voice chips that use their own encoding, so it may be one of those.
@@caralynx Having done quite a bit of work with Sunplus/Generalplus stuff... This doesn't look like one of their formats.
I'm 50/50 on whether there's code in there or not. I think Clive mentioned 39 songs, and my rough estimation of what looks to be the file system table of sorts at the beginning seems to show 44 "files", with each entry in the file system table being 32 bytes long and ending with 0x0F3E.
The first four "files" and the last one's FS entry are formatted significantly differently than the others, so I would presume the other 39 are the actual audio files. But what those 5 extra files are, who knows.
I know there are some MCU vendors that have "no code" MCUs that have predefined programs, and load their "unique" variations on the predefined behaviors and audio from the flash chip, so this might be one of those. I wish I could remember that vendor's name, heh.
@@devttyUSB0 same, but completely no results here.
Looking at the data and some of the comments, I have some thoughts:
- It does look like this is compressed data. Something like MP3, but not older telephony codecs which don't have as much entropy.
- It may be "encrypted" or obfuscated somehow, perhaps XOR'd or just read in an odd order. Codecs like MP3 use frames, and those frames have headers. Its difficult to spot that in the data.
- It would be useful to know exactly how may tracks the device plays and their approximate lengths.
- It may be useful corrupt the file in a way that sheds more light. (you could zero out a few bytes and see which track it effects and how. You could even copy blocks from one part of the file to another then reflashing it.)
I opened the file with a hex editor and I noticed that it ends with, what I think it is, the whole ASCII table, all the characters between 00 and 7F, separated by 00s. Do you have any idea why this is here and can you explain it to me? Thanks!
@@dimitarnikolov3527 It is referenced as a file, so its probably not some vestigial data in the ROM. As to its purpose - hard to say without seeing what the processor does with it.
I looked this over with binwalk and found that it has no header information but has deflate data. There's two common compression methods, 'zlib' and 'deflate', with the major difference being the latter has no header information, thus marginally smaller. I've heard the audio and we can all agree it is heavily compressed. I can't remember the original author of the quote but "Compression and encryption are indistinguishable from one another". There is little to no entropy present within this bin file which indicates that it has no encryption. It is compressed audio that has a deflate container, which makes sense given the space limitations.
EDIT: Trying to play it as a RAW audio file in audacity gives a beep and static sound. This chip has active write protection and I suspect the first few bits are the signal to allow it to continue to execute code. It verifies that the process is not flashing the memory. I honestly think you just stumbled on some machine code programmer that was flexing....
Just about every restaurant in China has dozens of that sort of thing playing out of synch. The little ones like the one Clive has been playing with, tiny one about half that size, and a rage of larger sizes. Art of choosing a table - study the room and look for the area where the noise generators have died as indicated by the lack of LED function. Some Chinese engineers deployed an approach more akin to Clive's - it was strange how many batteries "failed" quite abruptly ;-)
Way back in the 1970's, some American restaurants started using Muzak and uncomfortable furniture to increase diner turnover.
A friend of mine worked in a restaurant with door sensors that counted people as they went in and out to track approximately how many people were inside at any given time. If there were a lot of people, the lights got brighter and the music was louder. If the restaurant was mostly empty, the lighting and music were more soothing.
He reported that it actually worked pretty well. It was quite impressive for something designed before microcontrollers existed.
The circuit that counted customers as they came and went was not perfect, but the manager only needed to adjust the once or twice a shift.
Muzak was a subscription music service that provided environmental audio tailored for specific applications. I worked in a factory that played the _light industrial_ sound track. Fortunately, the employees could control the volume in most areas of the building.
I tried extracting few "tracks" (which are split by CB 80 sequence) - they indeed seem to be compressed (and possibly encrypted by simple XOR or something similar possible on such underpowered chip) as their entropy suggest, but neither VLC nor ffplay (from ffmpeg) can play it. Also tried to invert bits order in bytes to accommodate weird endians - but nope.
I recognise the language used here as English but….. 🤔😳. I’m feeling stupid now!
Shannon entropy is 7.872513892493156 (8 beeing the max and representing pure randomness)
So yeah, either compressed or encrypted
How do you know they are separated by CB 80? Yes, it is the start of the first block of data after the gap, but there appear to be more tracks than CB 80s going by the array at the beginning.
@@userPrehistoricman they are probably not, that is just the first 2 bytes of the "data".
It looks like its well compressed and then probably XOR'd but not with a single byte.
I have found these sequences throughout the data:
OFFS - DATA >> Size in hex (Size in Dec)
9700 - CB80BFF0 066772AA 6617F78A 3F440DC1 >> 058F44 (364356)
62644 - CB80BFF0 066772AA 6617F78B AF63545C >> F300 (62208)
71944 - CB81BFF0 066772AA 6617F79B D085AA98 >> CC7A (52346)
7e5be - CB81BFF0 066772AA 6617F79A DF445181 >> 0104d7 (66775)
8ea95 - CB81BFF0 066772AA 6617F79C 476A0BFE >> 63BB (25531)
94e50 - CB81BFF0 066772AA 6617F79C EB954B99
If you hexdump -C the file, you can see what appears to be a filesystem structure at the start. About offset 0x80 is the first entry. It looks like there are 39 valid entries. 0x600 might be offset of the first file or just random junk. About offset 0x700 is what looks like some file. But if you go forward you can see there some junk preceding offset 0x9700. So 0x700 is possibly a boot program and the first real file is 0x9700. I don't recognize the format, but that's not surprising since flash filesystems aren't my field. However, one dumb reverse engineering technique is to just dd with some increasing offset and running file on each extraction in hopes of finding something file knows about.
There is a chip called the isd1100 which RadioShack used to sell in the 90s. Needed no external memory and little support components. This could be a similar type of device with a longer play time then the seconds the 90s version had.
The chip could be bit banging the audio where it’s reading the info from the memory and reproducing it to the speaker. The chip does not know what it’s doing, just as instructed. The chip is not a specific audio chip
I used to use the ISD chips for the speech in my fairground games. Quite unusual with "analogue" memory.
Clive, any idea how many seconds / minutes of unique audio is in that thing, give or take? That probably would help us exclude a few audio compression streams off the bat.
Definitely a Jie Li/JL AC69XX MP3 player chip under this. Fun thing, these can play WAV files. Quite a feature packed chip!
At least the volume/on/off pot hasn't changed in 60 years that I can remember since the first one I ever saw in my sister's first cheap transistor radio. Some old technology seems to set to last until the end of time.
If it works why replace it? Cheap or throw away goods do not need quality.
Likewise my little red plastic radio from the past.
@Clive Please make a followup when someone smarter than me has decoded the file. I need to know. I also so want to replace it with my own storage solution.
As a Zen Buddhist who spent 3 years in monastary training to be a monk, I can assure you....
The lyrics for one of those songs, in their entirety, will no doubt by:
"Namu ami tabul."
,,,repeated at least a thousand times.
[Below the wrap text]
If you're curious about the nature of the universe, try chanting "Namu ami tabul" a thousand times on loop.
You WILL find it 'enlightening.'
There are many such chants. Another very powerful chant is "Owa tana Siam". Repeat this out loud 100 times and not only will you be enlightened, but the people around you hearing it will also be enlightened.
So now we're all enlightened. I would imagine that from a Buddhist perspective, that would amount to a huge success 😁
Big Clive's next up coming project: "How to 'un-blob' the 'Blob'".
This is definitely not just waveform data. It's been encoded with something very tight, maybe a gongkai'd greeting card chip. Sadly, I can't find anyone who's RE'd those codecs with quick googling.
😙👌
I managed to decrypt the start of the file. It has a bunch of filename and the audio files all have the .f1a filename extension, so if you have any ideas what that could be let me know!
I have a hunch that the audio data in that dump is pulse density modulation (PDM) rather than PCM or a compression codec; it is a digital representation of an analog signal rather than a true digital encoding. The reason for PDM is the low cost and simplicity of the playback circuitry - converting to analog is as simple as sending the raw encoded data as serial output (at the right clock speed) directly to a low pass filter and then an amplifier. This was used in a lot of toys in the 2000s like the HitClips, Furby, etc and still appears in various greetings card type devices. I might try my hand to see if decoding it in the same way as the HitClips data might work.
I'll take one, if we can figure out how to change the chants to Clive saying "Let's take it to bits", "Juicy lead based solder", and "Oh no, it's going to kill us all".....randomly switching between the 3.
You forgot "One moment, please" :)
@@mjrippe I knew I was forgetting a few! 😆
I would really like to know how much world economy would go down if we just cancelled all those pieces of garbage being produced ... I really have no idea how much that could be. (looking at you USB-Powered heating pad for hanger for the bathroom!!!!)
Dunno, but I bet the CO2 emission levels would go down 20% overnight!
it wouldn't go down, most likely. more of those things end up donated, garbaged, or in a car accident than get purchased. they have little effect on anyone except the workers putting the pieces together.
Not all of the songs on there are meant to be for meditation or relaxation - some are looping chants and prayers to be played near the coffin at funerals to "help" the deceased's spirit find its way to heaven. There are also tracks for various religious ceremonies. It's a great invention for those of us who can't afford to pay (or technically, donate) for monks to perform 3-day long live prayers at funerals.
Anyhow, great teardown vids from a longtime fan. Hope that explains some of the weird music on this device!
First thought on seeing the UA-cam thumbnail was that Clive was going to set fire to something. Second thought was maybe the AC adapter was dangerous enough to leave the device live somewhere. Sadly disappointed on both counts.
Re audio formats: dim & distant memory suggests that RLE encoding might be unlikely due to it not being efficient for compressing audio data (which is high entropy from the perspective of RLE). Other thoughts (also dim, distant and crusty) are whether the audio might be encoded using mu-law or perhaps something similar from the GSM telephony world: they’re astonishingly efficient, but at (great) cost in sample rate and resolution. Perfect for voice calls *and* cheap tat.
I have a dim recollection of these formats being in play pre-MP3 days on various Acorn computers too - again before the ubiquitous advent of perceptual coding and MP3.
As I read this back, I realise I may have dated myself somewhat…
Unlikely they would bother programing an MP3 decoder on a microcontroller chip. More likely to be a straight bit stream of some structure & timing. As for the file, there seem to be 32 byte long records at the beginning that could be the index to the locations of the different sound clips. There's also a section near the end of the file that runs through the lower 128 ASCII characters in a 16 bit format (padded by 00), so I don't think it's been encrypted with XOR.
Me love them when they have a Removable TF CARD - Micro SD Card and support 32GB
or a Re Programmable ESP 23 - or - ESP 8266
I know its a long shot and I only know some basics of electronics but is it possible there could be 2 chips under that blob?
Possibly. A processor and amplifier.
"I Took A Dump" - What? "Of Memory" - Ahhh.
There's some sort of TOC at the beginning of the bin.
The battery lid has 32 entries on it...
There's 32 (!) occurrences of 0xCB 0x80 char seq in the bin, each followed by a significant amount of data. Probably the audio 'files'. First occurrence of the sequence is right after an empty area @ 0x9700. Unfortunately google comes up empty on the sequence..
'i could be wrong' :)
I've run with that idea and split the file into the chunks between those CB80 markers. I can't see any repeated chunk signature like mp3 would have, so I tried having it interpreted as various kinds of PCM, but they all only come out as noise. I'm wondering whether some mathematically cheap compression like RLE might be in use here..
The thumbnail clip looks like it might be a 'Dame Edna' pair of glasses.
Definitely interesting to see how they keep the price down in these units, that speaker is the exact same found in musical greeting cards, I guess they’re so mass produced, they are probably less than a couple pennies a piece. I guess they splurged with this one, and gave it a speaker with a metal basket, must be the “premium” model lol. Also, the LED arrangement is rather interesting, I would have figured it would’ve been cheaper just to use one of the standard self changing RGB LEDs
The ones find in cards tend to be piezo buzzers, and that looks like a proper speaker, if a very weedy one.
It's probably the premium version - no expense spared by Clive!
That small flat speaker is what you’d find in a Chineseum crap, pocket radio or the speaker for those equally garbage cassette recorder/radio Walkmans
@@ianhosier4042 There is a 52 song version as well though paradoxically that seems to be cheaper!
That piezo device also makes a neat High-z mic.
This is the kind of thing that used to get circuit bent all the time,it's a shame boards are getting less complicated now so there are less contacts to jump for crazy noise.Id like to see a video on circuit bending sometime if you have any interest in it Clive,so much fun making electronic things make bizarre noises
That is one hell of a episode title
For the followers of Douglas Adams and Dirk Gently ... this is clearly an early version of an Electric Monk .... “... Electric Monks believed things for you ....” which, given the quantities of e-bilge slopping around the Internet, may turn out to be a useful tool. Thx Clive
The more advanced version also sprays you with holy water.
Source: I came across an electric monk while on vacation in Thailand a few years ago. Decided to try consulting it out of curiosity.
"Electric monk" also leapt into my few remaining brain cells. Also linear vs log pot triggers a tintinabulation.
This is a device used in Buddhism. They have become quite popular. If you were a Buddhist you would know at least the titles of the mantra's and what they are used for. This machine is used on a persons alter so the mantra is said 24/7.
Clive, Can you give us a clear detailed shot of the song list? I was able to use the google translate app to see "songs 39 in 1" in the first title line from the video footage here: ua-cam.com/video/LNpbvyLIvN0/v-deo.html But it's not high enough resolution for the rest. I'm thinking if we can convert the chinese text into UTF-8, we can port backwards to hex, and find the song titles in the data.
do you have the hardware to be able to sniff the data lines to see what it requests from the memory on power on, and what it does on song cycle - i'm guessing there is an offset list, or something being downloaded initially, and then something is being decompressed to actually pull the songs off, but this is only a guess
If it is 5V can an arduino be used to sniff?
@@kitecattestecke2303 in theory, yes. Though may be easier to get a pre-made sniffer sketch as I'm not sure how simple it will be to capture the data, or the arduinos speed or memory will cause issues
@@kitecattestecke2303 For a similar price to an arduino, you can get an 8-channel USB logic analyser.
@@userPrehistoricman That would be my go to, connect the track change switch to one of the channels as a reference marker then you can see exactly what happens on the data lines every time you press the button.
When I saw the title of this video, my first thought was that you'd had to make a dash for the smallest room halfway through filming...
A "flash dump" sounds in my mind like one of them flash-mob things, only they take a big ol' mass excretion instead of dancing... :P
They do this in San Francisco. Homeless people come out of the alleyways and just blow dump all over the sidewalk. It's very disgusting actually.
Group poop!
No that's called a stomp
That would be a UA-cam sensation.
@@baileyanderson6824 Defecation celebration.
They must be decoupling LEDs because they are connected in parallel with the supply, just like the filter capacitors are!
Don’t forget to put a decoupling resistor across the terminals of any dropper capacitors, to prevent people from getting a zing.
They are heater LEDs to keep the mosquitos warm.
Missed opportunity for a Highland Buddha!
You have to rig a flame device to it.
I am always impressed how you find these things.
Why bother with the time and presumably small bit of extra cost involved in adding an epoxy blob to this thing?
They probably converted it to a WAV audio file because it is just bare bones audio. Back in the mid 90's I could get 20/30 media files on to a standard 3.5 floppy drive.
I thought wav file bitrate varied? Edit: Hi quality wav files are 1411 bps so would hold less than eight seconds of audio. Reducing the bitrate likely contributes to the audio quality.
@@Scotty916 WAV is constant bitrate, but you can choose the bit depth and the sample rate yourself to end up with a low (but constant) bitrate. Many really old games used 8 bit, 11khz sounds for a low bitrate. Modern stuff generally uses the CD bitrate of 44khz, sometimes 48khz, and 16 bit.
@@mfbfreak a lot of the music I saved was full songs but in Kb file size, it didn't have a rich sound by any means.... Kinda sounded like a very low quality keyboard sound
Makes me curious what is under the blob. Wonder if there are any die markings.
Must be a centre piece on your next stream. The Budda Stream if you will.
Why didn't I think of that! 👍
Buddhist chanting always reminds me of my Father trying to get his Austin A40 started on a cold morning in the 1960s .
Crouching Tiger, Hidden harmonies...
the most interesting thing was for me is that they did not use a single RGB self-changing LED at the top...
Happy Saturday from Bonney Lake Washington
Well if it's something like MP3 compression, if it's 32kbit/s, you'd be able to fit about 8 minutes of music on that chip. 32 kbit/s is really on the low end of what's acceptable on a reasonable quality speaker system, but since that lovely piece of landfill really isn't one of those, I reckon you'll be able to get away with even less than that. Whatever encoding it is though, it probably isn't contained within a file type a PC would recognize.
MP3 isn’t really so much a file _type_ as it is a de facto file extension for a stream of raw MPEG frames. Frames are (more or less) independent units of a few ms of audio, each with its own short header sequence. If it actually is MPEG, then you can sever the stream anywhere you want and a player would lock on to the synch pattern at some point and begin playing until it ran out of frames to play.
MP3 files actually have tags and other metadata just haphazardly inserted at the beginning, end, and even arbitrarily in the middle of the file. As long as the non-MPEG data is between frames and doesn’t break one apart, it’s totally fine.
Ergo, if the data is really MPEG audio, then that synch pattern would tell you for sure, since it would happen every so many bytes.
I've always wanted you to do one of these and see how it works. Excellent video 😀
GOTTA HAVE MORE COW BELL !!!
"I've got a fever and the only cure is more cowbell"
It does need more cowbell.
Anyone still got an Acorn Archimedes? There was an audio player on it that would play anything even data 😩
I bet people are giving this toy way too much credit. to my ear it sounds like 1 bit audio where its structured to feed the bit stream directly into a speaker which acts like a low budget digital amp. You can confirm this by capturing the audio from output directly as data and comparing to the dump itself. I would do this if I had one of those toys to confirm this.
I think we will see a chanting Clive feature added to the air filter soon
How about dropping the blob in some formic acid?
I have only been watching your blogs for a couple of months but noticed that in most cases switching is on the negative/neutral. My training over the years has been that in the case of a.c. it is much safer/convenient to switch the live. Similarly switching the positive in d.c. was the norm. I am 79 years old so may be out of date but I am intrigued as to why the switching seems to me to be strange.
I can think of a couple of reasons. One is that most voltage regulators go on the positive. Usually a low voltage microcontroller ends up switching a higher voltage using a transistor. If the positive lines are at two levels, it is harder/unreliable to use a PNP or P-type to switch. The second reason is that N-type mosfets are smaller/cheaper for technical reasons and they go on the low side.
It is safer to switch the live in AC because neutral is referenced to ground and relatively harmless. Similar concerns don't apply for most DC devices which are usually low voltage anyway.
I find it funny that all Eastern Mysticism can be boiled down into a few circuits and resistors to produce a Buddha Machine. Switch on for Instant Enlightenment. well pretty lights anyway. LOL
Hey Clive I tried the file in various pieces of software like GoldWave audio editor and some programs such as MFAudio that I use for converting audio files from console video games. All I got was static. I loaded the file in a hex editor but I'm not good at that hex editing type of stuff. Bunch of random characters on the right. I know many chip devices use a programmer that converts the audio to a proprietary format. I have a paper jamz microphone that does this. Songs are converted to an internal format then loaded on the device.
If it was possible to reprogram these then I would buy one just to do this. Maybe put some smells like teen spirit on it, and maybe some of my farts.
Actually a pretty neat device for $23.74 or best offer with free shipping from China!I might buy one just because!
2:03 Our generation had Boom Boxes. This one has Buddha Boxes ...
Will have to take a look at the file
Looks like they used a linear pot for the volume instead of a logarithmic one. Also - you should put death metal on these and resell them :p
Clive should do one of those "Wired" videos explaining Batman's belt equipment.
Had a quick look at the ROM dump, but couldnt find anything very familiar. The beginning looks like some sort of table, describing the contents and their locations. Binwalk hasn't returned anything.
I figured out partly how to decrypt it and got a list of filenames, offsets and sizes out of it but it looks like the files themselves are similarly encrypted with a slightly different XOR algorithm. I posted the code on the Reddit post for this video, but I can't post a link here or my comment disappears.
@@Malvineous0 That's awesome! So they did just XOR it?
@@nrdesign1991 They did for the start of the data. The code that follows (the "code.app" file) uses a slightly shorter key, so I'm not sure whether the audio is encrypted or not but if it is I'm sure it'll be another variation on the same XOR cipher.
@@Malvineous0 Fascinating. I ran your code to try for myself and it indeed decrypts the file headers. I wonder how you got the key, by brute-forcing? 32 bytes are already quite a lot to do entirely by hand.
@@nrdesign1991 I did it by guesstimation, trying a few things that didn't work and gradually narrowing it down.
First I figured that a lot of the repeating bytes were probably 0x00 so I picked some keys that turned those bytes to 0x00. This didn't work but the other bytes all looked inverted so I tried XORing the whole thing by 0xFF first, and this worked - those bytes that I thought were 0x00 were actually 0xFF and some parts of the filename were revealed. I saw they were dots with three letter extensions and terminating nulls, so picking more values for the key bytes to get the nulls and dots to appear in some filename entries, revealed more parts of the filename in other entries, confirming the key bytes I had chosen were correct. Then it looked like the first field was an offset so I picked more key bytes that produced the offset I expected for the first file, then I had a look to see if the other file offsets seemed right and they were. Using the offsets I could calculate the file sizes and that gave me cleartext values for the next field so I could select more key bytes that produced those values, then I assumed the single incrementing byte was an index marker and sure enough picking a key to turn it into numbers starting from 0 also revealed the first line of data had the total file count in that position. I kept going like this until all the values looked right.
But it means the key I came up with is probably not 100% right, as there are some values in there I am not sure about. I am hoping that by looking at the mostly-correct key it might become clear what algorithm was used to generate it, because reimplementing that algorithm will produce the correct key and a fully correct decryption.
What happens if you just take the 8 bit data and chuck it through a DAC? I am thinking the simplest way to encode music is simply to sample it (admittedly at a crappy low sample rate - maybe 4 or 8kHz) then dump it onto a serial rom chip then use a DAC to play it back. I just can't see that blob containing the SOC and firmware that would be required to decode compressed data streams but a clock generator, counter to poke the address into the rom and a DAC I can see. Odd how they don't use one of the self colour changing LEDs that are as cheap as chips these days
It's pure and extremely even white noise.
@@hjalfi weird, direct sampling would have been the cheapest way to encode the sound. Unless it uses some crazy way to address the rom or some weird way to encode the bytes to stop copying. Why someone would bother to copy that crap quality music eludes me
@@ianhosier4042 Direct sampling would have been the simplest, but even at 4 bit audio (which would be unlistenable) it takes say too much space. Long ago the phone companies and military came up with very simple compression methods that could get about 12 bits of audio quality out of 4 or 5 bits of actual data. It still sounded awful, but was good enough for voice communications if you have good ears. That method was to just record the difference in level between two samples rather than recording the actual sample levels.
You definitely have to compress it to fit anything more than a few seconds on there. I managed to decrypt the first part of the dump which revealed a bunch of filenames. The audio files all have the filename extension .f1a which I have never heard of before, so if anyone has any idea what that could mean...
You could quite easily add a bottom half to this thing and slap a couple coats of paint on there and make a Holy Handgrenade.
It would be rather amusing to overdub the music with some "naughty" chants, and then switch the unit with another one that's in use somewhere. Just the way my mind works! We need a clever viewer to crack the file format first.
Made in Buddhapest, Hungry
Just the look of the thing in its Gordy gold paint for some reason triggers a desire to paint it silver. I definitely could not reach a meditative state looking and listening to that thing. The teardown was interesting though, Thanks Clive
I found that confusing until I realised that "Gordy" probably means 'gaudy'?
Could be one of the apple AAC+ codecs... possibly AAC+64 or AAC+128 at 16 or 24 kbps mono from iTunes pro or apple pro audio desktop app.
And if the dynamic range is shortened from 20Hz-40KHz to like 150Hz-8KHz and converted to mono before hand it could be crammed into AAC+64 at 16kbps mono.
The behaviour of the volume control might be because it's a high resistance compared with the speaker.
More probally because its a linear pot, we don't record or listen in a linear fashion so should realy be a log pot or often called 'audio taper' as the resistance increases decreases in a logarithmic way...probally.
@@andymouse If you connect a speaker directly to a pot then the value of the pot has to be similar to the impedance of the speaker. The speaker might be 8 ohm and the pot 1k. That would give this effect. This I've learnt in 65 years of playing with electronics!
@@OC35 Probally, first thing that sprang to mind was log/lin...cheers.
That's pretty fascinating.. I wonder what would happen if it had a better speaker and added a amplification circuit (maybe even synth sounds) between the module and the new speaker o.o...
Either way, that's a neat little device, cheers for the share!
That was my first thought. What'd happen if it was hooked up to an amplifier and some quality speakers?
I have no idea what 90% of what you're saying means, but it's really entertaining. I might actually even be learning something....however slowly lol
I think I'll hold fire for the Elvis version.
with the LEDs clive does the blob chip control them or are they the slow fade color changing?
Blob.
Hahaha you dumped the .bin freaking great.
Buddha on par with musical greeting cards.
I love the deeper stuff!
Much love!
Could the weird response to the volume control be caused by using a linear potentiometer instead of a logarithmic one.
Or the other way around...
Yeah, doubt they would spring for an audio taper pot !
Since it has been wired in series with the speaker, I suspect the problem is a combination of using a log pot and being too high a value. Most of those little thumbwheel pots I have seen are in the 4k-10k range, so unless the speaker has a very high impedance then only the last few degrees of movement are going to let through enough current to make any appreciable noise.
Other way around. Log pot intended to be placed before the output stage but instead connected directly to the speaker - mismatched impedance. These on/off/volume pots are intended for audio applications, so almost always log2.
@@Chrisamic cheers.
Fantastic. I so want to take the audio from that and play it very loudly through a PA horn 🤭🤣
You do for a living what ive always done.
REVERSE ENGENNERING ELECTRONICS and others objects
A curious man! Just like me!
Destroying stuff to know What is going on inside !
Im reparing almost everything broken nowadays, Because of that Perpetual Question i ask to myself all the time :
Why/how Does it work!
I love that channel. So much fun to watch during my Own Projects!
Likewise.
Almost makes me want to make a knockoff that plays some relaxing deathcore.