This is not malware because it just loads to the homebrew launcher, also I made an error with the upload because I uploaded the wrong filedidnt download it cus most people saying there is no banner changeand its bigger than the og launcher is this the next 3ds malware anyways people would download it if it was a cia format
It's not a boot.3dsxVoted no, because I don't use 3dsx'es
Yeah but its purpose is to run a 3dsx lolIt's not a boot.3dsx
I might make a sequel were it IS a 3dsxYeah but its purpose is to run a 3dsx lol
Well yeah, duh. It was compiled from a different person and with a different libctruWARNING: CRC-32 hash and size comparison between [hblauncher_loader_v1.3] vs [weebrew launcher] decompressed code.bin does NOT match. Need followup and more clarification from OP.
@weebrew, you said this was a banner and icon only re-skin. Did you use an older version of Homebrew launcher?
I'll update this post checking against this to HBL v1.2 , v1.1 , and v1.0 cia. For the time being, please reframe from downloading.
Edit 2 - I cannot verify any of the 4 available versions of Homebrew Launcher matching in hash and size against Weebrew Launcher.
Well yeah, duh. It was compiled from a different person and with a different libctru
I did a hash cross comparison check for the files between the Weebrew_Launcher_Loader-1.0.zip and Weebrew_Launcher_Loader-1.1.zip source codes.
All the files in both sets are the same except for:
Weebrew_Launcher_Loader-1.0.zip [898F5B95]
Weebrew_Launcher_Loader-1.1.zip [940F93C0]
- Build.bat - batch script that automates compiling, except it doesn't work as you forgot the makerom.exe in this release.
- Weebrew-Launcher.cia - prebuilt CIA in question (can't confirm it's status) [82BEF778]
- Weebrew-Launcher.elf - precursor file before CIA conversion (also in question) [421AF79D]
- Weebrew-Launcher.smdh - prebuilt icon
[source] - https://github.com/weebrew/Weebrew_Launcher_Loader/releases
- Build part 1.bat - replacement batch script that automates the Make file for source code compiling.
- Build part 2.bat - replacement batch script that automates the makerom process creating the CIA.
- makerom.exe - the provided tool that creates CIA files [DA35D4FC]
***
Let's take a step further in cross comparing against those in hblauncher_loader-1.3.zip source code.
hblauncher_loader-1.3.zip [A3E0EC54]
Files with the same hash and name in both WBL v1.1 and HBL v1.3
- ISSUE_TEMPLATE.md
- Makefile
- builtin_rootca.dr
- hblauncher_loader.c
- start.s
Files with same hash but different names
- [HBL] hblauncher_loader.rsf // [WBL] cia.rsf
Files unique to Homebrew Launcher
- hblauncher_loader.cwav - converted .wav for banner audio
- banner.png - self explanatory
- icon.png - self explanatory
- README.md - boring stuff
Files unique to Weebrew Launcher
[source] - https://github.com/yellows8/hblauncher_loader/releases
- banner.bin - premade banner for CIA compiling
- banner.png - WBL green theme banner (raw source)
- banner.wav - banner audio with a mario mushroom powerup and chu 3x times.
- icon.png - the blue haired chick
- README.md - boring stuff
- Build part 1.bat , Build part 1.bat , and makerom.exe - already mentioned before
***
Let's try compiling each with two attempts to ensure hash accuracy. Source code folders deleted and unzipped fresh.
- hblauncher_loader-1.3.elf [A3E6A8BA]
- Weebrew_Launcher_Loader-1.1.elf [45D6B92A]
Hmm, that doesn't seem right. Maybe it's because source code folders are named different? Yah, that must be it! I'll just rename Weebrew_Launcher_Loader-1.1 as hblauncher_loader-1.3 . In fact, I'll switch the names for both just to super sure.
- hblauncher_loader-1.3.elf - sourced from Weebrew Launcher with its folder renamed [A3E6A8BA]
- Weebrew_Launcher_Loader-1.1.elf - sourced from Homebrew Launcher with its folder renamed [45D6B92A]
Okay, so folder name affects hash when compiling. You're almost in the clear. Double click that Build part 2.bat script and all misunderstandings will be - but wait!
***
Remember that makerom.exe from earlier? Let's check its hash [DA35D4FC] against those provided by profi200's Github Project_CTR repository.
[source] - https://github.com/profi200/Project_CTR/releases/
makerom_015_ctrtool.zip [74CE5D43]
makerom_014_ctrtool.zip [7A8CB8F2]
- makerom.exe [3AB8CC38]
makerom_013_ctrtool.zip [0D35DD78]
- makerom.exe [A8A467A0]
- makerom.exe [128286A5]
Maybe you compiled that makerom.exe yourself or obtained a copy found elsewhere? Perhaps, I'll substitute the four makerom files as control variables. In any case, I can't verify CIA outputs, hashes, and decompressed codes as this is as far as I got.
Homebrew dev is tricky business.
If you are so suspicious of him, why don't you just reverse the provided binaries ? Currently, those accusations are baseless, clueless, but most importantly, pointless.
You won't be able to post links until you hit above a post limit, this is an anti-bot measure. You can however upload the source to the OP, which would have been suggested.@TurdPooCharger @Lilith Valentine
For some reason I was not able to put in he link to the github page, sorry about that , but thank you for posting the github link!
wow.. is this really necessary? Seems like you're making more work out of it to prove something 'may' be wrong, than the guy did to change colors and a banner..
I kinda start to feel bad for the guy trying to share some of his work.. with his source provided..
If you find somethings IS wrong.. let us know.. but now this thread is cluttered with negative speculation..
Considering the fact that there are parts of the source code missing and binary blobs that don't add up, there's something to be concerned about. It could be possible the the OP just doesn't know how to properly work their code, but they should have included all the changes and not just the changed binary blobs. If we don't know what's in these blobs, then we need to treat them with skepticism until we do.If you are so suspicious of him, why don't you just reverse the provided binaries ? Currently, those accusations are baseless, clueless, but most importantly, pointless.
I have not seen a single proof of evidence about anything. There are much better ways to prove someone's intentions than this kind of clueless conjecture. Open the executable in some disassembler and look for yourself, if you care so much about evil.
Which is understandable, but doesn't need to be done with baseless accusations. I would think that the author clearly seems to not understand very well what they're doing, considering the built binaries in the repository, the poll on this thread and the fact that this is only a banner/icon change.Considering the fact that there are parts of the source code missing and binary blobs that don't add up, there's something to be concerned about. It could be possible the the OP just doesn't know how to properly work their code, but they should have included all the changes and not just the changed binary blobs. If we don't know what's in these blobs, then we need to treat them with skepticism until we do.
It's not really baseless, he's trying to understand issues that seem a bit off and hopefully get to the handle on these issues. Personally I suggest the OP upload all the changed files to their repo and work with the skepticism.Which is understandable, but doesn't need to be done with baseless accusations. I would think that the author clearly seems to not understand very well what they're doing, considering the built binaries in the repository, the poll on this thread and the fact that this is only a banner/icon change.
wow.. is this really necessary? Seems like you're making more work out of it to prove something 'may' be wrong, than the guy did to change colors and a banner..
I kinda start to feel bad for the guy trying to share some of his work.. with his source provided..
If you find somethings IS wrong.. let us know.. but now this thread is cluttered with negative speculation..
If you are so suspicious of him, why don't you just reverse the provided binaries ? Currently, those accusations are baseless, clueless, but most importantly, pointless.
I have not seen a single proof of evidence about anything. There are much better ways to prove someone's intentions than this kind of clueless conjecture. Open the executable in some disassembler and look for yourself, if you care so much about evil.
Here is the thing,it can not really be the same file from your compile because I have other lib's installed and I may have installed an older version of devkitpro but don't worry because I just updated it. Also I used windows 10.Look, I know it sucks to be looked at under a microscope. My intent is not to harass @weebrew and tell him or her to stop his/her homebrew project. In fact, I'm trying to vouch for that person's sake because he/she is new here and has no reputation or previous works to rely on or show to us. Do you take someone words at face value if no one knows that person or can rep for them?
When he or she first posted on this thread, (s)he originally shared a single CIA file with no source code to back it up. Without anything to go by before then, the best I could do was hash compare the decompressed code.bin files between Weebrew Launcher and Homebrew Launcher. Because none of them matched, I made the reluctant decision to sound the alarm until further followup could be done in verifying Weebrew Launcher is indeed a safe and sound 3ds app.
Now since that GitHub page was shared, I want to ensure that the source code when compiled does match the provided weebrew launcher's cia. I'm not able to do this on my end as I believe my Window's devKitPro still doesn't work right. Maybe the Linux version of devKitPro will work better. Someone who does have a properly setup devKitPro, please chime in so we can settle this.
Then you haven't been following this thread very closely.
Even if I had a complete grasp of ARM assembly language (which I absolutely do not) and looked at the CIA under IDA Pro, this requires massive amounts of reverse engineering on the user's part to determine if any bits of code shouldn't be there. All of this can be missed if either IDA Pro doesn't pick up finding sub functions or you (the person who's doing the dissembling) absolutely cannot identify the exact nature of a specfic function found in an offshoot program differing from its parent.
That's why programmers will always go right to the source code if one is provided and not work your ways backward.
***
In case anyone doubts that 3DS homebrew can't be used for malicious means, let this be a history lesson for those who missed this. The concern for new projects and their safety status is not without merit.
Remember: Not everyone can build it with the exact hash and all that stuff because my setup is different from his setup, I also have other lib's installed. If you ever question about the code, please go to https://3ds.hacks.guide/ homebrew discord server because that is were I got help for different things. Don't rely on other gbatemp users because they may not understand, not to be rude or anything.@TurdPooCharger if you have the ability to compile 3DS homebrew stuff please compile from source and report whether it matches the download in the OP.
This is my first time doing this, I may get things wrong with the source code. I even uploaded the wrong files on some of them.You won't be able to post links until you hit above a post limit, this is an anti-bot measure. You can however upload the source to the OP, which would have been suggested.
Do understand that our comments are nothing personal towards you nor your work, we've just had people unload malicious re-skins of homebrew before.
Considering the fact that there are parts of the source code missing and binary blobs that don't add up, there's something to be concerned about. It could be possible the the OP just doesn't know how to properly work their code, but they should have included all the changes and not just the changed binary blobs. If we don't know what's in these blobs, then we need to treat them with skepticism until we do.